Welcome!

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

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
With more than 30 Kubernetes solutions in the marketplace, it's tempting to think Kubernetes and the vendor ecosystem has solved the problem of operationalizing containers at scale or of automatically managing the elasticity of the underlying infrastructure that these solutions need to be truly scalable. Far from it. There are at least six major pain points that companies experience when they try to deploy and run Kubernetes in their complex environments. In this presentation, the speaker will detail these pain points and explain how cloud can address them.
In an era of historic innovation fueled by unprecedented access to data and technology, the low cost and risk of entering new markets has leveled the playing field for business. Today, any ambitious innovator can easily introduce a new application or product that can reinvent business models and transform the client experience. In their Day 2 Keynote at 19th Cloud Expo, Mercer Rowe, IBM Vice President of Strategic Alliances, and Raejeanne Skillern, Intel Vice President of Data Center Group and GM, discussed how clients in this new era of innovation can apply data, technology, plus human ingenuity to springboard to advance new business value and opportunities.
Discussions of cloud computing have evolved in recent years from a focus on specific types of cloud, to a world of hybrid cloud, and to a world dominated by the APIs that make today's multi-cloud environments and hybrid clouds possible. In this Power Panel at 17th Cloud Expo, moderated by Conference Chair Roger Strukhoff, panelists addressed the importance of customers being able to use the specific technologies they need, through environments and ecosystems that expose their APIs to make true change and transformation possible.
The current age of digital transformation means that IT organizations must adapt their toolset to cover all digital experiences, beyond just the end users’. Today’s businesses can no longer focus solely on the digital interactions they manage with employees or customers; they must now contend with non-traditional factors. Whether it's the power of brand to make or break a company, the need to monitor across all locations 24/7, or the ability to proactively resolve issues, companies must adapt to the new world.
In his session at 20th Cloud Expo, Scott Davis, CTO of Embotics, discussed how automation can provide the dynamic management required to cost-effectively deliver microservices and container solutions at scale. He also discussed how flexible automation is the key to effectively bridging and seamlessly coordinating both IT and developer needs for component orchestration across disparate clouds – an increasingly important requirement at today’s multi-cloud enterprise.