In recent years, we've been hearing a lot about the cloud, but without real meaning. It was just a buzzword, and everybody was rushing to get some Amazon EC2 instances and put some services on it, just to spread the word—It's in the cloud; I put it in the cloud; we're in the cloud.
Embracing the cloud is much more than deploying something on it. Behind the word cloud, there's an entire world that isn't about a new technology or innovation or migration (even worse, transformation); it's about a revolution.
It's a revolution in terms of infrastructure, and development, deployment. Revolution in terms of teams.
The key point for the infrastructure is automation. Everything needs to be automated—provisioning servers, disk space, memory, networks, and resources—everything.
The key point for development is keep it small—small pieces of software independent of each other; small development teams focused on a few tasks that need to communicate excessively and receive feedback from failing software as fast as possible. The latter is possible only with automation—build automation, test automation, and deploy automation. The new infrastructure is built on the concept of automation. If you don't automate, you can't be elastic, flexible, resilient, and fault tolerant.
Getting into the cloud means changing your work habit, changing a company to organize and structure its IT department.
How do you start with cloud-native applications? First of all, a deep assessment of the actual infrastructure is mandatory. Integration boundaries, security, legacy systems, appliance components, processes, and business and operational requirements—all of these aspects need to be checked to find weaknesses and strengths. The assessment can lead to training people and creating new teams.
A cloud-native application is an application that takes into account all of the characteristics of the cloud architecture. Only then can you start the most beautiful game—building your cloud-native application.
One of the most used approaches to build a cloud-native application is microservices. The difference between a microservice and a cloud-native application is that the former can be provided by any infrastructure and the latter is the same but it takes into account all of the aspects of the nature of the cloud, and distributed environments, where a single place can't be considered.
Going back to the cloud architecture, the advantages of having microservices in addition to automation is efficiency:
- Auto-provisioning: Infrastructure as code
- Auto-redundancy: Cloud-native applications are inherently resilient to failure
- Auto-scaling: By constantly measuring your microservices, you can decide when it's appropriate to add more nodes (scale out)
A common way to deliver microservices is through Linux containers. Microservice architecture and Linux containers brought a lot to each other. Every microservice has to be a self-contained unit—dedicated resources, CPUs, memory, and disk space. Imagine delivering such services on a single virtual machine (VM) or tens or hundreds of VMs. The process would take quite a long time, the infrastructure would start lacking resources quickly, and in the short term, your infrastructure wouldn't be enough anymore—this would be a waste of money, a waste of time, and a waste of resources.
Containers fit the self-contained unit approach of microservices very well, from an infrastructure point of view. Containers are lightweight, isolated, and provisioned in seconds—actually in milliseconds.
In this chapter, we'll cover the following topics:
- Twelve-factor applications
- Microservices
- Runtime environments