For duck sake, don't use cloud!
Well, not literally.
Unless you Use-The-Cloud-Right and Use-The-Right-Cloud .
I remember there was a time when baggy hip-hop apparel was the most trendy outfit at the high school I was attending. It separated cool and uncool, it dictated the social circle, status and likelihood of success. Wearing them pretty much warranted a date. I thought. So I bought some and wore them.
And it was disastrous.
The clothing did nothing but emphasised my shorter than average height, larger than average head and I almost fell over 20 stairs because the dropped crotch jeans. I came to realisation that it wasn't for me.
Today, many companies look at Netflix, Atlassian and think "yep, I can be hip too if I rock that agile cloud thing!" Well, I only wish they could learn a thing or two from my high school styling mistake.
First, as I wrote in my another blog on congruence model & agile transformation, agile is not as simple as setting up team structure and reporting lines. Also you can successfully use cloud technologies without agile - there might be a correlation, but there is unlikely a causation.
Second, why do you want to use cloud? Requesting a new VM on-prem taking too long means you have inefficient processes and AWS can't solve that for you. Spending $$$ and successfully forklifting the CIS hardened SOE with 25 agents bootstrapped to IaaS is unlikely to equate to a successful cloud strategy.
Third, is your application intrinsically cloud optimised? Sales people may have told you that you can move mainframes or the entire Oracle DB farm to the cloud. The sales may not be lying, suppose there is also a reason for the migration, do metrics like cost and performance stack up?
Lastly, what do you want to do with cloud? On-demand compute intensive workloads, unstructured data storages, data analytics, or core CRM system, depending on your current resources and capabilities, 2 out of 4 may not be the best candidates.
Now, you've successfully answered why you want to use cloud and what you want to do with cloud. It is time to unpack the question of "how to do it?", which may also be the question that excites many nerdy technical people like me (I'm just wearing this hat until people throw stones at me - someone can't even code in Python!)
This topic can be a bit of minefield as it is being discussed quite fiercely at many places I worked for, so I will be careful and not disclose my position of IaaS<PaaS & SaaS explicitly, ahem...
Well, but I will share the general rules of thumb or the one-size-fits-all stress test that you can use to choose the right flavour of cloud.
List your strategic significant activities that will give you an edge over the competitors;
For each cloud decision point or building block, e.g., IaaS vs. PaaS, containerisation, self-managed vs. fully managed, put them into either Supporting or Irrelevant buckets for supporting activities in step 1;
For everything in the Supporting bucket, choose the flavour that you have the most of the control;
For everything in the Irrelevant bucket, choose the flavour that is vendor managed as possible.
To demonstrate how to use this test, here is an example.
Your advantage comes from the ability to update your app features rapidly to respond to the changing demand;
You need to decide whether to host containerisation stack yourself or use a vendor managed one. The question needs to be asked is "is hosting the containerisation stack supporting my strategic activity?" Well, it isn't. Good software development lifecycle practice may be.
Go with the managed stack and put your limited resources on building the containers/apps.
Note two things to consider when choosing the vendor managed solutions are the vendor lock-in and future scalability.
All in all, after 600 something words, I hope you take away some thoughts for your current or next cloud decision, other than my teenage styling disaster. I'm a big advocate of cloud technology, a bit of a fanboy too, so for the same reason, I want you to make the best of it.