Skip to main content

Flying into the Clouds

A few days ago I gave sage commentary on leaving the cloud. Today, it's about going into the cloud instead.

Image generated by MidJourney

I’ve been living with my head in the clouds for a long time now. As a fledgling startup from before AWS, I could only look on in envy as a cohort of youngsters flashed a credit card and pulled in computing power I had to spend months and millions with IBM to get just a handful of years ago, This got me deeply into the cloud, and my next few startup-ish attempts made me no money, but did teach me a lot about how to ignore IBM.

A History Lesson

I’ve worked with companies that were not startups but benefited greatly from the move to the cloud in selected areas. The first was Indiainfoline, a decade ago India’s largest broker and struggling mightily with its hyper-growth. We put — not the core, but a very essential and troublesome service on the cloud — email. Remember, a decade ago email was the collaboration lifeblood of a company, and constant problems with it were sapping a lot of energy. We wanted to get it off the table, Google met Nirmal and suddenly I was told — you have a month to move these 20,000 emails up there. This was well before such things became routine — we were one of the top ten largest migrations in the world. Googlers came down from San Francisco to help (though sometimes just to shake their head in disbelief). But it happened, and it was easier than we thought it would be, and what was worse — email just stopped failing. My best excuse for skipping meetings (I never got my invite) was zapped into the cloud in thirty days.

This was my first saas-bahu serial but more was to follow. My procurement approval workflows were saassed into existence within days when the pandemic removed all possibility of papers and peons. A loan origination system jumped into Salesforce in days. Cloud desktops bloomed like flowers when laptops were all sold out.

Then there was RBL’s disaster recovery. The argument took longer than the delivery and a handful of junior people faced the Nirmal in me. We went from nearly zero to full platinum drills in about three months. In a Bank. With lots of critical servers, apps, processes, data…

There were other stories too. Every time we had a messy complicated on-premise system we’d shove it onto the cloud and clean it up there. Legacy is notoriously hard to fix on-premise — turns out the cloud makes a lot of things easier. And along the way I kept realising, I was not the leader. People were using the cloud better than me. Getting more returns. Getting better value. So I did what you do when you can’t practice — you study and then you preach.

Staying Clear

Do CIOs have the choice today to steer entirely clear of the cloud? Of course, they do but it has to be a considered choice rather than the usual knee-jerk of security or regulation or cost fearmongering. The cloud is a powerful weapon so a CIO would be a fool to ignore or fear it. You could steer clear, but you should be very clear about the benefits of disavowing such a powerful tool.

Clear about the Cloud

The first thing about moving to the cloud is to be clear about why. Remember I wrote in the last post about not being scared of on-premise? I’ve met lots of people moving to the cloud precisely because they are. Some move because it's a fad like skinny jeans or green tea. Some don’t know why they move — they inherited someone else’s strategy and just went ahead.

Don’t move till you know why. No one is kicking you upwards yet; you can stay where you are for at least another decade (though I predict that eventually, you will have to move — data centres and server manufacturers will eventually just ignore you if your order basket isn’t a million servers). You thus have a decade to do the move well.

What are the reasons to move? Well, today only five things:

  1. Flexibility. On-premise has always been bound by a few rigidities. A few years ago it was normal to wait months to provision new servers or storage. Today, Businesses are changing, paradigms are shifting and suddenly flexibility is a crying need. On-premise is still largely cemented into the same place. Hence cloud.
  2. Reliability. When your grandmother’s foodblog has better availability than your expensive business website, CIOs feel worse than foolish — they feel incompetent. Better to join the bandwagon.
  3. Capacity. Egged on by these consumer tech companies, businesses are being forced to do things like analytics and AI properly, not using overgrown spreadsheets. Petabyte and microsecond no longer have the power to intimidate businesses like they used to; how is the poor CIO expected to produce these things on-premise?
  4. Cost. Yes, rent can be cheaper than buy. The catch? You need to be reasonably cloud-native to benefit (or if using a SaaS service, cloud-native in usage, which means eschewing premise-y things like printing). Huge benefits if the use case is correct, otherwise get back off now!
  5. Security. Everyone asks if the cloud is secure, whereas you should be asking if not being on the cloud is secure. Properly done, the cloud is far more secure and difficult to hack into than anything the average (or even above average) CIO can produce in his or her backyard.

