DevOps has been the darling of the new world and the shrinking/changing world of the server operations team. So, does the Oracle Autonomous database (both ADWC and ATP) change the paradigm even further and move us into a world of NoOps, where operations teams, specifically the DBA in this case, have no role to play?
I recently blogged about a use case for AWS Lambda and the whole Serverless model, and it’s easy to draw parallels between this and Autonomous Databases. In the Autonomous world the overwhelming majority of “core” DBA functions are automated and abstracted away by the service provider (Oracle in this case), in the AWS Lamba Function as a Service (FaaS) world the same is true of the system administrator who would traditionally have looked after the operating system and application server environment. So has the Ops role completely disappeared when we look at serverless/FaaS?
Firstly, let’s acknowledge some of this is future gazing as we’re on the start of this journey, so reviewing this in 12,24 or 36 months as the story starts to be written and with the benefit of hindsight is going to cast a harsh light I suspect! Disclaimers done/back covered!
My suggestion for the serverless world is that; yes the existing job definition has largely disappeared, with the skills required evolving into something very different. Instead of caring about the inputs to a system, it’s now much more about the outputs such as:
More crucially, I believe, will be the skills around debugging communications between decoupled systems and advising on architectural patterns. With a prevalence of platform services often looking, similar questions will need to be resolved such as is the choice AWS Kinesis or SQS? Is it Oracle SOA Cloud Service or Integration Cloud? When would Kafka be the better choice? Knowing the use cases, pros and cons, and cost/benefit of different platform services under different load conditions to make sure the business makes the best decisions. This also means the one size fits all model is going to disappear, the right tool for the right job replacing it.
So where does this leave the venerable DBA in a world of Autonomous Databases? In my mind, and similar to the DevOps/Serverless world, they’re going to become embedded within the project teams, being part of the delivery as opposed to being a discrete team (and let’s be honest those of us with DBA backgrounds could do with socialising a bit more at times!). Bringing the skills around data ingestion, manipulation, capacity planning, debugging and troubleshooting by understanding what’s going off behind the scenes directly into the team will make that team more productive and increasing the perceived worth of the DBA to people who traditionally maybe didn’t appreciate just what it took.
We’ve been talking a lot about “business outcomes” and I’d suggest that’s where we are going. The DBA will evolve to be an engineer (DBE anyone?) or maybe an architect (back to DBA …hoorah!), but we will have to change and adapt. So if you want my advice (if you don’t stop reading now), dust off those programming skills (if you’re part of a project team having some understanding of programming is going to be key), ingestion mechanisms, understand integration points and protocols, and start to care about the outcomes by looking at how the business operates its development and application teams.