Why create cloud native applications? In the cloud, nothing else even makes sense

Cloud native? What is it anyway?

It is a set of recommendations, how to build an application to get the most out of the cloud. Cloud native applications save their owners money. And in combination with PaaS operations has less support work to do, so it can focus on more important tasks.

Let's show the effect of using cloud native applications by using the example of running a web application on a VM (group of VMs) and running an Azure web app service with a load balancer (or better, an application gateway with a WAF).

Comparison of normal and cloud native access

In the first case, we need one VM for reverse proxy, which will filter requests, act as an application firewall, terminate SSL and last but not least balance between backend servers. The backend servers will "run" some IIS or other webserver. And you have to patch all of this, monitor it, and scale it somehow in case of performance issues.

For web servers, you add an instance (if the web application allows it), and for reverse proxies, you may need to add system resources or use another technology. Not to mention possible downtime due to system maintenance.

Unless, of course. you use IaaS, you don't have to worry about any of that. If you set up auto-scaling properly, you will scale both the web app service and the application gateway. Even your certificate can renew itself before it expires.

This is just a simple example that doesn't even take full advantage of cloud native apps. However, it shows that the right approach can save money and human work in the cloud. So how to create cloud native applications?

Basic recommendations for creating cloud native apps

We are used to build/write/support 2/3layer application. They have their advantages, of course: for example, everyone can write them, their performance can be easily scaled vertically, and deployment is typically done by installing a package on a virtual machine(s).

For example, their scheme looks like this:

Bottom line - don't be surprised if your hired consultant tells you that the application is not well written and it needs to be rewritten 🙂

How do you do that? Find out briefly in this article or on the website Cloud native computing Foundations.

Microservices

In contrast, an application designed as Microservices (microservices). Its individual functions run in their own containers and communicate with each other using a message broker. Such an architecture brings many advantages in development and operation.

Easier testing

In terms of development you will appreciate the possibility of easier testing. You solve the dependencies for each container separately, and it is therefore easier to make changes in the application code.

Operational advantages

In terms of traffic you will appreciate the horizontal scaling, error resilience and fast and unattended error recovery.

As a consequence of these benefits, your approach to running these applications will change. This is nicely described, for example concept of pets vs. livestock.

Monolithic applications or even on-premise servers are such pets for us - we take care of them, treat them and they give us something in return. We have an emotional attachment to them. When they don't give us enough, we get a bigger pet.

In contrast, microservices and other cloud resources are "livestock". As long as they give us eggs and milk - fine. Once they stop, we just kill them and replace them.

If they just give eggs and not enough milk, we increase the herd of cows or flock of hens (add an instance) and vice versa. Adding/removing instances is of course automatic if set up correctly. This is called self-healing a auto-scalling.

Technological separation of individual services

Services belonging to the same application can be written in different languages, maintained by different teams, and communicated using APIs.

It often happens that the application is built from existing open-source projects and is only properly linked to get the desired result. In this case, we are usually helped by various DevOps tools such as Azure DevOps, GitHub, Gitlab and so on. Which of course we save on development and accelerate it.

Summary of the benefits of microservices

1. Scalability
   By scaling individual microservices independently, we can respond to user traffic growth more efficiently. We can scale only those microservices that are experiencing increased load. The consequence is resource savings and higher application performance.
2. Flexibility
   Thanks to the independence of individual microservices, it is possible to make updates, fixes and deploy new features without affecting other parts of the application. This enables faster development and deployment of the application.
3. Resilience
   When one microservice fails or malfunctions, other parts of the application can operate normally. You just need to replace the instance. This results in higher application availability and resilience.
4. Technological independence
   Each microservice can be developed and deployed in different technologies or programming languages.

Cloud native application development by 12-factor apps

Probably best describes the development of cloud native apps 12-factor apps methodology, a set of 12 rules for cloud application development defined in 2011 by Heroku. Following them allows you to develop quickly, scale applications horizontally as needed, and add functionality without having to retest the entire application.

1. Codebase
   Use one common code repository for all deployments. Deployments may use different versions of the code.
2. Addictions
   Do not rely on system libraries or applications. Declare all dependencies explicitly and for each service separately.
3. Configuration
   Store application configurations, access data, and other values that vary from deployment to deployment outside the code, ideally in environment variables.
4. Backend services
   Think of backend services as connected resources. If you need to change the resource, you only change the handler and the application code remains the same.
5. Build, release, run
   Strictly separate the build, release and run phases. For example, it must not be possible to change code while the application is running.
6. Processes
   Run the application as one or more stateless processes. The process must be able to be replaced without data loss. Microservices - wink, wink...
7. Port assignment
   Expose services using port assignments. Individual application components also communicate using port assignments.
8. Parallelization
   Scale individual processes horizontally.
9. Removability
   Maximize robustness and scalability with fast startup and correct process shutdown. Ideally, the execution of a request (starting, stopping and running the process) should be handled within seconds. This minimizes the risk of crashing the entire application.
10. Matching dev/sales
    Keep the development, staging, and production environments as similar as possible - whether in terms of code (a different branch may be), services used, or personnel. It is also inappropriate to use so-called lightweight services in the dev environment - despite the use of resource handlers, there may be minor incompatibilities that only become apparent in production.
11. Logos
    Consider the logs as event streams and direct them to STDOUT. The application does not handle the log processing, that is handled by the runtime environment. In different deployments, the logs can be handled by a different system independent of the application, allowing us to have better portability.
12. Administrative processes
    Run admin tasks as one-off processes that will also meet the 12-factor apps. This means that their code is present in the codebase, they have strictly decoupled dependencies, and so on.

You will have noticed that by using microservices you meet most of these rules. The remaining rules are more like recommendations on how to handle code and deployment. Which DevOps can help us with.

DevOps

DevOps is currently very inflated how to create and support applications. It combines two different teams into one - developers and operations. And it puts a lot of emphasis on sharing information within and between teams.

With this synergy we achieve faster application deployment a greater product quality.

The main reasons to use DevOps are:

1. Speed and scalability
   The cloud environment provides the ability to quickly deploy applications and scale the infrastructure according to current needs. DevOps processes coupled with the cloud enable easy and efficient implementation of changes, leading to faster application development and deployment.
2. Reliability and stability
   By automating testing, deployment and monitoring, higher software quality can be achieved. By using cloud services that offer scalability and redundancy, downtime can be minimised and application availability can be ensured.
3. Efficiency and cooperation
   DevOps in the cloud promotes strong collaboration between the development and operations teams. Automated processes, shared tools and transparent communication enable efficient use of resources and achieve goals with minimal errors.
4. Flexibility and agility
   The cloud environment provides flexibility for the development team to quickly deploy new features and experiment. Infrastructure as Code enables automation of infrastructure management and rapid replication of environments.
5. Monitoring and feedback
   Cloud services provide tools for application performance monitoring and data collection. This allows you to react quickly to potential problems and get useful feedback for improving your application.

The topic of DevOps is covered in more detail in a separate article Cloud Encyclopedia If in the cloud, then DevOps. Why?.

Create cloud native applications

Using the example of animals, we have shown what the use and creation of cloud native applications can bring us. If you're running an application written the old-fashioned way and you're not having problems with it, you need to make a good calculation about whether it's worth rewriting such an application.

Unless you are writing a new application or your application has reached the point that it needs to be rewritten from the ground up anyway, it doesn't make sense not to use a cloud native approach. Demand it of your suppliers and subordinates, it will pay off.