More and more developers choose microservice architecture at the design stage, and monoliths are systematically eliminated. This is a long and complex work, so developers try to decide on the architecture at the design stage.
The "classical" cycle of monolithic application development inevitably faces a number of problems:
- It is difficult to release frequently due to difficulties in compiling and adding to the current build. This leads to accumulation of technical debt.
- During peak loads, applications lack processing power or channel width, which affects service quality and leads to loss of customers. Problems with load balancing deserve a separate article.
- The application is written in an old version of a programming language or the language itself is not suitable for the current tasks. Only a part of the team understands how to support it, so employees become indispensable.
The concept of Cloud Native presents a distinct approach to application creation and development. With this approach, updating an application can be accomplished without affecting the customer, allowing for a seamless transition.
Due to this reasoning, an increasing number of businesses are relinquishing the use of monolithic systems in favor of designing applications with a Cloud Native framework from the start or during the development process. Nevertheless, this can be a challenging procedure, and some may experience difficulties during the process of restructuring.
The Way to Cloud Native
In 2015, at the dawn of Cloud Native, the cloud-readiness classification of applications emerged.
- Cloud Ready. The application does not require constant access to the disc, it is containerized, and management with external services is done through configs. It is possible to connect third-party services.
- Cloud Friendly. The application has 12 factors. Here appears horizontal scaling due to the resources of the cloud platform.
- Cloud Resilient. Solutions built in such a way that an increase in load or failure of individual components will not lead to unavailability of the service.
- Cloud Native. Microservice architecture, the design uses the API-first principle.
Now an entire community, the Cloud Native Computing Foundation or CNCF, is looking after the development of a native approach to building applications.
Cloud Native as a landscape
Cloud Native is a concept that the community describes as an approach to constructing and operating applications in dynamic environments, including a variety of cloud types. This approach employs containers, microservices, service mesh, and immutable infrastructure. To manage the deployment of services and software on IT resources, this approach replaces components instead of modifying them. With every modification, the applications or services are deployed afresh.
Cloud Native is more than just signing up for cloud services and launching applications.
Several Cloud Native fundamentals must be implemented in a cloud application for it to be effectively deployed, launched, and managed.
Key features of cloud applications
- Containerization and orchestration.
- Adherence to CI/CD practices.
- Resource scalability based on workload.
- Fault tolerance and rapid automatic recovery in the event of global failure.
- Availability of state and performance monitoring systems.
Among other attributes of Cloud Native, the community notes the high level of automation and the ability to make significant changes with minimal effort. This makes it easier to deploy and, as a result, increases the number of releases. All these inputs indicate that CNCF so far trusts only Kubernetes, which combines all of the above, to work with containers.
For example, the introduction of Kubernetes has helped Adidas to run releases 3-4 times a day, instead of weekly launches.
However, community experts regularly update the service map, which collects all the necessary components for use in client applications.
Most of the projects belong to OpenSource solutions and are labeled with different statuses depending on what stage the project is at.
So any application can be Cloud Native? Actually, no. To break this point down, let's look at the different types of applications.
States and isolation
First of all, let's define applications by state type.
Stateless. In applications of this type, the server response does not depend on any state. No data about or references to past operations are stored. Each operation is executed as the first and only operation.
Applications that are stateless are designed to offer a solitary service or function. They rely on web servers and content delivery networks (CDNs) to manage brief requests, adhering to a one-request-one-response model.
Stateful applications and processes are those that maintain or remember the state of a user's session or interactions over time. This means that even after interruptions or disconnections, when a user revisits or re-engages with the application or process, it can resume from where it left off or provide contextual data based on past interactions. Examples of such applications include online banking and email services. These applications operate within the context of prior transactions, and the present session can be influenced by previous events. As a result, stateful applications utilize the same servers whenever a user request is processed.
If a stateful operation is interrupted, all of the relevant context and history remain intact. This allows the user to pick up exactly where they left off without any interruptions. Stateful applications are designed to keep track of and save important data, such as user preferences, window placement, and previous actions.
The vast majority of the applications we utilize on a daily basis are considered stateful. However, with technological advancements, the utilization of microservices and containers have facilitated the development and distribution of cloud-based applications.
Second, it is important to separate isolated and linked applications.
Isolated. Do not interact with third-party services, such as payment systems.
Linked. Use one or more external services.
Determining whether an application is Cloud Native depends on both of these factors.
It should be noted that stateful applications that operate in isolation necessitate logs to function, but the data is contained solely within the application and not stored elsewhere. However, this category of applications is uncommon in practice since they do not respond well to system reboots.
Next are applications with bound and non-static state, which must interact with external services to respond to requests. This type of application is more widespread because it involves interaction with the databases, message brokers.
Cloud Native for everyone
Cloud Native concepts are applicable to all kinds of apps, both with and without state. These apps can be deployed on the hybrid cloud infrastructure offered by different vendors. In addition, apps that need to interact with outside services can also be treated as Cloud Native. It should be noted that the ability to deploy these apps in the flexible hybrid cloud depends on the specific situation.
In case the front-end is a database which is hosted on the Kubernetes solely for the use of the application, the answer is yes. This means that the app does not depend on a particular cloud service provider and can be implemented in a hybrid cloud. This architecture, however, places a significant operational burden on the system. This is because a database or other form of data storage must be installed and administered in a Kubernetes environment.
