Bridging the Gap from an On-Premise DBA to Embrace Cloud
Experience counts for a lot. It gives you the breadth of knowledge. An encyclopedia of problems, scenarios and solutions which can be called upon in an instant. It is invaluable. It’s yours. You earned it.
Experience can also make you cynical. Cynicism is like salt; it is healthy in the right amount. Too much is not good. You’ve seen it all before, the next best thing. This is why youth and experience are the perfect partners, a cliché but one that exists for a reason. Fresh ideas, with the knowledge to make them a reality.
Here comes the cloud, the spawn of virtualisation. Your beard is now trendy and your vendor is steering you to that next best thing. Your experience counts for nothing. You are back at square one… No. The Cloud needs you and more to the point, you want to be part of the ‘next best thing’.
Beneath the Blue-sky Thinking
Cloud was once the object on the network diagram for the WAN. The switches, routers, and connectors making up the Wide Area Network had no relevance to the diagram. Your sites were connected, that is all that mattered.
Cloud in AWS or Azure is no different. Inside are servers, SANs and devices in lines of racks. There are air conditioning units, UPS and technicians who do not see the light of day. Instead of buying bandwidth for your WAN, you are buying compute and storage which is delivered to an agreed service level of performance and availability.
Step Costs
Now the why? An IT infrastructure needs to scale to meet the needs of the business and ultimately the customer. When the existing infrastructure cannot meet demand, it needs to be replaced or expanded. When the SAN has no additional shelf capacity, for example, a new SAN is required; one for Production and one for Disaster Recovery. It will be a step cost. Similarly, if a business takes on a new customer it would be presumed that this will be profitable. Indeed it probably will but if a new SAN is required to store the additional data for the new customer, it will negatively impact cash flow. We’re making money, but where’s the cash going?
The ability to scale with even unit costs is one of the key benefits of the cloud. This can be provided due to the vendor's ability to achieve large economies of scale unavailable to all but the largest organisations.
Administer the Administration
Cloud is hosted somewhere else but with happy accountants to boot. Step up the on-premise DBA: the laws of physics have not changed, but where we focus our attention has. Cloud offers a framework in which servers or services can be administered. Templates within the framework enable standardisation. Standardisation enables predictable behaviour, in particular with scripting and maintaining infrastructure with code, we can build and repeat. Centralised management was a DBAs elysium, but with heterogeneous operating system versions, patch levels, security and RPC configuration to name a few, such a goal has remained a goal due to the level of investment required to achieve it.
No longer do siloed teams maintain the infrastructure. This is all available to the DevOps DBA. Your job now is to administer the RunBooks which administer the databases. This means scripting languages such as Powershell and Python or tooling such as Terraform using HCL or JSON, are of equal importance as TSQL for the DevOps DBA as you will need to manage non-database objects, as well as cross-platform.
More than a Technology Change
An On-Premise DBA will be no stranger to an IDE. Visual Studio, Azure DevOps and AWS Cloud 9 are tools that compile code, store code and integrate with the infrastructure. They also contain collaboration features such as Kanban boards and task planning. This is where DevOps becomes a methodology or practice. DevOps requires openness and collaboration, which depending on how you approached the on-premise role will require a shift in mindset. That openness in mindset and with tooling enables an untied approach to deployment and maintaining the environment without losing the stability.
Time to think outside the Box
It may be soon that collaboration is a necessity, as the DevOps DBA needs to know the world outside their database server. How do I communicate with my instance? How does my instance communicate?
Your instance will sit inside a subnet, inside a virtual network. These will need routing and access lists. There are no changes here except you the DevOps DBA, will be deploying them and their configuration will be part of your designs.
Cut the rubbish - not the governance
DevOps is not deployed without testing and change control. A DevOps process is a code-based process. A DevOps process can run a unit test, it can raise a change request, it can wait for approvals, it can be documented, it can update your CMDB and the goal is that it should. A mature DevOps environment will give you a greater level of visibility of what has changed and how it changed. An IT environment with consistent and dependable levels of IT governance and less paperwork, administration, management, and red tape. Yes please…!
Code is agile, databases are ridged
It’s a fact that data is physical and that software is logical but continuous delivery is possible for databases, including for ACID-based systems.
What is the benefit to CD? Typically, we are referring to smaller, incremental changes which are unit tested through test-driven development. This enables not only faster delivery but also in theory safer developments via smaller changes. An on-premise DBA again would be familiar with this concept but without Agile jargon. If a DBA was required to change a large volume of data in a table, would you update thousands of rows or would you build a new table and then rename it. In this example, not only do you have a faster option but a solid rollback plan too. Extend this thinking to all aspects of database administration and into all future development too. Expect a higher frequency of a change with a smaller payload.
TDD requires a big investment in time if done retrospectively but the on-Premise DBA will pride themselves in their in-depth knowledge of system tables and views. Use this knowledge to validate deployment success. Also, think about logic tests in your development that can be run as part of operational monitoring to detect regression issues.
A DevOps DBA needs to engineer solutions that deliver faster and with greater confidence.
Visible value add
Continuous improvement has always been part of the on-premise DBA remit, through the ongoing reporting and review of high CPU queries for example, which would lead to refactoring. In the on-premise world this helped increase capacity and improve performance but now it also can have the effect of reducing operating costs. Compute capacity is flexible in the cloud and in some cases transactions and IOPs are billable facets. This is an opportunity for good on-premise DBAs to shine by reducing operational costs in a direct and highly visible way.
Storage is expensive… and it still is. The problem with cloud and as above the key benefit of the cloud, is the visibility of operating costs. No longer are your backups stored on a lump of disk and exported off-site in batches of tape, once buried in a black hole of infrastructure financing. An application database with largely static data which you’ve been backing up and storing for 7 years could be costing you tens of thousands of pounds. It always had, but now there is nowhere to hide. Every database will have a retention policy and a cost for retention. Understand the data life cycle, understand the regulatory and legal requirements.
In summary, there is a lot to offer with the cloud in case you haven’t heard and depending on what type of on-premise DBA you are, the gap to bridge may not be a long as you think.
Enjoy the new control you have over the environment your database is hosted on. Pick up a cross-platform scripting language or tool and start using it. You may feel liberated being able to build and rebuild your test environment at a timescale of your choosing. You now have more control and more responsibility.
Teams now share knowledge, not service requests. An on-premise DBA shouldn’t be out of place here, a DBA has always been an intermediary between development and infrastructure, an advisor of standards and best-practice, guiding infrastructure and development teams on how to support and interface with data platforms.
Be an engineer and make repeatable processes, develop a script library that is dynamic and available across your organisation. Monitor costs and drive continuous improvement bringing direct success to your organisation.
A small gap, with a lot to embrace.
