If you haven't heard, cloud is the big buzz these days and has been for the last couple years. For those of us who have to contemplate the benefits and figure out how to integrate, it’s not a trivial task.
Probably the most misleading part of the entire cloud concept is that it will solve most of your on-premise issues and make your business agile. Well yes and no. It all depends on how you plan to use it.
What's the plan?
Are you struggling to distribute your applications geographically? You're a good candidate for the cloud, especially those companies that would like to get out of the datacenter business.
Are you having issues with scale because your flag ship product is a total success? Chances are if you didn't build it in the cloud to begin with, you'll be lucky to keep those customers. Your services will likely tank based on user load. Not many companies have tons of datacenter capacity lying around. On-premise infrastructure is by no means elastic, unless you've figured out a way to make bureaucracy work.
In a discussion with a fellow IT colleague...the subject of cloud and the potential for large bills came up. He mentioned how one company he works with pays over 1 million a month to their cloud provider. All because the business decided it would be a good idea to build applications with no particular architecture or framework in the cloud. I call that traditional IT in the cloud. Anyways, my comment was, it sounds like design and automation probably weren't on the top of their priority list. It's a fairly large company, but now they are stuck pulling that mess under control.
So what’s the answer to these common cloud challenges?
Start by designing upfront, plan your stratgey for a multiple business scenarios. Use the cloud for it's intended purpose and not like traditional IT.
Where do you start your design? It doesn't matter if it’s Amazon AWS, Microsoft Azure, or some one off cloud provider. Here are a few things to consider right out of the gate.
What business problem are you trying to solve? Cutting costs? Disaster Recovery? Agility? Portability? Elasticity?
If you don't know the real reasons, I'd suggest discovering them. Exploring what the cloud has to offer is fine, but once the business catches wind of how easy it is to deploy resources into the cloud you're in for a ride. Talk with business leaders, observe pain points and have a decent idea where you could start to leverage the cloud. Proofs of Concepts are a great way to start. Build your potential business use cases. Validate them via collaboration with stakeholders. Run through your scenarios, report the results and forecast an OPEX budget.
What is an acceptable IT operational budget?
The cloud model is a one of operational expense (OPEX). Most companies try to capitalize their IT costs for tax and depreciation benefits. OPEX can be frowned upon because it reflects on the cost to run your business. Your companies EBITDA (NET income) does not reflect capital expenditures, where as OPEX does. No company strives to appear to be less profitable. This is something that would be discussed by the CEO, CIO or CFO levels with the company board of directors. Assuming your company is public, stock prices can be affected by your EBITDA calculation. Think about that company I mentioned earlier, they now spends over 1 million a month OPEX, that's 12 million a year. No small chunk of change.
Does your data have compliance restrictions?
Be very careful about where your data moves to in the cloud, local state or federal restrictions may apply. Always consult your legal team. Some cloud providers have level one PCI, SOX and HIPAA certifications on the infrastructure. It's up to you to secure your applications.
How do you advocate for the cloud?
I think after you demonstrate the speed and flexibility, you'll have plenty of customers. The cloud really sells itself to developers alike. Your biggest hurtles will be cloud sprawl, processes around provisioning cloud resources and automation. Ask your cloud provider how they can help; you’re not the only one in that situation.
Below is a logical design diagram I've been working on for Amazon's cloud. It should demonstrate to you the overall complexity of cloud design. If you would like to see more like this, take a look at some of the Amazon AWS case studies. It's a good place to compare designs and read the actual business problems those companies solved with AWS services. For those architects or engineers that need to prove out the designs, most cloud providers offer free trials to access their cloud tools. That's a good way to vet any preliminary ideas or validate your version 1.0 design.
Amazon AWS Logical Design
Amazon AWS VPC Design
Will you need connectivity back to an on-premise datacenter? If so, will your applications talk to each other, across data centers?
You'll need to understand the traffic patterns of your applications, along with how users access and work with them. Network bandwidth and redundancy are important because the cloud becomes an extension of your datacenter. Talk with your network team as soon as you consider cloud connectivity. They will thank you.
Where will the source of all your data live?
You'll most likely ship data back and forth between an on-premise datacenter and the cloud. Possibly for logs, data analytics, or batch processing. Either way you’re going to have to figure out and decide on your data source process.
How will you get your IT organization's buy-in?
Start early with training, attend non-marketing vendor seminars and promote collaboration around potential business cases. Get people to ask the tough questions, that will coax out most of their fears. Amazon in particular is growing so rapidly, that it adds the volume of it's infrastructure when they were a 7 billion dollar company on daily basis. That's insane and should be a good story to tell your team. New customers are already migrating to and /or extending there infrastructure to a cloud provider.
Planning your cloud strategy is a crucial step. I don't think organizations stop to comtemplate the long term strategy. All of the considerations I mentioned only stratch the surface, but are a great starting point. Business leadership buy-in will be easier than the struggle to convince your IT organization. Check out some of my other posts for more advice around that challenge.