DevOps, DevApps and the Death of Infrastructure – InApps 2022

In 1897, rumors swirled that the great American humorist, Samuel Clemens (a.k.a. Mark Twain) was ill. Eventually, rumors turned to belief that he had passed away. The English correspondent for the New York Journal, Frank Marshall, inquired of Twain whether this was true. Twain famously responded:

“I can understand perfectly how the report of my illness got about, I have even heard on good authority that I was dead. James Ross Clemens, a cousin of mine, was seriously ill two or three weeks ago in London, but is well now. The report of my illness grew out of his illness.

The report of my death was an exaggeration.”

My claim that infrastructure is dead may be deliberately cheeky, but it’s not too much of an exaggeration. Just as Clemens’ disappearance from view allowed the rumor to spread, we can now say the same about infrastructure. As we continue to move toward a services-based IT economy, we trade in self-administered servers for services, and delegate the administration of infrastructure to cloud providers.

As serverless grows, it’s not that infrastructure is dying; instead, it’s becoming more abstracted and out of sight. In fact, there is more infrastructure in use than ever, but the administration of those servers, routers and storages are being delegated to a smaller group of skilled administrators — helped by improved tools and automation.

DevOps, Infrastructure-as-Code

The DevOps movement has been focused around the convergence of operations and development, with infrastructure practices increasingly mirroring those of software developers. Practitioners often describe DevOps using the acronym CAMS (Culture, Automation, Measurement, and Sharing), a term coined by one of the luminaries of DevOps and co-author of the DevOps Handbook, John Willis. The Automation piece was one of the more tangible parts of the DevOps movement. Technologies like CFengine, Puppet, Chef and Red Hat’s Ansible automate the configuration of infrastructure — although that’s simply one type of automation.

Another common practice is to automate the deployment of software via continuous integration and deployment (CI/CD). Automated build-and-test steps triggered by CI ensure that code changes being merged into the repository are reliable and then delivered seamlessly as a part of the CD process.

More recently, Amazon’s Cloud Formation and Hashicorp’s Terraform help enterprises automate the configuration of cloud services through a declarative API, services that accelerate deploying and maintaining infrastructure. Taken togther, these automation capabilities changed the global IT culture to one where it’s now commonplace for system updates to occur monthly, or in more aggressive cases weekly, during smaller maintenance windows. Today, many organizations are pushing updates daily and even hourly.

Over time, cloud services from Google, AWS or Microsoft provided redundant systems at a cost much lower than possible within the enterprise. The main risk of cloud vendors isn’t downtime, but rather vendor lock-in, a lack of understanding of the consequences of utilizing certain services, or inferiority of services relative to other cloud providers.

Multicloud cloud usage is rising, but not for redundancy. At one point in time, the implication of multicloud was to run the same workload on multiple clouds. As noted “cloud good troublemaker” Corey Quinn observes, that’s a worst practice. Instead, enterprises are picking the best solution for their needs, e.g. Gitlab for code repositories, Salesforce for CRM, Datadog for monitoring, and Google, Microsoft and Amazon for infrastructure hosting. This combination is really the multicloud that makes sense. Once organizations start consuming multiple services that solve individual problems, it’s no longer a problem of infrastructure but of integration.

DevApps, Integration-as-Code

The godfather of the DevOps movement, Patrick Debois, often speaks about how we are moving to a more service-oriented or serviceful intranet (See his talk on Serviceful versus Serverless). I have been calling this riff on DevOps deployment methodology, DevApps.

This is an emerging design pattern where cloud native applications are a combination of bespoke services (like Twilio, Salesforce, and many others) alongside custom software deployed as functions on scale-to-zero web services like Amazon Lambda. Services are being managed with Terraform, just as the services of the past had been managed by Chef or Puppet.

Once organizations tackle the well-accepted practice to automate deployment, the next frontier is to create applications that are composable via automated means. What we’re talking about here is layering integration-as-code on top of infrastructure-as-code. With a wide variety of cloud services at their disposal, application developers need not worry about the latter — just the former.

At TriggerMesh, we are seeing more and more organizations looking to create applications that are configured with automated workflows on the fly. We are seeing an evolution where a developer can now, via declarative APIs, simply define the components of their cloud native application and the workflows between them, to create an end-to-end application without the need for provisioning infrastructure. For example, a recent workflow used TriggerMesh and Robotic Process Automation (RPA) technology to mine Salesforce for data, dumped that data on Google Cloud and then sent out invoices via Twilio Sendgrid. This involved the chaining together of very different services managed by four different providers. The resulting workflow had the potential to implement the best-of-breed in each category based on costs and functionality and providing a single automated cloud native solution.

An Example: The Jamstack

As the growth of the web boomed, the LAMP Stack was a common way to deploy applications on Linux — with Apache web server, MySQL, and one of the 3 Ps (Python, Perl, or PHP). Today, we are starting to see the emergence of a new “stack,” the Jamstack. Jamstack is less of a well-defined stack and more an architecture designed to make the web faster, more secure, and easier to scale. It builds on many tools (Gatsby, Hugo, Jekyll, Eleventy, NextJS, and many more) and workflows to greatly increase productivity.

A thriving ecosystem of cloud services, like Netlify CDN, has become a significant enabler for Jamstack sites. The ability to leverage domain experts who offer their products and services via APIs has allowed teams to build increasingly powerful networked applications, with fewer resources. Developers can consume and integrate other services for tasks — including authentication and identity, payments, content management, data services, search, and much more.

Jamstack sites might utilize such services at build time, and also at run time directly from the browser via JavaScript. The clean decoupling of these services allows for greater portability and flexibility, and speed to value.

Digital or COVID-19 Transformation

As McKinsey and company pointed out in their report, How COVID-19 has pushed companies over the technology tipping point — and transformed business forever, the COVID-19 pandemic has accelerated the need for companies to increase their ability to interact with their customers digitally.

For these reasons, companies not only have to move faster, but they have to adopt processes and tooling that enable them to move faster — in order to accelerate their digital transformation initiatives. That includes adopting cloud services that reduce the time to value, and adding other capabilities — like integration-as-code and CI/CD. At the end of the day, companies need to focus their energy on differentiated services that provide an advantage to their company. Moving to a more serviceful approach to developing and maintaining digital experiences is the pathway to a better and more agile online presence.

Feature image via Pixabay.