Cloud Native is a compound word. Let's break it down into the words cloud and native.
"Cloud" is an online network. We all know that traditional applications run on local servers, while traditional applications deployed locally may require downtime and update, and cannot be dynamically expanded, etc., while "cloud" means that applications run on a distributed cloud environment, support frequent changes and continuous delivery.
'Native' means that the application is designed for the cloud with the elastic and distributed nature of the cloud platform in mind.
Then with the continuous development of cloud-native technology, its definition is constantly iterated and updated. Different communities and companies have different understandings and definitions of cloud native. If you are interested, you can take a look at the development process of cloud-native.
Four Key Points of Cloud Native
Cloud native can be simply understood as: cloud native = microservices + DevOps + continuous delivery + containerization
Microservice
Microservice is software architecture. Using the microservice architecture, a large application can be divided into multiple independent and autonomous microservices according to functional modules. Each microservice only implements one function and has a clear boundary.
Using a microservices architecture can bring us the following benefits:
- 1) Independent deployment of services: Each service is an independent project that can be deployed independently, does not depend on other services and has low coupling.
- 2) Quick start of the service: After the split, the service startup speed is much faster than before the split, because there are fewer dependent libraries and less code.
- 3) More suitable for agile development: Agile development takes the evolution of users' needs as the core and adopts an iterative and step-by-step approach. Service splitting can quickly release a new version. To modify which service, only the corresponding service needs to be released, and there is no need to re-release it as a whole.
- 4) Dedicated responsibilities, and a dedicated team is responsible for dedicated services: When the business develops rapidly, there will be more and more R&D personnel, each team can be responsible for the corresponding business line, and the splitting of services is conducive to the division of labor between teams.
- 5) Services can be dynamically expanded on demand: When a service has a large number of visits, we only need to expand the service.
- 6) Code reuse: Each service provides a REST API, all basic services must be extracted, and many underlying implementations can be provided in the form of interfaces.
Containerized
- More agile application creation and deployment process: Using container images of applications is easier and more efficient than virtual machine images.
- Sustainable development, integration, and deployment: With the immutability of container images, container image versions can be quickly updated or rolled back for reliable and frequent container image builds and deployments.
- Provide environment consistency: Standardized container images can ensure the consistency of development, test, and production environments without having to worry about the nuances of different environments.
- Provide application portability: Standardized container images can ensure that applications run on various operating systems or cloud environments such as Ubuntu and CentOS.
- Provides the foundation for the loosely coupled architecture of the application: The application can be broken down into smaller independent components that can be easily composed and distributed.
- Resource utilization is higher.
- Resource isolation is achieved: the isolation between container applications and the host, and the isolation between container applications can provide certain security guarantees for running applications.
Comments
Post a Comment