Since the invention of computers, the architecture paradigm has been swinging like a pendulum, between centralized & distributed systems.

So you have spent months convincing your leadership to go with OpenStack. Finally the keys of the cloud are turned over to you as the Cloud Operator, and you then look over at your co-workers and say “now what”. The next set of phrases normally are something like: Now how do we best administer this cloud? Cloud is suppose to be easier, right?

Through the course of technology, infrastructure and application monitoring have changed positions. Not so long ago, monitoring was an afterthought when rolling out your new application or standing up your new rack of servers. More recently, I have observed monitoring to be one of the first considerations, to the point where it is actually in the initial project plan.

This evolution, while late in my mind, is the right direction…not just for the System Admin who gets the 2AM email alert or the application owner who on a monthly basis sadly report to his leadership 97% SLA on his app. Truly knowing how your application is affecting your infrastructure is one of the keys to a successful cloud.

With monitoring now being in an elevated position, that then leaves you to think: what should I use for monitoring? While there are plenty of software solutions in the market, many of which solve for different problems.

This is the fourth and last article in my series on OpenStack orchestration with Heat. In the previous articles, I gave you a gentle introduction to Heat, and then I showed you some techniques to orchestrate the deployment of single and multiple instance applications on the cloud, all done with generic and reusable components.

Today I’m going to discuss how Heat can help with one of the most important topics in cloud computing: scalability. Like in my previous articles, I’m going to give you actual examples that you can play with on your OpenStack cloud, so make sure you have an environment where you can run tests, whether it’s a Rackspace Private Cloud, DevStack or any other OpenStack distribution that includes Heat.

This is the third article in my series on OpenStack orchestration with Heat. In Part 1, I introduced the HOT template syntax, and then in Part 2, I showed you some of the techniques Heat offers to orchestrate the deployment of applications that run entirely within a single compute instance.

Today, building on the same ideas exposed in my previous article, I’m going to show you how to design deployments across more than one instance, and I’m going to demonstrate these concepts by deploying an application that runs on a server and connects to a MySQL database on another server. You have seen how to deploy a Python application in my previous examples, so, to add some variety, I’m now going to switch to a PHP application as guinea pig. That application is none other than the venerable Wordpress.

Welcome to the second part of my series on OpenStack orchestration with Heat. In the previous article, I gave you an introduction to Heat orchestration. All the examples that I showed you were simple and not terribly useful, as they were only intended to introduce the structure of the HOT (Heat Orchestration Template) syntax.

In today’s article, I’m going to elevate the complexity quite a bit, demonstrating some of the tricks you can use with Heat to perform deployments of single instance applications. As with the introductory examples, you are encouraged to try my examples on a Rackspace Private Cloud, DevStack or any other OpenStack installation that includes Heat.

With this article I begin a series of hands-on developer oriented blog posts that explore OpenStack orchestration using Heat.

To make the most of this article, I recommend that you have an OpenStack installation where you can run the examples I present below. You can use our Rackspace Private Cloud distribution, DevStack, or any other OpenStack distribution that includes Heat.