Recently, VMware announced vFabric Application Director product to help deploy applications on public and private clouds. I have had the privilege of leading the engineering team that delivered this product, and am proud that we were able to build a tool that is truly open to the cloud, including all the application types and deployment locations that companies will want to service. Application Director meets not only current workload requirements that run within VMs, but is also open to enable future application stacks like Django, Ruby on Rails, NodeJS as well as noSQL and SQL databases. Likewise, it is open to deploy a variety of apps on variety of platforms—both public and private, including popular locations such as amazon and openstack. Most developers will recognize that building a product that is so flexible is not a trivial matter. However, we felt that not locking users into a single app stack or cloud environments was critical in order to not hinder application development. Giving developers the freedom of choice for application stacks while helping them keep their applications abstracted enough to land into the right production ready environments has been our guiding principal.
Enabling IT towards their journey to PaaS
Development technologies and practices are evolving quickly, so there were a lot of factors into planning this product out, and we felt it was important to service them all. For instance, current (sometimes referred as legacy) application stacks like JEE and SOA architectures have a specific requirement in terms of boot order for various app components. While new app frameworks have moved away from this specific boot order requirements. With the advent of nosql databases, the requirements for handling data is changing very fast, and there are sure to be bigger changes on the horizon. This was a big challenge for building Application Director: how do we satisfy current workloads but also build a product that is futuristic? How do we ensure that it paves a clear path for Platform as a Service (PaaS) model? And finally how do we aid and leverage the DevOps movement for today’s applications?
Most PaaS platforms expect IT to follow a narrow set of application stack (you can only build on what they provide), and if your applications can standardize on certain set of application stacks, then you can harness the power of their PaaS offering including automated app lifecycle management, seamless behind-the-scenes updates to middleware, and monitoring of workloads and so on. Sounds great, but how many current IT administrators are really ready for PaaS? When we talk to customers, we find them in various phases of readiness for PaaS, ranging from not ready at all, with tons of application types spread across several datacenters and no plan to standardize, to very ready, claiming "we have disciplined our developers to follow specific application stacks and we are looking forward to operation-less IT through PaaS." Enabling customers to go from first end of the spectrum to the nirvana state of PaaS, is where Application Director fits right in.
Concepts engineered to enable today’s deployments and tomorrow’s PaaS
1) Support a variety of apps
2) Support a variety of cloud platforms
3) Enable various phases of application lifecycle
Obviously there is a lot to the engineering of this product, but here are a few enabling concepts that paved the path for Application Director to be the product it is today:
1. Reusable application blueprints: While defining features that would be further useful to satisfy today’s complex app management and tomorrow’s PaaS, we looked at trends that would change app management in cloud. One trend that stands out is the DevOps movement, which brings development and operational activities for an application closer together. Application Director provides features that enable dev and IT to work collaboratively if not as one job function, empowering application teams to more definitively “own” their application lifecycle. Application Director graphically maps out an application build plan through a live document called an Application Blueprint. Application Blueprints pull together all dependencies of the business logic in one place—including code, configuration, middleware, and dependencies. Application Blueprints are abstracted from the infrastructure bindings, and can be attached and moved to different environments through a late binding process to make these app definitions portable, or reusable, across cloud environments.
2. Independent deployment environments: Application Director enables IT to set up their compute, network and storage capacity as Deployment environments. Abstracted from the application blueprint, this capacity could be bought from public cloud or private cloud and blueprints can move across them with ease. To setup a deployment environment(s) from a cloud provider, Application Director requires user to register that cloud provider in vCloud Director. Once a Cloud Provider is registered, deployment environments could be created to further divide that capacity between various teams. In vCloud land, deployment environment is equal to an orgvdc and cloud provider is equivalent to organization. For amazon, it would be region + aws account as AppD cloud provider and availability zone + AWS VPC as deployment environment.
3. Standardization of application components: Application Director enables users to standardize their inventory of application components. While it does not limit the choices of technologies, standardization of the components is key to making repeatable deployments possible. It is also the first step to reduce the operational costs associated with using variety of application stacks in a cloud environment. Standardizing the configuration associated with these middleware components, further enables reuse of middleware instances across various applications. Standardization of application stacks and their configuration forms the first step towards PaaS. For instance, a standardized application component would be an Apache Tomcat or tc server, preconfigured to have certain users and roles assigned, virtual hosts defined and authentication set up. Making these definitions uniform with a certain degree of flexibility, enables teams to come together towards working in a curated environment. Add this preconfigured application server to a service catalog and now developers can quickly provision and reuse appstack definition to support their application. This translates a consolidated set of application components that IT needs to manage and update, while not limiting the technology options for their developers, and thus paving the way to a PaaS that fits each organization uniquely.
4. Interchangeable cloud drivers: Supporting different clouds require the product to have special architectural considerations. As we started thinking harder about building hybrid cloud support in the architecture, we made the analogy to Java language. Java language is considered portable due to the Java Runtime that translates the abstracted language to specific machine bindings. Similar work is required for apps that may reside on various clouds across different stages of their development cycle. For Application Director, we achieved this through creating a Cloud Abstraction Layer (CAL) that interchangeably plugs in cloud drivers specific to the target environment. While today, Application Director ships with only a vCloud driver, it does have API’s for CAL, providing the necessary extensibility to users to write drivers for additional clouds. Additionally, in keeping with the independent environments above, the cloud driver is agnostic of internal application semantics. While it understands parts of the Application Blueprint to know the number of VM’s to be provisioned and network requirements of the app, it does not matter what language or architecture is deployed atop it.
5. Application centric multi-tenancy: Given a main use case for Application Director was to empower self-service portals, it is critical there is the necessary isolation of infrastructure supporting a variety of applications. Known as multi-tenancy, Application Director allows users to be part of a group and automatically associates deployment work with the group to which the user is a member. But what happens when a user moves or leaves? Should the application follow the user (user centric multi-tenancy) or remain with the application team (application centric multi-tenancy)? Typically the project does not end, and the knowledge of how that user architected the application needs to be shared easily to the remainder of the group. Therefore, in Application Director, if a user leaves the group and moves to another group or leaves the organization entirely, their work remains available within the group in order to reuse it.
In Conclusion, Application Director is designed to provide features that aids transformation of existing IT Applications and existing IT processes towards Cloud era, where development and operations are tightly integrated to provide operational efficiency, development agility and policy enforcement across assets deployed in hybrid environments. Thus preparing enterprises to adopt fully governed and curated PaaS environments.