Choosing The Right Path To The Cloud

What happens when customers with on-prem databases decide they want to embrace the public cloud? If you’ve been following the story so far, it is my assertion that most of “the easy stuff” has already moved to the cloud: backups, websites, test/dev suites, videos of cats etc. We are now in the next phase of enterprise cloud adoption, where all the difficult, complex, gnarly stuff is being considered – and that usually means business-critical databases.

The guys at IBM Cloud have a name for this: they call it “Chapter Two“. In fact here’s a quote from page one of a recent IBM annual report (emphasis added by me):

“… the most challenging and complex work of these digital transformations still lies ahead. We call this work ‘Chapter 2,’ in which our clients modernize and move their mission-critical workloads to the cloud, and infuse AI deep into the decision-making workflows of their business.”

It seems that IBM knows it missed out on Chapter 1, but is determined to have a different result for this second, complex wave of cloud transformation. It has a long way to go to catch up, though, because Microsoft and AWS are dominating this market right now – while Oracle and Google are both racing hard to build their own shares of this massive opportunity.

Regardless of which public cloud is being considered, the question for most customers isn’t so much “Who?” as the more thorny issue of “How?”

So with that in mind, let’s have a look at the three main approaches to moving complex database applications into the public cloud.

Three Journeys To The Public Cloud

When it comes to existing, business-critical database-based applications, there are three high-level methods to consider when moving to the cloud. Yes that’s right, migrating to the public cloud is as easy as 1, 2, 3…

1. Optimize: The ‘Lift and Shift’ Approach [IaaS]

The chances are that your on-prem database is going to be one of the usual suspects: Oracle, SQL Server, Postgres, mySQL, DB/2 etc. And as probabilities have it, that database is more than likely running on Linux or Windows (if you are still running on big iron UNIX or – heaven help you – some kind of mainframe, you can leave now please) and there’s a fair chance you have a virtualization layer in there too. So just pick it up and wazz it into an Infrastructure-as-a-Service (IaaS) offering, will you? Quit fooling around reading this, you could have done it by now.

Welcome to lift and shift. You have now immediately realized the benefits of the cloud: all that on-prem hardware has been turned off and junked, the Capex bills have been replaced by monthly Opex costs to the cloud vendor and the DBAs have been rebadged as Site Reliability Engineers (SREs) and given new, cooler t-shirts to wear. Somebody give the CIO a bonus!

Of course, life is never this simple and there are inevitable pros and cons. IaaS still has to be managed by your own operations teams (which is expensive), databases licenses, where applicable, still have to be managed (and are expensive) and those cloud infrastructure bills are looking awfully large. Did somebody say the cloud was going to save money?

Performance is a problem too. The Dream Of The Cloud™️ is to have infinite scale of resources on demand, but your architecture was designed for on-prem and simply cannot take advantage of cloud scalability. When the DBAs (sorry, SREs) deployed this in the cloud, they had to choose between architecting for the average workload – which means performance sucks at peak times – or architecting for the max, which is way more expensive. Inevitably, the compromise fell on the side of cost and so the result is that application latency is high, user experience is low and nobody dares to run any analytical workloads for fear of taking the whole platform down.

Maybe there’s an alternative?

2. Modernize: Managed Database Services [PaaS]

Every cloud vendor has managed database offerings – in fact, most have a plethora of different offerings. Microsoft, for example, has Azure SQL Database as well as Cosmos DB. Oracle has the managed version of its eponymous database, Google has Cloud SQL and AWS has so many database services that there aren’t enough electrons on the internet to list them all. So why choose managed databases?

The Dream Of The Cloud™️ is to rid your business of all the low-level drudgery that comes with running IT infrastructure, so that your operations staff can rebadge themselves as DevOps and spend their time on more valuable activities, like drinking artisan coffees or breaking CI/CD pipelines. IaaS doesn’t really deliver on that dream, but PaaS gets a lot closer. Now, the cloud vendor takes care of much more drudgery and also – for licensable database products – manages the licenses so that you only pay for what you consume.

Of course, life is never this simple and there are inevitable pros and cons. Managed database services can be notoriously expensive if you need all the enterprise features you took for granted on-prem, while performance can often be problematic. Remember that managed SQL databases are designed for the average workload and not the peak, so if your system is an edge case in any way – if you’re not running with the pack – it won’t be a perfect fit. Maybe far from perfect.

Another potential issue is that many business-critical database applications are full of business logic. Think of Oracle database with PL/SQL packages written by developers long since retired. Can that be easily migrated into Managed Postgres on Azure, or Cloud SQL on GCP? Maybe the code calls UTL_FILE to write files which are then sent elsewhere using UTL_TCP. Try feeding that code into an automatic migration service.

Managed Databases are a great solution for the hundreds of boring databases you may have on-prem. Imagine never having to patch stuff again! But for anything even remotely unusual, or anything that regularly causes you pain, the chances are slim that PaaS will be the right fit.

Of course, there is another option…

3. Transform: Refactor to Cloud Native

Ahh, the path of the truly enlightened! Rip up your existing applications and rewrite everything to be cloud native. Fill out a bingo card with words like microservices, containers, serverless, Kubernetes and mutable infrastructure; tick them off one by one as your DevOps team write the whole application in Rust. Move to open source quasi-database platforms like Postgres, Cassandra and Elasticsearch.

Boom! You have now achieved The Dream Of The Cloud™️ which means that your application is truly distributed, scalable and has virtually no performance limits. I sound like I’m being sarcastic, but I’m really not – I have recently been working with customers who have built environments exactly like this and I could not be more impressed with the results (although these were “born-in-the-cloud” companies who were building new application stacks, rather than toiling with the technical debt of “legacy” on-prem apps). It’s the future.

But guess what? Life is never this simple and there are inevitable pros and cons. If you are starting with the baggage of an on-prem deployment which needs to be migrated, this is quite clearly the most complex and time-consuming option. It’s a proper migration project – and everybody in IT has a story about a long-term migration project which ran over time, over budget and ultimately didn’t deliver on its starting goals. Also, it may require specialist skills which your organisation doesn’t have. Do you really want to engage a team of consultants and pay them on a time and materials basis?

No matter which way you look at it, this option is the most expensive and carries the most risk.

So Which Option Is Best?

To state the obvious, there is no best option and everything has to be evaluated on a case by case basis. It makes sense to look at the anticipated lifetime of the application in question, because if it’s only going to be around for another couple of years, why expend the effort of rewriting anything? Just lift and shift, or use PaaS if possible. But most important of all, keep in mind that the options above don’t have to be mutually exclusive. It’s possible to lift and shift multiple applications to achieve an immediate goal of reducing your on-prem data centre footprint, then consider a smaller selection of those for further adaptation to PaaS. It’s also possible to move into the cloud using IaaS or PaaS while, at the same time, starting a longer-term project to refactor to cloud native.

In summary, there is no perfect journey to the cloud. The bigger and more complex the application/database, the more you’ll have to compromise on the expected result. But, after all, when was that not the case in Enterprise IT?