Welcome!

@DevOpsSummit Authors: Zakia Bouachraoui, Carmen Gonzalez, Yeshim Deniz, Elizabeth White, Courtney Abud

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.

The Message: STOP USING THE TERM 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
Cloud-Native thinking and Serverless Computing are now the norm in financial services, manufacturing, telco, healthcare, transportation, energy, media, entertainment, retail and other consumer industries, as well as the public sector. The widespread success of cloud computing is driving the DevOps revolution in enterprise IT. Now as never before, development teams must communicate and collaborate in a dynamic, 24/7/365 environment. There is no time to wait for long development cycles that produce software that is obsolete at launch. DevOps may be disruptive, but it is essential. DevOpsSUMMIT at CloudEXPO expands the DevOps community, enable a wide sharing of knowledge, and educate delegates and technology providers alike.
Cloud-Native thinking and Serverless Computing are now the norm in financial services, manufacturing, telco, healthcare, transportation, energy, media, entertainment, retail and other consumer industries, as well as the public sector. The widespread success of cloud computing is driving the DevOps revolution in enterprise IT. Now as never before, development teams must communicate and collaborate in a dynamic, 24/7/365 environment. There is no time to wait for long development cycles that produce software that is obsolete at launch. DevOps may be disruptive, but it is essential. DevOpsSUMMIT at CloudEXPO expands the DevOps community, enable a wide sharing of knowledge, and educate delegates and technology providers alike.
The dream is universal: heuristic driven, global business operations without interruption so that nobody has to wake up at 4am to solve a problem. Building upon Nutanix Acropolis software defined storage, virtualization, and networking platform, Mark will demonstrate business lifecycle automation with freedom of choice and consumption models. Hybrid cloud applications and operations are controllable by the Nutanix Prism control plane with Calm automation, which can weave together the following: database as a service with Era, micro segmentation with Flow, event driven lifecycle operations with Epoch monitoring, and both financial and cloud governance with Beam. Combined together, the Nutanix Enterprise Cloud OS democratizes and accelerates every aspect of your business with simplicity, security, and scalability.
Is your enterprise growing the right skills to fight the digital transformation (DX) battles? With 69% of enterprises describing the DX skill drought as being soft skills, rather than technology skills, are you ready to survive against disrupters? The next wave of business disruption is already crashing on your enterprise as AI, Blockchain and IoT change the nature and location of business. Now is the time to prepare. Drawing on experiences with large and midsize enterprises, Marco Coulter tabulates the skills needed to survive DX while innovating at scale. He will start with a focus on the ‘lingua franca' or common language between business and technology needed for today's digitally savvy or agile enterprise.
Where many organizations get into trouble, however, is that they try to have a broad and deep knowledge in each of these areas. This is a huge blow to an organization's productivity. By automating or outsourcing some of these pieces, such as databases, infrastructure, and networks, your team can instead focus on development, testing, and deployment. Further, organizations that focus their attention on these areas can eventually move to a test-driven development structure that condenses several long phases into a faster, more efficient process. This methodology has a name, of course: Continuous delivery. As Jones pointed out at CloudEXPO, continuous delivery allows developers to trim the fat off tasks and gives them more time to focus on the individual parts of the process. But remember-implementing this methodology requires organizations to offload management of databases, infrastruct...