I can see CIOs yawning already. This is all well-known stuff; spouted by every brainiac in the last decade so why is this worth anyone’s time anymore? Well, for one I’m saying these are the ONLY five things worth thinking about here; if you have a longer list you’re wasting your time with diversions or an overpaid consultant. Sure, there are lots of other benefits possible but — if you’re at a river full of gold nuggets, pick up the nuggets and don’t get distracted fishing trout.

Go Big or Go Home

These five (FRCCS, if you want to sound like a doctor) are the lodestones of a successful move to the cloud — where I define success as better outcome and not just uneventful migration. I want each move to the cloud to achieve at least one of these outcomes, and I want that improvement in outcome to be a noticeable, substantial, Messi-winning-the-cup kind of achievement.

Why do I insist on this? The cloud is not an improved version of your on-premise setup; it's a substantial shift in paradigm, and paradigm shifts are hard, costly, stressful, risky to get right. If you achieve only marginal gains you have either not really shifted paradigms or all those huge efforts were not necessary in the first place. When we moved our first lot of servers into the cloud as is, shifting IP address rather than paradigms, costs increased by 30%. We then went and cleaned up, did the actual shift needed and costs came down dramatically, by some 80%.

Why did we move as is in the first place? It's quick and low risk; much better to move paradigms once the move is done (though the homework should have been done well beforehand). Think of it this way; If you’re planning to move apartments would you decorate first, then box it up and move or move as is, then redecorate?

Summary

So that's my quickie summary of the advice. Decide which of the five matters in your shift, plan well, move quickly as is and then paradigm-shift immediately after. Then sit back and sip coffee at the substantial improvement (or move back if you discover you’ve made a mistake).

Comments

Popular posts from this blog

Outsourcing I–The "Why" Question

A little while ago, I was asked to give a presentation to CEOs on outsourcing. The audience wanted to know about adopting outsourcing for their companies; making use of its promise while avoiding its pitfalls. It seemed to me (unimaginatively, I must admit) that the whole thing boiled down to four fundamental questions - the why , the what , the who and the how . I decided to expand the presentation into a series of blog posts, one per question. The Why Question Why outsource? Given that a trillion-dollar industry has crowded a lot of people into Bangalore and made more than one driver rich, it seems a little late to ask this question. However, this isn't really about outsourcing being good or bad per se. Bloggers like us love to wallow in theoretical questions; companies usually want answers to more prosaic stuff. The question really is, why should a company be looking for an outsource partner ?   I've divided the universe into two simple flavours – Tactical and Str

Rethinking Disaster Recovery

Disaster Recovery has been on the minds of companies ever since the early days of commercially available computing. Today's world of DR revolves around four acronyms - BIA (business impact analysis), RPO (recovery point objective), RTO (recovery time objective) and BCP (business continuity plan). The acronyms appear in a disaster recovery plan in roughly in that order, the thinking being that you first analyse the impact to business of systems being down, then figure out how far back in the past are you willing to turn the dial back to recover from (last day, last hour, last millisecond). Next focus on how long you can afford to be down. Finally - buy a boatload of hardware, software and services to convert all this into action. Setting up a DR is a hugely expensive affair that takes a significant amount planning and effort, not to mention all those drills and tests every now and then. CTOs have followed this prescription since the late seventies (apparently the first hot site wa

Outsourcing III–The "Who" Question

A little while ago, I was asked to give a presentation to CEOs on outsourcing. The audience wanted to know about adopting outsourcing for their companies; making use of its promise while avoiding its pitfalls. It seemed to me (unimaginatively, I must admit) that the whole thing boiled down to four fundamental questions - the why , the what , the who and the how . I decided to expand the presentation into a series of blog posts, one per question. The Who Question Once you've clarified why you're looking for an outsource partner and also which pieces to outsource, you're faced with the next big question – who? What should you look for in your potential outsourcing partner? The choice, I put to you, comes down to four linked characteristics. Ability The first characteristic, of course, is ability. A vendor cannot be under consideration at all if the basic ability to handle whatever you plan to outsource is not present. This is not always an easy thing to judge, especi