Though its roots stretch back to the 1960s (like many IT innovations, we
owe this to DARPA funding), the cloud only really became a fixture on the
IT landscape in the late 1990s/early 2000s. It mostly took off thanks to
the effective marketing of companies like Salesforce and Amazon (as AWS
launched in 2006).
For over a decade we’ve been told that the answer to any IT business
question—from storage to distributed workloads, from scalability to third
party application access—was cloud, cloud, cloud. To quote Marc Benioff,
Salesforce supremo and prime mover of the ‘No Software’ movement, “I
envisioned an opportunity to deliver software to businesses in a new way,
to make purchasing software easier, simpler, and more democratic.”
Well… yes and no. It seems we’re now experiencing something of a
backlash—with an increasing number of CIOs questioning whether cloud
really is the answer to every question.
CIO’s are waking up to issues they have previously not considered, such
as how they can ensure the choices they make now about cloud versus
on-prem don’t expensively catch the business out further down the road.
While few companies are completely moving away from public cloud,
many are quietly pulling at least something out and re-examining their
dependence on the cloud. This phenomenon is called cloud (or workload)
repatriation and involves moving workloads or applications away from the
public cloud to either on-prem or other clouds.
The trend seems to be a rebound from the hyperscalers, as opposed to an
issue with the cloud per se. It may also partly be a response to the
ongoing debate about avoiding CSP lock-in, which results in many
companies choosing to adopt a more multi-cloud approach. Whatever the
cause, analyst group 451 Research, recently polled enterprises and found
a surprisingly high 54% had moved workloads or data away from the
public cloud in the last 12 months, and 36% of them had moved both
data and applications.
Only a fraction (4%) of those surveyed had moved completely away from
the public cloud, but nearly a third (27%) had relocated between a
quarter and a half (26%-50%) of all their cloud-based deployments.
Various reasons were given for this activity including concerns about
security (which never really went away), data sovereignty, and cost
concerns around overspending on public cloud services.
Evidence of the last point was given by the CTPO of a firm called
37signals, who went public to say that moving some of his workloads off
his chosen CSP partner has reduced his cloud spend by 60%. This took
his bill from $180,000/month to less than $80,000. He expects a further
$10m of savings over the next ten years as a result of this move.
Food for thought. But of course, just as it was probably misguided to say
‘cloud’ to everything, it’s just as short sighted to now say ‘no to cloud’
Any decision on the optimal destination for your workloads should be on a
case-by-case basis—which means that many workloads are still better
deployed to cloud infrastructure. Start-ups (or start-up apps) often
benefit from cloud deployment, which is characterised by small volumes
and unpredictable growth.
When volume and growth takes off, or you expect it to, deployment
choices need to be more carefully considered. But, you may examine
individual workloads and say, actually, this is fairly predictable stuff.
We've been running this architecture at this scale and data volume and
we know it isn't going to change massively. Then it’s time to conduct a
structured price comparison, and perhaps determine that it’s actually best
to keep it in-house.
Making the right choice in the stack to optimise hybrid workload
deployment is extremely important. Perhaps we can usefully crystallise
this down to a new slogan. Instead of on-prem first or cloud first, we
should perhaps be hybrid-first.
Is a new relationship with your CSP on the cards?
There is a price to pay for your new-found freedom. If you make the
wrong initial choice, you exclude yourself from any chance of easy two-
way application of workload migration between on-prem and cloud.
This means you will lose the chance for easy repatriation of data or
workload from an expensive cloud, something organisations like 37signals
have done to save costs. It also stops you flipping your data centre-
hosted app to the CSP (Cloud Service Provider), if that makes more sense
in the future.
Making the wrong database choice and removing the option to move
easily between on-prem and cloud could seriously limit your business
growth. If an on-prem app suddenly becomes a huge hit with your users
or end-customers, you need immediate access to the high scalability the
So, poor database selection is a huge potential blind spot in your data
layer. If you have chosen a business database (say, DB2) that cements
you into a single deployment choice, it’s generally a bad idea. By the
same token, if you use a great but proprietary Amazon cloud database for
your cloud application, it’s virtually impossible to move it out of that
environment to an alternative. Private cloud or not; it just can’t happen.
So, hybrid-first solves many problems for organisations who can afford to
run a data centre. But, you need to plan ahead to see if you can
reproduce the functionality you need wherever you decide to run.
That may sound tough, as surely there’s no database architecture that
can convincingly work in both on-prem and cloud…? Here’s the good
news! Scalable, open source PostgreSQL (like YugabyteDB) can double up
on both jobs if required.
An in-depth look at cloud repatriation is probably long overdue. Business
is now much more complex and requires more IT flexibility than ever
before. As IT professionals, we should always seek to use the right tool
for the job to ensure we achieve optimal results.
It’s also a timely reminder to avoid committing to a proprietary system if
you can avoid it, as you might find it tricky and expensive to extricate
yourself as the needs of your business evolve. Ultimately, it’s always best
to make sure you keep your options open.