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.

Here is the revised version of the bar-chart I posted in the previous blog showing the evolution of IT to explain the benefits and challenges of cloud computing, and showing why and how we got to cloud computing.

Dedicated Physical Servers:  Each application owner bought servers for running their application/s.

Physical Server Consolidation: Moving from physical servers to dedicated servers to consolidated physical servers resulted in greater server utilization, however it increased time to market significantly as multiple applications sharing same server have to worry about configuration management issues; deploying patches and changes required all application owners to test their apps for impact.

Virtualization: Virtualization improved time to market as it allowed each application owner to get a virtual server (slice of the physical server) and make changes (installing patches, libs etc.) without impacting other application owner running a different virtual server on the same physical machine.  However, virtualization increased management complexity as for each physical server IT team has to manage multiple virtual servers.

Private Cloud (in house): Going from virtualization to private cloud is basically a step to provide self service capabilities to the application owners.  It reduces time to market however, it also increases the management complexity and increases need for transparency, as it adds another layer of abstraction.

Public Cloud: Using cloud (public) is the only way to reduce fixed costs, as in all other scenarios you have to build for peak capacity.

• Benefits of the Cloud: Lower fixed and overall costs, shorter time to market, higher infrastructure utilization.
• Challenges of the Cloud: Additional management complexity due to scale and distributed nature. Increased need for transparency and security.

To fully take advantage of the cloud we need to be able to address the challenges of cloud computing.  Security challenges in public cloud can be mitigated by using existing security technologies, e.g. private network within the public cloud, data encryption, etc.  The transparency and management challenges can be mitigated by using the top down application centric management.
 

After the earlier blog discussing the evolution of IT, I had several discussions on  the benefits and challenges of virtualization, private, and public clouds.  Following bar chart is an attempt to capture the benefits and challenges of various phases of IT evolution from the days of having dedicated physical servers for each application to the use of public cloud. 

The chart is self explanatory, some key points to note are:

• Going from virtualization to private cloud is basically a step to provide self service capabilities to the application owners.  It increases flexibility, improves time to market, and also increases the management complexity, as it adds another layer of abstraction
• The biggest advantage of using public cloud is reduction in fix costs, as you don’t have to build the capacity for exceptional peak cases.  Several IT activities have elastic demand, development, functional testing, load testing, end of quarter processing etc.

Amazon took the lead in addressing one of key objections of enterprise customers to cloud adoption by announcing the Virtual Private Cloud today.  Jeff Barr at AWS has done a great job in explaining the technical details of the solution.  The solution goes a long way in addressing some of the concerns we encountered first hand at Kaavo in dealing with enterprise customers.  Recently I blogged about a solution we had to implement using open source tools to address the needs of one of our customers.  We were hoping that someone is going to step up to the plate and offer better connectivity solutions for cloud computing to make things easier, it is great to see that the AWS team is first to deliver.  The key promise of cloud computing is instant on-demand access to compute resources, as we know compute resources don’t work in isolation and to fully take advantage of cloud computing there is a  pressing need to establish on-demand instant secure connectivity among the distributed compute resources.  This solution will go a long way in helping enterprise customers to get on the cloud.  Hopefully in not too far future we will see more innovation in networking/connectivity solutions to have on-demand guaranteed service levels, bandwidths, etc.

One of our customers wanted to establish a site to site connectivity between their datacenter and  public cloud (Amazon EC2) and then have a private network within Amazon EC2 with their own custom IP addresses for their servers in the cloud.  Basically idea here is to augment the internal datacenter resources with the resources in the public cloud securely so that the servers in the cloud appear as if they are part of their own private corporate network.  The idea here is to isolate the servers used by the customer in the cloud from the rest of the servers in the cloud using private network, just like the corporate internal datacenters are isolated using private network with private routers routing the internal traffic.

Kaavo team setup the required network using OpenSwan and OpenVPN, see the figure below.

The advantage of this setup is that users within the corporate firewalls can access the server in the cloud seamlessly as servers in the cloud are part of the private corporate network.

One of the barriers to cloud adoption for a large number of enterprise customers is that, they can’t just lift and load applications and run them in isolation in the cloud as majority of enterprise applications are connected to backend systems, internal authentication servers, etc.  Having a secure seamless connectivity b/w corporate datacenters and the servers in cloud reduces the barrier for enterprise customers to gradually move applications in the cloud without having to worry about the integration issues between internal resources and the resources in the cloud.

Having the ability to create secure, high-bandwidth network, on-demand between two end points (in this case customer datacenter and cloud or between two different clouds) via API would be an ideal solution.  Hopefully networking solution providers can step up to the plate and deliver solutions where we can dynamically create networks for applications and manage the bandwidth and Service Levels, in the context of the application, on-demand.  So for example if we know some application has a peak bandwidth usage during afternoon we can allocate the appropriate bandwidth on-demand in the afternoon and release extra bandwidth when the usage is low.  Another example is data warehouse application which may require high bandwidth during batch load window (typically late night) and relatively small bandwidth during other times of the day.