To paraphrase Charles Dickens, “it was the best of ideas, it was the worst of ideas.” What am I referring to? DevOps and how it’s come to be interpreted. The best idea of DevOps is infrastructure as code, known as IaC. Instead of manually building application environments, a lengthy and error-prone process, IaC defines the […]
The post DevOps and Shifting Left the Right Way: 3 Tips appeared first on eWEEK.
To paraphrase Charles Dickens, “it was the best of ideas, it was the worst of ideas.” What am I referring to? DevOps and how it’s come to be interpreted.
The best idea of DevOps is infrastructure as code, known as IaC. Instead of manually building application environments, a lengthy and error-prone process, IaC defines the “how” of building the environment in a template, and then automatically builds that environment using the template definition.
This occurs at computer speed rather than human speed, and, just as important, is done consistently every time, vastly improving application quality. Done right, DevOps can vastly increase application velocity.
This approach to application development and deployment became known as “shift left,” because it moves post-development tasks earlier in the application lifecycle.
Also see: DevOps, Low-Code and RPA: Pros and Cons
However, while DevOps’s infrastructure as code was its best idea, it also – as it has been commonly implemented – one of the worst.
All too often, developers were told that they should take responsibility for creating the IaC templates. There’s some logic to this; after all, an application’s developer should know its infrastructure requirements best, right?
On the other hand, this also makes developers responsible for understanding production networking requirements, large scale storage configurations, and resiliency resource management. Due to this onerous demand, it’s fair to say that, depending on the complexity of an application’s production environment, DevOps is not a panacea.
Nevertheless, inspired by the shift left mantra, many IT organizations decided it makes sense to move other tasks earlier in the application lifecycle. So developers became responsible for testing. And security. And patch management.
Unfortunately, as commonly pursued, these tasks were not treated “as code.” That is, the groups formerly responsible for them passed on responsibility to developers along with the manual checklists typically used to perform the group’s tasks. So developers took on lots of manual effort in areas they had no particular expertise.
And guess what? A developer doing something manually doesn’t get the task done any faster, especially if executed with low subject matter expertise. So the potential speed of a DevOps approach often remains much lower than desired.
Also see: Why Cloud Means Cloud Native
So what is the path forward for a shift left, “as code” approach? Are applications destined to remain mired in manual processes conducted by overwhelmed developers?
In a word, no. But organizations need to shift left the right way. Here are three tips on how to do that.
If it makes sense to do infrastructure as code, it makes sense to do testing as code, security as code, and patch management as code. In other words, apply the logic of DevOps to all the steps in the path to production.
Naturally, this means applying development skills to these tasks, which requires, well, developers. Expect the profile of subject matter specialists (e.g., a QA staff member) to change to incorporate programming experience. This also means managing each task automation as its own application, with its own lifecycle management.
The technology organizations with the fastest path to production treat the entire process as an integrated product to be automated across its various sub-steps. This means automated handoffs between intermediate steps and removing manual approvals. I’m looking at you, Change Control Boards.
In the real world, most manual approval steps are formal rituals that tick review boxes automatically. If the handoff from one step to another can be reduced to an automatic nod, it can be reduced to an automated handoff as well, with well-defined exception handling.
This also means that the path to production requires management of the entirety as a product itself, with architecture review to ensure all the automated subsystems play well with one another.
If this sounds like work and investment, you’re right. Without this, however, the path to production will remain slow, with speed at both ends (via Dev and Ops) bookending the same old slow manual steps in the middle.
While automating all the tasks – and automating the overall process – are good steps, it’s still a challenge to ensure good security if vulnerable or obsolete code forms the foundation of an application. As the old saying goes, garbage in, garbage out.
Living with these kinds of security exposures is made even worse when a vulnerability becomes known or someone attacks it. What ensues is a mad scramble to update code bases and roll the updates into production.
This problem is endemic when developers start with a blank slate, downloading libraries and components directly from the Internet. It’s shocking how many container-based applications are built with images downloaded from DockerHub, despite the fact that it’s well-known that many of the most popular ones contain outdated and/or vulnerable code.
A much better approach is to provide developers with prepared code bases that are known to be up-to-date and assessed to be free of vulnerabilities. The mechanisms for this are known as templates, frameworks, or accelerators. Essentially, the developer downloads the template into a preferred IDE and begins with a safe foundation of code into which the functionality of the application is incorporated.
Once the application update is complete, it enters the automated process described above. Application artifacts are created and moved through the different stages in the lifecycle until finally deployed.
This code hygiene approach can be extended into the rest of the lifecycle, by having a process sitting outside of a specific application pipeline to monitor announced vulnerabilities. If a vulnerability is announced and a patch made available, an application build and deploy process kicks off which automatically updates the relevant artifact and put it into production.
This avoids the manual tracking of what libraries and components each application contains. It also avoids the crisis management associated with trying to ensure every relevant application is updated, which inevitably misses some and results in vulnerable applications never getting fixed.
This emerging industry term for this “shift further left” is the secure software supply chain, and is an approach that will become more common going forward, especially as more and more business processes shift to digital mechanisms. I’ve only touched on it here, and hope to delve further into the topic in a future column.
The truth is, DevOps is both a good idea and a bad idea, depending on how applied. Sprinkled onto a lethargic application lifecycle, it solves little. Applied as an automation concept as part of an application assembly line, it’s a powerful tool to enable digital transformation.
Also see: Digital Transformation Guide: Definition, Types & Strategy
The post DevOps and Shifting Left the Right Way: 3 Tips appeared first on eWEEK.
