What is Cloud Native?
Cloud Native refers to an approach in which an application is built and operated in such a way that the advantages of the cloud. In particular that scalability, speed and security, can be exploited to the best possible extent. An application in the cloud is operated differently than in traditional data centers, so a rethink is necessary. On the one hand, it is beneficial to promote and support microservice architectures. The same applies to the principle of Continuous Delivery (CD) and Continuous Integration (CI). Likewise, opportunities such as zero downtime and rapid development and feedback are a reason for cloud natives. Furthermore, automated and integrated possibilities to implement DevOps are needed. DevOps refers to the cooperation between developers and operators of IT and has the goal of automating the operation and development of applications.
However, the above tends to be implementation details. The question arises as to which concepts the cloud must cover in order to really do justice to the properties. Therefore I will describe the most important concepts for cloud native in the following.
Powered by disposable infrastructure
The cloud is designed so that new instances can be acquired quickly. Therefore, resource usage should also be designed so that resources can be created or discarded as needed, such as infrastructure. To achieve this, a high level of automation must be used. This lays the foundation for scaling and elasticity
Composed of bounded, isolated components that scale globally
People make mistakes. However, an automated and replaceable infrastructure can reduce the potential for errors, but not prevent them. If the infrastructure components are limited and isolated from each other, it is achieved that a fault in one component has no influence on others. It is also easier to repair or replace defective components. Resilience is achieved through data replication. This makes replication easier, because the individual components do not have to communicate synchronously with each other. This in turn facilitates scaling, as the load is distributed over many independent data sources. Likewise, the possibilities of the scalability of the cloud should be exploited as far as possible.
Embrace disposable architecture
The abbreviation DURS is often used in connection with Cloud Native. It stands for Deploy, Update, Replace and Scale. In a monolithic architecture, the all or nothing approach often applies. This means that risks are avoided. This is because it is not possible to proceed in small steps. However, it would be worthwhile to take precisely these risks. The architecture is not seen as small replaceable components. Compromises are made and even suboptimal solutions and components are used simply because it is too costly to replace them. This is where the so-called disposable infrastructure approach comes in. It refers to the “Replace”. It is possible to get the knowledge how an optimal solution for a problem should look like by small incremental steps and also related setbacks.
For example, a component is created in short development times, e.g. two weeks, piece by piece. It is not planned as a whole, but in partial steps. Thus, problems in the design are more quickly apparent and can be adapted or refractored. In addition, the waste of resources is minimized. Thus experiments are possible. The result is therefore not only testable in the overall architecture.
Leverages value-added cloud services
It should be noted that third-party resources may be more difficult to integrate than those provided directly by the provider. While the danger of vendor lock may exist, the benefits may outweigh the risks. Nevertheless, an exit strategy is important. This is also given by the replaceable and isolated architecture.
Welcomes polyglot cloud
A polyglote cloud means that there is no need to commit to one technology or language. Competitive pressures are forcing cloud providers to innovate and differentiate themselves. In most cases, there is an easy way to test different services. For example, to a certain degree of usage, some services are even free. This allows different providers, solutions and offers to be validated and tested. This is done on a project or component basis. It is recommended not to focus on just one provider.
Especially companies, even if they use a cloud solution for one project, will not necessarily classify it as optimal for another. For example, one project is implemented with AWS, another with Azure solutions. It should be noted that a polyglot cloud is different from a multicloud.
Empower Self-sufficient, full-stack teams
Conway`s Law states that the organization of a team is also reflected in the handling of the code and the architecture. As already mentioned, each component of the application manages its own resources. They are also isolated from each other. Each development team is now responsible for its own components, there is no division. This enables better communication and coordination. Each team is responsible for the entire life cycle.
