“Cloud native” is a very important concept in cloud computing, but the understanding and interpretation of “cloud native” are different. In our opinion, cloud native is centered around the core of “cloud native application”. ** microservices, containers, DevOps, etc. are the tools and methodologies for cloud native implementation, and they are not equivalent. Clarifying concepts and clarifying cognition is the basis for promoting the implementation of “cloud native application”.
When I first heard the phrase “Could Native”, I was also confused and did not understand the twelve elements of cloud Native. With the progress of the project, I have gained more and more understanding of cloud computing and some of my own experience. When I look at the concept of cloud native again, I have a new understanding. I see a lot of talk about cloud native, some people say cloud native is the way to build and run applications; Some people say that cloud native is a set of technical system and methodology; Some say cloud native apps; Some say cloud native architecture; Others say cloud native is continuous delivery, microservices, containers, DevOps, and so on. It can’t be wrong, it can’t be right, what different people say is not on the same channel. We have always emphasized that we should take a holistic and comprehensive view of problems, rather than just look at one point selectively. We feel that many people are more or less ignoring the core essence of cloud Native: Native.
I. Cloud Native
What exactly is the cloud native concept?
We think the first and most important thing for a new technology is to understand the concept and the application scenario. A: I’m Native of China. **Cloud Native is a kind of Cloud Native. ** Is just like the native language of Americans is English. It does not mean that americans change their nationality and join the nationality of other countries, but their native language will change forever.
Its core is cloud native application, and its scope includes the theory, tools and methods of cloud native application lifecycle process. ** The twelve factors of cloud native are the basic principles for determining whether it is cloud native or not, and ** is also the basic theoretical guidance for implementing cloud native applications (although these factors are not completely accurate). In terms of continuous delivery, containers, microservices, DevOps are methods, tool frameworks, and environmental support for implementing cloud native applications or services. ** is either micro services, container technology, DevOps or cloud native, ** that’s just one way to do it. Without them, other tools can be used to implement cloud native. And even if you have them, you’re not necessarily cloud native if you use them.
Second, the characteristics of cloud native
First of all, we need to understand that cloud origin is a natural part of the cloud. Cloud native is not born for the cloud, but is born for the cloud, so it has cloud characteristics: network access, remote deployment execution, scalable elastic scaling, sharing, on-demand self-service, high availability, remote monitoring of billing audit, standardized delivery independent of location, etc.
Among the twelve factors of cloud native, the benchmark code is shared; Dependencies, configuration, back-end services, and management processes are autonomous service categories. Build, publish, run, and port binding are location-independent categories of standardized delivery; Port binding is also a remote access category; Process and concurrency are extensibility elasticity requirements; Easy handling is a high availability requirement; Logs are a requirement for monitoring billing and auditing, and a location-independent requirement for cloud applications as event flows.
The Twelve Factors of Cloud Native Although most of the features of cloud native applications are proposed, there is no clear definition of what cloud native is. What exactly should we talk about when discussing cloud native?
What should we pay attention to when discussing cloud native?
What exactly should we focus on when discussing cloud native? Is architecture? System? Or method?
We think the most important thing to talk about cloud native is to talk about cloud native apps. This is at the heart of all discussions about cloud native. Cloud native architecture is the architecture of cloud native application, cloud native methodology is the methodology to realize cloud native application, cloud native program is cloud native application, cloud native system is the theory, method, tool, environment, process, culture and so on to build, publish and run cloud native application. The end goal is for business applications. The first element of cloud native is “one base code, multiple deployments”, which has also been identified as cloud native applications.
An application may be born with cloud genes and fit for deployment in a cloud environment, or it may be modified to fit in a cloud computing environment, but the modified application is not a cloud native application because it is not a natural cloud application. Cloud native applications are not for migrating to the cloud, traditional applications are for migrating to the cloud. This is a concept we need to be very clear about when discussing cloud native. The concept is not clear will talk more disorderly, more talk more confused.
4. Cloud native applications
Cloud native applications are those that are born with cloud computing genes and are built with cloud computing ideas and applied to cloud computing environment. ** It should have the features we mentioned: network access, remote deployment execution, scalable elastic scaling, sharing, on-demand use of autonomous services, high availability, remote monitoring of billing audits, standardized delivery location-independent, etc. Some people say that is light, stateless cloud native characteristics? We don’t think so. Lightweight and stateless containers are the characteristics of containers, which are ideal for deploying microservice applications, but microservice applications are not necessarily cloud native applications.
Cloud native ideas, can use micro service architecture, containers, such as enterprise technology to build lightweight, stateless cloud native applications, applications with cloud deployment, can remote access, elastic, sharing, on-demand self-service, high availability, has nothing to do with the location and other characteristics, make it naturally has the cloud genes, suitable for running the cloud deployment. The twelve factors of cloud native are discussed more from the perspective of building cloud native applications.
(1) Elasticity
Elasticity is an important feature of cloud computing, which is theoretically free from resource constraints and can consume resources indefinitely (at a pay-as-you-use rate, of course). Containers are related to cloud natives because elasticity is also an important feature of containers, and the ability to be resilient is important to adopt containers. Resiliency includes the ability to use resources and service instances resiliently to expand. When the resources of single instance reach the bottleneck, elastic extension of container instances can be realized with load balancing mechanism. When we talk about cloud native application resiliency, we should include the resiliency of application using resources and the resiliency of application instance scaling.
2. Sharing
There are three types of cloud computing: IaaS, PaaS, and SaaS, which involve three levels of sharing: resource sharing, platform sharing, and application sharing. Cloud native applications are SaaS layer services deployed on the IaaS or PaaS layer. Application has a benchmark code, multiple deployments, is also shared, from the perspective of application development, but not cloud application sharing significance.
Cloud applications can be open to everyone and everyone can share the services provided by cloud applications. Cloud applications need to be deployed on cloud computing platforms and use cloud computing resources to achieve platform sharing and resource sharing.
(3) Autonomy
Cloud application deployment is location-independent, you don’t know where it will be deployed to, and the underlying layer is transparent to users. Therefore, the dependency packages, configuration files, and back-end services of cloud native applications need to live and die together with applications to achieve self-management and self-governance.
Microservices are also designed to be autonomous, much like cloud native apps. That’s probably why we put them together. Therefore, when we use microservices to realize cloud native applications, autonomy is an important criterion. That’s the beauty of a distributed center, all in one. Like people, everyone is a distributed center, capable of self-management.
(iv) Standardization of delivery, regardless of location
Cloud applications can be built locally or in the cloud, run in the cloud, and then be delivered according to certain standards, such as container images, to standardize delivery. Standards delivery can be deployed anywhere in the cloud that supports standards, or it does not need to know where it is deployed to run, regardless of the environment. As Java Once proclaimed: Write Once, Run Anywhere, implement Build Once, Run Anywhere.
One of the benefits of containers is that the application runtime tools are standardized, and all applications are delivered as standardized images and run in standardized containers. The container can run anywhere, or you don’t need to know where, just submit the image to run.
High availability
Features such as multi-instance deployment, flexibility, and autonomy ensure high availability. Using containers sometimes does not guarantee application stability, but can be agile start – stop, multi-instance and highly available. If you need a stable, highly available mechanism, containers may not be the best choice.
(6) Audit can be monitored
Users’ access to and invocation of applications and application running status can be obtained in real time through logs or interfaces for metering, charging, monitoring, and auditing. For example, elastic scaling can be achieved based on load flow.
(7) On-demand access self-service
Cloud applications are deployed on the cloud and can be accessed by customers on the network based on their own requirements without contacting cloud application management personnel. There is usually a cloud application service catalog, each application service has instructions, through the service catalog can be suitable for their own needs to meet the application.
(8) Configurable
Cloud applications often rely on configuration centers to deploy and run applications in different environments. For development, test, and production environments, some parameters may be configured differently. Most of the time, it is not convenient to pack all the configuration files with the application. Therefore, you can use the configuration center to manage the application configuration files in a unified way, and even realize the runtime parameter update.
The configuration center is considered more from an application operation and maintenance perspective. From the point of view of autonomy, it is not necessary. But it is also a very important carrier, just as people have a brain to store, but still need to use paper and pen to remember.
(9) Agility
Agile is needed both from an application deployment perspective and from an operations perspective. But we don’t think it’s a key feature of cloud native apps. Agile is usually associated with lightweight, microservice componentization, small, light relative to agile. A lot of times agile is about architecture, not just technical architecture, but organizational architecture. Agile is more about process, management, or experience requirements.
Microservices, containers, and DevOps build cloud native applications
Lightweight and flexible container; Microservices are small but dedicated to improve the efficiency of development, testing and updating, realizing agility; DevOps is a closed loop of continuous integration, continuous deployment, continuous release, continuous monitoring, continuous feedback, and continuous improvement. The lightweight nature of the container is ideal for running microservitization applications. Microservices architecture changes the thinking of application design architecture. Using small and specialized microservices to complete a specific business unit work; Through the combination or orchestration of microservices into a business application, to complete a specific business process; Business processes can be choreographed on demand and deployed in real time; Mirrors standardize delivery, containers standardize operation and maintenance scheduling, and mirror repositories standardize distribution and deployment. Standardization simplifies continuous integration, deployment, and release processes, service choreography makes application development agile, and DevOps keeps monitoring, feedback, and improvement agile in response to change. It can timely reflect the changes and requirements of market business needs.
So containers, microservices, and DevOps will be brought together to build lightweight, stateless cloud-native applications.
Six, application transformation and migration
The application can be modified to have the features of cloud native (rebirth) and deployed in the cloud environment, so that it can be easily seen as a cloud native application. However, if you migrate directly to the cloud without modification, you are not cloud native, even if you have some features of the cloud, such as ESB services, that are not cloud native.
When considering application migration, it is necessary to consider whether the application has the features of cloud native applications. If it does not, it is usually necessary to consider transformation to enable it to have the advantages of cloud computing. (Article from TWT Enterprise IT Community, thanks)