So, you're thinking about cloud. Fantastic, it's the solution to all technical problems known to mankind, it is so enticingly attractive and all-encompassing that surely, in the not too distant future, Starbucks will be dispensing your favorite, Vanilla double-shot skinny latte from a cloud-based espresso machine, right?1 Running an online service supporting 7 million online video editors, 50 000 of whom will be using the service concurrently and from every corner of the earth will take about 1 man-week to shift to the cloud won't it? The cloud makes it simple, doesn't it?
Perhaps not. Cloud services are indeed a remarkable set of abstracted computing resources that give you on-demand access to services such as database, processing, bandwidth and storage. But whether to use them, when to use them, and how to use them (as public, private or hybrid cloud deployments) entirely depends on the use case.
If you're thinking about using the cloud here are some 'starters for 10' to be mindful of:
Drill down... the devil is in the detail.
Leading cloud providers are very good at marketing and they do offer services that can support large scale, high-demand applications such as NetFlix, which is no small feat by anyone's standards. But if you're just getting started in the cloud and don't have the ability to negotiate custom deals with Amazon or MS Azure you'll have to accept the standard terms offered to 99% of regular users. And you need to drill into these Ts and Cs and understand what you're agreeing to. AWS for example, will offer you a SLA of 99.999% uptime, but if you drill down further into detail, you'll learn that this 99.999% uptime doesn't include maintenance downtime of 1 hour every week for their RDS service. Now, you may not use RDS as part of your system but if you do, you need to be aware of the interdependencies of the cloud services you use and how these affect the overall 'package' you're getting from your cloud provider.
Pay as you go but what are you paying for?
The cloud seems incredibly attractive from a pay as you go perspective due to the fact that you only pay for what you use, with no minimum contract term (for some services). But again, drill down before you sign up. To take the example of AWS again, as one of the most popular cloud providers, 451 Research has recently concluded that there are more than 1800 individual price points on AWS. That's quite a pricing matrix you have to navigate, based on the particular combination of services you use. For good reason, there's an emerging skill set around the 'black art of cloud cost management'2.
Use initial tests to figure out what you'll likely actually be paying for and make sure you can either pay it, or throttle it, if things go well. If cloud pricing seems tricky, don't worry, 99.9% of everyone else thinks so too!
Also, it may seem like old-school standard business practice - but you need to understand what your likely costs are going to be using cloud services. This is particularly the case in the event that your usage accelerates. If it does, it's probably a good thing and supporting the rapid growth of computing resource is exactly what the cloud is good at, but you still need to be able to cover your bills. One company that didn't plan adequately in this regard was (the now defunct) Everpix, a cloud-based photo organizing and sharing application which experienced rapid growth on AWS but pretty quickly found it couldn't cover its monthly AWS bill. That bill, like Everpix's usage, had trebled in just a few months, but the company couldn't cover the cost and had to shut down3. Perhaps the old adage should be revamped for the cloud era ; three things you can never escape - 'death, taxes and your AWS bill'.
Can you manage your business using a variable cost base as the technical cornerstone and with the potential risk of receiving a large bill at any time?
Be the guru - help your business
(it's you against the combined marketing power of Amazon, IBM, RedHat, Microsoft, Google, Rackspace, Internap, Pivotal, ...)
Business owners LOVE the cloud. They don't just like it - they LOVE it. For the first time they have apparent control and understanding of application development, deployments and IT operations. Need a new application developed? Do it in the cloud. Need to run it? Put it in the cloud. What happens if it grows fast? No problem, the cloud will take care of it. It is nigh on impossible to underestimate the sense of empowerment that the cloud provides to business owners who are finally able to 'understand' technology. If the cloud could be personified, it would be on a pedestal in the middle of your office and every 20 minutes all employees would need to face it and bow.
Cloud providers are very good at marketing and business owners love the apparent simplicity that those marketing messages suggest. However there is a real danger of unreasonable expectations from the business as to what cloud-based technologies can provide, when, how and at what cost (both direct and indirect). Business teams are being enticed by the simple and strong marketing promises of the leading cloud providers. Technical teams are then being asked to deliver against these lofty hopes, but it is not as straightforward as the marketing suggests or as the business expects. Whether or not the cloud is an appropriate choice for a particular application depends on the specifics of that application and the business case into which it fits. Indeed, some applications, both commercial and open source, do not architecturally fit into the cloud model and therefore the cloud is a non-starter.
Drill into the detail - early: Understand what you're signing up to so that your expectations are in the right place before you start. Help your business make informed decisions about the cloud, the types of cloud and the types of cloud services available by doing your homework!
In each of these internal conversations, technical teams need to be informed about the pros and cons of the cloud, and of the variants of cloud deployments in order to provide a clear and strong voice to the business. This clarity will help the business, as a whole, arrive at the most appropriate technical solution for the particular business case being considered. Adoption of new technology, in practice, is driven by the technical developers tasked with delivering it.4 It is no different with the cloud. These same technical teams need to be able to debate with and potentially rebuff pressure from the business to move the cloud if it's not an appropriate choice. In regard to the cloud, like so many other things, wishful thinking is not a strategy5. Any move to the cloud, and the type of cloud deployment chosen, needs to be thought through carefully.
Yes, I'm sorry. Extremely dull to the points of tears, but such are the legal and social frameworks in which we all live and operate. I like my streetlights on. I'll make this part short and sweet so I'll use bullets:
- you need to know where your data is so, in turn, your cloud provider needs to be able to tell you where it is.
- if you move your data outside the geographical EU, that's ok, but your data outside the EU needs to be taken care of with the same care and attention as it would were it hosted in the EU. Again, your cloud provider needs to show you it can do this.
- cloud providers need to be in compliance with a directive set by the European Commission in 2010.6
There are, of course, different types of clouds (public, private and hybrid). With a private cloud, you know where your data is. If you're using a public cloud provider you still need to know where your or your users' data is. The whole environment is reasonably fluid (driven by cloud technology rather than the efficiencies of Brussels) so when in doubt speak to a lawyer.
Clouds have corners - don't paint yourself into one.
Your choice of cloud provider can limit your future cloud choices. Some cloud platform providers are portable (Red Hat's OpenShift or IBM's Bluemix, for example), allowing you to maintain relative control of your cloud platform. Should you wish to use the public cloud, you can do so using these platforms and if you change your mind, you can also revert to a private cloud or a hybrid cloud deployment. Others aren't portable. As far as I'm aware, you can't really license Google's platform nor AWS. You need to be aware that if you go with one of the big public cloud providers and start to build on top of the services they provide, it will be a reasonably big job to then move off of it and go with an alternative provider.
Keep in mind as well that the pace of change on cloud platforms is nothing short of staggering. IBM has recently released 3 new APIs on Bluemix that simply were not there two weeks ago. Bluemix itself had a big revamp just 4 months ago. Many cloud providers are still trying to figure out their own business models and others are run being subsidized by other parts of their family (AWS for example). This very much means that any cloud foundation you choose to build on can change and change quickly. You need to be aware of this possibility and just be sure where the exit signs are if you need them. A prudent strategy could be to identify the core services you might need and use from the cloud, ensure they come from a good provider and make sure that that provider can satisfy a variety of deployment options you may need - private, public, or hybrid.
Start smart - start small - then test test test (and then test again)
A lot of cloud service providers will allow you to run test deployments so that you can come up to speed in your own time about using their particular flavour of cloud. This is a smart way forwards as it allows you to get a feel for what is possible, the different skills your team may need to run cloud deployments, and you also get an early, risk-free understanding of the different costs factors involved in your particular use case. This of course links back to points 2 and 3 above.
Test, benchmark and ensure your cloud system is able to deliver and cater according to demand. You may find unexpected bottlenecks with the cloud provider / platform you have chosen. This will require design, implementation and a lot of hard work in setting up regression tests, load tests, performance tests, and pricing tests. For example, you may quickly find that your Java web application, which has been tested on Jetty and Glassfish, won't run on you chosen cloud platform as it only supports Tomcat and JBoss. These are the details you'll only discover through testing. This testing period necessitates internal budget being assigned for a 'cloud discovery project' but it is resource well spent in understanding how best to utilize cloud services for your business case.
The Nutshell: key takeaways to slap on the fridge
- Drill into the detail - early: Know what you're signing up to and so your expectations are in the right place before you start.
- Understand what you will be paying for: Use initial tests to figure out what you'll likely actually be paying for and make sure you can either pay it, or throttle it, if things go well. If cloud pricing seems tricky, don't worry, 99.9% of everyone else thinks so too.
- Be the guru: help your business make informed decisions about the cloud, the types of cloud and the types of cloud services available by doing your homework. Clouds are awesome if used correctly (p.s. this article counts as homework).
- Yuck - legislation: Know where your data is. Protect it. Demand the same from your cloud provider.
- Clouds have corners: make sure that if you need to be portable you choose a set of cloud services that can be moved. If you're happy to be more restricted, fine, but just know that you're making that choice.
- Start smart - start small and test, test, test before you scale up: Any investment in testing will more than pay dividends when you go live with cloud services.