What is the Cloud?

Good article to explain Cloud!

I am excited to have a guest post today from sharing his thoughts on the cloud. Chris heads up the Solutions Architect team for storage and virtualisation at leading UK system integrator . If you're considering moving to the cloud, this post offers guidance on what you should be thinking about as you create your plan.

 

I’ve been discussing and reading Cloud now for well over a year. For a long time I was skeptical, basically because it was all marketing hype with very little technical substance. Elastic IT, IT as a Service, Platform as a Service, IT Agility have all become cliché terms used daily in most publications talking about anything to do with IT, even if it has nothing to do with Cloud! So what is my take on Cloud? What do I think you really need to do in order to achieve a Cloud infrastructure? I will touch on the specifics of Private, Public and Hybrid Clouds, but in general I’m talking about generic Cloud infrastructures. There are so many *aaS terms now (and people make up their own daily it seems) that it’d be impossible to cover them all. I’ll coin my own KaaS (Kranz as a Service) where-by many of my customers’ ad-hoc email and phone me and get a fairly prompt response. That’s Cloud isn’t it?

 

Cloud is a Framework

 

For me the basis of Cloud began long ago, and it’s something that has been with us for some time now, but it has only been evolved into “The Cloud” fairly recently and as all good sales trends, it’s been a huge marketing success story. Oddly the Cloud wouldn’t be as successful as it is without Cloud services! Social Media has played a huge role in opening up the Cloud debate and that is entirely dependent on Cloud infrastructures. Cloud is basically a framework that supports all the services that it is designed to deliver. Still a little complex and vague maybe? For years we have been told to design our infrastructures around a framework methodology, whether this is ITIL, TOGAF, Prince2, SOA or some internally developed infrastructure framework. However not everyone has done this (in my experience, very few people have!) and many people simply install point solutions. For years this hasn’t been a huge issue as point solutions were more often than not physical servers with a single role and local storage. I think this is perhaps the history behind why the storage and networking teams have been so distant from the rest of the IT team as they have actually had to consider a shared infrastructure!

 

Virtualisation brought a new wave however, suddenly the server team had to think about the shared infrastructure, suddenly entire servers, applications, services could be rolled out and deployed in a matter of hours or days (perhaps minutes?) rather than weeks or months. This led to a lot of confusion and unfortunately bad practice as people just weren’t used to thinking with the sort of mind-set that encompassed an entire infrastructure and many people still focused on the point solutions and point deployments. This led to the term “VM sprawl” where suddenly a relatively stable IT infrastructure boomed with services after deploying a virtual infrastructure, but with no real management over this. A virtual infrastructure is fairly simple to deploy today, you don’t even need proper shared storage thanks to the abundance of virtual storage appliances (god forbid!). But to do it well still needs a clear methodology and framework understanding.

 

Virtualization and Cloud: Similar Elements; Big Mind Shift

 

So what’s the difference between a clearly defined virtual infrastructure with a clear framework and methodology and a Cloud infrastructure? Very little, if anything in my opinion! But there is a big mindset change that is required in order to transition from a virtual infrastructure into Cloud services. This has nothing to do with software solutions, although these can often help execute once the definitions have been made. The IT team needs to understand that the IT infrastructure needs to be clearly defined and controlled.

 

I truly believe that a Cloud infrastructure can be put together in a fully physical environment with no management applications or orchestration and automation tools. How? By clearly defining the processes and procedures that the IT team will under go in order to support and service an infrastructure, you will have a Cloud. It might not be as smooth or efficient as if you had a stack of software tools, but it would be a Cloud none-the-less. The key to deploying your own Cloud is to understand what the framework is that underpins your own infrastructure. This brings me on nicely to an important statement.  Best Practices are only ever developed and validated by you!

 

Good Practices vs Best Practices

 

The industry cannot tell you what best practices you should follow and be guided by. The industry will tell you the good practices that will help support their own products and the designs that they have supplied, but best practices need to be validated by your own staff and services as they will only apply to you. I have been to see many customers over my years, and what makes my job so fun and interesting is that everyone does it differently! I could go see 2 finance firms that have identical infrastructures where all the teams go drinking together as one big group, but they will do IT very differently from each other and this is why an industry supplied “best practice” cannot be adopted without validation as an internal best practice. Don’t underestimate this and don’t believe any guarantees unless they are validated against your own services!

 

However, don’t re-invent the wheel. I’m not suggesting everyone goes out and develops their own frameworks and best practices from the ground up. Industry experts have already put in the hard work for you, so use what you can and make your life easy. There are a lot of carefully validated good practices, frameworks and IT maturity models out there that you can develop and adapt for your own infrastructure. The important part is that these are fully validated against your own infrastructure. Don’t sign off on a test plan unless it includes some validation against your own systems, preferably a clone copy of mission critical systems! Don’t sign off on a best practice or framework unless you have validated it yourself internally.

 

Instruction Manual for the Cloud: Frameworks

 

I keep talking frameworks, so what do I mean by this? I won’t go into too much boring detail around the different frameworks, but lookup ITIL, TOGAF, SOA and Prince2 as a starting point and you’ll get a feel for what a framework is. It is very much like an instruction manual, but far less rigid. Think of it as paint by numbers where the colour can be anything you choose and the picture can change depending on what you require. It simply helps guide you through a standard process using a set of procedures. I think one of the best models to start with is the ITIL model. This is very specific to IT and it has one very important aspect that I think should be adopted in almost anything that we do: “Continual Service Improvement Programme”. This is very important as it makes you continually analyze and develop your own infrastructure. What you deployed today isn’t necessarily going to be optimal or the best in a year’s time, so you need to continually analyze your own infrastructure and determine whether it is optimized fully. Even a fully automated Cloud infrastructure requires analyzing and improving. Many public sector bodies talk about a “Continual Service Improvement Programme” as it shows that they have an investment in quality assurance and they are continually re-investing in their services.

 

