As enterprises struggle to modernise and unlock the benefits hidden in their databases, the best minds in the industry are using distributed SQL databases to overcome most of the challenges in modernisation. Is this approach the answer you’ve been looking for?
You may have heard a lot of chat recently about ‘database modernisation.’ You might have even received sales emails about it from companies promising you improved system performance and availability, lower hardware and license costs—and best of all, a stable, agile database platform.
Sounds great. But, there’s a problem with these claims.
The kind of database ‘modernisation’ we’re hearing so much about can’t actually deliver on the promises being made—or at best, these solutions only deliver half of what is claimed.
That’s because, as enterprises have finally accelerated the move towards turning cloud into the promised default business platform it’s meant to be, they have done great work on application and infrastructure modernisation, but have still not sufficiently addressed the last step – database modernisation.
This last step is more complex than the ones before, so organisations are receiving vague promises that providers will “do something,” but they don’t spell out what that “something” actually is.
Let’s use an average cloud vendor to see why.
It will have all the right things in place, like microservices and containers. But the reality is, it’s possible to run core business data work on Oracle with Sun hardware, DB2 on IBM, or on Microsoft SQL Server with some flavour of Linux as its data centre.
Shall I Just Carve Up My Database and Make it Fit?
Well, no.
That topology doesn’t work well with the kind of cloud applications businesses want to run. These systems are great, but they were designed for a very different type of IT architecture.
To keep them running, IT teams need to spend a lot of effort pumping data into them from the cloud (which massively increases application transaction latency). This means it won’t be too long until the CFO starts wondering aloud why they are still paying for big products in a data centre, when they and the board were told the shift to cloud meant leaving that behind?
Putting your big data engine into the cloud is challenging. You need the biggest cloud server available to run it, while everything else in your new cloud runs on a little hive of small, commodity boxes. We’ve also worked with customers who have huge data transfer needs (think banking), and couldn’t physically support the traffic on a single cloud box.
What can you do about this? Many teams start by accepting they can’t just ‘lift and shift’ their old monolithic Oracle-style business databases in one go into the cloud, as that a) doesn’t work and b) doesn’t scale. What they then try is logical enough; split that big database into lots of little ones.
Which is, yes, database modernisation—but only of a very limited sort.
If you try to ‘game’ cloud by splitting your core business database into lots of little ones, you end up with all kinds of additional requirements, like keeping multiple copies and back-ups synched.
Machines can get overloaded, and you are always buying more licences to make it work. Reliability is also a big headache if you go down this route, as you’ll constantly be switching between databases, and potentially, not reconciling your transactions in time. This is not ideal for any type of transaction processing.
So—that doesn’t work. Other firms thought they could avoid all this by going NoSQL instead. This seems a logical choice as these databases were designed to do this scale-out stuff, plus high availability and resilience in the cloud. The right choice, surely?
NoSQL Has Its Own Database Modernisation Challenges
It’s a good choice—to some extent. But NoSQL, while cloud native, isn’t great at application transactional consistency.
To be clear, lots of applications will work fine on NoSQL, because they don’t rely on full transactional/ACID transactions. However, if you have any kind of serious transaction services, then you need to ensure, for example, that if a customer’s money comes out of one account it will land on time in the right place.
I’ve personally seen scenarios where engineers were spending all of their time trying to patch up or work around the fact that transactions cannot be guaranteed to be consistently applied in a distributed NoSQL database.
We have a situation where the first wave of database modernisation was either to go monolithic SQL in the cloud or go NoSQL. However, both involve a compromise. They will incur loads of engineering time and (often) too much ‘technical debt’ to make it worthwhile.
Yes, this can be avoided in certain scenarios. Some of the big cloud companies offer a distributed SQL database solution that can give you great results. However, these only work in their own single cloud environment.
What if your business wants to go multi-cloud? If your app is on Amazon but you want to move into GCP or Azure, you can’t share the load between them.
Clearly, a new approach to working with data in the cloud that is truly distributed is the answer. Not doing so means increased risk and cost, because if you adopt either of those compromises, the engineering team will have to live with all the limitations we’ve discussed.
This means increased risk, increased cost, increased complexity, brittleness across the whole architecture, and your team spending its limited time focused on constant patching and database hacking. Not a recipe for long-term success and true cloud ROI.
Distributed SQL = Real Database Modernisation
The good news is that there is a way to do full, consistent and successful database modernisation. Distributed SQL database, based on open source PostgreSQL, are a good way to get started.
We’ve supported customers who adopted both of the limited ‘first wave’ of database modernisation techniques I’ve described above. We helped them to properly modernise and future-proof their database, ending their technical debt issues, freeing their engineers to focus on business problems instead of database wrangling, and completing the last mile to achieve full enterprise cloud multi-application exploitation.
All this is why you went cloud in the first place. So, is it time for you to focus on real database modernisation, not just the hype?
ABOUT OUR GUEST WRITER
Martin Gaffney
Area Vice President – EMEA, Yugabyte
Martin Gaffney is a specialist sales executive for US enterprise software companies wishing to enter the EMEA market place. Long and incredibly successful track record of being either first-person-on-the-groud or member of the very early EMEA team in stand-out companies such as Netezza, ThoughtSpot, Sequent, Tivoli and now, Yugabyte. Martin also possesses a 7+year hands-on experience of co-founding a UK-based enterprise software firm, Volantis Systems, from 2000-2007.
