Cloud infrastructure is useless without applications running atop, providing business services and solving customer needs. So, as applications ascend to the throne as the rightful king of cloud, focus sharpens on their support within OpenStack-based Cisco Intercloud. With this focus, let's walk through a survey of components and projects supporting applications in OpenStack, understanding what a day in the life of an application in OpenStack is like. We'll start with an overview of the application ecosystem comprised of a number of supporting projects. In the ecosystem overview below, relevant OpenStack projects are presented in context of existing, similar technologies with which you may be familiar. These similar technologies both under and overlap functionality of the respective OpenStack project, but are shown to hasten your general understanding of which bucket these projects fall into by way of tech you may already know (so, add a pinch of salt when considering relevancy of suggested affiliated technologies).

Application Ecosystem by Project

Like individual lines in a product family, projects within OpenStack engulf and extend one another for related, but distinct purposes and target use cases. OpenStack developers are cautious to apply DRY principles in their approach to project design, integrating functionality rather than reinventing the wheel as they go. TheProject Focus and Relationshipdiagram both figuratively and literally places project relationships into round bubbles, identifying conceptual starting points for the genesis of an application as well as the reuse of some projects by others.

• Application Blueprint Designer - Merlin
  • RavelloSystems, UrbanCode, CliQr, Prime Service Catalog*...
• Application Lifecycle Management PaaS -Solum Project Focus and Relationship
  • Similar technologies (ALM) -Atlassian Suite, HP ALM, Cloudpipes, Serena...
  • Similar technologies (PaaS) -Openshift, Cloud Foundry, BlueMix, AppScale, Heroku, App Engine...
• Application Catalog - Murano
  • Similar technologies -AppStack, CliQr, ITApp, AppDirect...
• Application Stack Provisioning -Heat, Magnum
  • Similar technologies -AWS Elastic Beanstalk, Kubernetes, GearD, Warden, Fleet, MaestroNG, CliQr, Nirmata...
• Application Containers - Docker
  • Similar technologies -OpenVZ, Linux V-Server, FreeBSD jails, AIX Workload Partitions and Solaris Containers
• Application Configuration Management -Puppet, Chef
  • Similar technologies -Heat, Salt, Ansible, Satori*...

A Day in the Life of an OpenStack-Native Application

TheApplication Lifecycle Flowsdiagram defines different entrance points by which applications are birthed and the flow between different OpenStack projects within their lifecycle.

Users may designapplications with Merlin, develop applications with Solum, orderapplications with Murano, deployapplications and resources with Heat and manageapplications with Puppet/other configuration managers.

"Applications"

Given that applications are varied in nature both in terms of their type and complexity, let's take a moment to review their possible shapes and sizes. With regard to types of applications, some are  image-based and some are container-based while others are offered simply as a SaaS subscription (implying that a singular instance of this application may serve multiple tenants). Applications may be cloud-native (designed to be scaled out, highly distributed, service-oriented) or enterprise-architected (designed to be scaled up, designed with layers and functional domains). Application complexity ranges from single component (image or container) to multiple component, multiple environment, multiple OpenStack deployments to OpenStack and other systems. Applications may be comprised of multiple components (e.g. MySQL, PHP, Apache) or a singular components (MySQL). Application components may be distributed or contained within a given container, VM or cloud. With these possibilities in mind, let's begin our survey of their support with the OpenStack-native application catalog -Murano in the next post in this series.

This article originally appeared on Lee Calcote's blog.

-
*denotes forthcoming capability