HashiCorp Field CTO Weekly: RIP DevOps? And what on Earth is the “super cloud?”

Volume 100

Dear reader,

Good morning. You're probably wondering what this newsletter is and why it's starting at Volume 100. The writers you'll see publishing this blog are largely the Field CTO team at HashiCorp, which I have the privilege to lead. We used to publish an internal newsletter, primarily for the sales org, and at Volume 100 we're now making it public. The first couple of newsletters won't be perfect because we'll be switching from our inside voices to our outside voices. It’ll get better. Probably.

How did it start, you ask? Great question. One day, our original VP of sales approached me via phone and the following conversation ensued:

VP: I need you to write a weekly newsletter.

Me: I can do that. What should I write about?

VP: Who cares.

With that newfound purpose and confidence, I started the newsletter you see before you today. Because of the flexibility of the assignment, I decided to try and distill what was going on in the industry and square that with what was going on at HashiCorp. That’s the goal, anyway. You’ll also spot an occasional reference to Doug, who is a real-life person at HashiCorp, and one of my favorite people here.

So what's new in the zoo? Where do we even start? This week began with a video clip of Bill Belichick smiling, which I can only describe as haunting. The U.S. Open continues into its second week relatively ho-hum. The Game of Thrones prequel House of the Dragon debuted which was, in a word, graphic. Mikhail Gorbachev passed away. And per usual, there's so much news surrounding the former U.S. president that I'm sure the week is going to end with him in the back of a white Ford Bronco headed southbound on the LA freeway. If life's got you down, you can always rely on Device Orchestra's version of Britney Spears’ Toxic to cheer you up. If you find yourself watching the clip of the washing machine playing My Heart Will Go On at 2 o'clock in the morning, don't say I didn't warn you.

With that, let's get into it.

---

Devs don’t want to do Ops

The word is out: DevOps is dead. I don't know if I fully believe that. That statement assumes every company moves at exactly the same rate and embraces change the same way, and uses the same definition of DevOps. It's a significant portion of my job to speak to different companies about their strategy and technology, and I can assure you that is not the case. Some companies are just starting on that journey. Some are on versions 3, 4, or 10. The way the industry articulated DevOps was that developers now needed to take on operations as well. For most, it was an abject failure. Some companies tried the band-aid of site reliability engineering, which was another term that had wildly varying responsibilities from company to company. For some it was another term for operations, for others it was the folks that wrote the automation for developers to interface with the underlying platform be it AWS, Azure, GCP, or others. The definition is less reliable than the title would insinuate.

The goal has always been to make developers as effective as possible at delivering new code to applications. The time to go from idea to production needs to be as small as possible. DevOps has been, for the last decade or so, the gold standard of how to do that. It's also common to hear DevOps described as continuous integration pipeline maintenance. For some shops, the pipeline is what drives the process of building/deploying/releasing applications and is seen as the destination instead of embedded technology. Fundamentally, the challenge of DevOps has been that developers have been told responsibilities are "shifting left." That means developers get to inherit problems that are out of scope for them. Security? Sure. Operations? Even better. Let’s call it DevSecOps, or DevSecFinOps. Maybe the concept of a developer who takes on operational, security, and financial responsibilities works at some companies. For most, it does not.

Most attempts at pushing more responsibilities on developers have failed either because it's nearly impossible to be an expert at all technologies, or because it was simply too expensive to hand the developer groups the keys to the AWS account and hope the bill didn't explode. My favorite quote from the article is by Nick Durkin, Field CTO at Harness:

People are beginning to realize we wouldn’t hire an electrician to do our plumbing.

RIP DevOps

So what should the epitaph of DevOps read?

Here lies the combination of developer and operations person?

Here lies pipeline engineering?

Here lies the development process model?

The irony of the discussion is that the way the industry has defined DevOps has been primarily around the responsibilities and skills of the person. Where the term DevOps is best served is to describe the process model of how developers get work done. If you can neatly define a line between dev and ops, where that interface is an API that has “Just Enough Abstraction™” to define templated work, that's where most teams will find success. And that's where the concept of the internal developer platform was born. According to HashiCorp’s State of the Cloud survey, 86% of respondents said they rely on cloud platform teams.

But why?

The platform owns the problem

Instead of throwing more on a developer's plate, the platform owns the problem, and thus reduces the cognitive load on the person just trying to do the simple thing of deploying code. Things such as infrastructure as code promised to make developers more effective, and it does. Kind of. You're only as effective with IaC as you are with the underlying platform. If you are a combination AWS solutions architect and developer with AWS credentials your world will be terrific, at least on the first day. For everyone else who just wants to get on with their day and plow through some business logic, it's not quite that easy. What they're looking for is something repeatable.

I've heard every term you can think of to describe this pattern: the paved path, the golden path, the yellow-brick road, the path through the CNCF technology nightmare-scape. I may have made up that last one, but I doubt this is the first time you're hearing the other terms. It simply means finding the repeatable patterns that are aligned with the application deployment lifecycle and assigning owners within the platform to streamline their workflow. The platform is your new interface to the world for a specific job to be done, which is why they're seeing a lot of traction.

