How OpenStack fills the gap between PaaS and IaaS
Posted by David M. Fishman
One day at the dawn of my career, long before OpenStack, I emailed a joke to a development team. The joke ended with the phrase: not a single person with a three-digit IQ will argue about which is better - Emacs or VI, or vice versa. What surprised me was the answer I received, something like:
“Hey, that sounded very insulting and tactless. I can’t believe that you could send such an email! ”
If you survived the DevOps separation, you know that developers can defend their choice of development tools more aggressively than an angry frog with a sunburn. Whether this is due to the disorder due to lack of maturity or the reason for this self-confidence, however, this may be one of the most serious barriers to the implementation of the cloud and even greater for the implementation of OpenStack.
Whether cultural differences and organizational models are the cause or consequence of IT balkanization is a moot point ( some points of discussion are covered in our blog here) Be that as it may, my goal is to consider how OpenStack openly solves this split problem, making the choice of a platform as a service (PaaS) a developer a more functional solution and, to a lesser extent, a 99-year commitment.
The tremendous progress that we have seen along the path of * aaS-authentication over the past 10 years has created a significant gap between application developers and the infrastructure on which these applications work. Meanwhile, in the OpenStack environment, it is tempting to think that the problem is solved by expressing the elements of building the infrastructure through the ReST application programming interface.
But this is just turning the problem inside out. Interfaces to cloud-based components based on services do not form an environment ready for use by applications, not to mention an environment that serves as a reliable host and basis for a constantly changing set of applications. Just announcing the ReST application software list will not convince developers that Cattle will become Pets. How exactly do we expect the owners of Pets-class servers / applications to turn “cats” and “dogs” into “meat and dairy plants”? Pet applications run on Pet servers.
With their own set of devices, development teams will dictate infrastructure restrictions for their own set of applications, and operating teams will deal with the same inconsistencies and fragmentation that prevent them from working today. The OpenStack initiative should accept the fact that it is application developers who need to understand the role they will have to play in the transition to the cloud. We need to help developers realize why they can’t just continue to behave as before and think of infrastructure exclusively as something that can be blamed for the abominable functioning and interruptions in their work.
To deal with the problem, let's go in the opposite direction: what do developers need for their applications to work successfully in an infrastructure as a service (IaaS) environment? Bridging the abyss implies that the OpenStack initiative should offer abstractions to solve real developer problems in a way that is appropriate for the developer. To do this, OpenStack has several projects designed to help PaaS developers create an environment in which they can succeed.
Today, the OpenStack ecosystem is of the opinion that it is necessary to apply the same “aggressive modularization” that underlies the OpenStack project to solve the problem of the organic connection of PaaS and IaaS. Such modularization covers 3 main dimensions:
-Turning source code into something that can work in the cloud.
-Search for applications that can be used or reused.
- A generalization of the deployment topology, including hardware resources and configurations, as well as executable software components.
If you are a PaaS supporter, then you can say: “Wait a minute, PaaS does just that. Point". And this is not a stupid answer, nor is there a sufficient basis for doubting the three-digit IQ. But hold your unbelief for a moment.
When I started programming, not long after people learned how to make fire and invented the wheel, the source code was something that I compiled (or hoped to compile; Visual Basic was a great success). Today, the goal is not a compiler, but a cloud, and the output is not binary, but packet data.
Of course, this is a simplified view. Build tools such as Jenkins, which work from the source tree and produce ready-to-use code, are essential. In the most promising cloud development methods, Jenkins helps launch the process of continuous integration and continuous development, also known as CI / CD (CI / CD mechanisms are not discussed in detail in this post). Deployment will not be successful if the packaging to libraries and components is incorrect; standardization plays an important role in keeping applications up to date.
The OpenStack project that is responsible for this area of problem solving is Solum . Despite some positioning Solum as a replacement for today's PaaS technology, it can not be classified as "either-or." Instead of being just a public PaaS, Solum's goal is to provide services that enable PaaS to function within OpenStack.
In fact, if Solum succeeds as intended, it will provide a toolkit that will allow any existing application, including another PaaS, to generate an artifact that can be deployed on the OpenStack cloud. The idea is that Solum will know what “such-and-such deployable element” is needed in a particular cloud. In other words, Solum could provide the antidote to binding to PaaS.
About one level higher on the stack is reusable code - a fantasy as old as myself. Cloud technologies have contributed to this. But you need to make reusable deployment-ready applications easier to find and use. Why puzzle over trying to figure out how to deploy a Tomcat server when you can just click a button for that?
A “service catalog” is a well-known concept in the world of the ITIL library of information technology infrastructure (although most application developers believe that ITIL is not their problem), it’s about as interesting as, say, the SNMP protocol. The directory that organizes ready-to-use cloud applications does not only eliminate the need to reinvent the wheel for your cloud application; but also provides a mechanism for distributing proven application components. Application stores are the catalogs that made mobile phones what they are today (an interesting look at the problem of finding applications is presented at Quixey .)
Of course, you do not need to often combine applications on your smartphone; which cannot be said of the cloud, where it is a common occurrence. At the same time, it is undoubtedly good when you do not have to deal with the problem of deploying a database in JSON format from scratch or figure out how to adapt Microsoft SQL Server DBMS to Windows guest OS running on KVM in OpenStack. The presence of a unified list of descriptors for requirements, functionality, access rights, etc. and establishing rules for all of these aspects of the application is equally critical for both discovery and management and maintenance. Such a catalog is provided by the efforts of the Murano project as part of OpenStack.
The classic definition of packaging implies that, with its help, resources and relationships are defined. In the context of the cloud, resources and relationships are distributed infrastructure. In a simplified view, IaaS defines a VM with some memory and a network address where you “install” the application, as if it were running on a pair of Mac Mini computers and through a router at your desk.
Of course, all this does not work so well in a distributed environment with many infrastructure resources. In the cloud, you need the ability to “tell” the infrastructure that your application needs, say, two networks:
-Network A has Apache servers whose IP addresses are assigned by the DHCP protocol.
-Network B has a database and listeners on ports X, Y, and Z.
-A router between them with access policies defined in such a way ...
If you have ever tried to deploy an application on different physical resources, you may be familiar with such dependencies. Their exact indication (as well as consistent compliance) and debugging when problems arise are not optional or trivial.
By definition, a project to orchestrate cloud applications based on OpenStack , or Heat, modeled on AWS CloudFormation, is designed to solve this problem. This is a declarative language that should answer the question: “What does your application need?” Heat creates the equivalent of a checklist for execution, which is then converted by the Heat engine to the appropriate dependency graphs, IaaS call sequence, etc., thereby contributing to the self-organization of the underlying infrastructure primitives in a properly configured runtime. Why heat? Undoubtedly, one of its advantages is the lack of binding to AWS when deploying to OpenStack. But another plus is that if you change the infrastructure, you can take advantage of the new components.
So, after such a “gap analysis”, wouldn’t it be easier to deploy to PaaS and that's it? For organizations that have a very clear idea of the future landscape of their software, this would be great. Those who can take a look back at the years of technical debt (accumulated as a result of past confidence in the future software development plan) can make PaaS think.
The convenience of PaaS solutions lies in the fact that they provide a single, integrated infrastructure. You can start with the source code, and PaaS can take care of packaging, cataloging, and deployment; try moving what is already compiled in PaaS from one IaaS to another, and this may not be so simple. Each PaaS has its own way of containerizing the application, sometimes no more than by configuring a separate VM image on which the application will run, and giving it freedom in your infrastructure.
Moving an application from one PaaS to another is also not an easy task. It is as if you pulled a cartridge from one printer and tried to use it in another, even if both printers have the same manufacturer.
It would be an exaggeration to assume that work on OpenStack is as functionally complete as on standard PaaS (not to mention hosted PaaS like Heroku; the experience of the developer on Heroku is quite pleasant).
But it is precisely such non-functional qualities as performance, scalability, security, etc. that should make OpenStack a more attractive alternative. And if you imagine a cloud on which many different applications can work together in varying degrees of operational harmony, then you should think about PaaS (well, this is the last time I use this phrase). If each application will be responsible for its own data storage, computing and consumption of network resources, then this can easily generate cloud chaos.
Looking ahead, the OpenStack initiative is trying to find ways to simplify the interoperability and interoperability between the natural diversity of PaaS tools so that you can integrate applications from different PaaS into a uniform OpenStack infrastructure. For the period of the Juno release and the next release following it, the goals are as follows:
- Starting with the build process, the Solum project will provide a set of tools for each PaaS. He will introduce an API that will take the source code from PaaS and generate an image that will work with packaging options / runtime compatible with OpenStack. The Solum project will receive build instructions from PaaS and use them to route PaaS output to a container / guest OS / virtual machine / image, etc.
- Each PaaS has an internal, closed service catalog. It sets important details of how the application uses each service presented based on such basic parameters as the connection string. In contrast, the OpenStack approach, expressed in the Murano project through a generic directory structure, allows you to combine applications and services regardless of the original development environment. You get much more choice in the catalog by combining different PaaS or generating services from other sources, thereby avoiding binding (in fact, the Murano strategy also aims to include a number of application packaging standards in the catalog, such as TOSCA, Parallels APS, or even Heat patterns .
- The Murano directory can start generating the Heat pattern during deployment to distribute the IaaS OpenStack resources needed to run the application suite. As the infrastructure changes and new features are added to IaaS OpenStack, removing the binding of the infrastructure to the application means that the infrastructure can more quickly adapt to changing platform requirements and components.
In keeping with the initial focus on infrastructure, the OpenStack initiative today can offer more on the deployment side than on the development side in the resulting gap between PaaS and IaaS. But accepting this as the desired state of affairs is the same as ignoring the flow on the port side of the boat just because you are on deck on the port side. And there are signs that the PaaS community is ready to take this opportunity seriously, as recent discussions of the Cloud Foundry platform for OpenStack show .
Of course, independent PaaS vendors can always just wait while IaaS vendors adapt to their assumptions. But betting on it is reckless. The assumption that some PaaS methods solve all past and future problems with cloud applications is probably as reliable as binding to a particular programming language of the 90s era or to some other technology platform from Seattle. Better PaaS vendors roll up their sleeves and contribute to the successful implementation of the Solum, Murano and Heat levels as part of OpenStack.
In fact, while ongoing Emacs or VI disputes are some indication, supporting better integration with OpenStack may even be a smart strategy among PaaS vendors to ensure that they don’t repeat the fate of Visual Basic.
Original articlein English .
One day at the dawn of my career, long before OpenStack, I emailed a joke to a development team. The joke ended with the phrase: not a single person with a three-digit IQ will argue about which is better - Emacs or VI, or vice versa. What surprised me was the answer I received, something like:
“Hey, that sounded very insulting and tactless. I can’t believe that you could send such an email! ”
If you survived the DevOps separation, you know that developers can defend their choice of development tools more aggressively than an angry frog with a sunburn. Whether this is due to the disorder due to lack of maturity or the reason for this self-confidence, however, this may be one of the most serious barriers to the implementation of the cloud and even greater for the implementation of OpenStack.
Whether cultural differences and organizational models are the cause or consequence of IT balkanization is a moot point ( some points of discussion are covered in our blog here) Be that as it may, my goal is to consider how OpenStack openly solves this split problem, making the choice of a platform as a service (PaaS) a developer a more functional solution and, to a lesser extent, a 99-year commitment.
ReST won't help developers get a head start
The tremendous progress that we have seen along the path of * aaS-authentication over the past 10 years has created a significant gap between application developers and the infrastructure on which these applications work. Meanwhile, in the OpenStack environment, it is tempting to think that the problem is solved by expressing the elements of building the infrastructure through the ReST application programming interface.
But this is just turning the problem inside out. Interfaces to cloud-based components based on services do not form an environment ready for use by applications, not to mention an environment that serves as a reliable host and basis for a constantly changing set of applications. Just announcing the ReST application software list will not convince developers that Cattle will become Pets. How exactly do we expect the owners of Pets-class servers / applications to turn “cats” and “dogs” into “meat and dairy plants”? Pet applications run on Pet servers.
With their own set of devices, development teams will dictate infrastructure restrictions for their own set of applications, and operating teams will deal with the same inconsistencies and fragmentation that prevent them from working today. The OpenStack initiative should accept the fact that it is application developers who need to understand the role they will have to play in the transition to the cloud. We need to help developers realize why they can’t just continue to behave as before and think of infrastructure exclusively as something that can be blamed for the abominable functioning and interruptions in their work.
Status between PaaS and IaaS
To deal with the problem, let's go in the opposite direction: what do developers need for their applications to work successfully in an infrastructure as a service (IaaS) environment? Bridging the abyss implies that the OpenStack initiative should offer abstractions to solve real developer problems in a way that is appropriate for the developer. To do this, OpenStack has several projects designed to help PaaS developers create an environment in which they can succeed.
Today, the OpenStack ecosystem is of the opinion that it is necessary to apply the same “aggressive modularization” that underlies the OpenStack project to solve the problem of the organic connection of PaaS and IaaS. Such modularization covers 3 main dimensions:
-Turning source code into something that can work in the cloud.
-Search for applications that can be used or reused.
- A generalization of the deployment topology, including hardware resources and configurations, as well as executable software components.
If you are a PaaS supporter, then you can say: “Wait a minute, PaaS does just that. Point". And this is not a stupid answer, nor is there a sufficient basis for doubting the three-digit IQ. But hold your unbelief for a moment.
Solum: sending source code to the cloud
When I started programming, not long after people learned how to make fire and invented the wheel, the source code was something that I compiled (or hoped to compile; Visual Basic was a great success). Today, the goal is not a compiler, but a cloud, and the output is not binary, but packet data.
Of course, this is a simplified view. Build tools such as Jenkins, which work from the source tree and produce ready-to-use code, are essential. In the most promising cloud development methods, Jenkins helps launch the process of continuous integration and continuous development, also known as CI / CD (CI / CD mechanisms are not discussed in detail in this post). Deployment will not be successful if the packaging to libraries and components is incorrect; standardization plays an important role in keeping applications up to date.
The OpenStack project that is responsible for this area of problem solving is Solum . Despite some positioning Solum as a replacement for today's PaaS technology, it can not be classified as "either-or." Instead of being just a public PaaS, Solum's goal is to provide services that enable PaaS to function within OpenStack.
In fact, if Solum succeeds as intended, it will provide a toolkit that will allow any existing application, including another PaaS, to generate an artifact that can be deployed on the OpenStack cloud. The idea is that Solum will know what “such-and-such deployable element” is needed in a particular cloud. In other words, Solum could provide the antidote to binding to PaaS.
Murano: do I need to do this, or is someone already doing this?
About one level higher on the stack is reusable code - a fantasy as old as myself. Cloud technologies have contributed to this. But you need to make reusable deployment-ready applications easier to find and use. Why puzzle over trying to figure out how to deploy a Tomcat server when you can just click a button for that?
A “service catalog” is a well-known concept in the world of the ITIL library of information technology infrastructure (although most application developers believe that ITIL is not their problem), it’s about as interesting as, say, the SNMP protocol. The directory that organizes ready-to-use cloud applications does not only eliminate the need to reinvent the wheel for your cloud application; but also provides a mechanism for distributing proven application components. Application stores are the catalogs that made mobile phones what they are today (an interesting look at the problem of finding applications is presented at Quixey .)
Of course, you do not need to often combine applications on your smartphone; which cannot be said of the cloud, where it is a common occurrence. At the same time, it is undoubtedly good when you do not have to deal with the problem of deploying a database in JSON format from scratch or figure out how to adapt Microsoft SQL Server DBMS to Windows guest OS running on KVM in OpenStack. The presence of a unified list of descriptors for requirements, functionality, access rights, etc. and establishing rules for all of these aspects of the application is equally critical for both discovery and management and maintenance. Such a catalog is provided by the efforts of the Murano project as part of OpenStack.
Deployment: Identify the resources required by cloud applications
The classic definition of packaging implies that, with its help, resources and relationships are defined. In the context of the cloud, resources and relationships are distributed infrastructure. In a simplified view, IaaS defines a VM with some memory and a network address where you “install” the application, as if it were running on a pair of Mac Mini computers and through a router at your desk.
Of course, all this does not work so well in a distributed environment with many infrastructure resources. In the cloud, you need the ability to “tell” the infrastructure that your application needs, say, two networks:
-Network A has Apache servers whose IP addresses are assigned by the DHCP protocol.
-Network B has a database and listeners on ports X, Y, and Z.
-A router between them with access policies defined in such a way ...
If you have ever tried to deploy an application on different physical resources, you may be familiar with such dependencies. Their exact indication (as well as consistent compliance) and debugging when problems arise are not optional or trivial.
By definition, a project to orchestrate cloud applications based on OpenStack , or Heat, modeled on AWS CloudFormation, is designed to solve this problem. This is a declarative language that should answer the question: “What does your application need?” Heat creates the equivalent of a checklist for execution, which is then converted by the Heat engine to the appropriate dependency graphs, IaaS call sequence, etc., thereby contributing to the self-organization of the underlying infrastructure primitives in a properly configured runtime. Why heat? Undoubtedly, one of its advantages is the lack of binding to AWS when deploying to OpenStack. But another plus is that if you change the infrastructure, you can take advantage of the new components.
Can PaaS take a step back to the future?
So, after such a “gap analysis”, wouldn’t it be easier to deploy to PaaS and that's it? For organizations that have a very clear idea of the future landscape of their software, this would be great. Those who can take a look back at the years of technical debt (accumulated as a result of past confidence in the future software development plan) can make PaaS think.
The convenience of PaaS solutions lies in the fact that they provide a single, integrated infrastructure. You can start with the source code, and PaaS can take care of packaging, cataloging, and deployment; try moving what is already compiled in PaaS from one IaaS to another, and this may not be so simple. Each PaaS has its own way of containerizing the application, sometimes no more than by configuring a separate VM image on which the application will run, and giving it freedom in your infrastructure.
Moving an application from one PaaS to another is also not an easy task. It is as if you pulled a cartridge from one printer and tried to use it in another, even if both printers have the same manufacturer.
It would be an exaggeration to assume that work on OpenStack is as functionally complete as on standard PaaS (not to mention hosted PaaS like Heroku; the experience of the developer on Heroku is quite pleasant).
But it is precisely such non-functional qualities as performance, scalability, security, etc. that should make OpenStack a more attractive alternative. And if you imagine a cloud on which many different applications can work together in varying degrees of operational harmony, then you should think about PaaS (well, this is the last time I use this phrase). If each application will be responsible for its own data storage, computing and consumption of network resources, then this can easily generate cloud chaos.
Looking ahead, the OpenStack initiative is trying to find ways to simplify the interoperability and interoperability between the natural diversity of PaaS tools so that you can integrate applications from different PaaS into a uniform OpenStack infrastructure. For the period of the Juno release and the next release following it, the goals are as follows:
- Starting with the build process, the Solum project will provide a set of tools for each PaaS. He will introduce an API that will take the source code from PaaS and generate an image that will work with packaging options / runtime compatible with OpenStack. The Solum project will receive build instructions from PaaS and use them to route PaaS output to a container / guest OS / virtual machine / image, etc.
- Each PaaS has an internal, closed service catalog. It sets important details of how the application uses each service presented based on such basic parameters as the connection string. In contrast, the OpenStack approach, expressed in the Murano project through a generic directory structure, allows you to combine applications and services regardless of the original development environment. You get much more choice in the catalog by combining different PaaS or generating services from other sources, thereby avoiding binding (in fact, the Murano strategy also aims to include a number of application packaging standards in the catalog, such as TOSCA, Parallels APS, or even Heat patterns .
- The Murano directory can start generating the Heat pattern during deployment to distribute the IaaS OpenStack resources needed to run the application suite. As the infrastructure changes and new features are added to IaaS OpenStack, removing the binding of the infrastructure to the application means that the infrastructure can more quickly adapt to changing platform requirements and components.
Conclusion
In keeping with the initial focus on infrastructure, the OpenStack initiative today can offer more on the deployment side than on the development side in the resulting gap between PaaS and IaaS. But accepting this as the desired state of affairs is the same as ignoring the flow on the port side of the boat just because you are on deck on the port side. And there are signs that the PaaS community is ready to take this opportunity seriously, as recent discussions of the Cloud Foundry platform for OpenStack show .
Of course, independent PaaS vendors can always just wait while IaaS vendors adapt to their assumptions. But betting on it is reckless. The assumption that some PaaS methods solve all past and future problems with cloud applications is probably as reliable as binding to a particular programming language of the 90s era or to some other technology platform from Seattle. Better PaaS vendors roll up their sleeves and contribute to the successful implementation of the Solum, Murano and Heat levels as part of OpenStack.
In fact, while ongoing Emacs or VI disputes are some indication, supporting better integration with OpenStack may even be a smart strategy among PaaS vendors to ensure that they don’t repeat the fate of Visual Basic.
Original articlein English .