Gone are the days when most IT companies had their own physical data centers. On-premises infrastructure is no longer a prerequisite for running a successful IT business. Cloud data storage and hosting has become so routine you barely even give it a thought. More often than not, customers expect your app to be hosted in the cloud because they associate it with less downtime, speedy work and reliability.
However, when considering cloud infrastructure, there is a big difference between cloud-native and cloud-enabled applications. You can make a monolithic app work in the cloud, but it doesn’t mean that it will solve all the potential issues this app might have due to the way it was designed. Only apps built according to cloud-native architecture principles can fully embrace all the advantages of the cloud.
Cloud - what is it?
Cloud-native architecture is a way to design apps for optimal performance in the cloud. But what is the cloud? Usually, when we speak of keeping something in the cloud, we think of storing data on a remote server maintained by a provider that specializes in this kind of service. But there are actually three service models in cloud computing that aim to achieve different business goals. These models include:
- SaaS - software as a service
- PaaS - platform as a service
- IaaS - infrastructure as a service
The main idea behind all three models is the same: instead of acquiring your own hardware, you choose someone else to house and manage it and simply pay for using exactly as many resources as you need. But since SaaS presumes you will also be using the software someone else has already built, it is the PaaS and IaaS models that play an especially important role for cloud-native architecture, along with a number of other principles that we will review in this article.
Why go cloud?
Hosting your application in the cloud has significant benefits, even if it is a monolith. As opposed to hosting on-premises, you avoid multiple responsibilities, like keeping the hardware and software up-to-date, finding specialists to manage your data center, and keeping an eye on available resources. Going to the cloud removes the need to even pay rent for the space where your servers would live if you kept them on the premises. And that is just one of all the ways you can save money with the cloud.
Security is another headache you won’t have anymore. Cloud infrastructure usually comes with top cybersecurity experts who monitor the data centers with special software around the clock.
With your application in the cloud, the uptime is guaranteed to be much better. Your app will remain accessible for your customers at all times. And if your client base increases, you won’t even have to think about getting more servers. In the cloud your app can scale up automatically when any part of it requires more resources. Of course, if your application is monolithic, there is only so much you can do to scale it up, even if you put it in the cloud. To get the best out of everything that the cloud has to offer, you need to consider cloud-native architecture for your app.
Why cloud-native?
It might seem that an app’s architecture is not that important: just get your app in the cloud, and your life will become easier. Acquiring managed services from cloud providers might indeed remove some of the strain of everyday management even for a monolithic application. But in the end you will discover that all the problems that an app built traditionally might encounter are still there. Cloud-enabled apps can never be as resilient and scalable as the modern customer needs.
Choosing to design your app according to cloud-native architecture principles moves you to the next level and makes everything better, from the quality of your code to the user experience. Cloud computing has capabilities that only a cloud-native app can truly embrace.
The benefits start with the freedom to design each component of your app as an independent service using whatever programming language or framework your team deems best. They also include true independence from hosting, since you can switch between cloud services vendors as you see fit and choose what works best for your business out of the multiple available public, private, or hybrid clouds.
Cloud-native architecture components
The main idea behind introducing a cloud-native architecture methodology into the software development process is solving issues that a more traditional approach cannot. An app designed as a monolith, with a single codebase and long development cycle, can be pushed to work in the cloud but that won’t make such an app scalable, resilient and easy to update and maintain. There are certain elements in the cloud-native app design that you should consider from the very beginning of your project. These components are what makes cloud-native architecture so powerful. Let’s review them in more detail.
Microservices
One of the most important principles of building a cloud-native app is to move away from monolithic app design. That is why you can sometimes see cloud-native architecture equated to using microservices. Developing an app as a set of smaller, loosely-coupled, independent elements is indeed one of the basics of cloud-native methodology. However, microservices are just one of the core components involved, so cloud-native architecture is a wider term.
The reason why microservices are so important is that they ensure your application’s agility. You build an app as a number of services, each of which has a number of specific traits. Each microservice is designed, developed and deployed independently, owned by a small team, and communicates with other services using APIs to work together as an app. Microservices are highly maintainable and testable. You can use different technologies, and preferably separate teams to work on each service, which promotes using better, more suitable solutions and shortens development time.
Each microservice works to fulfill a specific business task, but thanks to being only loosely coupled with other elements, if one service stops working, the rest of the app will not go offline. This also allows your team to add new functionality or update existing features safely.
One of the best things about microservices is that you don’t need to use the same stack for each of them. Each component can be implemented through a different framework or technology, if that particular solution works best for the specific goal the service needs to achieve. Having separate independent teams work on different services facilitates faster development and shorter time to market. It is easier for the developers to choose the stack that will be the most effective for certain functionality when they need to only solve a specific problem, instead of looking for a solution that should work for the whole application at once.
APIs
Although microservices work as autonomous units, they have to communicate to ensure the application functions as planned. Cloud-native apps typically use lightweight declarative APIs (application programming interfaces) to exchange data between microservices. To successfully organize the communication between components using a declarative API, you only need to know the endpoint and what exactly you want to do with it - there is no need to understand the whole backend architecture.
Furthermore, the system itself can decide how to achieve a certain end state, you just need to specify it, instead of manually configuring all the API attributes. That lowers the risk of making significant errors.
Declarative APIs allow you to control and track the state of the app, which includes quickly rolling back changes and restoring the previous state if necessary. Using them in your app ensures maintenance of effective version control and scalability.
Service mesh
Another component that any successful cloud-native app must have is a service mesh. This is a software layer that is dedicated to controlling the communication between microservices and ensuring its safety. It is especially significant for large-scale enterprise apps with thousands of services because as the number of requests between services grows, it becomes more and more complicated to ensure app performance remains high.
A service mesh manages traffic routing and load balancing, optimizing the dataflow so that the microservices continue communicating effectively. It also supports services discovery to enhance their visibility.
A service mesh is an essential part of app security, used for encrypting communication and performing authentication. It is also vital for monitoring purposes since it can gather service logs and telemetry data, which can then be used for troubleshooting and resolving issues. The service mesh makes it easier for the DevOps teams to build and manage distributed applications by providing a consistent interface for microservices communication.
Containers
Any application has its smallest compute unit, and for cloud-native apps that unit is represented by containers. The Cloud Native Computing Foundation (CNCF) counts the containerization of microservices as step one on the road to becoming cloud-native. A container image is a binary package that holds the app code together with its runtime and dependencies. There are multiple repositories available for storing container images, both private and public. Anyone with access to these container registries can use the image to run the app in a container instance on multiple various hosts without pre-configuring the environment for it.
Containers are a great way to guarantee application portability. The Docker image itself holds the system required to run the app, so it can run smoothly on multiple different OSs.
But what makes containers crucial for cloud-native applications is the tiny footprint. Unlike a virtual machine, a container uses much fewer resources. Multiple containers can run on the same host and share the same memory, processor, and OS without any difficulties.
Special container orchestration tools like Kubernetes allow you to facilitate and automate container management. As a result, you can successfully scale and monitor your cloud-native app, upgrade or change it without any downtime, enable the communication between microservices, and complete many other tasks without an overwhelming amount of manual coding.
Immutable cloud infrastructure
One popular DevOps concept describes two different approaches to treating the underlying app infrastructure as pets vs. cattle. In this paradigm, servers in a traditional data center are taken care of like pets. Each one has a name, and if something goes wrong, you try to cure it. Any server problem will attract everyone’s attention. If you need to scale, you keep using the same machine but add more resources to it. In short, servers are not disposable.
Cloud-native applications are designed with the cattle pattern in mind. This service model provisions numbered and identical nodes or virtual machines for the app. If one of the nodes stops working, you just create a new one. Also instead of scaling up, you scale out by adding more identical instances. The model where servers are not modified or fixed but only discarded and replaced with new ones is called immutable infrastructure. This type of infrastructure is highly secure and reliable, it can heal itself and scale automatically, saving a lot of time and effort for your team.
When you acquire this infrastructure as a part of cloud computing service (PaaS or IaaS) from providers like Amazon or Microsoft, you can also significantly reduce the amount of money spent on hosting. Clouds allow you to adjust the number of required devices in the real time, which will keep your costs closer to your actual needs.
Main principles of cloud-native architecture
Building with the right components is only a part of the deal. There are also certain practices that you need to follow when designing and developing a cloud-native application. Cloud capabilities are very different from traditional infrastructure, so if you want to create a really successful cloud-native app, you need to build it in a special way from the start.
Use loosely-coupled components
If you design the application as a set of smaller services, each of which is dedicated to a specific business task, it will solve multiple potential problems before you even encounter them. Today, everyone accepts the fact that you can’t imagine cloud-native architecture without microservices. By creating a set of distributed components, you make your app easy to update and fix, it becomes more resilient and stable.
However, you really need to think it through because creating microservices carelessly can have the completely opposite effect. Each microservice should be independent and dedicated to fulfilling a certain function. Only thorough planning beforehand can ensure you don’t end up with too many microservices or, vice versa, too few of them. Not enough separate services will end up with problems similar to the ones that monolithic apps have, while an extremely high number of services are difficult to manage and can cause unnecessary expenses.
Use business logic as the basis for separating your app into microservices. They have multiple advantages like scalability, flexibility, agility, and you want your cloud-native app to have all that.
Apply the Twelve-Factor methodology
The methodology known as the Twelve-Factor Application manifesto was first compiled in 2011 by engineers from Heroku (a PaaS company). It was not specifically designed for cloud-native apps but is valid anyway because these best practices work for all web-based or mobile applications. Using the following methodology in your software development workflow results in resilient and portable applications.
- Ensure that each microservice has its own codebase which you can deploy to multiple environments. Codebases are stored in separate repositories. You can track them using version control software like Git.
- Don’t let the changes to one microservice influence the whole application. You can achieve that by packaging dependencies together with the microservice they define in containers and isolating microservices from one another.
- Keep configuration data outside of microservices and managed externally through specialized software. You can use environmental variables to store configurations and successfully deploy the same code across multiple environments.
- Decouple ancillary resources like message brokers or data stores from the app. Make sure these backing services are interchangeable and you just need to edit the configuration file to replace them.
- Separate the build, release and run stages of your project. Assign a unique ID to each release and make sure you can roll back the changes easily.
- Use isolated stateless processes to execute the app. Share-nothing processes are easy to scale, they increase fault tolerance. If you need to persist any data, use stateful backing services.
- To free the app from runtime injection from a web server dependency, use port binding to expose each microservice and make it available for communication with other services and applications.
- Handle increasing workload by adding multiple concurrent processes instead of assigning more resources to a single powerful instance. Assign different types of work to specific types of processes for better load balancing.
- Create disposable robust processes that can quickly start up and gracefully shut down. If any service fails, the system should quickly replace it.
- Reduce differences between environments throughout the development lifecycle. The gaps between development, staging, and production environments should be as small as possible to avoid incompatibilities.
- Enhance your app behavior visibility by treating logs from microservices as event streams. Use a decoupled service to process and store log data.
- Invoke one-off processes to run management or administrative tasks like database migration or cleaning up the data. Run these tasks in an environment that is identical to production but separately from the regular app processes.
Modern cloud-native app design is not limited to just these twelve factors. For example, Kevin Hoffman, author of ‘Beyond the Twelve-Factor App’, has extended the list by adding three more recommendations: including telemetry in the design, taking care of security from the very first stages of your project, and putting API first design, meaning you should build everything like a service to facilitate integration capabilities.
Embrace the automation
No application can be truly flexible and scalable if you still deploy or provision the infrastructure manually. Any part of the software development lifecycle that you control manually slows down your releases and multiplies errors. However, for a cloud-native app, automation becomes something more than a best practice, it is an inherent part of the design. The idea is to automate as much as possible, but there are several areas that cloud-native architecture advises you to target as a priority.
Modern agile software development workflow is angled towards making product delivery fast but safe. The practices of continuous integration and continuous delivery involve releasing new builds with small, well/tested changes multiple times a day, or even an hour. Automating your CI/CD pipeline, together with rollback and testing, ensures you can ship your software as often as you need to always provide the best version of your product.
Cloud systems provide unprecedented capabilities to run your app without any downtime. Automating infrastructure handling is a sure way to exceed your customers’ expectations. The practice of implementing infrastructure as code has gained wide recognition, since it allows allocation of resources and application of updates by changing the configuration file. Everything else will happen automatically. Cloud services providers offer special tools like Terraform to script the required infrastructure parameters declaratively and then use the script repeatedly to create identical disposable environments. This enforces the consistency and scalability of the services.
Scaling your app is another thing that should be automated. In large enterprise apps the workload can change multiple times a day, it is just impossible to increase or decrease resources manually every time that happens. Adding or removing running instances automatically can significantly reduce the overhead and make sure you pay for extra resources only when your app needs them.
Sometimes issues will happen anyway, it is impossible to eliminate them completely. But you can make sure the time your cloud-native app needs for recovery is so short that your end users will barely notice. If you automate monitoring your system health and recovery, you can catch errors before much damage is done and restore the working state. And log analysis automation can provide valuable insights to avoid repeating issues and improve the system overall.
Go stateless
The way an application handles its state, i.e. the data about the system-s condition at a certain point in time, directly impacts its performance. Cloud-native architecture suggests that your app components should be created stateless if that is an option. When you have external storage for any persistent data, it makes your running instances easy to replace.
Stateful instances in an app require more resources and more time to recover from issues. If your microservice is stateless, you can just shut it down and add a new one without spending a lot of time on fixes. Scaling an app with stateless components becomes a simple matter of adding more instances when needed. It is much easier to load-balance a stateless application too.
Build for resiliency
No matter how great your application is, it will still fail sometimes, there is no way around that. So the goal is not to build an app that never fails - that won’t work - but to implement certain strategies that will speed up the recovery and reduce the inconveniences and consequences for your end users. Careful planning will ensure higher availability of your cloud-native app and shorten the time to complete recovery after a potential disaster. There are multiple patterns that increase app resiliency.
In a distributed system with isolated elements that communicate with each other, connection errors are inevitable. These failures are usually transient and, as a rule, quickly get self-corrected by the services. You can allow a service to repeat the failed call after a certain period of time (which should be increased before each next attempt to provide enough time for correction). This solution is known as the retry pattern. It is important to limit the number of retries and put other strategies in place to avoid making the period of waiting too long.
When an operation fails multiple times and it is likely it will fail again, you need to stop the app from repeating it. Allowing repetition of a request that fails each time is only going to waste system resources, potentially causing other services that might use the same database connections or memory to fail as well. The circuit breaker pattern stops all calls to a service if the number of failed attempts reaches a certain limit.
When you design a cloud-native application, you can usually predict some issues that might happen to it. You can make your app more resilient by preparing fallback scenarios that will define how exactly the services should behave in certain conditions caused by failures. And in situations when there are no fallbacks, your application should degrade gracefully, so that the user experience remains as positive as possible.
Finally, keep in mind that resiliency testing is different from the regular quality assurance procedures. It is also known as chaos testing and involves testing the application under unusual stressful conditions that might not happen often. You can gain important insights from testing how your app will behave when dependent services become unavailable or processes crash and improve the design accordingly.
Cloud Native Computing Foundation
It is impossible to discuss cloud-native applications design without mentioning the open-source Cloud Native Computing Foundation. This organization, created in 2015, is a part of the Linux Foundation and supports companies in adopting cloud-native technologies. The CNCF ecosystem hosts multiple open-source projects that are most closely associated with the very idea of cloud-native, such as Prometheus and Kubernetes.
More than 400 companies can boast CNCF membership, from startups to such staples of the industry as Intel, Oracle, and Microsoft. The foundation offers multiple resources that can make each step of adopting the cloud-native approach less of a shock for newcomers. The CNCF has also established a list of major components that cloud-native architecture is based on.
Microservices architecture ensures a speedier development lifecycle and shorter delivery time for your web application. Modern applications built for the cloud can handle any workload thanks to the horizontal scaling that happens automatically whenever you need. The benefits are truly endless.
Going cloud-native might not be an easy road, especially if your team hasn’t adopted the DevOps culture yet. Managing multiple microservices can seem daunting, and the learning curve has the potential to become exhausting. But if you make sure to use the best tools for cloud-native architecture, then everything, from troubleshooting to monitoring, becomes manageable. You will find it all worth it in the long-term, and the customers will come to love your fast, efficient, and stable cloud-native application.
