How OpenStack Fills the Gap between PaaS and IaaS
By: David M. Fishman
Once at the dawn of my career, long before OpenStack, I sent a joke to the development team by email. The joke ended with the phrase: not a single person with a three-digit IQ will argue about whether Emacs or VI is better, or vice versa. What surprised me was the answer I received, something like:
“Hey, it sounded very insulting and tactless. I can't believe you could send such an email! ”
')
If you survived the DevOps separation, you know that developers can protect their choice of development tools more aggressively than an angry frog with a sunburn. Whether this is due to frustration due to insufficient maturity or self-confidence, however, this may be one of the most serious barriers to cloud adoption and even more to OpenStack implementation.
Whether cultural differences and organizational models are the cause or consequence of IT balkanization is a controversial issue ( some points of discussion are touched upon 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 platform as a service (PaaS) a more functional solution and less so a 99-year commitment.
The tremendous progress that we have seen on the way of * aaS-authentication in the last 10 years has created a significant gap between the application developers and the infrastructure on which these applications work. Meanwhile, in the OpenStack environment there is a temptation to think that the problem is solved by expressing the elements of building the infrastructure through the ReST application programming interface.
But it just turns the problem inside out. Interfaces to cloud components based on services do not form an environment ready to use applications, not to mention an environment that serves as a reliable host and the basis for a constantly changing set of applications. Simply announcing the list of ReST application software applications will not convince developers that Cattle will become Pets. How exactly do we expect Pets-class server / application owners 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 the infrastructural constraints for their own set of applications, and the operational teams will deal with the same inconsistencies and inconsistencies that prevent them from working today. The OpenStack initiative must accept the fact that application developers need to understand the role that they will have to play in the transition to the cloud environment. We need to help developers realize why they cannot just continue to behave as before, and think about infrastructure only as something that can be blamed for the disgusting functioning and interruptions in work.
To deal with the problem, let's go in the opposite direction: what do developers need in order for their applications to work successfully in an infrastructure-as-a-service (IaaS) environment? Bridging the gap that has been formed implies that the OpenStack initiative should offer abstractions to solve real problems of a developer 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, in the OpenStack ecosystem, there is a perception that the same “aggressive modularization”, which lies at the heart of the OpenStack project, must be applied to solving the problem of organic PaaS and IaaS. Such modularization covers 3 main dimensions:
-Turning the source code into something that can work in the cloud.
-Search for applications that can be used or re-consumed.
-Generalize the deployment topology, including hardware resources and configurations, as well as executable software components.
If you are a supporter of PaaS, you can say: “Just a minute, PaaS does just that. Point". And this is not a stupid answer, as well as not enough reason to doubt the three-digit IQ. But hold on to your disbelief for a moment.
When I started programming, a little bit after people learned how to make fire and invented the wheel, the source text was something that I compiled (or hoped to compile; Visual Basic was a great success). Today, the goal is not the compiler, but the cloud, and the output is not binary, but packet data.
Of course, this is a simplified view. Most important are build tools, such as Jenkins, which run from the source tree and issue ready-to-use code. In the most promising development methods, Jenkins cloud helps to launch a process of continuous integration and continuous development, also known as CI / CD (the CI / CD mechanisms are not discussed in detail in this post). Deployment will not succeed if packaging in libraries and components is incorrectly implemented; standardization plays an important role in keeping applications up-to-date.
The OpenStack project, which is responsible for this area of ​​problem solving, is Solum . Despite the fact that some position Solum as a replacement for today's PaaS technologies , it cannot be classified as either or-or. Rather than being just an open-source PaaS, the goal of Solum is to provide services that enable PaaS to work within OpenStack.
In fact, if Solum turns out to be as intended, it will provide a toolkit that will allow any existing application, including another PaaS, to generate an artifact that can be deployed to the OpenStack cloud. The idea is that Solum will know what “such an element to be deployed” in a particular cloud for. In other words, Solum could provide an antidote to binding to PaaS.
About one level up on the stack is reusable code - fantasy is as old as I am. Cloud technologies have contributed to this. But you need to make it so that reusable, ready-to-deploy applications are easier to find and use. Why bother trying to figure out how to deploy a Tomcat server when you can just click a button to do this?
The Service Catalog is a well-known concept in the world of the ITIL Information Technology Infrastructure Library (although most application developers find that ITIL is not their problem), about as interesting as, say, the SNMP protocol. The catalog, which organizes ready-to-use cloud applications, not only eliminates the need to reinvent the wheel for your cloud application; it also provides a mechanism for distributing proven application components. App stores are directories that made mobile phones what they are today (an interesting look at the problem of finding apps is presented on Quixey .)
Of course, you do not need to often combine applications on your smartphone; what can not be said about the cloud, where it is commonplace. In this case, of course, it’s good when you don’t have to deal with the problem of deploying a database in JSON format from scratch or deal with how to customize the Microsoft SQL Server DBMS to the Windows guest OS running on KVM in OpenStack. Availability of a unified list of descriptors for requirements, functionality, access rights, etc. and setting rules for all these aspects of the application is equally critical for detection as well as for control and maintenance. Such a directory is provided by the efforts of the Murano project as part of OpenStack.
The classic definition of packaging implies that it identifies resources and relationships. In a cloud context, the resources and interconnections are distributed infrastructure. In a simplified view, IaaS defines a VM with some memory and network address where you “install” the application, as if it was 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 "talk" to the infrastructure, that your application needs, say, two networks:
- Network A has Apache servers whose IP addresses are assigned by DHCP.
Network B has a database and listeners on ports X, Y, and Z.
-The router between them with access policies defined in this way ...
If you have ever tried to deploy an application on different physical resources, you may be familiar with such dependencies. Their precise instructions (as well as consistent compliance) and debugging when problems occur are not optional or trivial.
According to the definition, a project for orchestrating cloud-based 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 an action checklist for execution, which is then converted by Heat into corresponding dependency graphs, a sequence of IaaS calls, etc., thereby promoting self-organization at the heart of the infrastructure of the primitives in a properly configured runtime environment. Why heat? Undoubtedly, one of its advantages is the lack of binding to AWS when deployed 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”, would it not be easier to deploy to PaaS and that's it? For organizations that very clearly represent the future landscape of their software, this would be just fine. For those who can take a look back at the years of technical debt (accumulated as a result of past confidence in the future of the software development plan), this may make PaaS think.
The convenience of PaaS solutions lies in the fact that they provide a unified, integrated infrastructure. You can start with the source code, and let PaaS take care of packaging, cataloging, and deployment; Try to move what is already collected in PaaS, from one IaaS to another, and this may not be so easy. 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’s as if you pulled the cartridge out of one printer and tried to use it in another, even if both printers had the same manufacturer.
It would be an exaggeration to assume that the work on OpenStack is as functionally complete as on the standard PaaS (not to mention the hosted PaaS of the Heroku type; the developer’s work experience on Heroku is quite pleasant).
But precisely such non-functional qualities as performance, scalability, security, etc. 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 is responsible for its own data storage, computing, and network resource consumption, this can easily create cloudy chaos.
Looking ahead, the OpenStack initiative is trying to find ways to simplify interoperability and interoperability between the natural diversity of the PaaS tools so that you can integrate applications from different PaaS into a single OpenStack infrastructure. For the period of the release of Juno and the release following it, the goals are:
- Starting with the build process, the Solum project will provide a set of tools for each PaaS. He will present an API that will take the source code from PaaS and generate an image that will work with packaging / runtime parameters compatible with OpenStack. The Solum project will receive build instructions from PaaS and apply them to send PaaS output to a container / guest OS / virtual machine / image, etc.
- Each PaaS has an internal, closed catalog of services. It sets important details of how the application uses each service presented based on basic parameters such as a connection string. In contrast, the OpenStack approach, expressed in the Murano project through a generalized directory structure, allows you to combine applications and services regardless of the original development environment. You get a much larger choice in the catalog by combining various PaaS or spawning services from other sources, thereby avoiding binding (in fact, Murano's strategy also aims to include a number of application packaging standards in the catalog, such as TOSCA, Parallels APS, or even Heat templates .
- The Murano catalog can trigger the generation of the Heat template during deployment to allocate the IaaS OpenStack resources needed to run a set of applications. As the infrastructure changes and new features are added to IaaS OpenStack, eliminating the attachment of the infrastructure to the application means that the infrastructure can more quickly adapt to changing requirements and components of the platform.
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 to accept this as the desired state of affairs is the same as to ignore the flow along the port side of the boat just because you are on deck along the starboard. And there are signs that the PaaS community is ready to take this opportunity seriously, as shown by recent discussions of the Cloud Foundry platform for OpenStack .
Of course, independent PaaS vendors can always just wait until the IaaS vendors adapt to their assumptions. But to rely on it recklessly. The assumption that some PaaS methods solve all past and future problems with cloud applications is probably as reliable as binding to one or another programming language of the 90s or to some other technological platform from Seattle. It is better for PaaS vendors to roll up their sleeves and contribute to the successful implementation of the Solum, Murano and Heat levels in OpenStack.
In fact, if the ongoing “Emacs or VI” disputes are some indication, then supporting better integration with OpenStack can even be a reasonable strategy among PaaS providers to ensure that they do not repeat the fate of Visual Basic.
Original article in English .
Once at the dawn of my career, long before OpenStack, I sent a joke to the development team by email. The joke ended with the phrase: not a single person with a three-digit IQ will argue about whether Emacs or VI is better, or vice versa. What surprised me was the answer I received, something like:
“Hey, it sounded very insulting and tactless. I can't believe you could send such an email! ”
')
If you survived the DevOps separation, you know that developers can protect their choice of development tools more aggressively than an angry frog with a sunburn. Whether this is due to frustration due to insufficient maturity or self-confidence, however, this may be one of the most serious barriers to cloud adoption and even more to OpenStack implementation.
Whether cultural differences and organizational models are the cause or consequence of IT balkanization is a controversial issue ( some points of discussion are touched upon 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 platform as a service (PaaS) a more functional solution and less so a 99-year commitment.
ReST does not help developers to look into the head.
The tremendous progress that we have seen on the way of * aaS-authentication in the last 10 years has created a significant gap between the application developers and the infrastructure on which these applications work. Meanwhile, in the OpenStack environment there is a temptation to think that the problem is solved by expressing the elements of building the infrastructure through the ReST application programming interface.
But it just turns the problem inside out. Interfaces to cloud components based on services do not form an environment ready to use applications, not to mention an environment that serves as a reliable host and the basis for a constantly changing set of applications. Simply announcing the list of ReST application software applications will not convince developers that Cattle will become Pets. How exactly do we expect Pets-class server / application owners 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 the infrastructural constraints for their own set of applications, and the operational teams will deal with the same inconsistencies and inconsistencies that prevent them from working today. The OpenStack initiative must accept the fact that application developers need to understand the role that they will have to play in the transition to the cloud environment. We need to help developers realize why they cannot just continue to behave as before, and think about infrastructure only as something that can be blamed for the disgusting functioning and interruptions in work.
The state of affairs between PaaS and IaaS
To deal with the problem, let's go in the opposite direction: what do developers need in order for their applications to work successfully in an infrastructure-as-a-service (IaaS) environment? Bridging the gap that has been formed implies that the OpenStack initiative should offer abstractions to solve real problems of a developer 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, in the OpenStack ecosystem, there is a perception that the same “aggressive modularization”, which lies at the heart of the OpenStack project, must be applied to solving the problem of organic PaaS and IaaS. Such modularization covers 3 main dimensions:
-Turning the source code into something that can work in the cloud.
-Search for applications that can be used or re-consumed.
-Generalize the deployment topology, including hardware resources and configurations, as well as executable software components.
If you are a supporter of PaaS, you can say: “Just a minute, PaaS does just that. Point". And this is not a stupid answer, as well as not enough reason to doubt the three-digit IQ. But hold on to your disbelief for a moment.
Solum: send source code to the cloud
When I started programming, a little bit after people learned how to make fire and invented the wheel, the source text was something that I compiled (or hoped to compile; Visual Basic was a great success). Today, the goal is not the compiler, but the cloud, and the output is not binary, but packet data.
Of course, this is a simplified view. Most important are build tools, such as Jenkins, which run from the source tree and issue ready-to-use code. In the most promising development methods, Jenkins cloud helps to launch a process of continuous integration and continuous development, also known as CI / CD (the CI / CD mechanisms are not discussed in detail in this post). Deployment will not succeed if packaging in libraries and components is incorrectly implemented; standardization plays an important role in keeping applications up-to-date.
The OpenStack project, which is responsible for this area of ​​problem solving, is Solum . Despite the fact that some position Solum as a replacement for today's PaaS technologies , it cannot be classified as either or-or. Rather than being just an open-source PaaS, the goal of Solum is to provide services that enable PaaS to work within OpenStack.
In fact, if Solum turns out to be as intended, it will provide a toolkit that will allow any existing application, including another PaaS, to generate an artifact that can be deployed to the OpenStack cloud. The idea is that Solum will know what “such an element to be deployed” in a particular cloud for. In other words, Solum could provide an antidote to binding to PaaS.
Murano: do I need to do this, or is someone already doing this?
About one level up on the stack is reusable code - fantasy is as old as I am. Cloud technologies have contributed to this. But you need to make it so that reusable, ready-to-deploy applications are easier to find and use. Why bother trying to figure out how to deploy a Tomcat server when you can just click a button to do this?
The Service Catalog is a well-known concept in the world of the ITIL Information Technology Infrastructure Library (although most application developers find that ITIL is not their problem), about as interesting as, say, the SNMP protocol. The catalog, which organizes ready-to-use cloud applications, not only eliminates the need to reinvent the wheel for your cloud application; it also provides a mechanism for distributing proven application components. App stores are directories that made mobile phones what they are today (an interesting look at the problem of finding apps is presented on Quixey .)
Of course, you do not need to often combine applications on your smartphone; what can not be said about the cloud, where it is commonplace. In this case, of course, it’s good when you don’t have to deal with the problem of deploying a database in JSON format from scratch or deal with how to customize the Microsoft SQL Server DBMS to the Windows guest OS running on KVM in OpenStack. Availability of a unified list of descriptors for requirements, functionality, access rights, etc. and setting rules for all these aspects of the application is equally critical for detection as well as for control and maintenance. Such a directory is provided by the efforts of the Murano project as part of OpenStack.
Deployment: Identify the resources that applications need on the cloud
The classic definition of packaging implies that it identifies resources and relationships. In a cloud context, the resources and interconnections are distributed infrastructure. In a simplified view, IaaS defines a VM with some memory and network address where you “install” the application, as if it was 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 "talk" to the infrastructure, that your application needs, say, two networks:
- Network A has Apache servers whose IP addresses are assigned by DHCP.
Network B has a database and listeners on ports X, Y, and Z.
-The router between them with access policies defined in this way ...
If you have ever tried to deploy an application on different physical resources, you may be familiar with such dependencies. Their precise instructions (as well as consistent compliance) and debugging when problems occur are not optional or trivial.
According to the definition, a project for orchestrating cloud-based 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 an action checklist for execution, which is then converted by Heat into corresponding dependency graphs, a sequence of IaaS calls, etc., thereby promoting self-organization at the heart of the infrastructure of the primitives in a properly configured runtime environment. Why heat? Undoubtedly, one of its advantages is the lack of binding to AWS when deployed 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 into the future?
So, after such a “gap analysis”, would it not be easier to deploy to PaaS and that's it? For organizations that very clearly represent the future landscape of their software, this would be just fine. For those who can take a look back at the years of technical debt (accumulated as a result of past confidence in the future of the software development plan), this may make PaaS think.
The convenience of PaaS solutions lies in the fact that they provide a unified, integrated infrastructure. You can start with the source code, and let PaaS take care of packaging, cataloging, and deployment; Try to move what is already collected in PaaS, from one IaaS to another, and this may not be so easy. 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’s as if you pulled the cartridge out of one printer and tried to use it in another, even if both printers had the same manufacturer.
It would be an exaggeration to assume that the work on OpenStack is as functionally complete as on the standard PaaS (not to mention the hosted PaaS of the Heroku type; the developer’s work experience on Heroku is quite pleasant).
But precisely such non-functional qualities as performance, scalability, security, etc. 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 is responsible for its own data storage, computing, and network resource consumption, this can easily create cloudy chaos.
Looking ahead, the OpenStack initiative is trying to find ways to simplify interoperability and interoperability between the natural diversity of the PaaS tools so that you can integrate applications from different PaaS into a single OpenStack infrastructure. For the period of the release of Juno and the release following it, the goals are:
- Starting with the build process, the Solum project will provide a set of tools for each PaaS. He will present an API that will take the source code from PaaS and generate an image that will work with packaging / runtime parameters compatible with OpenStack. The Solum project will receive build instructions from PaaS and apply them to send PaaS output to a container / guest OS / virtual machine / image, etc.
- Each PaaS has an internal, closed catalog of services. It sets important details of how the application uses each service presented based on basic parameters such as a connection string. In contrast, the OpenStack approach, expressed in the Murano project through a generalized directory structure, allows you to combine applications and services regardless of the original development environment. You get a much larger choice in the catalog by combining various PaaS or spawning services from other sources, thereby avoiding binding (in fact, Murano's strategy also aims to include a number of application packaging standards in the catalog, such as TOSCA, Parallels APS, or even Heat templates .
- The Murano catalog can trigger the generation of the Heat template during deployment to allocate the IaaS OpenStack resources needed to run a set of applications. As the infrastructure changes and new features are added to IaaS OpenStack, eliminating the attachment of the infrastructure to the application means that the infrastructure can more quickly adapt to changing requirements and components of the platform.
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 to accept this as the desired state of affairs is the same as to ignore the flow along the port side of the boat just because you are on deck along the starboard. And there are signs that the PaaS community is ready to take this opportunity seriously, as shown by recent discussions of the Cloud Foundry platform for OpenStack .
Of course, independent PaaS vendors can always just wait until the IaaS vendors adapt to their assumptions. But to rely on it recklessly. The assumption that some PaaS methods solve all past and future problems with cloud applications is probably as reliable as binding to one or another programming language of the 90s or to some other technological platform from Seattle. It is better for PaaS vendors to roll up their sleeves and contribute to the successful implementation of the Solum, Murano and Heat levels in OpenStack.
In fact, if the ongoing “Emacs or VI” disputes are some indication, then supporting better integration with OpenStack can even be a reasonable strategy among PaaS providers to ensure that they do not repeat the fate of Visual Basic.
Original article in English .
Source: https://habr.com/ru/post/243761/
All Articles