What to do with cloud container services

Container technology has been very hot recently, and projects have come up with their own support solutions, such as OpenStack, CF, Mesos, and a stack of container-based platform solutions, which are not related to container technology.

What is a container? It is not a virtual machine such simple underlying virtualization, nor pure application, it happens to be located between the two, the location is extremely important. It's like an IP protocol layer that can't be bypassed either from the top down or bottom up.

This has also led directly to the long-established IaaS and PaaS areas formally beginning a positive conflict.

In the IaaS Engineer's view, do PaaS is to provide a few application templates, the original virtual machine is not good to do, now have Docker, instantly give you the service to the whole. Not to mention there are recently out of the hyper, virtual machine called to with the container than performance, the original familiar with the machine engineers but too like.

In PaaS engineers ' view, IaaS should honestly do the underlying physical resources to abstract into virtual resources. Originally the bottom is the virtual machine when, feel good complex, what sr-iov,libvirt/kvm,sdn,overlay,ceph ... People who do PaaS generally don't understand. And now there is a stack of ready-made Docker container platform, and then to the application, are doing software people can do things, so in fact, the IaaS is not so critical.

These discussions, like the one-core and micro-kernel battles of the year, are not only related to technology, but also to the critical battle of the model.

It can be said that it seems to have reached a critical juncture in which the design of the middle tier will determine the shape of the cloud computing industry for at least the next 10 years.

Current situation

Let's just drop these arguments, and we'll look at the Top Open source project in IaaS, what OpenStack is doing with containers now.

There are currently three types of options:

• Nova-docker: Pipe up the container as a virtual machine. Basically no other components need to be moved. The only problem is that the container is not a virtual machine after all, such as the need to provide some additional parameter support, need to introduce the concept of the group, the need for performance optimization. This leads to the people playing PaaS very dislike.
• Heat Docker Driver: Use Heat to pipe containers. Heat, as we all know, is a very flexible and powerful interpretation engine, and theoretically Docker needs the support it can have. The only problem is that Heat, after all, is an explanation engine, which is essentially based on APIs provided by other services. Because it is not an operation and maintenance engine, the management of the runtime is not guaranteed, such as automatic resource scheduling ah, network functions Ah, and so on. If all this is done, it would be tantamount to reinventing the wheel on a higher level.
• Magnum: The people who play the container look at the problem of course basically from the application layer up to the beginning. A bunch of people excitedly ran to Nova project talk, how should support container-based DevOps Ah, application template Ah, the Nova group of people to do the system is silly, how can we do? This is clearly what PaaS should do. But Jiabuzhu everyone thinks Docker is very hot, we must still play tricks, so a new project was born. But the people who play the application do not understand the system, research, found that now can manage Docker's open-source program is really a few, such as Swarm and Kubernetes. That's great, so how do you integrate PaaS platforms such as Swarm and Kubernetes into an IaaS platform like OpenStack? This does not seem to understand Ah, some people think of Heat, a beat head, you can take Heat to install a set of AH. Each time you need to adjust a Heat command, dynamic loading set. All the questions seem to have been solved, everyone is happy!

In this way, the most critical container service provides this layer is inadvertently ignored by everyone.

Thinking about cloud computing

A famous person said that I can see far because of standing on the shoulders of the predecessors.

Let us throw away the system and application of the dispute, but also boldly stand on the shoulders of the predecessors 重新发明轮子 .

First of all, it is important to reiterate that the most central idea in the field of information technology is stratification and abstraction. Historically, layered and abstracted in different locations, the birth of a minicomputer, the birth of a processor, the birth of a programming language, the birth of a Web service, the birth of cloud computing ...

What does cloud computing have to offer, aside from the IaaS and the PaaS? This problem is known to all, is service.

What do you call a service? The user needs the operating system, can give you a direct, the user needs a running environment, you can directly give you A; users need a set of software, you can directly give you a solution, the user needs a set of solutions, this is not directly to you, is the outsourcing company's business.

So, for the designers of cloud platform, it is to provide these different levels of service to the user, this is the so-called IaaS and PaaS. So, keep in mind that various XaaS are different from the level of service presented to the user at all, not at all at the design level and technical solution.

Just like you bought a mobile phone, you can play games, you can also call. Games and phones are the different forms of service that mobile phones offer to you, not that games are a special kind of mobile phone, but that the phone is another special kind of mobile phone.

OK, so the following question is about how the design should be layered in order to meet the needs of the user. The predecessors summed up the three fundamental basic business of computing, storage and network. The calculation is the core and the most direct.

Let's look at the direct user-oriented computing business. The data center is in the physical machine, the physical machine can be installed operating system, the operating system can be loaded with a variety of software, you can run the virtual machine, you can run the container. Both physical machines, virtual machines, and containers are compute resources. All should be implemented and supplied with the cloud platform.

If IDC is to allow users to take the physical machine as a computing resource carrier, then the current cloud computing is a step further, so that users can directly ignore the actual carrier of computing resources, whether operating system or application, directly available to you, no need to care about the specific carrier.

In a word, cloud computing is to facilitate the provision of computing resources!

Questions and Directions

Magnum is currently considered to be the most dynamic container project in OpenStack, but unfortunately, the initial path is biased.

Magnum is positioned to provide a set of OpenStack APIs that can be compatible/dependent on a variety of third-party container management platforms. OpenStack is supposed to be a resource management platform, and now it's used by others, which means it's not much of a relationship with OpenStack. But without OpenStack, the set of OpenStack APIs encapsulated above is meaningless. Third-party management platforms have their own ready-made APIs.

The real Container as a Service should actually be a container platform in OpenStack instead of installing someone else's set of platforms in OpenStack and then encapsulating the API.

One might guess that the reason for not doing the bottom-up is probably related to Nova-docker.

If you're talking about technology, it's easy to implement a real Container as a Service in Nova. In Nova's view, all compute nodes, but compute nodes can take their own type, for example, some compute nodes are physical machines, there are virtual machines, there are containers and even container groups. Different types mean different drivers at the bottom. With a set of abstract resource scheduling framework (refer to the Mesos two-tier scheduling mechanism), with different underlying framework, the problem is easy to solve.

But it is now has a nova-docker, already have a Magnum, do not know how many twists and turns can go to this direction. Maybe it's too hard in the big environment of OpenStack.

Perhaps, this is the charm of open source, on and off, twists and turns in the forward.

Reprint Please specify: http://blog.csdn.net/yeasy/article/details/46545837

What to do with cloud container services