Three major helpers of service containerization
We all know that there are many needs for the implementation of microservices, and containerization technology is the best choice. Containerization realizes the many needs for the implementation of microservices through three major assistances:
- There are many docks - various software and hardware platforms are emerging in endlessly
Containerization solutions have universality and are suitable for various different software and hardware platforms. - Microservices - high cohesion, low coupling, minute start, stop and deployment
This is reflected in the micro-scale containerization, which can achieve minute-level start, stop and deployment. Deployment - Conway's Law - The organization determines the superstructure
Containerization technology is a relatively abstract technology. It strips away a lot of operation and maintenance workload and is more suitable for our current hot topics. DevOps is more suitable for some enterprise changes made by our Internet architecture under Conway's Law, and it also requires our applications to change.
piers lined with piers
From the perspective of virtualization, a large number of our operating systems will not be directly on the physical machine, but on the virtualization platform. This large number of storage, servers, virtualization, and operating systems determine what we have. There are a variety of different docks, whether they are static web pages, Java code, nodejs applications, or even some underlying middleware applications, as well as new applications emerging from microservice transformation.
How can it be successfully carried to these docks? Do all applications need to be tested for compatibility on all platforms? We use a large number of repeated tests to verify that these applications can be deployed, so that each of our developers and architects can understand these compatibility?
The answer is no, whether your goods are transported by train, car, plane or ship, it usually does not put the goods directly in the cabin, or in the cabin of the ship, but puts them on a long and wide Inside a relatively fixed cube is a container. This container can be easily transported from airplanes to trains, and from trains to ships. It is suitable for different virtualization technologies, operating systems, server technologies, storage technologies, and networks. Technology, these containers are equivalent to our containers. Their English words are Container, which means that in an environment full of docks, the versatility of containers solves the compatibility issues of our different applications and different software and hardware platforms.
microservices
The second point is the "micro" of microservices we mentioned above. "Micro" means that usually our code will not be a large code of several gigabytes, but only a few megabytes, dozens of megabytes, or hundreds of megabytes. M small application code, micro means that the release of our application does not require a long release process of several months, or even half a year. Its iteration is very fast, maybe a few hours, maybe a few days. Another level of "micro" means The startup and shutdown of applications is very fast, with seconds or minutes being a common startup and shutdown situation for microservices, while traditional native applications usually take dozens of minutes or even hours.
Just like in the picture above, the applications in the large square on the left are no longer suitable. It will extract all applications into different microservice modules. Each module will become a small square, and this small square will It runs on different virtual machines, different physical machines, and different operating systems, so we hope to put each small square in a container. This container is our containerization technology.
As shown in the figure above, our previous application was to pile up a lot of small services into a large application and deploy it on a physical machine or a virtual machine. Then this virtual machine requires a lot of memory and a lot of computing. The unit also needs an independent operating system to host its entire set of applications.
Let’s take a look at the picture below:
After reaching the small square we just mentioned in the first picture, if a small square still occupies an operating system and an independent CPU Memory space, such resource consumption is very large. Taking the single application before our microservice transformation as an example, we only need one or two virtual machines to complete it. However, after our microservice transformation is completed, hundreds of such Microservices require virtual machines to complete, which requires hundreds of virtual machines. This does not take into account high availability or data backup and disaster recovery. If high availability, performance requirements, and disaster recovery are taken into consideration, we will Thousands of virtual machines may be needed. You can imagine how much pressure our data center will bear. So what will happen if there is containerization?
All these tiny contents become a tiny body that packages the runtime and application. The code of this tiny body may be 20M. After we package it, it may be 30M. Then the start and stop of the original code In an operating system, including operating system start and stop, database start and stop, and application start and stop, it may take dozens of minutes. In our containerization, it may take ten seconds to several minutes. Through such a technology, we can still Hundreds of different microservices run on one operating system. In order to achieve high availability, we may have multiple operating systems. Through such a comparison, the tiny containerized deployment method can realize all microservices and it is very convenient. It floats around in various places, but it is not restricted by the hardware platform. This is the coupling point between our microservices and our containerization.
Conway's Law
This is the fundamental, or the biggest change, of our current Internet. In the early stages of the development of the Internet or e-commerce, we usually have one department, such as the development department. This department is responsible for payment, alarms, Order management, user management, and management of buying and selling business processes. At the same time, our operation and maintenance department builds the entire data center to complete the environment of all virtual machines and access to all networks. At the same time, it may also be necessary to provide the underlying database, such as the underlying database. Some of the functions of network load balancing and content caching exposed by the API are a large department with weak coupling. They are relatively independent and have mutual constraints. In order to meet the continuous development of new needs of our Internet, many companies are developing Great adjustments have been made to the organization, and development, testing, and operation and maintenance have been separated into small business groups. One business group is responsible for users. It is responsible for not only the development of user code, but also quality inspection, implementation and implementation; Another business group may be engaged in payment. This payment may include both its application architecture and its deployment architecture, as well as actual response services to customers. If the payment platform is broken, they provide 24-hour response. This is A change in our organizational structure, according to our now popular Conway's Law, is that the organizational structure determines the superstructure.
When a company has an organizational structure, it has a business form, or an IT system. So for any organization’s IT system, most of their members are actually We engineers, taking our currently hottest Java as an example, are our Java architects, developers and testers of our Java platform. With them as the main body, you have to complete the basic QA release of all business systems and prepare for production. Release and the release of production platforms that are flexible, scalable, and highly stable require each of our Java architects and our Java developers to have a deep understanding of system operation and maintenance, which is actually somewhat realistic.
So how does containerization technology solve it? Container technology requires us to have a unified container platform built on an open source or a platform supported by a third party. For us R&D personnel, as long as we understand the characteristics of this platform and learn how to publish an application through such a platform, this platform can automatically complete our expansion and contraction, high availability, and quick start and stop, which satisfies our organizational structure. After the change, there are not many additional requirements for all our systems, all architects, and all developers. It is very suitable for the changes in our organizational structure, and even realizes the problems encountered during our microservice transformation process. Lots of questions.