What is the reason for the slow development of PaaS?

[Editor's note] The author is Google App Engine's early users, IaaS, PaaS development has been concerned about the author analysis of the reasons for the slow development of the PaaS platform, including cost, lock-in and user habits several factors, but the author thinks These are temporary, and a large-scale PaaS era is coming.

In 2009, I found the Google App engine, and since then I liked it. It expects the goal: to allow any software developer can build any person in any place, 7 days 24 hours can use the web service. Developers no longer have to worry about service configuration, or database startup, operating system version, security patches, or load balancing and so on. Applications can be automatically extended! All that the user needs to do is complete the code, and everything else is handled by App Engine.

  • Where is Docker's "next hop"?
  • DassOne Share (79): Building Enterprise-Class PaaS Cloud Platform Practice Based on Container Technology
  • 2015 Docker and other subversive trends in IT
  • Why is the current PaaS unsuccessful? Talking about the development direction of cloud computing
  • Together to test the first domestic Docker-based cloud platform
  • Look at CaaS (container service) from PaaS's front desk
  • In 2009, all this for me is somewhat incredible, by 2015, most of the code has been able to run on such a similar platform. In fact, no one wants to spend time on basic configuration and operation and maintenance work. These platforms freed the system administrator from the heavy work of the restraint (I mean that the traditional system administrator or dismissed, or by the platform provider hired, transformed into a developer). The last ideal state is that we are free to write our code without worrying about how the code is executed and where it is being executed. Developers will be liberated from the operation and maintenance tool chain, no longer care about the application of automatic scaling, only need to care about the details of the code can be specific.

    Yes, but so far, in actual production, not exactly as described above.

    what is the reason?

    The current product is still far from the " one write, run everywhere " function, App Engine is actually in the realization, and also continue to achieve its initial goal. (Which is why I still use App Engine to make slides). At present, in the user's view, it may be a series of hard-to-understand instructions, as well as occasional puzzling memory leaks and waiting times. Just like a Google employee said: "Although App Engine is very surprising, no matter how many users are using, they are running as slow as they are."

    There are many other PaaS competitors. Even the AWS, known as the bottom of the basic set of virtual computing aspects of the uncrowned king, also began to provide Elastic Beanstalk PaaS services. I often use the professional services provided by Heroku , and it does have a lot of good things to do: it's not as good as App Engine in dealing with asynchronous tasks or automatic load balancing, but in git-push-to-deploy, As well as the PostgreSQL database to do better. But it does not provide a large number of available APIs, so the use of the scene has been limited. Google's API is perfect, through these APIs you can almost any scene to use the appropriate service. Running your code on Google's platform (more or less) is good and bad, and that's what you need to weigh. It now appears that even Google itself does not seem to be obsessed with the concepts that they put forward in 2009. In 2012, probably not satisfied with the success of App Engine, they launched a new project that is Google Compute Engine , the project has become a direct competitor to Amazon Web Services. Of course, the two of them in addition to the basic provision of services, but also to provide users with many other convenience. However, in the same peers that provide PaaS services, both of them seem to have varying degrees of retrogression in terms of ease of use, flexibility, and development time. Why i feel something wrong? Why does PaaS develop so slowly?

    Although the PaaS field has achieved some success, the famous Snapchat , can run on App Engine, as Khan Academy did, Genius and Product Hunt can run on Heroku. There are many start-up companies and relatively mature companies are using the services they provide. But if the PaaS platform is more successful, Google will not worry about Compute Engine. If the PaaS platform can be more successful, Docker will not be as popular as it is now, and if PaaS is more successful, DevOps will not be so valued as it is now.

    Why are people still keen to use AWS and Compute Engine? Why did App Engine and Heroku and Elastic Beanstalk not fully occupy the market? Is fine granularity of resource control really so important?

    I think the reason comes from the following three aspects: cost, lock-in, and user habits.

    App Engine prices are declining, but the price is still relatively expensive and the price is also very puzzling. Give an example: rent a small virtual machine, one day need to spend more than a dollar, which does not include storage and bandwidth spending. Using Heroku is also basically the same price. Although this can provide users with many benefits, if the user to buy their own servers, there may be a lot of trouble operation and maintenance operations, to a large extent reduce the development time. But I think the current price of the service is still relatively expensive.

    There is also an aspect of lock-in, once the user in the App Engine provided API on the basis of building their own services, it is equivalent to making a commitment, if the user wants to go back operation or want to switch to other service platform , It will become very difficult. For other PaaS providers, the lock-in phenomenon may be less, but it still exists. There is still no generic PaaS standard, such as the OpenStack and Docker standards on the IaaS layer.

    The third aspect, it seems most likely to be overlooked, it may be the most important factor is the user habits. As a company, there is usually no desire to give up control of their own systems. Even if this control will make the company spend a lot of energy, and understand that, as a system administrator, they do not want to exclude themselves from the work of the system management.

    In my opinion, all the reasons for these three aspects are the reasons for the slow development of PaaS, but I think these are temporary. The cost will continue to decline, the user habits will gradually change, and there are already some signals that a stable, standardized PaaS service is coming. (You might think Docker is making big strides in this area)

    In the early days of the electrical age, the factories had their own generators. In the end, however, they all use a unified grid to provide electricity. The IaaS service concept is similar to each company getting power from the grid. But it is still very difficult to use, for example, for the company, the need to provide three-phase AC power grid into a single-phase power in order to use. For the IaaS platform is also used, the company needs to be based on the original service on the basis of further customization. I think we are currently moving to a large-scale PaaS era, developers only need to write can run the code can, do not need to know or care about the problem of the server, which is now occurring, but may be better than I think Slow down some.

    The original link: Whatever Happened To PaaS? (Translation: Wang Zhe proofreading: Li Yingjie)

    ===========================
    Translator introduction <br /> Wang Zhe, Zhejiang University SEL laboratory graduate, currently in the cloud platform team engaged in scientific research and development work. Zhejiang University team PaaS, Docker, large data and mainstream open source cloud computing technology has in-depth research and secondary development experience, the team is now part of the community will contribute to the technical articles, hoping to help readers.

    Heads up! This alert needs your attention, but it's not super important.