COTSOps - Cloud
This is the fourth in the COTSOps Ecosystem Optimization Strategy series. Links to the first, second, and third articles.
Before assessing public and private cloud utilization constraints for COTSOps enterprises and the COTSOps ecosystem, it is first important to ask ..
What is Cloud?
A simple technical description of the public cloud stack components would include: open source software-defined everything up and down the infrastructure and application stack, Linux, x86, and ARM-based computing, rich and mature APIs, and lots of advanced lifecycle automation.
The previous Mainframe, Midrange, and much of the Distributed Systems compute eras platform components were, and still are, many proprietary hardware and software vendor systems up and down the stack (i.e.; hardware, operating system, application servers, databases, storage, networking, ..).
While there have been attempts by proprietary systems vendors to continue to monetize their commercial offerings (i.e.; hyper-converged infrastructure, ..), the velocity of global open-source software communities and collaboration has been dominating the last decade or so.
The success of open-source software is well exemplified by core public cloud vendors' utility of computing services. The public cloud hyperscalers have successfully maximized the delivery of open-source software in the wrapper of proprietary services.
COTSOps Cloud ‘Hosting’
For decades, the industry has had many options for running non-cloud architecture workloads outside of the corporate data center. Most commonly this has been referred to as ‘hosting’.
Is it ‘cloud’, when public cloud vendors offer ‘hosting’ services for non-cloud architecture workloads running legacy and/or proprietary hardware and/or software?
It depends on the motivations of the beholder and their 'north star' strategy that is providing direction and guardrails for strategy execution.
Many COTSOps enterprises for years have been executing the first step (Rehosting) of the Five R’s of Cloud Adoption, and some are still not done.
COTSOps enterprises are generally >98% legacy workload architectures. In regards to the challenges of migrating legacy workloads to different hosting providers, it has been slow work for 30 years.
COTSOps Cloud Rehosting … aka: "Deferred Maintenance"
Many COTSOps enterprise’s Rehosting to cloud programs has been executing deferred maintenance.
For many, the mantra has been ..
"we’ll modernize our workloads to cloud architecture after we’re done with Rehosting".
Looking back over the last 6-years, Rehosting has taken (or took) much longer than originally projected (shock to nobody) and many are still at it.
So, we’ve had a significant period of time, years for some, where the COTSOps enterprise is paying many tens of millions of dollars annually for software maintenance/subscriptions to their software supply chain vendors, but many of the incumbent COTS are not being upgraded for years.
Each ISV has different release cycles for its COTS, however, generally, each COTS release includes new capabilities that can help the business compete, differentiate, disrupt, and if fortunate innovate. As COTS are frequently improved, so 'should' the customer's domain APIs and the COTS APIs in order to continuously improve the throughput velocity of wielding data ‘trapped’ in the COTS.
Generally, for many years, COTSOps enterprises have averaged being multiple versions behind the currently available version of the software from their incumbent software supply chain partners. This tends to calcify deployed COTS and impede software change velocity. Older software increases Cybersecurity risks.
COTSOps enterprises running legacy COTS versions are a tax on their ISVs. Most ISVs will have significant maintenance/subscription charges to support legacy COTS versions prior to end-of-version support.
When available software that can materially enable the business is not in production; this is a negative hard and soft opportunity cost.
The software industry best practice for two decades has been ‘do not’ customize ISV COTS. However, this best practice is violated frequently by COTSOps enterprises. Think about it. ISV sends COTSOps enterprise a proprietary complex system and they highly couple unique customizations, their own complex system, to the COTS complex system. Even if an incumbent ISV were to deliver a modernized cloud-native architecture COTS, where COTSOps enterprises have customized their deployed COTS version will impede the COTS upgrade. This topic is worthy of its own article as it severely impedes COTS software change velocity.
How might Rehosting non-cloud architecture workloads to public cloud create destructive WIP?
We Rehosted To Cloud, But We ‘May Not’ Modernize To Cloud Architecture
Many COTSOps enterprises have a disproportionate volume (~80%) of ISV COTS workload and Rehosting for a few years has compounded the significantly increased cost to run these cloud vendor-hosted workloads.
At some point in the Rehosting effort, the focus shifts to optimizing the affordability of consuming the Cloud vendor's services. Right-sizing the allocated compute resources and workload automation has its limitations on cost impact since most of these workloads are not 'Cloud-Native' architecture.
The significant double-digit cloud cost optimization savings are realized when COTS workloads are modernized to 'Cloud-Native' architecture (i.e.; Serverless, Microservices, loosely coupled microservices for COTS customizations, ..) providing the intelligent automation to dynamically spin up and spin down services and compute resources.
So the next step in the Five R’s of Cloud Adoption are steps 2 through 4 - Rebuild, Refactor, and Rearchitect.
Most of these Rehosted incumbent COTS workloads are legacy software architecture, so the COTS architecture does not support much dynamic provisioning to optimize public cloud compute utilization. No, many of these COTS are big monolithic applications that don’t offer the ability to spin up/down individual services. There is no magic dust to be sprinkled here. Many COTSOps enterprise’s cloud architects have said to me we will modernize our workloads after we Rehost.
A big mantra from COTSOps enterprises is they will focus on modernizing their workloads for optimizing cloud utilization after Rehosting.
What is the ‘unspoken assumption’ of steps 2 through 4 of the 5 R’s of Cloud Adoption?
The COTSOps enterprise must own their workloads software source code in order that they ‘may’ (have permission) execute Rebuild, Refactor, and Rearchitect its workloads from its legacy architecture to cloud-native architecture. Steps 2 through 4 of workload modernization ‘may not’ be executed for most COTS.
So, let's assess where many COTSOps enterprises are today.
The above provides more examples of the COTSOps ‘complex ecosystem interdependency constraints’.
And why the COTSOps ecosystem faces an order of magnitude greater complexity challenge to optimize than a DevOps workloads profile type enterprise.
What is ‘cloud-native’ architecture?
Cloud-native architecture is a modern discipline for software development and delivery that looks to deliver smaller applications and services (i.e.; Microservices). Smaller focused capabilities can run as their own affinity service, be reused by other services, and with few interdependencies, this can improve software change velocity for resiliency for continuous improvement. To contrast, large monolithic applications have numerous interdependencies that are difficult to change with much frequency and resiliency mileage varies.
Another tenant of Cloud-native architecture design is software portability. In the Mainframe and Midrange eras, software was highly coupled to hardware. As a software vendor, this means for a single software product one had to have multiple versions (forks) of the same software product in order to support running on different hardware/software (i.e.; Unix flavors, ..). So Cloud-Native architecture by design intentionally decouples software from hardware.
What is ‘Cloud-vendor-Native’?
Many in the industry use the term ‘cloud-native’, however, they are referring to the cloud vendors' native services. Almost all of the cloud vendor’s native services (i.e.; AI/ML, IoT, Database as a Service, storage, ..) only run on that public cloud vendor’s cloud platform (hardware). For most of the public cloud vendor’s native services, there are competitive 3rd party service offerings that are ‘hybrid cloud’ - by design support running across many mono-cloud vendor platforms.
Why is it that the design intent of the major public mono-cloud vendors is that their native services only run on that public mono-cloud vendor’s platform?
Generally speaking, cloud services should stand on their own affinity.
When enterprises and ISVs have a preference to consume the mono-cloud vendor's native services then often this does not align with Cloud-Native Architecture principles. And this does create future constraints when the enterprise will have the requirement to support that mono-cloud vendor’s native service on other mono-cloud vendor platforms.
Cloud Marketplaces
Contractual commits to mono-cloud platform vendors is driving the software aggregate spend to consolidate through the mono-cloud vendors.
We’ll see how well this goes for COTSOps enterprises as their hosting costs and committed spend with mono-cloud vendors will test the value of the operating model.
We also must consider the interdependency constraints of the COTS ISVs constraints as their customers in aggregate require them to support >5 mono-cloud vendors. They could go mono-cloud vendor native on one mono-cloud, but that will certainly cause challenges later. The ISVs could choose to use a hybrid cloud platform standardization providing go-to-market platform standardization across the mono-cloud vendor requirements. A nuance is that not all COTS will be modernized by ISVs, so it is important to standardize on a hybrid cloud application development and delivery platform that supports both legacy and modern workload architectures. By doing so the COTS ISV ecosystem is positioned to securely wield software and data for velocity and agility in order to compete, differentiate, disrupt, and if fortunate innovate.
Then we must consider the interdependency constraints of the Systems Integrators (SIs) who also have much go-to-market complexity since each mono-cloud platform vendor is completely bespoke from the other mono-cloud vendors. The SIs, that implement COTS, must support aggregate customer requirements across >5 mono-cloud vendors. Unless the SI’s also focus optimization on hybrid cloud platform standardization, they will be highly constrained to meet market demand. Consider the constraints of an SI's attempting to go to market on each bespoke (>5) mono-cloud and such specialized talent redundancy.
Whereas, hybrid cloud application platform standardization provides SIs with go-to-market leverage to scale.
As the era of loose monetary policy is constrained, possibly hybrid cloud go-to-market optimization will come quickly into focus for the SIs and the rest of the COTSOps interdependent software ecosystem.
I will continue on the significant cloud topic in a future article; the next article is on Lifecycle Automation program optimization. Hint: should we invert the delivery responsibility to improve throughput?