Changing the delivery of IT

Tony Bishop

Subscribe to Tony Bishop: eMailAlertsEmail Alerts
Get Tony Bishop: homepageHomepage mobileMobile rssRSS facebookFacebook twitterTwitter linkedinLinkedIn


Related Topics: Cloud Computing, Microservices Journal, Cloud Data Analytics

Article

I Want Cloud Apps, Not Just Cloud Servers! – Part 2

Running cloud applications is the end-game; acquiring cloud servers is only the beginning

In Part I, I talked about how it is important to think about cloud use from the application's point of view. We need to digitally centralize our best-practice institutional knowledge so that it can be used to easily replicate application environments from development to test, and then on towards production. Centralizing these steps helps you manage and automate what used to be manual labor. But how do you go from securing VMs within the cloud to actually deploying applications and their environments in the cloud with a single click?

Transformation never happens overnight, and must involve systematic change (a roadmap). Many large organizations and small businesses still do not have battle-tested processes in place governing areas such as change management and disaster recovery. Now we've all heard of best practice frameworks such as ITIL and COBIT. If you peel back the onion, you will see that the idea of making sure your house is in order to enable business agility and transformation is the common theme of those frameworks. Deploying and managing applications in the cloud will undoubtedly force you to do exactly that - get your IT house in order - so that you can capitalize on an agile platform that is the cloud. You may have been able to get away with it on-premise, but the speed of the cloud will enable you to correct the flaws.

Many of you have already virtualized to some degree the infrastructure underneath your applications. The optimizations come through establishing best practices for areas such as: change management, lifecycle management (development --> testing --> production), hardware independence & VM configuration, responses to dynamic events (overutilization, underutilization, server recovery, etc.), and timely responses for application health (e.g. the need to restart a particular component due to memory leak issues). In addition, household tasks such as backups and replication batch jobs must be implemented and working. Let's also not forget security at the user and group level. Even if you perform some of these tasks by hand, it's important to document everything so that if you are unable to perform these duties someone else can pick up the baton. If you have Disaster Recovery plans (which you should), the documentation of these steps helps toward this critical business function. You may even be able to lift a lot of these steps from those plans, especially the ORDER in which you execute these steps. Make sure you have also captured the steps to bring your application up from scratch on top of vanilla compute/storage/network resources; for example, what middleware needs to be installed and where can you get those packages from, and what specific software/security configurations do you need to enable your application. As you gain confidence in these best practices, you can then implement automation to execute some of these tasks.

Not all applications can actually take advantage of the cloud. A very good article which I found here captures the basic tenets of a cloud application:

  • Periodic Processing - "end of the month" type of processing
  • Start Small, Grow Fast - exponential growth of application use
  • Unpredictable Burst - on-demand increase in application use
  • Predictable Burst - scheduled increase in application use

Remember that moving an application to the cloud does have to be done in one swoop, especially if you are dealing with a multi-tier deployment. Start with the lowest tier and duplicate the steps required to lay down its environment, test it to make sure it is set up for your specific application requirements (connectivity, configuration, etc.), and then move onto the next tier. Using Kaavo IMOD as an example, let's quickly walk through how we can do this.

Example of a 3-tier cloud application in Kaavo IMOD

This is a representation of a 3-tier application's deployment stack, after we have defined the configuration (OS, memory, disk space, etc.) of each of the VMs within each tier based upon their role. You could easily scale this down to start with only the bottom tier (in this example we will look at the db_tier), so that you are focusing only on a particular environment.

Description of install-mysql-manager action in Kaavo IMOD

IMOD allows you to organize the steps you've captured into logical actions. In this example, the "install-mysql-manager" action contains the steps necessary to stand up MySQL cluster manager; this includes grabbing the software from a particular location, installing a prerequisite package, and then installing the actual product. To the right, you'll see that this particular action applies to the db_tier, where the server role is of type "manager". IMOD will call out to the cloud provider (in this case it is Amazon EC2) and request the type of VM that we configured. When it is time to execute this action, IMOD will connect to the VM securely through SSH, inject the mysql-cluster-gpl.sh script into /root, and then run the script to perform the appropriate steps.

Description of create-manager-config action in Kaavo IMOD

Actions are not limited to executable steps. In the "create-manager-config" action, we will create the config.ini file for MySQL within this same server role in the database tier. You may also want to set up an action to configure your security firewall rules. Note at the bottom right that we can also pass parameters as reference to these actions. In the cloud, you do not know server information ahead of time and so it is important to have the ability to share this information at run-time to configuration tasks.

Description of "db_tier (tier) startup" in Kaavo IMOD

In IMOD, events are a sequence of actions that will execute for a given cause. In the example above, the "db_tier (tier) startup" event will start up the database tier by executing the actions listed to the right in this exact order. I can now go back to the "RUN TIME" tab and start up the database tier by clicking on the "Start" button. This will grab the appropriate VMs and automate the best-practice steps you just captured to stand up the database environment.

As you implement subsequent tiers to include within this deployment, you will then be able to start the entire application environment with a single click. You may even want to just set up a shell of an environment where only servers are started up and there are no post-configuration tasks to execute, so that you can directly work on the vanilla VMs themselves to understand how on-premise configuration tasks map to the cloud environment; once you've done that, you can then capture them in IMOD as actions and subsequently events. IMOD does not have any direct hooks into any one application, giving you the freedom to describe any application's deployment and then subsequently automate its startup.

You may have noted during all of this that the amount of visibility into the intricacies of standing up an application is very important. By spending time and capturing those steps while moving to the cloud, you will then be able to automate their execution in a standard and repeatable manner. This is important when you think about development lifecycle management, as you should have a consistent cloud environment cloned for development and test, and then ultimately for production. IMOD comes with sample System Definition files, but there is no magic tool to automatically take your custom deployment of a particular application and move it to the cloud. However, by following a methodological approach, you too can get to the point where you can bring up a complex application in the cloud with a single click. Solutions such as Kaavo IMOD can help simplify your use of the cloud, one application at a time.

More Stories By Sam Somashekar

Sam Somashekar is Vice President of Marketing and Business Development at Kaavo, a leader in application-centric cloud management solutions. In this role, Sam is responsible for leading all marketing and business development initiatives at Kaavo. These include driving strategic partnerships, product marketing, product management, thought leadership and industry presence.

Sam has over 18 years of experience demonstrating success in enterprise product management and development, market research and strategy, marketing and business development. Prior to Kaavo, he held various senior management roles at public and private companies, including Senior Director of Product Management at CA Technologies (a leading IT management software and solutions company). Sam has created and managed market-leading solutions within key industry areas such as cloud computing, data center automation, service automation, and green IT. Throughout his career Sam has provided leadership and vision to increase both top line and bottom line growth, maximizing profitability while addressing challenging and realistic problems.

Sam holds a BA in Computer Science from New York University and is Pragmatic Marketing Certified. He is on the board of AFCOM’s Data Center Institute (DCI), and has authored several articles and whitepapers on the subject of enterprise IT management. Sam has also been quoted in articles appearing in leading industry publications such as InfoWorld and Computerworld and has been a regular speaker at industry events.

Comments (0)

Share your thoughts on this story.

Add your comment
You must be signed in to add a comment. Sign-in | Register

In accordance with our Comment Policy, we encourage comments that are on topic, relevant and to-the-point. We will remove comments that include profanity, personal attacks, racial slurs, threats of violence, or other inappropriate material that violates our Terms and Conditions, and will block users who make repeated violations. We ask all readers to expect diversity of opinion and to treat one another with dignity and respect.