Determining Your Best Fit Business Services for the Cloud

 

So let me bring this back to Cloud. There is a wealth of software and services available now that are Cloud enablers or directly from service providers, but with out a clear understanding yourself what you need / want to achieve from a Cloud infrastructure, they will only offer you a good practice way of doing things, and they will rarely be able to give you the full business benefit. Don’t get me wrong, many of them will give you fantastic changes from the way you are doing things today, but they aren’t making the most of what you can achieve. Without sounding like a motivational speaker, you can only get to be your greatest by achieving it yourself!

 

Start at the top, the end user. You need to be able to define your business as a set of services. What services does the end-user rely on in order to keep your business functioning?

 

Many people come to me and say, I need Oracle to be 100% available as all my users use it. Well, actually they probably don’t. Ask any of those users and they’ll say they use the intranet, or X application. They don’t care or know that it’s Oracle that powers all this, they care that there is an interface for them to work from. Users open Outlook, not Exchange, so why do they care that you have deployed a geo-cluster across 3 locations? They care that they can open Outlook, not have to watch the timer for too long and respond to an email from their manager (or laugh at a YouTube video and share it to a hundred other people in your company).

 

Understanding Your Full Service Stack from the Top Down

 

Once you have defined your business services you can work down and start understanding what supports these services. Okay, now we can talk Oracle and Exchange. But what goes into these systems? If I need to expand my Oracle or Exchange infrastructure, what are the steps required in achieving this? This is where my processes and procedures come into play. This is where my understanding of my SLAs comes from. Without an understanding of the business services and what these rely on, how can you clearly define your SLAs? It’s great the business is saying they require a 2 hour SLA on an application, but if it takes 1 hour to recover Oracle, 30 minutes to contact an IT administrator and 40 minutes to diagnose, you’ll break your SLA. You need to understand your services in as much detail as possible.

 

Again, many of my customers talk to me about DR facilities of their storage and virtual infrastructure. Great, we can provide a 2 hour RTO on all services. But how will end-users access these services? If there is a 6 hour DNS refresh period and users have no other way of accessing DR, it doesn’t matter how great replication is, my users are offline for 6 hours! This is why it is so important to understand your full service stack. This is essential in order to successfully deploy and manage a Cloud infrastructure. Especially if this is hosted as a Public offering, you really need to understand your services.

 

Managing SLAs: Be Proactive

 

Remember that an SLA isn’t just about Disaster Recovery or Business Continuity. It’s a Service Level Agreement. If my Oracle system requires 5000 IOPS and I’m only giving it 3000 IOPS, it will not give the level of service that I require, so it will break the SLA that you have defined. SLAs need to be defined at the service level for the end user. If an end user is offline for 2 hours, it’s bad, but if he is spending 2 hours every day staring at the egg timer, then it’s catastrophic!!! Make sure you define your SLAs properly and have an effective way of auditing and monitoring these. (Would you consider adding something here about performance and capacity monitoring of the infrastructure to assure service levels?) This is especially important in the Public or Hybrid Cloud where you don’t necessarily own the infrastructure and you are paying someone else for a service and a certain level of service performance and availability.

 

Orchestration: Plan and Define Before you Orchestrate and Automate

 

Something that comes up quite a lot at the moment is Orchestration, and I think this is particularly hot as software vendors are starting to release some very good tools around this. This is an important topic as it doesn’t necessarily need to be software, but it is essential for making the Cloud function. Orchestration is basically a set of procedures that define how something will operate. Sounds familiar? Orchestration is key to the Cloud infrastructure as it allows things to run smoothly to a predefined standard. There are some very good software solutions emerging today that allow Orchestration, but without planning and defining what exactly you want to automate or orchestrate, these packages aren’t going to offer you much other than what someone else has defined as a Cloud requirement. A good Orchestration tool allows you to develop and define your own procedures and also defines an audit trail to validate these.

 

Auditing: Validate Your Best Practices

 

This brings me onto another important topic. Although perhaps not an immediate requirement of a Cloud infrastructure, I believe it is fundamental to putting in a secure, reliable and streamlined deployment of the Cloud, making the most out of your investment. Auditing! Auditing allows you to track how a system was deployed, what services were provisioned, what configuration changes were made and whether you met your defined SLAs. These are all important as it’s useless going to all the effort of clearly defining your Cloud Orchestration model with all the bells and whistles, but then no way to check that any of it actually works, other than having a service come online the other end. You need to be able to audit your infrastructure to allow you to validate that you have indeed met your own Best Practices and that you have the robust infrastructure that think! And auditing is also essential to having a continual service improvement programme. How can you improve something that you haven’t validated and don’t know how it works today?

 

Cloud is All About Services, Flexibility and Agility

 

So bottom line, what is my definition of a Cloud? It is a clearly defined framework and service model that is validated against your own business services that enables IT agility and improved service availability. A bit of a mouthful, but I think if you have read this far, it’ll make a lot more sense to you. Everyone has their own definition, and I’m sure many people will chip in with comments regarding things I have missed out or applications that can enable this, but the fundamental important takeaway is that you need to define your own Cloud and validate it against your own services, or it will never be as strong or as beneficial as it potentially could be.

 

Good luck with your journey to the Cloud!