@DevOpsSummit Authors: Yeshim Deniz, Elizabeth White, Liz McMillan, Zakia Bouachraoui, Pat Romanski

Related Topics: @DevOpsSummit, Containers Expo Blog, @CloudExpo

@DevOpsSummit: Blog Feed Post

It Is Past Time to Deconstruct #DevOps By @DMacVittie | @DevOpsSummit #Containers #Microservices

The term no longer has any meaning, and we need to consider the implications of that fact

It is interesting to me how quickly the hype cycle of a good thing can turn it into a monster that will inevitably eat itself, leaving a much smaller – and much more useful – concept or toolset behind. It has happened over and over in high tech, one need only say “XML” to understand what I mean. It is definitely a useful tool for some jobs, but the “XML Everywhere” craze was insane. People declaring such patently false ideas as “It will end the need for programmers.”

Thankfully for those of us using it, XML in the enterprise is largely a data-at-rest tool for small datasets (including serialization) and a diminishing communication tool at this point. That gets the confusion of XML everything somewhat out of the way, while we try to find answers to important questions in the areas where it is actually used.

This same process is unfolding in the hype cycle of DevOps. The term no longer has any meaning, and we need to consider the implications of that fact.

Note to vendors that have invested a ton of marketing dollars in the term DevOps: Sorry you’re upset by even the premise of this post, but in the long run, this concept would work out better for you also. Read on.

Let’s just do a limited-subset recap to explain what I mean. If I say “The problem here is the need for DevOps” to you, I could mean:

  • Continuous Integration
  • Continuous Delivery
  • Application Deployment Automation
  • Server/Provisioning Automation
  • Cloud Services Automation
  • Enhanced Build Tools (without an eye to CI)
  • Security Automation
  • Full Culture Change

Or more. Or any combination thereof.

Not only are these concepts supported by wildly differing technologies, many of these categories involve completely different groups within IT.

There are not very many people out there who fail to acknowledge the usefulness of at least some of these areas, but to lump them all together seems like a massive pile of mostly not relevant ideas. For example, in my day job I use Enhanced Build Tools, and the Engineering team uses CD – while the company is focused in the server provisioning (see: Stacki) and warehouse grade configuration (see: Boss) spaces. In my side job, I use CI, CD, and Automated Testing (see: D20PRO).

The easiest task to take, and the one that seems to be happening naturally, is to take the above pre-existing categories and talk about them, adding the completely new ones like Culture Change. This is an okay solution, but we still have way too much being dumped under the “DevOps” moniker.

Perhaps a more formal approach would be useful to enterprise IT staff who are just trying to solve their problems. It could take the same view as above, but get passed around instead of wandered to at leisure.

What started me thinking about this topic was looking at Xebia Labs’ Table of DevOps Tools. While I disagree with several portions of this chart (most notably the absence of Stacki in the provisioning category ;-)), it is a better attempt than I’ve seen anyone else make.

Things that occurred to me while looking this over:

  • I’ve used all of these categories at one time or another.
  • Some of them don’t rightly qualify as DevOps tools, IMO (Databases, for example), though I understand why they’re in there.
  • Some are accurate but poorly cast.
  • But it’s an excellent list of tools. Emphasis added to avoid the bolts of flame about to be directed at me by those who’ve invested their career in the “Culture Change” part of DevOps.

These terms are much more applicable to direct usage than the term DevOps. If you are blogging, reach your target market by saying what you are actually talking about instead of listing the primordial stew that the phrase “DevOps” has become.

The point is to get IT folks the information they need in a rapid manner. Go ahead and pick a tool category from Xebia Labs’ graphic, okay, got one? Now search on “DevOps” in your preferred search engine, and try to find an article relevant to it. We’ll wait the couple hours, go ahead, try it.

And that’s bad for everyone. Of course some small percentage of people will find what they’re looking for at the top of the search results, which people greatly depends on which part of DevOps is getting buzz this week. A few weeks ago it was CI/CD, when I just did the search now, it looks like all those people trying to define DevOps to be inclusive of 50 categories are at the top.

