As we are in the early stages of the transformation offered by cloud computing, there is lot of confusion around how various solutions and offerings fit in the overall picture for enterprise customers and the benefits of various offerings.  Whether you have to deliver SaaS, PaaS, or Custom Apps there are three building blocks you need to deliver them, datacenter with virtualization, IaaS layer on top of virtualization, and application/workload management for efficient deployment and management.  It can be argued that you don’t need virtualization or IaaS to deliver the SaaS or PaaS offerings, however, if you care about efficiency and agility you will be better off leveraging the IaaS layer running on top of the virtualization layer and using a tool for application/workload management for deploying and managing your solutions (SaaS, PaaS, or Custom Apps),  All major SaaS and PaaS players have built their own private clouds for efficiently delivering the public SaaS and PaaS solutions.

In this blog we will cover benefits provided by each of the three core building blocks, i.e. virtualization, IaaS, and Application/Workload management.  For application/workload management layer  we are using Kaavo IMOD as an example.  If you are interested in learning about when you use SaaS, Custom apps, or PaaS you may want to refer to the earlier blog on this topic.  Refer to the following figure as a big picture overview of how the major components fit in.

In datacenters we moved to virtualization to increase the resource utilization and as a result we increased the utilization of physical resources by 20%.  The virtualization market is dominated by VMWare and XEN (Citrix).  Infrastructure as a Service (Cloud) layer is another layer added on top of virtualization to provide better utilization of resources across multiple datacenters.   E.g. if you have 100 physical servers and you have 30 percent utilization, there is no need to equally distribute load across all 100 servers, a smart IaaS layer should distribute this load on less than 50 servers and turn off power to other physical servers and bring additional physical servers online as needed to optimize power utilization.  In addition IaaS layer provides optimization and simple web services and web browser interface for automating the provisioning of virtual compute, storage, and network resources across geographically distributed datacenters.  IaaS layer can be build in house (aka private cloud) or customers can choose to leverage public cloud, or Hybrid cloud (combination of public and private).  IaaS for both public and private cloud is in early stages of adoption especially in the enterprise market.  Leading players in public cloud (IaaS) space are Amazon, IBM, Rackspace, Terremark, alt.  In the private cloud space there are few companies which provide solution for building in house IaaS layer (aka private cloud), some of the companies in this space are Eucalyptus, Enomaly, IBM, Cloud.com, Nimbula, alt.  VMWare is also moving up the stack from virtualization to providing the IaaS layer.  We are not covering benefits / trade-offs of public, private, or hybrid clouds here, to learn about them, please watch this 5 minutes video.

IaaS layer provides infrastructure resources on demand, e.g. compute, storage, network, etc.  However, customers still need to install the software configure their applications or workloads to get their solution running on the IaaS layer.  In addition customers still need to provide production support for the applications / workloads for managing the run-time service levels.  Kaavo plays in the Application / Workload management space and provides the solution to automate the deployment and runtime management of applications and workloads in the cloud.  Kaavo is the first and only company that takes a top down application centric approach to managing infrastructure resources, allowing users to deliver on-demand Custom Apps, SaaS, or PaaS offerings.  Kaavo also provides the solution for automating complex  custom management tasks for maintaining application service levels similar to airplane autopilot during run-time.   To learn more about this please check the earlier blog on the subject and also checkout the high-level value proposition video for Kaavo.

Following chart summarizes the benefits delivered by each layer (Virtualization, IaaS, and Application/Workload management)

Lately there have been several discussions around cloud API standards, and I am failing to understand why it is a big deal.  Lets first identify two type of standards:

1. Syntax Standards
2. Functional Standards
   

For cloud lot of attention is given to syntax standards, e.g. using same method signatures.  E.g. some IaaS enablers are using exact same method signatures in their APIs as Amazon EC2.  After integrating with several cloud providers we found API differences (Syntax) may seem annoying but they really don’t matter much, as it is trivial effort to deal with them.  E.g. how hard it is to deal with a difference like start.server , or start-server, or s-server all doing the same thing i.e. starting a server on various clouds?

