Editor's note:
This article is based on the Shanghai Container Conference on-site speech content, based on the actual combat with you to share the next generation of PAAs platform construction problems encountered, the current mainstream PAAs platform analysis, enterprise delivery experience and experiences. The article is long, divided into upper and lower two parts, this article is the previous article.
Guest Introduction:
Ma Hongxi, PTZ co-founder and chief architect. Prior to the position of rancher Labs China technology leader, Citrix Senior architect, Oracle Virtualization product Development Manager, we have a wealth of experience in container cloud, IaaS Cloud, and desktop cloud building.
Most of the Friends of this Conference are to share the story and experience of their own family as a user, I as one of the manufacturers, first of all, I want to communicate with you from a large face to all aspects of the knowledge point, but also to share the story of the other people we met, I believe that we have a certain reference to the significance.
Let's go to the topic below. Dr. Leung (Editor: Rancher Labs CEO Dr. Liang Sheng) also said that PAAs is an old concept, developed to now have the old generation PAAs also has a new generation of PAAs, of which the next generation I call the container-driven lightweight PAAs. One of the trends that we can see in the industry today is that we are gradually abandoning the old PAAs technology and embracing the new generation of lightweight PAAs that the container drives. Take one of our financial customers in southern China, they want to do a devops-wide development and operation system, they invite the traditional PAAs vendors, but the demand has not been satisfied. Later, when I talked to the people in charge, I introduced a new generation of lightweight PAAs, or CAAS, that was driven by the container, and found that the requirements were matched. This is a very typical representation. There is also a national commercial bank in Beijing, talking to them when they are hesitant to use the old generation of PAAs technology or directly with the container, and then exchange the container-driven lightweight PAAs technology, they have not invited the traditional PAAs manufacturers to test, All shortlisted tests are based on the Docker container technology vendor. This is the case for some customers. So why does this happen?
Through this film you can see that the old generation of PAAs technology products have a very heavy, closed relatively strong. Of course, there's a commercial version of the open source version, but if you choose a commercial version you have to wait for its version and component release pace, such as waiting for a new version of the Redis component, the programmer is not very fond of closed things. A new generation of container technology, whether based on kubernetes or Mesos or other technologies, is a feature of a lighter, more open, and programmers will feel that they can contribute, there is a sense of participation, which is a difference between them. So we see that today's customers have a lot of this new generation of PAAs needs, many enterprises in the choice of time will consider the container-based PAAs. Interestingly, some companies may have purchased traditional PAAs products in the last two years, but this year they will be looking at how the new generation of container-technology PAAs can bring him convenience. We all believe that the future is the use of container technology to achieve the direction of PAAs, that people in the choice of such a container of PAAs solutions or vendors will focus on what issues. I can give you a little bit of a share.
A world top 500 insurance Group
1. Open source solution, easy to use- this is actually a consensus in the industry. You can be pure open source or commercial open source. The so-called commercial open source is that you can not be the Apache or GPL release, but you promise to open all the source code to the customer, which is also a form of open source.
2. High demand matching, rich API, customizable – another requirement is that you must have a very rich API interface. I will not necessarily use your portal, but maybe I need to do some very rich integration, all of your interface features API must be able to achieve, even some hidden features are not interface, but the API must have.
3. The service team is strong- the delivery ability of the service team is not only the vendor or service provider, but also the cooperation and tacit understanding between the customer's own team and the manufacturer.
a national joint-stock Commercial Bank
1. Strong container Management capability- the PAAs platform built on the container requires a very strong management capability of the container, and the requirements of container scheduling and orchestration strategy are more abundant.
2. PAAs capability is fast on-line- the best customer team can quickly develop a PAAs capability module built on top of the container without relying on the vendor's release cycle.
3. Application configuration management feature rich- My application configuration, such as my CI, CD deployment parameters are not all the same, in the development, testing, production and other environments are not different. So my application has a lot of customization requirements, customers want the platform can provide flexible application configuration parameters, even the Java stack memory parameters, in short, the application parameters must be customizable.
A communications solution provider
There are also some communications solution providers that look at their concerns:
container Network, storage, grayscale publishing, etc. -they ask for more detail, first of all the container network requirements are relatively high, and secondly on the container scene to build PAAs when I stored problems how to solve. There is also a gray-scale publishing, but also a more advanced topic, including another bank customer, they also made this request, they want to apply to what scenario. For example, I want to send the latest version only to the IP of Shenzhen, and other areas of IP access is the old version, or want to put the new version only to one department in it access, but other departments access to the old version. So we also discuss whether you can use the source IP, or use the access tag to identify and differentiate. In fact, we can hear a lot of new needs from different customers in the manufacturers, and these requirements can be constantly integrated into our products.
Medical Big Data Project of a provincial science and technology department
In addition, this is a provincial science and technology department of Medical Big Data project concerns. We can imagine that it is very meaningful to bring together big data from all hospital blood, to make a healthy big data system, to do some early prediction of tumors, to screen for certain diseases, and so on. They're not just building a big data platform for PAAs, they want to build on container technology and what they need.
1. Hybrid cloud capabilities- they want to use public clouds like Ali and Tencent to run their big data analytics systems;
2. Container data storage, big data and container combination- They want this PAAs platform to be a big achievement in big data, with strong ability of big data analysis;
3. Local Delivery team- easy to communicate and provide technical support at any time.
These are the needs of the different industry customers I have listed to build a PAAs platform. What is our understanding of that?
We have a large number of customer exchanges, customer delivery made a summary: The success of the project at least two points, the first is based on a good framework or product to do your thing, most users can not be completely self-made, based on Docker to do, on the other hand is a relatively strong service delivery team, At least these two points are essential, whether it's your own or a team that invites partners to collaborate.
As you know, for Docker, it itself is just a few dozens of trillion installation packages, itself only provides a command line way, of course, now also provides Docker swarm can achieve cluster management, but in production still need a container management platform. This allows us to use a Docker core engine plus a container management platform to form a complete container service. Container as a services is only part of the container scenario, and he is not equal to a complete PAAs platform, and PAAs is much larger than it is. In our definition, a complete PAAs should include a good container management platform as a solid foundation, the upper layer has the deployment pipeline, big data, middleware and other PAAs capabilities plug-in, which we call the basis for the construction of PAAs, but in fact, this distance from the enterprise complete PAAs needs are not enough, A delivery team is also needed to complement it.
When we went to a customer to talk, they said that you do the portal I do not care, all the above things I need to do some docking with my system, so you have to ensure that your products have a better mechanism, rich API interface, the team to have the ability, Join us to build a PAAs platform that meets our needs. As you know, the out-of-the-box PAAs platform may not meet the individual needs of each enterprise, so building PAAs has a lot of personality needs.
Today we also see that many friends based on Swarm,kubernetes, Mesos do PAAs technology sharing, there are also some based on rancher or we have PTZ appsoar PAAs technology sharing. I'm not going to make a comparison between the pros and cons of this chart, but rather to make a metaphor. The most famous Three Musketeers, Swarm, Mesos, and Kubernetes, are engines of engine technology, while rancher, Appsoar, and OpenShift are a broader range of products or platforms built on engine technology. Maybe some users will say, OK, I do not want to spend more time to assemble the engine, wheel, steering wheel, I just want to buy a car directly can drive, and some users will say I want to have some flexible customization, I want to configure is a my favorite performance state, For example, the chassis debugging and other all are in accordance with my wishes to assemble. So our picture is to tell you that there are two trends in the choice.
I'll take some time to talk to you about my superficial understanding of three frameworks. Before also with Dr. Liang had communication, these three kinds of technology in a short period of time will not appear who kill who the situation, but in my personal point of view, when you choose Kubernetes, or Docker swarm, at least these two are a completely different route, not technically speaking, It's not a technical point. Everyone in the circle has heard that both the Kubernetes community and the Docker community are a PK relationship, including support for the network stack. A very interesting story, kubernetes before an article said why we do not support the CNM structure of Docker support, the future will have more Docker features kubernetes not, but Kubernetes will take another thing to complement. This is the relevant benefit to the two communities, their ideas are different.
For example Kubernetes, they want to do is the future everyone just use kubernetes, as for the bottom of the engine you use, in the end is rocket or Docker, you do not care, you just need to know kubernetes good. The main advantage for Docker is that they have a lot of user base. When Solomon was asked in a technical interview whether there was any pressure from a formidable competitor like Google, Solomon's answer was that we were not afraid of any difficulties or challenges because more than 90% of container users were using Docker. As you can see, Docker will soon have its own ecosystem, and it will gradually grow up. Although today's swarm is relatively weak, but we will see that he will gradually become strong, so that for rancher or, for we have the cloud ourselves, our choice is not selected side not queued, all support.
Let's talk about an example of the entire CAAS framework. This example is based on our own product, but I will use a generic way to tell you what it means. In short, I would like to use this picture to tell you a complete container management system which aspects of the function he should include. The first point is the management of the underlying multi-master. Some might say that most platforms support multi-host management, but I believe that one day we need a state of a hybrid cloud, and we want companies to be able to move our business in the same way as running water, drifting between private clouds and rented public clouds.
For example, my business is deployed on private cloud, special activities such as double ten a pair of 12, charging red envelopes, promotions and so on when we expand the business can be automatically migrated to the public cloud, and the migration of traffic ingress can also come in from the public cloud. Future if enterprises want to achieve these capabilities, Docker is a very good technical component to do this, but we must choose a suitable platform, in the future or today can be very good management of hybrid cloud business scenario model.
On top of that, we have different ways to cut tenants or the cutting of business scenarios, such as testing, production and other environmental resources, to achieve similar "multi-tenancy" management. Before listening to some friends about storage, the introduction of the network, are very good, we also realize that the container era we face from the storage, network challenges and the virtual machine era is the same. Not to say, the virtual machine era we stepped on the pit, such as the standard switch on VMware, the distributed switch has done well, naturally in the container age, these problems have been solved. In fact