Skip to main content

Vendor lock-in and relational databases

Avoiding features to enable portability

In the early 2000s the company that I was working for got a fright when the database vendor that we were tied to came out with a different approach to charging for their software license. Having applications on "the Internet" got the vendor's attention so they wanted to have a way of deriving more revenue from websites.

From then on all developers on our relatively small team were directed towards avoiding using any non-standard features of that particular database engine, as it would make it more difficult for us to be able to transition across to an alternative vendor. For example, stored procedures were only allowed for edge cases such as an advertising engine (yeah, we rolled our own advert engine for a customer back in the day).

Keep in mind that this was back when self-hosted physical servers were pretty much the only way to operate, well before cloud computing such as AWS even existed, so it was a big deal to set up a database server, involving direct license agreements with vendors.

Much much later on my career, we had guidance come down from senior management that there was frustration that the cloud vendor knew about the broad range of their services that we were using, so felt confident that we were not a flight risk of giong to another provider. On that basis we were instructed to either not make use of vendor-specific services, or wrap them in such a way that our services would be able to be ported across to another cloud provider. That tied up quite a bit of developer time, and left us restricting our implementations to the lowest common denominator level of functionality when it came to considerations like messaging systems.

"Standard" functionality doesn't mean it's the same

Looking back after a couple of decades, my recent dabbling with transaction isolation levels has been a real eye opener as to how much relational database engines can differ in the way that they go about complying to standards, even without going into obvious vendor extensions.

This has reinforced an opinion that some former colleagues of mine expressed while we were working together on a large cloud transformation project during my time in London, "You'll never end up changing database, so just use whatever it offers." 

Don't get me wrong, vendor lock-in is still a risk to keep in mind, but it needs to be weighed up against the opportunity cost of not making use of the differentiating features that could make the product worth paying extra for in the first place.

Labels:
Location: Christchurch, New Zealand

Comments

Post a Comment

Popular posts from this blog

Speeding up Software Builds for Continuous Integration

Downloading the Internet Can you remember the last time you started out on a clean development environment and ran the build of some software using Maven or Gradle for dependency management? It takes ages to download all of the necessary third party libraries from one or more remote repositories, leading to expressions like, "Just waiting for Maven to download the Internet". Once your development environment has been used for building a few projects the range of dependencies that will need to be downloaded for other builds reduces down as the previously referenced ones will now be cached and found locally on your computer's hard drive. What happens on the Continuous Integration environment? Now consider what goes on when Jenkins or your other preferred Continuous Integration server comes to build your software. If it doesn't have a local copy of the libraries that have been referenced then it is going to pay the cost of that slow " download the Internet" p...
3 comments
Read more

2022 - A year in review

Just a look back over the last 12 months. January I moved back to Christchurch to live, after having spent a few months further south since moving back from London. Work was mainly around balancing other peoples' understanding and expectations around our use of Kafka. February I decided that it would be worthwhile to have a year's subscription for streaming Sky Sports, as some rugby matches that I would want to watch would be on at time when venues wouldn't be open. Having moved to Christchurch to be close to an office, now found myself working from home as Covid restrictions came back into effect across New Zealand. March Got back into some actual coding at work - as opposed to mainly reviewing pull requests for configuration changes for Kafka topics.  This became urgent, as the command line interface tool that our provisioning system was dependent on had been marked for deprecation. April   Had my first direct experience with Covid-19.  I only went for a test because ...
Post a Comment
Read more

Applying AI to software development can be like following SatNav

Trying out a different navigation system A month or so ago I upgraded to a car that has a SatNav system included, so I have been trying to use that instead of the Maps app on my phone. My experiences with it so far have generally been good, but it is far from flawless - a bit like Artificial Intelligence (AI) in software development. As context, my previous vehicle was not too old to include SatNav, it just hadn't been set up with English language or New Zealand maps - one of the down sides of having a second hand vehicle that originated in Japan. Flawed or incomplete information Driving around central Christchurch can be a bit challenging at times as various roadworks are underway, leaving streets closed off or narrowed down to a single lane. It could be reasonable to expect that a basic navigation system might not have up to the minute awareness of those closures and restrictions. However, something that I did not expect to encounter was the navigation system advising me to expec...
Post a Comment
Read more