In terms of functional standards, it is ignorant to expect that all cloud providers will provide the exact same set of functionality.  Usually the way innovation works is that someone pushes the limit and deliver a new functionality and then other players in the industry try to catch up and implement the same functionality (given there is customer demand for it).  Once the new functionality is implemented by all vendors it becomes an standard.  The innovation cycle continues as some other vendor in the industry steps up to deliver new functionality and rest of the vendors follow to catch up.  This cycle keeps on repeating till the technology becomes obsolete.  It would be really stupid for anyone to expect that vendors will stop innovating after they reach some agreed common functionality.   After integrating with several cloud APIs (IaaS), we have identified following functionality as the expected “standard” for the cloud (IaaS), and all major cloud players are delivering this (plus more).  The method signatures may not be identical,across all the providers, however, the functionality offered by various providers is comparable for following. 

Instance Management: Launch, Terminate, Suspend, Resume, Describe, GetIP, List
Image Management: ListImages, DescribeImage, CreateImage
Storage Management: CreateVolume, DeleteVolume, AttachVolume, DetachVolume, ListVolumes, VolumeStatus
Security: CreateKeyPair, DeleteKeyPairs, DescribeKeyPairs
Backup Management: CreateSnapShot, DeleteSnapshots,DescribeSnapshots
IP Address Management: AllocateAddresses, ReleaseAddress, AssociateAddress, DisassociateAddress
Firewall Setups: CreateSecurityGroup, DeleteSecurityGroup, DescribeSecurityGroups

The above list will change as IaaS providers will innovate more and deliver more functionality.  E.g. right now the biggest gap is that no cloud provider gives SLAs around network, e.g. guarantee of minimum latency, bandwidth, etc.    Some providers are providing additional APIs for creating private networks/VLANs etc and over the period of time the VLAN type functions would become more common across providers.

At Kaavo we took a top down application centric approach because we believe that cloud APIs will be different for different clouds and will evolve and we need to provide a consistent interface for deploying and managing workloads, regardless of the cloud.  From the customer perspective two things are important:

1. Ability to deploy, configure, run workloads (custom apps, SaaS, PaaS) securely and automatically on-demand within in minutes on the IaaS layer (regardless of the IaaS provider)
   
2. Automation to manage run-time service levels

Because of our top down approach anytime a new functionality is added by a cloud provider or API is changed, we are able to handle it easily.  For additional reference checkout how we easily handle the differences in server attributes across providers and also the web service API we provide for deploying and managing workloads in the cloud.

To optimally use the cloud and to effectively manage the service levels of applications we need two things:

1) On-demand configuration: Without cloud it used to take us several days to procure infrastructure resources so it was acceptable to spend couple of days configuring servers and installing software to get the applications to work.  However, with the cloud we can get the infrastructure resources on demand within minutes, so it is no longer acceptable to spend few days configuring the infrastructure to run applications or workloads in the cloud.  Users are looking for on-demand ability to run their applications or workloads in the cloud not just on-demand infrastructure.  We need ability to install software, configure the infrastructure, e.g. firewall rules, etc. automatically within minutes to run our applications or workloads on-demand.

2)  Runtime Autopilot for Managing Service Levels:   As computing needs are growing, management complexity is increasing and  to manage this complexity we need automation to manage application service levels during run-time.  Most of us fly on airplanes frequently and we don’t even think about that most of the time airplane we are on is flying on autopilot.  In fact on all large airplanes and longer routes, autopilot is required by FAA to manage complexity and to avoid incidents due to pilot fatigue.  Autopilot takes corrective actions in response to changing conditions e.g. wind speed, wind direction etc. to keep the airplane on course.  Compare this to how we manage application service levels in IT, we have a pager system to page someone at 3am to fix a production outage, by performing tasks like restarting a process or booting a server etc.  Eighty to Ninety percent of all production support activities are known events with known responses.  Primary reliance on pager model is not scalable at the cloud scale, we need automation to manage service level during runtime.  Let’s think about this if we can trust airplane autopilot everyday with millions of human lives to keep airplanes on course and take passengers safely to their destinations, there is no reason why we shouldn’t trust automation to fully manage the deployment and run-time service levels of our business applications.

To provide automation for on-demand configuration and runtime service level management, Kaavo is the first and only company to take a top down application centric approach.  We do not just look at servers, we look at all the resources required to deploy, run, and manage an application top down from application owner perspective, this includes servers, storage, networks, software, runtime management tasks, service levels etc.

