If you do not adopt DevOps your business is going to fail.
It is going to fail because you underestimate the cost of your slow and cumbersome IT delivery processes. Either you will realise this before your competitors, or they will realise it before you.
No-one cares about Bing.
But you know this. That’s why you already love DevOps – and you are already “DevOps-ing” all the things… Apart from your relational databases.
Who cares about the database?
Me. And future you. Because your business will fail if you don’t. For three reasons.
One – Your business will fail because it won’t scale
I’ve been helping organisations adopt DevOps for SQL Server and Oracle databases for six years. There is a pattern to the organisations that seek my help. Their history looks like this:
- Some clever person had a fantastic business idea. It took off. They made lots of money. Well done them.
- The business grew quickly but did not make the time or possess the awareness or skills to invest in database DevOps.
- The database became a legacy big ball of mud very quickly. Now the business struggles to change it. They make bad design decisions to avoid changing the database, exacerbating problems.
- As they grow more and more people need to make changes to the database. It becomes harder and harder to manage it all. The error rate increases, the pace of development crumbles and simultaneously costs spiral.
It’s much easier to adopt DevOps while the project is still young, before it turns into a big ball of mud.
What doesn’t help is when Mr or Mrs business person thinks their initial success was because they broke the rules, rather than in spite of that fact. Had they adopted Database Lifecycle Management (DLM) early they would have grown even more quickly in those early days.
Two – Your business will fail because database people love silos
DevOps started as a reaction against siloed development and operations teams that have different responsibilities and processes. This separation of concerns results in enormous inefficiency and unreliability since the left hand doesn’t talk to the right.
Nowhere is this division more apparent than in the realm of data, where teams of developers and DBAs sit at either ends of the office and blame each other for every delayed release or failed deployment.
The typical cycle time for a database change is measured in weeks or months and requires various hand-overs and approvals. This delays your product release, reduces the number of times you can iterate, and gives your competitors a real advantage.
Three – Your business will fail because data will be your bottleneck
One of the core principles of DevOps is Lean.
Lean manufacturing sees the importance of recognising your bottlenecks. For example, if you have a highway between two cities and you want to improve through-put, there is no point adding an extra lane to a section of highway that is already nice and wide if the traffic normally builds up somewhere else.
Similarly, if your application deployments are always delayed because you are waiting on database changes, there is no point optimising your process for delivering your web apps until you have solved the database problem.
DevOps folk say “if it’s hard, do it often”. The theory is that the hard stuff is the stuff you need to practice and optimise. Yet we ignore the database, because it’s too hard.
— .json (@jasonhand) November 10, 2016
Alex Yates is a Database Lifecycle Management (DLM – aka database DevOps) consultant with DLM Consultants. DLM Consultants mission is that their clients’ databases will no longer be their bottlenecks. They offer online and on-site DLM training and consultancy.
Before working for DLM Consultants Alex worked for Redgate software.