Tools like Terraform are still highly popular with enterprise IT and that won't be going away anytime soon. Terraform has an enormous ecosystem that enables a different process model. It's still very common that Terraform is used by an operations team sitting behind a ticket queue. What frustrates developers is the cycle time of how long it takes for a human in operations to respond, regardless of how quickly the action taken will be. You can make Terraform somewhat easier to consume with modules, but even then it is not the most friendly interface for an auditor.

The answer to a developer platform is a tool like Waypoint, which is designed to solve developer problems similar to the way Vagrant does, as a frontend to the platform that hooks into all of the existing technologies of the data center, or cloud platform. It's pretty slick and worth taking a closer look at.

What CEOs really need from today’s CIOs

What's interesting is how much more relevant the CIO role is today compared to twenty years ago. In the early aughts, the role was mainly confined to IT as a cost center and financial boat anchor of a department. IT was mainly a service desk providing new laptops and the folks responsible for setting up Bob Marley (the printer that was always jammin'). Fast forward to today, and the CIO role commonly reports directly to the CEO, with 51% of U.S. CIOs reporting to the CEO according to Deloitte’s 2021 Trends in CIO reporting structure report. The CIO has a new charter of being responsible for the digital side of the business. With that new power comes a clear path to the chief executive role. As described by Martha Heller – the illustrious CIO recruiter – in her CIO.com column, here is a short list of what CEOs want from their CIOs to focus on (in no particular order):

• Taking their orgs from software and the business to software is the business

• Modern delivery

• The democratization of IT

• The cloud

• Usable data

• Transformational leadership

Given the previous section, I want to dive more deeply into what modern delivery means, and how it's different by relating to the cloud. Here's how it’s described by Wafaa Mamilli, chief information and digital officer of the global animal health business at Zoetis:

A platform model is more than architecture. It is a mindset that lets us zoom in to think vertically about how we deliver to the farmer, vet, and pet owner, and then zoom out to think horizontally about how to make the solutions reusable, scalable, and secure. Platforms are modular, intelligent, and run algorithms that allow us to change very quickly. If we didn't move to a platform approach, we would still be funding these huge programs.

Everyone is being pushed to think of products vs projects, and platforms vs piecemeal. A modern software delivery experience is at the heart of every successful business. To be successful, a CIO will have to navigate the people, process, and tools of their organization (in that order) while also owning the digital side of the business. No easy feat. Successful CIOs will need to be part data scientist, part technologist, and part business leader. Roll that in with organizational leadership and you’ve got yourself a handful. To be fair, nobody ever said the path to being a chief executive was easy.

How Dave McJannet thinks about the super cloud

I’ve heard the term “super cloud” more than once in the last few months from a customer. It’s admittedly a new one for me, and apparently, it was for some of the guests on the Cube during their recent roundtable which included HashiCorp’s CEO Dave McJannet. Definitions vary similar to the term DevOps, or just about anything else in tech. Here’s how Dave Vellante defined it in an article for Silicon Angle:

We used the term supercloud to describe an abstraction layer that resides above and across hyperscale infrastructure, connects on-premises workloads and eventually stretches to the edge. Our premise is that supercloud goes beyond running services in native mode on each individual cloud. Rather, supercloud hides the underlying primitives and application programming interfaces of the respective cloud vendors and creates a new connection layer across locations.

Typical of most technologists, the answer tends to be described as a balancing act between primitives and abstractions. There’s nothing Doug loves more than a leaky abstraction. Customers typically want it both ways: they want simplicity to apply to all cloud vendors so they can re-use all of the same patterns, and they also want you to expose all of the knobs for the underlying primitives. The real discussion is: what is the workflow provided on top of these platforms that we can provide consistently? And dear reader, that is the real problem to be solved. If you work backward from the user experience, it all comes back to what is the job to be done and how easy is it to get work done.

It seems as though the term “supercloud” is both the world’s most underconstrained and overconstrained term. Let’s figure out how to solve the user workflow problems first, and then worry about how leaky the abstractions should be. Raghu Raghuram, CEO of VMware, is on the right track with this line of thinking:

I use the word abstraction. And usually when people think of abstraction, they think it hides capabilities of the cloud providers. That’s not what we are trying to do. In fact, that’s the last thing we are trying to do. What we are trying to do is to provide a consistent developer experience regardless of where you want to build your application. So that you can use the cloud provider services if that’s what you want to use. But the DevSecOps tool chain, the runtime environment which turns out to be Kubernetes and how you control the Kubernetes environment, how do you manage and secure and connect all of these things? Those are the places where we are adding the value.

Ah, ok. You had me, and then you lost me. Where I disagree is with the point at which Kubernetes is the decided abstraction layer. Perhaps on a layer cake diagram it looks fine, but to anyone who’s written the hundreds of lines of YAML to be productive, it can be a chore to get applications moved onto it. Is that what we’re settling for? Can’t this be easier to use? Abstractions are good, but when too many primitives make them difficult to use they miss the point.

Instead of using the term supercloud, I would instead lean toward the cloud operating model. The challenge with treating all of your clouds as one massive entity is application data portability. It’s simply heinously expensive, by design, to move large amounts of data between providers. However, it’s much more common to settle on providers for things they do that are best-in-class for your workload, and make it easier to onboard developers using some simple patterns. What is a supercloud? It’s a way to get people productive and applications servicing users in a consistent enough manner across providers. I doubt I’ll be seeing the messaging in AWS’ materials any time soon.

And that’s the tea.

-brent