Everyone in the industry right now is building cloud offerings bottom up by implementing solutions for launching/monitoring servers, etc.  In the end the goal is to deploy and manage applications and workloads securely in the cloud and manage the service levels for applications.  This is why using our top down application centric approach we have developed IMOD which interacts with Infrastructure as a Service layer to enable customers to fully automate the deployment and run-time management of any complex custom application or workload in the cloud.  This approach is specially designed to handle complex enterprise applications with order of execution configuration dependencies, and long running runtime management processes.  Taking a top down approach to interact with the IaaS layer also gives us an extra advantage that using the same framework we can manage PaaS and/or SaaS with the same ease as we can manage any custom IT app running on IaaS.  To learn more about our approach, view this 5 minute video on YouTube

Last Friday I was invited to speak on the entrepreneurship panel at the Columbia University conference on India.  The topic is very close to all of us at Kaavo as we setup our primary R&D activities and product development team in Kolkata, India from day one.  Most of the US based technology companies have setup R&D teams in India as a branch office of their core R&D function.  In our case we decided to pick India for our core product development activities for two reasons, one is availability of extraordinary untapped talent and other is the potential of the local market.  Indian economy is growing and is expected to grow for next several years at close to double digit growth rates.  At present the awareness of cloud computing is relatively low in India, however, given that several domestic companies are growing exponentially and have no legacy infrastructure of in-house data centers, these companies have opportunity to bypass the legacy stuff and move directly to the cloud.  Cloud adoption in India would be similar to the cell phone adoption.  Cell phones were introduced in India well after their introduction in the developed countries, however, they were adopted faster than the developed countries as the existing landlines infrastructure was non-existent and the technology addressed something which was not do-able with the available infrastructure.

Looking at entrepreneurs in India, historically they mostly came from either the business families (Tata, Birlas, etc.) or from families with modest means who didn’t have much to lose (e.g. Dhirubhai Ambani).  Middleclass in India historically has been content in getting higher education and working for someone else.  First known success of middleclass participation in entrepreneurship is the formation of Infosys by Narayana Murthy, Nandan Nilakani alt.  Infosys founders were engineers who left their jobs to start the company which arguably acted as a catalyst to grow the technology services industry in India and become a huge success globally.  Arguably India has establish global leadership in IT services business, so the question is when will we see a global software product company like Microsoft, Google, alt. from India.  I think it will take some time, we are still at a stage where product companies are founded in India from outsiders to leverage the local talent and market opportunity. If we look at the history of Silicon Valley, the Fairchild was the first success and after that several employees of Fairchild went on to form VC firms (e.g. Sequoia, KPCB) and other startups (e.g. Intel) and it started the whole ecosystem.  Prior to the success of Fairchild, all the major technology companies in the US were founded on the East Coast, e.g. G.E., AT&T (Bell Labs), IBM, alt.  Given all that is happening, it is just a matter of time before we will see a breakout success in the technology innovation from India and the successful company will act as a catalyst for further technology innovation in India.

At Kaavo we recognized that there is a need to provide a horizontal framework that anyone can use to quickly build a vertical solution for running and managing their complex custom applications in the cloud.   To enable single click deployment and runtime management of any custom application in the cloud Kaavo’s IMOD uses System Definition file for automating complex workflows and dependencies for deployment and runtime management.  Understanding the structure of System Definition file is important to fully benefit from Kaavo’s application centric management approach.

System Definition file is an xml document with support for embedding velocity templates for dynamically generating configuration files, scripts, and workflows in any programming language on the fly during deployment or in response to run-time events.

The system definition file has two main sections, deployment and runtime.   See the figure below for more details.

Deployment section contains information about tiers in the system, we can define 1 or n tiers, in each tier we can have 1 or n resources, each resource can have post startup or pre-shutdown actions or workflows.  We can define the order in which tiers are configured and displayed and group the resources within a tier.  We can also define workflows at the tier level and at the system level.

Runtime section of the system definition file can contain complex custom workflows required for managing the runtime service levels of the application.  Runtime workflows can be custom automation, for example scale up, scale down, auto-recovery or any application specific custom maintenance task, e.g. backup database, run batch jobs, etc.  For more information please review the N-tier System Definition Guide and the XSD for the System Definition.