Please do not forget "operation and maintenance"
PaaS is not a strange topic, in the emerging container world, how do we see the relationship between maintenance and PaaS? How to rethink Dev and Ops positioning? The author of this share their own unique opinion. For example, the author said: Docker best point is that it is for the development and operation and maintenance of a clear line: any inside the container are the development of concern, while the outside is the operation and maintenance of the world.
Do you remember when PaaS rose?
Five years ago, the concept of PaaS has just risen, when a lot of people (including myself) that the operation and maintenance of this career will be to decline. Because you can put the operation and maintenance work to the PaaS platform, and then to focus on what they are good at, so it should no longer be willing to do those who deal with the basic services of the machine miscellaneous activities, right?
- 2015 Docker and other subversive trends in IT
- DockOne to share (106): music as cloud based on Kubernetes PaaS platform construction
- Why is the private cloud positioning supposed to be PaaS, not IaaS?
- Look at CaaS (container service) from PaaS's front desk
- Kubernetes1.5 source code analysis (b) apiServer resource registration
- Construction of PaaS Based on Docker
Now, six years have passed, we finally see a large number of cases of PaaS failure, I began to realize that I was wrong , PaaS is not the future I want, it can not completely solve some of the basic services problems, and Just let these problems a little ease .
In the beginning, PaaS service providers invested hundreds to thousands of dollars a month to finance and resources to train customers, and in the end can only watch them leave, and then put into the embrace of cloud service providers.
The reality now is that the public PaaS service has become a platform for some rookie entry, and the winners of those games have abandoned PaaS, and choose to build their own servers on a number of cloud services platforms to carry their services.
I have previously written an article about why I think so innovative and popular public PaaS service can not completely conquer some of the world's views, so here will not repeat them. But there is an argument here I would like to further emphasize that I personally think we may have committed a similar mistake, that is, "operation and maintenance of this career is about to die," this prediction.
Believe that from the public PaaS service to the developers who need to do each operation and maintenance (I can call it Devops?) To participate in the things we see and read, you can feel "operation and maintenance" We are not very far away, but it is always in a dying cusp. I think this kind of "operation and maintenance is about to die" the majority of ideas from among those who are lucky to go to a large or old business work friends, or simply to look at the technical point of view rather than the enterprise point of view friend.
Any business still need the operation and maintenance of the work. If they were not the case, then they must have redefined the things (such as the development of wearing a hat on the operation and maintenance, and then dry up the machine to live) or temporary to outsource these things to some public PaaS service providers, as many companies do now.
This is not a simple technical architecture issues, but also a certain relationship with the business structure. In the business logic, there are different lifecycles for innovation (Dev) and stable earnings (Ops), and we have good reason to tell those who want to use the technology developed in the big direction to make the enterprise take off the developers Do not have to bear all the things, and they must also recognize this.
Here, personally, I think the biggest reason why public PaaS can not really flourish is that as business grows, companies need to regulate and simplify their operation and maintenance, which causes the operation and maintenance personnel to re- External PaaS service providers take over the work that is already operational (or, more appropriately, these companies will arrange the developers to different business cycles).
On the other hand, this is why the private PaaS service like Cloudfoundry is more of a reason than their public service brothers: they are tools for the operation and maintenance personnel, and they cater to the needs of the developers. They were so successful because they realized the true value of the operation and maintenance: they acted as a resource management tool set for the operation and maintenance personnel rather than a tool developed to replace the "operation and maintenance".
Let us not forget the operation and maintenance
However, I feel that we may again have committed the same mistakes we had made in public PaaS before this new container world. Most of the solutions used to run and manage containers in the production environment appear to be too much for development. They do not have a clear line to specify how the application should be standardized to stop the service, basic services, some of the needs should be how to achieve.
A tool like Docker Swarm is a good example of how the development and operation of the tools are used in their original perspective at the concept level. However, we still have a lot of work to do in terms of application specifications: How to define the concept of service, how they interact with other entities, what kind of agreement they should use when interacting with other entities, and so on. These are the application level specification issues.
Next we need to face a series of operational and maintenance issues: how to load the resources into our infrastructure, how to build the entities we need, how to constrain the service areas of each service and how they locate the other Service configuration entities (translators note: for example, positioning to the same IDC or network communication quality of high service entities, rather than random selection), and so on.
I was encouraged when I was concerned about tools such as Swarm and Compose that were clearly divided from different functions. However, they do not make a big difference in the development and operation of the API. For example, Compose tends to support all of the Docker CLI command-line options, and most (and perhaps not all) of the Docker CLI command-line arguments are purely development-centric.
The best thing about Docker is that it divides into a clear line for development and operation and maintenance: anything that is inside the container is developed and the outside is the world of operation and maintenance. The current version of the Compose API and the development of Swarm to some extent but it is blurred the boundaries of this division.
We are trying to make this division more clear and reflected in the actual enterprise production business. The division of manifest.yml and services.yml or the way we build the UI is some of the first attempts we have made to promote this vision. On these, we are very welcome to get some of your thoughts and feedback.
Original links: Let's not forget about Ops (translation: Wu Jiaxing proofreading: Guo Lei)
Translator: Colstuwjx , now working on an online OTA, a little art, a little technical control, a bit paranoid.