Good morning, everyone! Day two and a rainy day in the nation's capital. Might make for some interesting maneuvering as I get to go home tonight but there are still plenty of things to talk about for the remainder of the day.
The starting keynote for today is Jeffery Payne talking about the proliferation of acronyms and initialisms related to the outgrowth of the portmanteau of Development and Operations. We all know that today as DevOps. Of course, like any catchy/sticky term, we can't leave well enough alone and we add other aspects to each. With that, we now have (as the title shows) DevSecOps, DevTestOps, SecTestOps, and if we want to get a little more creative (for some definition of the term) I guess we can have DevPerfOps and even BizDevTestSecPerfOps! So what is the point of all of this? If we end up with something like BizDevTestSecPerfOps... how is that really in any meaningful way different from general everyday software development?
Realistically speaking, the whole point of DevOps as it was originally introduced was the idea that by combining the disciplines of Development and Operations, we would be able to more quickly develop and deploy our solutions. By having our Development teams and our Operations teams working in tandem, we'd be able to deploy more frequently, make smaller changes more often, and be able to address smaller changes and test them more frequently rather than try to gather up a bunch of features and drop them all at once. The net goal is that we are able to create a better quality product and deliver value to our customers more frequently and effectively. That's the promise, in any event. How well that is done is going to vary from organization to organization. Additionally, the DevOps methodology is really a balance of accelerating change while providing operational stability. still, even with this rapid change and stable deployment, there are a lot of things that could fall by the wayside. Such as where is the testing performed? Who is doing it? What is the quality of that testing? What is the endpoint of that testing, as in does it actually deliver the quality expected/desired?
Over time, as these principles have been applied and examined, there are a variety of items that we notice are not entirely addressed by DevOps alone. How do we focus on security? How do we focus on general testing? What do we do about performance? What do we do about usability? Over time, we get feedback for the changes we make and deploy. The bigger question is "what do we do with that feedback?" Do we learn from the feedback we receive, do we integrate that feedback into the process of Development and Delivery? How do these processes affect Lead Time, Deployment Frequency, Mean Time to Restore (if needed), and what is our Change/Fail Percentage? The key point is, what are we gaining in benefits when it comes to speeding up this feature delivery?
Additionally, some environments and markets get better benefits considering the risks of implementing these processes. Updating Netflix frequently, even if it may have bugs or areas of annoyance? The aggravation level is low, or not really meaningful in the broader sense of things. By contrast, if we have issues with speed and delivery for a product that monitors a person's pacemaker, bugs or missed features are not just undesired, they can be dangerous and life-threatening. Thus, DevOps and its ilk will not be beneficial in all areas.
This proliferation is going to continue and over time the differences between software development ten to fifteen years ago and today are very different for most teams. Getting the systems to work the way we want to will always be a challenge and the discipline to manage development and deployment will always be an area of interest. There will certainly be changes and a desire to add more coverage areas and more "ilities" to the list. Ultimately we will have to pick and choose which areas we are able to do well and how quickly. As Jeffrey points out there is a variety of augmentations that can be included but there's nothing really special about any of these. We have to pay attention to what we are doing and how well we are doing it, be early with our development and testing ideas, work with them in a focused fashion , and once they are out monitor for any issues and be ready to react and update to address the feedback we receive. With that, cooking metaphors fit pretty well and our goal is to make our collective soups in a way that we don't burn it or create something that is dreadful to consume. Recipes require a balance and so does the variety of DevAlphapetSoupOps. Understanding the recipe and how to cook it will spell the difference between a great soup and an inedible one.
No comments:
Post a Comment