Posted on

How Monitoring and AIOps Delivers the Ultimate DevOps Platform

When it comes to delivering software through a DevOps model, the primacy of the platform is increasingly evident. DevOps platforms are multi-tenant, self-service oriented, developer-centric, and are an essential component of a multi-cloud strategy. They provide guide rails and standardized tools and technologies for developers to build, test, and iterate with ease. A core component that must not be neglected when operating a DevOps model, however, is resilience.  

DevOps breaks down monolithic products into smaller value streams that can be delivered as independent cloud-based services. Once teams are set up to deliver under this model, it will be formalized through service level agreements (SLAs). To deliver against these, robust monitoring and alerting practices must be put in place. As with any DevOps practice, automation is the ultimate goal — and when it comes to monitoring and alerting, an AIOps platform is the gold standard. 

Posted on

Security’s Shift Right

Software development has gotten tricky. If you have been in the DevOps game in the past few years, then you have noticed a drumbeat of "shift left" echoing across your brainpan. You can't escape it — it's at conferences, in blogs, and on numerous podcasts. We know how to write tests before writing code — boom, we shifted left! We added acceptance testing in our CI system — notch one up for another shift-left win. 

Yet, with all this shifting left, there is a whisper in the wind (it may be hard to hear), but it is not a new sound. It is a more of a nagging reminder of a truth we knew long ago — it's the faint reverberation call to shift right. 

Posted on

Shift Left, Shift Right — What Are We Shifting, and Why?

As more teams embrace the challenges of continuous delivery, we hear lots of people talking about "shift left" and "shift right" in a testing context. What does that mean, exactly, and why does everyone want to do it?

When Software Development Was Linear

I joined my first "waterfall" process project back in the mid-1980s, as a developer. It was a linear progression, and in my head, I saw it unfurl from left to right. It seemed reasonable (to my naive eyes) to start with a thorough analysis of the system to be built, finding out what the customers wanted. This "phase" produced an analysis document which triggered the "requirements phase," during which analysts and product managers created a document detailing every bit of functionality to be built. And on it went, handoffs from one phase, and often one team, to the next, with thick Word documents changing hands, until the developers finally "froze" the code so that no more changes could be done. Finally, QA could start the testing phase, usually with very little time left until the release deadline!