So stop trying to make it 50 categories. Call what you’re doing what it is. Use DevOps to refer only to culture change, which could then use the other categories. While some enterprises have a DevOps Team, increasingly you will see a subset of the Ops team using CD, or a subset of the Dev team using CD, or a mixed bag of the two using CD. So why not talk about CD and leave DevOps out of it, if that’s what you’re addressing?

I do this for StackIQ. We fit into the “DevOps” moniker, and sometimes I reference it to mention larger efforts. But StackIQ products are largely provisioning and application configuration, so that’s what I call it. Just as I wouldn’t call a cat “Mammal” unless I was trying to make a point larger than felines.

Some will be against this idea because they believe you have to do it all. I (and the available empirical evidence) respectfully disagree with this view, but calling it by different names doesn’t put a halt to execution. You can still do it all, we’re only talking about words here.

So let’s clean up the terminology, and help IT find the products/vendors/methodologies they need without having to paw through dozens they’re not interested in right now – or at all.

Read the original blog entry...

More Stories By Don MacVittie

Don MacVittie is founder of Ingrained Technology, A technical advocacy and software development consultancy. He has experience in application development, architecture, infrastructure, technical writing,DevOps, and IT management. MacVittie holds a B.S. in Computer Science from Northern Michigan University, and an M.S. in Computer Science from Nova Southeastern University.

@DevOpsSummit Stories
Hackers took three days to identify and exploit a known vulnerability in Equifax’s web applications. I will share new data that reveals why three days (at most) is the new normal for DevSecOps teams to move new business /security requirements from design into production. This session aims to enlighten DevOps teams, security and development professionals by sharing results from the 4th annual State of the Software Supply Chain Report -- a blend of public and proprietary data with expert research and analysis.Attendees can join this session to better understand how DevSecOps teams are applying lessons from W. Edwards Deming (circa 1982), Malcolm Goldrath (circa 1984) and Gene Kim (circa 2013) to improve their ability to respond to new business requirements and cyber risks.
Dynatrace is an application performance management software company with products for the information technology departments and digital business owners of medium and large businesses. Building the Future of Monitoring with Artificial Intelligence. Today we can collect lots and lots of performance data. We build beautiful dashboards and even have fancy query languages to access and transform the data. Still performance data is a secret language only a couple of people understand. The more business becomes digital the more stakeholders are interested in this data including how it relates to business. Some of these people have never used a monitoring tool before. They have a question on their mind like "How is my application doing" but no idea how to get a proper answer.
Enterprises are universally struggling to understand where the new tools and methodologies of DevOps fit into their organizations, and are universally making the same mistakes. These mistakes are not unavoidable, and in fact, avoiding them gifts an organization with sustained competitive advantage, just like it did for Japanese Manufacturing Post WWII.
DevOpsSUMMIT at CloudEXPO, to be held June 25-26, 2019 at the Santa Clara Convention Center in Santa Clara, CA – announces that its Call for Papers is open. Born out of proven success in agile development, cloud computing, and process automation, DevOps is a macro trend you cannot afford to miss. From showcase success stories from early adopters and web-scale businesses, DevOps is expanding to organizations of all sizes, including the world's largest enterprises – and delivering real results. Among the proven benefits, DevOps is correlated with 20% faster time-to-market, 22% improvement in quality, and 18% reduction in dev and ops costs, according to research firm Vanson-Bourne. It is changing the way IT works, how businesses interact with customers, and how organizations are buying, building, and delivering software.
This is going to be a live demo on a production ready CICD pipeline which automate the deployment of application onto AWS ECS and Fargate. The same pipeline will automate deployment into various environment such as Test, UAT, and Prod. The pipeline will go through various stages such as source, build, test, approval, UAT stage, Prod stage. The demo will utilize only AWS services including AWS CodeCommit, Codebuild, code pipeline, Elastic container service (ECS), ECR, and Fargate.