Another year, another re:Invent. In what has proved to be a year of change for everyone, AWS showed that cloud computing is no exception. There was no slowing in the pace of innovation by the leading public Cloud provider. New services and features abound. Amid a myriad a new service names, one stands out as being exceptionally silly. Or does it? That service is Babelfish for Aurora PostgreSQL.
What is Babelfish?
Keen fans of the Hitchhikers Guide to the Galaxy will recognise the reference to a tiny yellow fish, which when inserted into the ear allows the host organism to understand any language spoken to them. The reference has been used by numerous translation services and software, starting with Yahoo’s creation in 1997.
Today we’re talking about AWS’s Babelfish for Aurora PostgreSQL. It is a translation layer, which allows commands for Microsoft SQL Server to be sent to AWS Aurora databases. What does that really means? Well, it allows applications speaking the Microsoft proprietary T-SQL to read and store information in an AWS cloud native database solution, Aurora.
Why use AWS Babelfish?
To answer this question we have to start by talking about AWS Aurora. Aurora is a AWS database built for the Cloud. It is compatible with both MySQL and PostgreSQL database workloads.
Amazon Aurora is up to five times faster than a standard MySQL databases and three times faster than standard PostgreSQL databases. It provides the security, availability, and reliability of commercial databases at 1/10th the cost. Amazon Aurora is provided through the Amazon Relational Database Service (RDS). This automates time-consuming administration tasks like hardware provisioning, database setup, patching, and backups.
I won’t go into detail about which database schema is “the best”. If you’ve ever tried to run Microsoft SQL databases in AWS, you’ll know that its not always easy. Both EC2 and RDS based options that their minor challenges. However, it is Microsoft’s punitive approach to licensing when running in a non-Microsoft Cloud that is the real kicker. Cost alone is likely to be one of the main drivers for adoption of Babelfish.
It’s ideal for those old legacy parts of the application that are tricky to re-write. Often razor sharp response times are not important but data must be secure and highly available. Say goodbye to paying for a SQL Server license (whether BYOL or included in your RDS instance) and managing the complexity of replication to another region. Just pop it on the same size Aurora instance for a fraction of the cost and effort.
How does it work?
Well, there’s a tiny yellow fish see, and it feeds off the brainwaves you give off as you… oh, nevermind!
Babelfish takes the calls you make to your database in T-SQL and then interprets them into their PostgreSQL equivalent. However, don’t dust off that ancient SQL Server 2008 application just yet. Babelfish is only compatible with SQL Server 2014 or newer.
“No problem! I have a modern application” you might say, “Lets get into it!”.
Sloooow down! AWS have made one thing very clear. Expect some errors in this process. Data types are stored slightly differently in each of these database engines. This can result in some slightly different data types being returned from what you would expect. For the most part, with some testing this shouldn’t be an issue. However if the validity of payroll or your manufacturing process hinges on whether you’re getting a decimal place to 5 places or rounded down to 2 then caveat emptor. The takeout is check the maths!
A migration path
Of course, when you’re working with Babelfish, you’ll have your T-SQL endpoint alongside a perfectly working PostgreSQL endpoint. AWS do not expect you to keep developing your application with T-SQL at this point. Think of Babelfish as a way to migrate off that legacy SQL database.
Start using native PostgreSQL. It will work more cleanly and be less error prone. That said, one of the main precepts of the service is accuracy. If a database query cannot be translated it won’t just “do its best”. It will return an error.
Its important to note of course, Aurora will not support many of the other Microsoft SQL features present in most omnipotent monolithic applications of old. There will be no out of the box AD / ADFS integration. Depending on your use case, there will be no simple backup and restore functionality the dyed-in-the-wool Microsoft crew expect as their bread and butter. This is now a cloud native database. If you restore it, it is the whole instance to a point in time, using the Cloud native way.
Babelfish is a built-in capability of Amazon Aurora and does not have any additional cost. Still currently in preview, you can enable Babelfish on your Amazon Aurora cluster with a just few clicks in the RDS management console. Amazon also offer their Schema Conversion tool. This makes converting your existing database into Aurora as simple as possible.
Babelfish for Aurora is sure to be another great offering from AWS. As we all know, if there is a customer need, AWS will built it. Assuredly, there are thousands of users out there rubbing their hands at the prospect of this new functionality. As with all new technologies, it will not be perfect day one and will evolve over time. The main premise behind Babelfish is to ease the transition away from Microsoft SQL Server, not to allow your applications to continue to use it!
Will you be able to escape legacy with Babelfish? Like any service, this one will certainly make it easier to adopt a Cloud native database. As with any migration though, the true value comes through a re-factor not refit approach. Otherwise, you’ll end up with a shiny Cloud database pretending to be an old legacy one with a monolithic application not knowing the difference!
If you would like to understand your database journey to the Cloud, please get in contact with us at RedBear.