What's Hindering Database Teams from Embracing DevOps?
by John Pocknell, on Oct 24, 2019, 1:00:00 PM
The global app economy is set to be worth $6.3 trillion by 2021, with the user base rising to nearly every person on the planet. As a result, organisations are having to rethink the way they build products or services to meet the always-on culture today.
The DevOps methodology has emerged over the past few years to address this phenomenon, accelerating the way companies build, test and deploy applications. Now as we head into 2020, it’s the buzzword on every CEO’s lips and the priority of most development and operations teams as the pressure to release applications faster has never been greater.
The reality is that a DevOps strategy is less about the tools and much more about the company’s culture. In practice, DevOps establishes a culture and environment to build, test and release software in a rapid, frequent and reliable fashion by embracing agile methodologies across the IT teams. It doesn’t matter whether an organisation is operating entirely in the cloud, taking a hybrid approach or strictly on-premise, the core elements of DevOps don’t change, only the speed of delivery.
Cloud technology accelerates the speed of DevOps as steps like automation are easier through cloud-based APIs, database access is faster and scalability is achievable on-demand. However, organisations run into problems when they try to do too much at once, ignore core elements like the database, and don’t have the expertise in place to drive the transformation forward.
Setting realistic goals and objectives
There are a number of factors that can stifle even the best DevOps intentions. The first is getting everyone across the tech team – developers, operations, security teams, database administrators – to buy into the DevOps approach, especially when organisational silos have been heavily ingrained in some organisations for years. Take Barclays Bank for example. They tried to transform a 120-year-old business using the DevOps methodology, applying it to 1000 applications across the personal and corporate banking divisions and sales. Unfortunately, this first attempt failed thanks to different internal views and agendas across different lines of business, a highly-regulated environment, a strict central IT system and limited knowledge of DevOps strategies and supporting technology. Instead, they applied that learning to each line of business, rather than the entire company and were effectively able to scale-up to the entire business with over 10,000 employees.
The danger of having a centralised DevOps team is that you create a huge silo which project teams can’t or won’t access.
As we see with many other organisations like Barclays, DevOps initiatives must be driven from the very top. Without sponsorship from executive leadership, any ambitions of being truly agile cannot be realised. This drive needs to filter its way down the organisational structure with leadership training playing a key role, otherwise the necessary cultural shift won’t happen.
Centres of Excellence
The second factor that often holds DevOps back from success is overlooking their database change management processes. If application updates require changes to the database, the DevOps process often breaks down, because databases are historically developed and managed differently due to their complexity, development process and sensitive nature. Additionally, database development frequently lacks code testing and reviews, source code controls, and the ability to integrate with existing build automation processes, which are critical to preventing errors impacting production systems.
One approach that I’ve seen work well is having a dedicated cross-functional team as part of a “Centre of Excellence” (or working group) whose sole job is to examine various technologies and vendors with the goal of automating existing manual, waterfall processes.
One US-based financial services company I worked with recently had implemented DevOps practices across most of their business, but the database operations and development teams were not. The consequence of this was that database changes were only being released every 8 weeks when the business demanded every 2 weeks.
As a result of their CoC helping the database teams to embrace the new culture by reorganising them into cross-functional teams (or tribes) and by leveraging automated processes and the right tools, they were able to automate many database development and deployment tasks and integrate them into their existing application change management processes and achieve their goal of 2 week sprints.
Cloud-based tools can also help break down the common barriers associated with deploying database changes and automate those adjustments within existing DevOps continuous integration and continuous delivery processes. But it also requires database administrators to have a seat at the DevOps table, to avoid unnecessary bottlenecks and ensure the best possible solutions are being put forward.
Putting it into Practice
As business leaders today are building their DevOps strategies for 2020, there are five factors they should consider to ensure the business remains agile and ensures success in the digital era.
- Skill-up: It’s critical to make sure that anyone involved in implementing DevOps, especially in the cloud, are properly trained in both technologies and are able to pass their knowledge onto others in the organisation. DevOps represents a cultural change and people are its key so it’s essential that there is a shared understanding of what is involved so that expectations of what can be delivered are realistic.
- Avoid vendor lock-in: Don’t lock the business into one cloud or database vendor. To ensure success with DevOps, organisations need to be as open and flexible as possible in their choice of tools as changes to the platforms may be needed in the future. Consider the use of containers for application deployment to provide additional flexibility.
- Integrate database development: Weave database development into the fabric of any DevOps plans in order that it integrates with CI/CD automated processes, otherwise this will become a significant bottleneck that could delay application delivery.
- Prioritise performance testing: This infrequently happens during on-premise deployments. With cloud based services, where it’s subscription-based, performance testing becomes more important so you don’t find yourself unnecessarily using more cloud resources than you need.
- Don’t over-commit: Try DevOps practices and supporting technology on a relatively low-risk or pilot project first, learn from them and then roll-out additional projects with the enhanced knowledge of what worked or didn’t previously.
The enthusiasm for DevOps will only continue in 2020. The demands of today’s digital era mean organisations cannot afford to have delayed releases, security breaches, or application downtime, as these effect everything from customer experience to company profits. Adopting cloud technology as part of a DevOps strategy puts companies in a better position to ensure those issues do not arise, but can quickly respond in real-time if they do.
Now more than ever, business leaders need to understand the importance of agile work environments, prioritise core elements like the database and take a realistic project-based approach to application development. Only then will businesses and their teams be able to realise their full potential.
For more information on how Quest Software can help integrate your database operations into a CI/CD pipeline, please visit https://www.quest.com/solutions/devops/.
Database Solutions Evangelist at Quest Software
John Pocknell is a database solutions evangelist at Quest Software and part of the product marketing team. Based at the European headquarters in the U.K., John is responsible for developing and evangelising solutions-based stories and messaging which relate to major IT initiatives for our extensive portfolio of database products, worldwide. He has been with Quest Software since 2000, working in the database design, development and deployment product areas and spent over 10 years as product manager for the Toad product line. John has been successfully evangelising Toad and other database solutions at various conferences and user groups around the world for the last 19 years as well as writing blogs and technical papers both internally and for the media.
John has worked in IT for more than 30 years, most of that time in Oracle application design and development. He is a qualified aeronautical engineer with more than 10 years of experience in provisioning IT consultancy services and implementing quality assurance systems to ISO 9001.