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

Developers today can develop applications directly for the cloud. In practice, however, they usually offer the customer a ready-made solution so that they don’t have to rewrite the application to be run in the cloud. But by doing so, they increase the application’s operating costs and often reduce its performance. In this article, we’ll discuss why it pays for application owners, managers, and the like to use only cloud-native applications in the cloud.

 

Cloud native? What is it anyway?

It’s a set of recommendations on how to build an application to make the most of the cloud. Cloud native applications save their owners money. And when combined with PaaS, operations faces less support work so they can focus on more important tasks.

Let’s show the effect of using cloud native applications by taking 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 cloud native application and common approach

In the first case, we need a single VM for a reverse proxy that 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 probably have to add system resources or use another technology. Not to mention potential downtime due to systems maintenance.

However, if you use IaaS, you don’t have to worry about any of that. With auto-scaling set up 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 the capabilities of cloud native apps, but it shows that by taking the right approach, you can save money and human labor in the cloud.

So how do you create cloud native applications?

 

Basic recommendations for creating cloud native apps

We are used to building/writing/supporting 2/3layer apps. They have their advantages of course: for example, everyone knows how to write them, their performance can easily scale vertically, and deployment is typically done by installing some package on a virtual machine/machines.

For example, their schema might look like this:

However, as already mentioned, when deploying and running such a monolithic application in the cloud, we basically throw away most of its advantages. When making modifications, we then run into the complexity of the application, which increases costs. If one component is unstable, the whole application will crash.

Bottom line – you can’t be surprised when a hired consultant tells you that the application is not well written and needs to be rewritten 🙂

How to do it? You can find out briefly in this article or on Cloud native computing Foundations website.

 

Microservices

In contrast, applications designed as microservices stand in contrast. 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

From a development point of view, you will appreciate the possibility of easier testing, because you solve dependencies for each container separately, and therefore it is easier to make changes in the application code.

Operational benefits

From an operational perspective, you’ll appreciate the ability to scale horizontally, the fault tolerance, and the fast and unattended error recovery.

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

Monolithic applications or even on-premise servers are like pets to 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 "farm animals". As long as they give us eggs and milk, fine. Once they stop, we just kill them and replace them.

If they just don’t give enough eggs and milk, we increase the herd of cows or flock of chickens (add instances) and vice versa. Adding/removing instances is, of course, automatic when set up correctly.

This is called self-healing and 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 is not uncommon for an application to be built from existing open-source projects, and only properly linked to get the desired result. In such a case, various DevOps tools such as Azure DevOps, GitHub, Gitlab and so on are usually helpful. Which of course saves on development and speeds up development.

Summary of the benefits of microservices

1. Scalability: independent scaling of individual microservices makes it possible to respond to user traffic growth more efficiently. Only those microservices that experience increased load can be scaled, resulting in resource savings and improved application performance.
2. Flexibility: thanks to the autonomy of individual microservices, it is possible to make updates, fixes and deploy new features without affecting other parts of the application. This allows for faster development and deployment of the application.
3. Resilience. All that is needed is to replace the instance. This results in higher application availability and resilience.
4. Technology independence: each microservice can be developed and deployed in different technologies or programming languages.

 

Cloud native application development by 12-factor apps

Perhaps the best way to describe cloud native app development is the 12-factor apps methodology, a set of 12 rules for cloud native app development defined by Heroku in 2011. Following it allows you to develop quickly, scale apps horizontally as needed, and add functionality without having to retest the entire app.

1. Codebase: use one common code repository for all deployments. Deployments may use different versions of the code.
2. Dependencies: do not rely on system libraries or applications, but declare all dependencies explicitly and for each service separately.
3. Configuration: store application configurations, credentials, and other values that differ from deployment to deployment outside the code, ideally in environment variables.
4. Backend services: consider backend services as connected resources. If you need to change the resource, you only change the handler and the application code itself 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: Individual application components also communicate using port assignment.
8. Parallelization: scale the processes horizontally by using the port connection.
9. Removability: ideally, the execution of a  request (starting, stopping, and running the process itself) should be handled within seconds. This minimizes the risk of crashing the entire application.
10. Dev/Prod Consistency: keep the development, staging, and production environments as similar as possible – whether in terms of code (different branch may be), services used, or personnel. The use of so-called lightweight services in the dev environment is also inappropriate – despite the use of resource handlers, minor incompatibilities may occur that will only become apparent in production.
11. Logs: consider logs as event streams and direct them to STDOUT. The application does not handle the processing of the logs, that is handled by the runtime environment. In different deployments, the logs can be handled by another system independent of the application, which will allow for better portability.
12. Administrative processes: run administrative tasks as one-off processes that will also conform to 12-factor apps, meaning 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. That’s what DevOps can help us with.

 

DevOps

DevOps is currently a much talked about way of creating and supporting 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. This synergy results in faster application deployment and higher product quality.

The main reasons to use DevOps are:

1. Speed and scalability: the cloud environment provides the ability to rapidly deploy applications and scale the infrastructure according to current needs. DevOps processes coupled with the cloud enable easy and efficient deployment 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 leveraging cloud services that offer scalability and redundancy, downtime can be minimized, and application availability can be ensured.
3. Efficiency and collaboration: cloud-based DevOps promotes strong collaboration between 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: a cloud environment provides flexibility for the development team to rapidly deploy new features and experiment. Infrastructure as Code enables automation of infrastructure management and rapid replication of the environment.
5. Monitoring and feedback. This enables rapid response to potential problems and useful feedback for application improvement.

We cover the topic of DevOps in more detail in a separate article Cloud Encyclopedia When in the cloud, then DevOps. Why?

 

Create cloud native applications

Using the example of animals, we have shown what using and creating cloud native applications can bring. If you’re running an application written the old-fashioned way and you’re not having problems with it, you need to do the math to see if it’s worth rewriting it.

However, if 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. Require it of your suppliers and subordinates, it will pay off.

This is a machine translation. Please excuse any possible errors.