How Self-Service Is Redefining Ops Engineering – InApps Technology 2022

Pivotal sponsored this post.

You don’t have to spend much time in Japan to notice it must be the world capital of self-service. The country’s ubiquitous vending machines, virtually a national institution, line the streets of cities large and small. It’s estimated there are 5.5 million of them in the country — one for every 23 people — and they offer everything from cold drinks to hot lunch.

What’s more, Japan’s tendency toward DIY purchasing has expanded in recent years. These days, there are entirely unmanned convenience stores, where every shelf is automated. Even restaurants are experimenting with self-service ordering.

For Westerners, this might sound strange — but it should not. Consider: How long ago was it that you first used an automated teller machine instead of engaging with a bank teller? And there are plenty more examples. We’ve gone from buying stamps in vending machines to iPhones. In certain U.S. markets, McDonald’s has even been following Europe’s lead by experimenting with having customers order their burgers with giant touchscreen panels. No more “Would you like fries with that?”

Given these trends, it should come as no surprise that in the high-tech world of enterprise IT, the desire for self-service is similarly growing. In fact, it’s fast becoming both a catalyst and a key driver for digital transformation.

Self-service? But … That’s Anarchy!

Consider the Bad Old Days of 20 years ago, when centralized IT ruled. When a line of business requested new infrastructure, it often took months before it was provisioned. Little wonder that the Waterfall model of app delivery reigned; everyone had plenty of time.

As the pace of software innovation accelerated, things needed to change. Enter DevOps. The idea was that breaking up centralized IT and embedding operations engineers within product development teams, developers could have their operations needs met more quickly and efficiently. And yet, while this model worked well for tech companies like Spotify — which helped pioneer DevOps — for many other companies, it wasn’t quite right. Particularly in large enterprises, DevOps can be hard to scale without ballooning costs.

The rise of “hyperscale” cloud providers, such as AWS, Azure and Google have offered a different model. These vendors offer an a la carte menu of IT services, ranging from compute and storage to backend software instances, any of which can be ordered with a few mouse clicks. Indeed, the “service” in “*aaS” might as well stand for “self-service.” And it’s this model of self-service that enterprise development teams are increasingly clamoring for.

And yet, truly laissez-faire self-service can often lead to chaos. The many perils of so-called rogue IT include cost overruns, duplicated efforts, incompatible platforms and standards, inconsistent security policies, poor integration across projects, zombie instances and more.

What Modern Self-Service Looks Like

So how do we deliver what today’s dev teams want? Not surprisingly, perhaps, Google gives us one piece of the puzzle. Google operates at near-incomprehensible scale and its operations must support truly countless teams and projects. Classic DevOps methods were never going to scale to meet its needs. It needed a new model and Google called the one it developed Site Reliability Engineering (SRE).

Broadly, SRE is related to DevOps in that reliability engineers apply the principles and practices of software engineering to operational tasks. Sometimes they might provision new infrastructures, such as storage, backup systems or load balancing. Their primary focus is on reliability — ensuring the systems and platforms to which developers will deploy their apps will be as available, scalable and efficient as possible.

Where SRE diverges from DevOps, however, is that SREs are not embedded in product teams. Rather, they serve multiple product teams at once. But unlike the old centralized model, they do this by delivering solutions and services that can be consumed by multiple products. Often, their job will be to find ways that existing solutions can be applied to new problems.

Another piece of this puzzle is the concept of “platform as product.” In this model, reliability engineers focus on delivering a platform upon which development teams can build and deploy their software. They do this by considering the platform their product, just as other teams produce products — only in this case, their “customers” are other internal development teams.

Critical to this concept is that the platform cannot be one-size-fits-all. Like other modern software, the platform must be delivered in a continuous, iterative fashion, constantly responding to the needs of the developer-customers.

The End Result

If you haven’t guessed by now, the central theme underlying the emergence of self-service for DevOps is automation. The goal is to automate as many manual processes as possible, for two primary reasons.

First, automation enables reliability engineers to operate effectively. Where in the DevOps model, embedded operations engineers often sat fallow as they waited for new releases to be delivered, automation allows reliability engineers to provide services to multiple product teams in an efficient and, equally important, standardized way.

Second, automated operations allows development teams to get what they want, when they want. Much like Japan’s unmanned convenience store, they can request the tools, infrastructure and services they need—most likely, through some type of service catalog—without creating backlog for operations engineers. And when these requests are handled in a standardized, automated way, the chaos of a cloud-based, self-service free for all is avoided.

If you think implementing these practices sounds like a significant overhaul of traditional IT operations, you’re not wrong. The demand for self-service of this kind is really just a ground-level manifestation of the demand for digital transformation, this time coming not from the CIO’s office, but from the product teams themselves.

By recognizing this demand and acting on it, self-service can become not just a result of digital transformation, but a driver of it. Increasingly, IT and DevOps organizations that are itching for modernization may find they have more allies than they think.

Meet and Collaborate

One place to learn more and explore these concepts will be at the Pivotal SpringOne Platform 2019 conference. Select talks include “More Devs, No Problems: Enabling Self-Service Access to Kubernetes” and “K8s at Scale in the Enterprise: Self-Service Through the View of Personas,” among many more. The conference takes place at the Austin Convention Center, Oct. 7–10.

Feature image: Neil McAllister