It’s no secret that cloud services are on the rise. Gartner estimates that businesses will spend $266.4 billion on cloud services this year, growing to $354.6 billion by 2022. Why is cloud consumption rising so quickly? Because free-market economies hate inefficiencies, and the cloud is all about efficiency. But that’s not to suggest that cloud adoption didn’t create ripples in the industry, as we see when we look at its history and the impact on ISVs (Individual Software Vendors).

 

History of Cloud Services

In the early days of cloud, enterprises were primarily attracted to the cloud for data center outsourcing: servers, switches, storage, infrastructure-oriented software, and the expertise to manage it all. The premise was that the cloud provider could offer better economies of scale by hosting multiple customer data centers and streamlining their own operations through in-house expertise, particularly around automation. In exchange for a monthly fee, enterprises could eliminate the hardware, software and IT resources associated with maintaining their own data center environment.

Infrastructure Abstraction

Over time, enterprises (and their software suppliers) were able to focus more on the applications and less on the integration points of their legacy infrastructure—the value of infrastructure abstraction was profitably exploited. This soon led to enterprises embracing managed Software as a Service (SaaS) offerings for the supporting systems of their mission-critical applications.

Examples of this include observability-oriented systems (e.g., ElasticSearch, Logstash, Kibana, Prometheus, Grafana) and database systems (e.g., MongoDB, Cassandra). With the cloud provider now offering these systems as managed services, the enterprise no longer needed to worry about deploying and supporting these systems; they could just order them through the cloud provider’s portal.

As all this lower-layer abstraction was happening, however, the remaining applications and the business logic they contained grew more complex—so complex, in fact, that the traditional model of licensing application software to another organization for deployment and operation began to disappear. Modern software is consumed in one of two ways and operated only in one way. Operationally speaking, the organization that builds the software, operates it. Enterprises consume the software they write directly and consume anything else as a service via APIs over the Internet. It should be clear that the API service provider is indeed operating the software that they wrote.

Businesses Defined by Software

While this change was happening, an even more important transformation was taking place in the software industry. A growing number of businesses became defined by software, which created a greater need for improved agility. It was no longer acceptable to deliver only two or four upgrades per year; instead, businesses needed tens, hundreds and even thousands of software updates per day.

CI/CD (Continuous Integration/Continuous Deployment)

In 2010, responding to this need, Jez Humble and David Farley devised an extension to the existing concept of continuous integration, calling it Continuous Integration/Continuous Deployment (CI/CD). CI/CD proposed combining the previously separate functions of development and operations into a single function, DevOps. The DevOps team would be responsible for feature development, test automation and production operations. CI/CD maintained that only by breaking down internal barriers could an enterprise reach the point of executing 10 or more updates per day.

There was only one problem with CI/CD: existing software architectures were poorly suited to frequent releases because virtually all software was released monolithically. The software code may have been modularized, but the release needed to include all the functionality, fully tested. How fast could enterprises update a complex, monolithic application?

Microservices

As enterprises were struggling to answer this question, the idea of microservices—which had been floating around since 2007—began to take hold in architectural circles in 2011. Microservices maintained the idea that, by breaking larger applications into bite-size pieces that were developed and released independently, application development teams could release tens, hundreds, and even thousands of software updates per day using a fully automated CI/CD pipeline.

This meant that no human intervention would be required between the time the developer committed the code and the time they ran the code in a production environment. Microservices—particularly stateless microservices—bring their own complexities, however: API version controls, DB schema controls, observability, and more. Fortunately, in CI/CD’s DevOps team model, all the necessary expertise is contained in a single group.

 

The Impact on ISVs

So how does all this impact ISVs? Remember, these are the entities that produce applications and license them for use by others. Whether the licensing is annual or perpetual, the main issue is that the purchaser is ultimately responsible for the deployment and operation of that software. ISVs often supplement their licensing with extensive professional services and training as a means to achieve the requisite knowledge transfer. But that knowledge transfer is never complete, and the ultimate experts on the vendor’s software remain in the vendor’s organization.

What’s the natural consequence of this? The customer consumes hosted or fully managed services. It is a change in the way telcos have done things in the past, and change is never easy, but the efficiency and agility benefits of moving to a modern, cloud-native model can have a profoundly positive impact on telcos going forward.