Stacey Schneider is focused on helping evangelize how cloud technologies are transforming application development and delivery for VMware. Prior to its acquisition, Stacey led marketing and community management for application management software provider Hyperic, now a part of VMware’s management portfolio. Before her work in the cloud, she also held various technical leadership positions at CRM software pioneer Siebel Systems, including Director of Technology Product Marketing, managing the Technology Competency in Europe, and the Globalization professional services practice. She was also a part of Siebel’s Nexus project, which focused on building portable web applications that could be deployed across java application servers as well as .NET. Stacey is also the managing principal of SiliconSpark, a consulting agency that has helped over 12 software companies go to market on the web and across the cloud over the past 4 years. Stacey has posted 39 posts at DZone. You can read more from them at their website. View Full User Profile

Creating your Self-Curating Application Platform

08.24.2012
| 1186 views |
  • submit to reddit

In my previous post, I shared the engineering thoughts behind Application Director and how it is a strategic solution for IT to get ready for PaaS. We talked about the basic strategy around 3 main tenets: any app, on any cloud, and supporting the complete app lifecycle in cloud environment. At VMworld this year, I will be talking about evolution in our how VMware plans to take this aApplication management strategy to the next level and allowing DevOps to self-curate their own apps on any cloud they want.

Last week, we shared our vision for how the Cloud Operating Model is transforming IT and apps teams—how it is evident that the team managing infrastructure will be invisible to the team managing applications. In fact, this is not a new model for users in the cloud today. As an example, the respective teams powering Bluelock public vCloud or Amazon’s EC2 infrastructure are not within the reach of the system administrators running apps on them. However, while there is an organizational division between the responsibilities of infrastructure management and apps, the DevOps movement is bringing closer the vertical silos around app development and app operations.

Impact of Cloud and DevOps on Traditional Application Management

Traditionally, in order to deploy an app, sysadmins started from ground up with the physical infastructure and moved to the apps. They bought servers & storage, they installed operating systems & middleware, they configured the network and apps for their deployment, and finally they loaded the app. In the new world, apps come first.

Monitoring is also changing in the cloud, as Shahar Erez pointed out last week monitoring tools are evolving to different standards in the cloud. Shahar’s post described the new requirements for monitoring applications in the cloud. To take that a step further and have it really be a self-curating application management strategy. They are becoming more change-aware, and they are being more tightly pared with development. DevOps teams working in the cloud are starting to instrument the code with troubleshooting information to ease problem detection, and app management tools are more integrated with developer tools and provisioning tools to help keep apps under management and to speed problem resolution. We will talk more about how these tools are evolving during my VMworld session on Monday and Thursday, OPS-CIM2852 – VMware’s Application Management Platform – Enable Any App Any Where… Collaboratively.

The VMware Strategy

Given how organizations and technology are evolving in the cloud, its useful to revisit our 3 key tenets for our product strategy and map them out in a graph. The result is the picture below with the following axis matching each of our tenets:

The X-axis shows support for any type of app, lending freedom of choice and allowing developers to use the right languages and tools for their app, not their infrastructure.

The Y-axis maps to lifecycle enablement, taking into account the DevOps model that closes the loop between developers and operations teams.

The Z-axis expands hybrid cloud support to take into account the fact that parts of apps may be residing on a PaaS environment.

Model Driven Architecture

Our first answer is to rely on model driven architecture. By standardizing and abstracting the models for building applications, we have actually made our application management tools both application- and cloud-agnostic. vFabric Application Director uses a modeling concept called application blueprints that are abstracted from the infrastructure, allowing them to be reused and reapplied to any cloud service. Late binding of the application blueprint to the deployment profile on the cloud service, gives us the freedom of any cloud on the X-axis.

Model driven application architecture also provides us the freedom to deploy any app on the Z-axis. Models not only lend themselves to beautiful diagrams, but they also abstract out the relevant details, allowing the system to reuse chunks of work. For instance, a tc Server install with the configuration details kept separate for late binding means that tc Server install can be “reconfigured” on the fly to deploy on different cloud services and even different application profiles.

Provide Developers With Ways To Abstract Their Own Applications

Models allow services and app components to express dependencies on other services and app components. Installation and configuration time dependencies are common, and allow your tc Server to actually be installed before it is configured.

Another type of dependency that is particularly powerful for developers is expression dependencies. This is commonly used during first time configuration of apps and also during configuration updates. It allows you to show that a load balancer depends on all IP addresses of webserver cluster through an expression like all (webserver:ip), allowing you to automatically update the loadbalancer during scale out activity.

This is very appealing to developers who are now thinking like operations teams, since it allows the developer writing the code to wire various dependencies in configuration that make the whole app a lot easier to manage and potentially a lot more cost effective as it will be easier to scale up and down to respond to demand. This is one part of how the application lifecycle is integrated into the Y-axis.

Provide Operations With Ways To Abstract Their Deployment Environments

There are specific customizations that you may do differently when deploying to development, test and finally production environments. You may change cloud services and select different AMI or vCloud templates, you may use specific network selections, or change configuration properties such as allocating memory or changing permissions. Additionally, you may want deployment process to be integrated with existing processes and tools that could be different across environments. For example, after deploying to dev environment, you may run unit tests or before deploying to production environment, you may want to run a script to check that all templates have latest security patches. These customizations are abstracted again using a concept called deployment profiles in Application Director. Deployment profile allow operation teams and application architects to pre-configure the cloud services for specific uses. Application blueprints are then applied to the deployment profile and have become instantly portable across cloud services. This is a powerful concept, and is paving the way to streamline that application lifecycle across the Y-axis while also extending the reach of the hybrid cloud requirement on the X-axis.

Fusing Monitoring and Management

We see several solutions in market trying to fuse monitoring and management for applications in cloud. Only few are successful in their implementation on both aspects. With an application centric approach, Application Director can tell cloud application performance monitoring tools like Applinsight that an app was deployed, register all of its components, and start tracing performance as soon as it is deployed. Further, you can use monitoring tools to watch for thresholds on CPU or memory usage, and then have AppInsight call Application Director to perform an automated scale out of the application. This is the essence of a self-curating cloud application platform.

Summary

VMware has done a lot of work over the past few years, working with customers who are trusting their apps to the cloud in order to speed development, improve scalability and performance and in many cases, lower operating expenses. We are investing heavily in the DevOps services for application provisioning and management because we recognize how automation can eliminate much of the work, creating applications that are nearly self-curated, freeing application teams to spend more time on application development. And our investment is paying off, as organizations including our own VMware IT are reporting reducing provisioning time by 90% and cost savings of 30%.

We will talk more on this subject at VMworld and help you to understand the possibilities and the path to the deploying any app on any cloud (OPS-CIM2852) planned for Monday at 5:30 pm and Thursday 11:30 am.

0
Published at DZone with permission of its author, Stacey Schneider.

(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)