The Cranky Admin
The Changing 'As-A-Service' Model
There's a battle for control going on in your datacenter.
The smaller the organization, the less likely it is to be able to respond quickly to unexpected changes using in-house resources. A market is thus emerging for managed service providers to monitor forced changes to applications, operating systems and SaaS offerings to detect if updates (e.g., API changes) will break vital middleware. For lack of a better term, I'll call this emerging sector as-a-Service-as-a-Service (aaSaaS).
Businesses are losing control over the applications they use. Anyone signing up to Software-as-a-Service (SaaS) signs over all control over patching, updates and so forth to the provisioning vendor. The same thing is happening to on-premises operating systems and applications with cumulative updates. Anything about mission-critical applications can change at any time, without a business having an opportunity to test whether or not those changes break something critical, such as the often-custom middleware upon which virtually every business now depends.
Markets in Motion
aaSaaS changes the requirement for an organization to trust a potentially large number of vendors to having to place trust in a much smaller number of suppliers, or a single supplier. While ordinarily placing the future of one's business into the hands of a single supplier would be something to avoid, the as-a-Service (aaS) model changes a lot of the assumptions about IT.
aaS developers have an economic incentive to remove as many aspects of customer control over the software that they use and the environments in which that software operates as possible. The more freedom a customer has to customize their software, or the more control they have over their software, the greater the maintenance and support burden upon the vendor.
There's little incentive for a vendor to support interoperation with third-party applications or with a customer's custom middleware. Unless this lack of support would demonstrably result in a mass customer exodus, vendors are incentivized to either build requisite features into their own application or funnel customers into another application that they control and develop.
Placing the fate of one's organization into the hands of vendors who are incentivized to remove your ability to interoperate applications -- and thus automate your IT -- is not rational. Choosing to work with a layer of middleman vendors whose economic incentive is to work around vendor control, lock-in, and restrictions provides a competitive advantage over other organizations restricted to an increasingly narrow technological path.
This isn't the first time we've found ourselves on this side of the pendulum swing. As with everything in tech, the oscillation between openness and vertical integration is cyclical. Every now and again, the market moves towards vertically-integrated stacks with tightly-controlled support parameters and hierarchical, top-heavy vendor ecosystems.
The Pendulum Keeps Swinging
When on the vertical integration side of the pendulum swing, the word of the tech titan at the center of the ecosystem is unimpeachable law. If they want to change their API, no pushback from customers or their developer community will be entertained, let alone successful.
The result of reaching the pinnacle of the vertical integration cycle is an explosion of startups, services, and channel offerings dedicated to enabling customers to work around the most limiting of core vendor choices. After this new breed of startups has solved the most pressing pain points, they begin to move on to more and more esoteric use cases, ultimately enabling customers to migrate off of products and services supplied by the most egregious of the vertical integration vendors.
In days past, one might have seen startups making it possible to read proprietary data files, virtualize operating systems and applications, or use a single command and configuration language to address infrastructure components from multiple vendors.
The other side of the cycle is the open phase. In the open phase, vendors make noises about standards. They publish APIs, and may even commit to not changing certain portions of them for a limited period of time. Tech titans promote the feature-richness of their offerings, and the integration they have built between multiple applications, services and infrastructure components.
With their newfound "commitment" to openness, clearly customers need not leave them for significantly less expensive alternatives. An organization can accomplish its goals of avoiding lock-in simply by trusting in the tech titan to play nice with standards and whatever community or ecosystem has grown up around their startup competitors.
Standards and open interoperability bring bureaucracy. They slow the pace of innovation. While this is excellent for the risk averse, it makes solving challenges, especially challenges of scale, difficult. This sets us on the path back towards vertical integration.
The tech titans, having embraced standards, now extend them with proprietary feature sets and capabilities designed to solve what at the time are edge cases (such as hyperscale), but which in due time become the requirements of the mass market. Cue the pressure to head towards openness once more, and the cycle repeats ad nauseam.
The Data Battleground
Not all aaSes offer the ability to easily export data, and especially metadata or configurations. These are excellent ways to keep customers locked in. If you make it difficult, expensive, or at least time-consuming to extract all of the information from your system, migration to an alternative aaS or to an on-premises solution is unlikely.
Initially this approach worked. Over time, however, customers large enough not to be ignored started demanding the ability to export their data in a usable form, in some cases for regulatory compliance, in others for data warehousing and business intelligence. While this has opened the most critical of the big name aaSes, many retain a vice-like grip on data.
Fortunately, you can't prevent a customer from seeing their data and still have a usable application. Extracting the data using solutions such as HTML spiders is miserable, but that solution only has to be coded once, and can then be sold by aaSaaS providers as a solution to extract data from a recalcitrant aaS.
It's easy to fall into the trap of treating IT products and services like retail items purchased at the corner store. Going to Amazon with credit card in hand to spin up some aaS needed to cover a last-minute shortfall in many ways seems as simple as nipping down to the grocer when you're out of toilet paper.
However, toilet paper is rarely a strategic decision. (There are perhaps specific instances in which toilet paper could be a strategic decision. If you planned to climb Mount Everest, how much toilet paper you bring and how much you can compress it may actually matter.) For the average person, however, comfort, price and availability at the store where you want to buy it are the things that matter.
This isn't true of most aaS offerings. Even a seemingly small and innocuous isolated service can become a strategic commitment. Once your data is into your aaS, and you have begun to use that aaS in order to process that data and act upon the results, it has become a strategic part of your organization's IT. There are very few truly disposable solutions within an IT environment.
Whom Do You Trust?
Trust becomes critical. Trust between customer, vendor, and channel partner. Where does the power lie in the relationship? With the faceless vendor, unwilling to listen to or unconcerned with customer needs? Does it lie with the channel partner who can migrate customers between vendors at a whim?
Power almost never lives with the customer. However, there are many more IT vendors in play today than there were a decade ago, and a decade from now there will be multiples more. As the market oscillates between extremes, customers would do well to remember that newer is not always better. There is a competitive and strategic advantage to awareness of the pendulum swing and the ability to play channel against vendor -- aaSaaS against aaS -- to find the solutions that suit the customer's goals in the customer's time frame.
Power comes not merely from the ability to migrate or the ability to leverage new features. It comes also from the ability to choose when to change, what to change, and when to simply wait for the next cycle.
About the Author
Trevor Pott is a full-time nerd from Edmonton, Alberta, Canada. He splits his time between systems administration, technology writing, and consulting. As a consultant he helps Silicon Valley startups better understand systems administrators and how to sell to them.