Recommended
Recommended
More Related Content
What's hot
What's hot (20)
Similar to PaaS, IaaS and the Code-to-Cloud Toolchain
Similar to PaaS, IaaS and the Code-to-Cloud Toolchain (20)
More from aedocw
More from aedocw (6)
Recently uploaded
Recently uploaded (20)
PaaS, IaaS and the Code-to-Cloud Toolchain
- 1. © MIRANTIS 2014 PAGE ‹#›© MIRANTIS 2014 PaaS, IaaS and the Code-to- Cloud Toolchain Christopher Aedo Chief Product Architect
- 2. © MIRANTIS 2014 PAGE ‹#› Welcome! Cloud Open API Wall Street User Community
- 3. © MIRANTIS 2014 PAGE ‹#› PaaS Defined NIST: The capability provided to the consumer is to deploy onto the cloud infrastructure consumer- created or acquired applications created using programming languages, libraries, services, and tools supported by the provider. The consumer does not manage or control the underlying cloud infrastructure including network, servers, operating systems, or storage, but has control over the deployed applications and possibly configuration settings for the application-hosting environment.
- 4. © MIRANTIS 2014 PAGE ‹#› PaaS Defined An abstraction layer above your infrastructure providing a framework to address that infrastructure, along with a standard way to package, distribute and deploy your code.
- 5. © MIRANTIS 2014 PAGE ‹#› What’s Needed? What should a PaaS deliver? • Integrated framework to: • Build • Package • Deploy
- 6. © MIRANTIS 2014 PAGE ‹#› What’s Needed? What else should a PaaS deliver? • Ease of use? • Portability? • Catalog of available components? • Distance from infrastructure?
- 7. © MIRANTIS 2014 PAGE ‹#› Existing Examples • Cloud Formation (AWS) • Cloud Foundry (Pivotal) • OpenShift (RedHat) • APS (Parallels) • Heroku (PaaS-as-a-service?) • Azure (PaaS-ish components)
- 8. © MIRANTIS 2014 PAGE ‹#› What Next? Building a PaaS requires: • Open tooling (for transparent contiguity) • Open platform • Open community • (building your own from scratch could be difficult)
- 9. © MIRANTIS 2014 PAGE ‹#› OpenStack! Why? • Perfect platform: open source IaaS • Focused on App Dev Enablement • Tool chain exists • It’s constantly improving
- 10. © MIRANTIS 2014 PAGE ‹#› Heat • OpenStack Orchestration Engine • Inspired by Cloud Formation • Foundation for other OpenStack components
- 11. © MIRANTIS 2014 PAGE ‹#› Mistral • Workflow as a service • Intelligent task manager
- 12. © MIRANTIS 2014 PAGE ‹#› Murano • Application catalog project • Embed complicated deployment rules • Simpler for developers
- 13. © MIRANTIS 2014 PAGE ‹#› Solum • Convert code to managed application (a build pipeline) • Delivers application artifacts • Pre-incubation OpenStack project
- 14. © MIRANTIS 2014 PAGE ‹#› Sounds familiar… TOSCA • Topology and Orchestration Specification for Cloud Applications • Very thorough spec
- 15. © MIRANTIS 2014 PAGE ‹#› OpenStack mapping TOSCA translation • Deployment -> Heat • Components, relations, requirements, capabilities - > Murano • Workflows-Plans -> Mistral Workflow • Artifacts -> Glance • (No build process in TOSCA)
- 16. © MIRANTIS 2014 PAGE ‹#› In summary A good PaaS needs: • Big, engaged community • Transparent development and growth • Should enable agility throughout (dev, test, package, deploy, manage)
- 17. © MIRANTIS 2014 PAGE ‹#› Now… Let’s talk!
Editor's Notes
- In the hope of maximizing our time together today, we thought a quick overview of the PaaS space would be the best way to kick off the conversation. We can also make sure we’re all on the same page when we’re talking about IaaS, PaaS and what we should expect from an open PaaS API
- Don’t read this
- I like to think of it this way, and it should help simplify the conversation
- What should a PaaS deliver, for our purposes? A PaaS should offer an integrated framework you can rely on to build, package and deploy your code on the cloud platform of your choice.
- Bonus points for ease of use and portability across multiple platforms. Integrating a catalog of deployable components is helpful too, hopefully saving you the trouble of re-inventing anything. One important consideration to keep in mind when discussing the different PaaS solutions (existing and proposed) is the distance from the infrastructure - the further the PaaS is abstracted from the IaaS, the more portable the application could potentially be - usually at the expense of performance (less likely to be able to take advantage of anything special the hardware might offer - like Puppet-as-PaaS vs. Google App Engine)
- PaaS existed before people started deploying OpenStack in production. The biggest widespread adoption was enjoyed by AWS’s Cloud Formation. Those key ideas have been re-expressed by others on multiple platforms. These would include examples like Cloud Foundry from Pivotal, OpenShift from RedHat, and APS from Parallels (among others). Azure w/AD, sql-services, etc.
- On the open and transparent front, OpenStack can serve as a foundation for a contiguous toolchain that can provide all the tooling needed to go from code to cloud. The biggest advantage is that these tools are being built in the open, and there’s ample opportunity to ensure there’s focus in the specific areas that matter to you.
- OpenStack is an IaaS that cares about applications, and there are several specific principal projects that enable application development and deployment. I’ll run through the tools that can be combined to achieve a world class PaaS that can satisfy the needs of developers, operators, stakeholders, and everyone between. Open source is leverage.
- We’ll start from the project closest to the infrastructure, Heat, the OpenStack orchestration engine - it will instantiate your environment, for instance launching a multi-tier web app. Initially intended to be analogous to AWS’s Cloud Formation, is has been continually evolving with openstack (work on non-AWS DSL, hooks for autoscaling, more). [Heat templates, integration with ceilometer for autoscaling, and it’s very actively developed as so many other components of OpenStack rely on it - the tools I’ll mention next, triple-o, and nearly everything that aims to automate deployment and management within OpenStack]
- Mistral, the “workflow as a service” project (a tool for heat) - an intelligent task manager for cloud assets. Provides a DSL that allows for simple tasks (launch these two heat templates at a certain time) to a very complicated and fault tolerant chain of events (launch heat template X, when complete launch template Y to analyze results from template X - and ensure each step completes, take specific action if any failures) (has some overlap with heat/ceilometer around scaling triggers).
- Murano, the application catalog project - catalog applications with complicated deployment rules, compose and deploy reliable environments based on published applications. Uses heat to orchestrate the instantiation of VMs and networks. From the developer perspective, Heat might expose a little too much of the underlying infrastructure. For the sake of development speed and ease of portability, we feel Murano strikes a really great balance by providing a way to package applications without needing to know the deep details of the infrastructure.
- Solum, which intends to convert code into managed application running on an OpenStack cloud. Essentially it’s a build pipeline for delivering an application from source code to something deployable on the cloud by building your application artifacts. Holds the promise of providing a DSL and wrapper that could use Murano, Mistral and Heat (in addition to other tools or projects, for instance Jenkins and Trove). This is not an OpenStack project yet (and those involved say they’ll consider it based on community demand) - but it’s following the standard process for projects to gain inclusion in openstack, and seems to be headed towards incubation at some point in the future.
- What about TOSCA? The TOSCA spec is very rich, but very generic to cover multiple use cases (like SNMP). OpenStack is considering TOSCA, but it is too broad, and spans too many OpenStack Modular components.
- The current approach proposes to process TOSCA and write a translator that will process TOSCA manifests and refine them into different subsystems. Essentially, this provides an external schema that can decompose TOSCA into core services that can be managed modularly.
- Though each of these components represent an abstraction, at the end of the day they’re NOT obfuscating the infrastructure. They can all work collaboratively to simplify the access to the underlying infrastructure while maintaining agility and reliability. Using these tools with OpenStack enables efficient development and deployment, with a totally open approach that relies on community participation.