I Want Cloud Apps, Not Just Cloud Servers! – Part I
It is amazing how I continue to hear people talk about how they are still not familiar with “cloud”, what it is and how it will help their specific business. Just the other day I spoke to a customer prospect who believed they had a private cloud – as it turns out they had a virtual server farm which still could not be accessed through a self-service portal. But I am not surprised – after years of “cloud-washing” incumbent IT management solutions that cost a lot of money, time, and resources to implement, vendors have dictated how YOU should use the cloud. But, you need to figure out how the cloud actually applies to your specific business.
Now I won’t go through a Cloud 101 definitions check. I think we all know now that Infrastructure-as-a-Service (IaaS) delivers compute/storage/network services in a pay-as-you-go on-demand model from the network (internal or external). Platform-as-a-Service (PaaS) delivers development environments in the same style, and Software-as-a-Service (SaaS) are applications. We can get cute and also talk about Business-Process-as-a-Service (BPaaS) for processes such as payment services. At the end of the day, businesses today are driven by applications and services. So while IaaS is a quantum leap for provisioning servers, it does not by itself get you to laying down applications in the cloud. But how do you get from getting servers on-demand to running applications/services in the cloud?
Let’s face it, even the simplest of applications are all configured specifically for your own business and IT needs. SAP in my deployment model may be very different than how it is deployed in your shop. But the knowledge to lay down these applications, after gaining access to the servers/storage/network, is in our heads. And, as humans, the way you deploy an application could very well be different then the way I would lay it down. So we need a way to capture these best-practice steps so that anyone can follow the same methodology, especially as you take an application from development through testing and into production. Enter Kaavo IMOD
At IMOD’s very core is the ability to capture these best practice steps in a single dynamic file which we call a System Definition File. It not only describes how to lay down an application step-by-step, but for more advanced cases it also describes how to automate workflows for known events (such as adding more server resources when the demand for an application increases, and then letting them go when the demand shrinks). You can also think of a System Definition file as an electronic Disaster Recovery Plan; step-by-step instructions on how to get your application back up and running in the event of an outage. The reason I call it “dynamic” is that, if you need to change the deployment topology (i.e. add another tier, or more middleware, or update configurations), you don’t have to go and create another “package”. IMOD’s user interface will allow you to update the existing definition file without you having to go through and manually updating the XML file. The end result is that ANYONE in your organization can now start this application with a single click.
Ok so hopefully you are now starting to see how you can take all of that application-specific knowledge that's in your heads and place them in a centralized location, where it can be managed and automated to bring up your applications. You may now be asking this: what is the roadmap to move from grabbing cloud resources to actually starting up my application in the cloud with a single click? Stay tuned for my post next week for the answer.