Abstract: “Mama always said life is like a box of chocolates. You never know what you’re gonna get.” Obviously the title of this blog post is a variation on this famous quote from the movie “Forrest Gump.”
With cloud computing this quote is true in two ways:
- A wide variety of cloud services are available to compose with, like a box of chocolates.
- You don’t know up front what you’re going to get. This blog post offers the reader a three-step-plan to guide your journey to the cloud.
The first point is discussed in this blog post; a follow up post (part 2) will cover the second point.
A box of chocolates
The first point, the wide variety of cloud services are available, is a good thing. Almost every day more services are being made available as standardized services in the cloud, all available to be used to compose business functionality when needed. Composition is a term from service-oriented modeling, which describes the aggregation of smaller and fine-grained services with unique characteristic into business services. Now, I have been working as an IT Architect on standardization in IT landscapes for over eight years now, and I even wrote my Masters thesis about this for IBM in 2008, so I know that composition of re-usable services offers great potential.
And let’s face it; IT needs to be able to improve agility to take on the ever growing challenge of being able to offer enterprise users the functionality they need when they need it. Both business and development want more agility, to consider IT as an asset and not just an inconvenient bottleneck in between. That’s one of the main reasons for the recent trend in consumerization of IT, resulting in all sorts of “shadow IT” in organizations.
This is where the analogy of LEGO bricks comes in: Cloud is allowing all sorts of standardized bricks to be created, used on demand, and discarded after you don’t need them anymore. The difficulty however is that there are no instructions for how to build your enterprise IT landscape with the available bricks, from multiple providers. My though on this is that we need a catalog of building instructions, same as LEGO distributes building instructions with there boxes. The only difference is that we need to create building instructions with bricks from various vendors.
Construct your way into the cloud
The process of getting there is quite standard architecture, only the lingo is a bit different. In cloud, the word workload has been added, which can be considered as an abstraction of the functionality you require without going into the deployment model. Whatever way you look at IT projects and whichever terms you use, there are three main phases: design, build, and consume. Let’s go over each phase briefly to describe the key activities.
Basically, first figure out what you need before you start and how you will get it. Seems like an open door, but it happens only too often that organization units skip this phase or only do part of it. The result is an organization unit deciding on a specific vendor or even cloud service, without looking at the broader picture. Not only functional requirements, but also non-functional requirements such as security, resiliency, availability, and data privacy should be taken into account.
- Create an IT Roadmap.
Start your journey into cloud computing safely by first establishing a cloud strategy and implementation plan. Basically, think long term before you act short term.
- Assess the workloads.
Remember, there’s no one-size-fits-all cloud solution that will match all your IT landscape requirements. Therefore the advice is to split your IT landscape into chunks of unique functionality, called workloads. This helps you to find the best match between your individual workloads, each with unique requirements, with the many various cloud services available, each with unique characteristics.
- Define the best (mix of) delivery model (or models).
Many cloud services are available, from multiple cloud service providers each with its own strengths and weaknesses. Use a scoring mechanism to determine which delivery model best fits each workload.
- Define the business value.
Don’t get all uptight about only the IT part of cloud computing. Rather, look at the business value of each workload and how IT can increase this business value by focusing on specific aspects of cloud services out there. Think of rapid provisioning (have your server in a matter of minutes) which increases business agility, the possible reduction of CAPEX (no upfront investment), or pay for use (stop paying for a service when you no longer need it), enabling the possibility to expand and reduce your IT landscape without penalties.
- Establish the architecture.
A common mistake is that a journey to cloud reduces the need for proper architecture designs. Actually the opposite it true. Think about it — you are widening your IT landscape onto cloud services, which requires a well-defined architecture that includes where to place unique data and how this data is integrated with the remainder of the IT landscape.
Start your transition into cloud with the simple, easy workloads first, workloads that have lower non-functional requirements or are a one-to-one functional match with your requirements. These workloads can be development and test environments, which have lower non-functional and data privacy requirements than production workloads, or CRM functionality as a service.
After you have defined which workloads to focus on first, start composing the selected cloud services and integration mechanisms. Test your composite cloud application and make sure it is integrated with your service management environment, which should monitor key performance indicators, both functional and non-functional. This approach can allow you to manage and optimize consumption of cloud services.
Now that we’re done designing and deploying, we can start consuming the cloud composite services. Keep in mind that new cloud services, your building bricks, are created daily and evaluate whether more can be gained from altering the composition regularly. More about this in part 2 of the blog post.
So in short: get out your requirements, split your IT landscape into workloads, and define architecture for each workload. Happy traveling on your journey into cloud!
My question to you: Where do you see this going; do we need to build some sort of Cloud Consumption Reference Architecture, containing a wide variety of patterns on using multiple vendor “bricks?” Let me know your opinion!