DevOps promised faster development and easier maintenance. But does it always deliver?
The idea of technical debt is well understood, and not just limited to developers—there are lots of examples of cutting corners today and creating problems down the road. These problems are usually understood in terms of fixing bugs that arise out of workarounds or refactoring code that might work fine when implemented but is not sustainable long term. But there are other ways that this debt can appear.
DevOps means adopting a new culture, designed to speed up the development and delivery of higher quality software. This change in culture needs to be supported by the right tools, software that tracks progress, creates plans, allows collaboration at a distance, automated testing, and more. There is a tendency for teams to mix software with their own scripts and applications, and for the tech stack to become a mess of what’s needed at a particular time, rather than dedicated DevOps tools. As such, things can get way more complicated than they need to, and will tend to stay that way rather than spending precious time creating a new stack.
Onboarding woes
The average DevOps team uses somewhere between ten and fifteen tools to manage their team and applications—covering the coding of applications, infrastructure management, system administration and more. That means there are up to fifteen different onboarding procedures for every new team member. That means time spent setting up credentials and ensuring access, training time if needed, and of course all the time it takes to work with all of these applications.
If it is not possible to integrate these applications, or if the time necessary to integrate them has not been taken, then users will need to manually update each application as necessary—for example, updating their progress on a project management app when a pull request is completed and closed, and then adding the time spent to a tracking application. Or when upgrading languages or frameworks, it is tricky to branch, test build and deploy new versions in a consistent way across projects. All of this adds time, not just the time spent completing the action, but also time lost due to the productivity hit of switching between different applications. Plus there’s always a chance that one of these might be missed, leading to further complications.
Each tool also has its own maintenance requirements, with updates often necessary to patch security updates but bringing with it the risk of bugs and incompatibilities in the code. While it might only be a small amount of time for each update, this all adds up. And it was, after all, dealing with inefficiencies that led businesses to adopt DevOps in the first place. The use of manual processes rather than automation can make this even worse.
Data protection and compliance
These aren’t the only problems with an out-of-control technology stack. Development teams need to ensure that the applications which their team is responsible for are secure against cyberattack, but they also need to ensure that data is fully protected and can be easily traced, and that all legislation and regulations are being adhered to.
The seriousness of this point was underlined earlier this year when Meta was fined €1.2bn for mishandling data. This was, of course, not an error, and Meta maintains it acted appropriately when transferring data outside Europe. But it shows that regulators take this very seriously, and are happy to pass down huge fines if businesses are treating personal data improperly.
For those managing applications on a global scale, that’s no easy task, especially when many people are collaborating. Without the right controls in place it can be very easy to transfer data to places where you really don’t want it, breaking regulations without even noticing. Data governance is everyone’s responsibility, but it becomes extremely difficult to control and understand data flows when the DevOps team is collaborating across the globe.
Much is made of the need for a cultural change to make DevOps a success, and that’s absolutely true. But the technology that supports it needs to be evaluated regularly to make sure it is fit for purpose and not adding unnecessary burden to a team. While DevOps is supposed to enable agile development, too many applications can be the equivalent of fitting the team with lead shoes.
About the Author
Guillaume Moigneu is VP of Product at Platform.sh. The PaaS that removes the complexities of cloud infrastructure management and optimizes development-to-production workflows, Platform.sh reduces the time it takes to build and deploy applications. Delivering efficiency, reliability, and security, Platform.sh gives development teams both control and peace of mind.
Featured image: ©maciek905
