Many modern cloud platforms, such as Google’s Cloud Services Platform, utilize containers as the core mechanism for consistent deployment and operation of applications and services. When discussing container technology with traditional IT organizations, one response that I frequently hear is: “many of my enterprise applications, especially commercial off-the-shelf software, don’t run in containers, or at least not without the vendor’s support.” Fair point! The answer to this conundrum, interestingly, lies in taking a step back and asking a more fundamental question.

Enterprise IT = Running someone else’s software

Enterprise It largely runs other people’s software. That’s because enterprise IT favors buying over building software, and in most cases rightly so. Over time, running other people’s software has essentially become the fundamental premise of IT: IT procures software and hardware, installs the software on the hardware, configures and integrates, and then operates it.

It has also led to a state where IT is quite overloaded with all those applications.

Is your IT overloaded?

If your IT looks a little bit like this, it’s time to slim down.

Running other people’s software is actually a bad deal!

Come to think of it, running others’ software is actually a pretty bad deal:

  • You have to pay for hardware. To make it worse, vendors’ sizing requirements are often very conservative because it’s easier for them to have you buy more hardware than to explain performance challenges.
  • Installation is cumbersome. I once had a software vendor tell me that all the installation issues are due to our environment. My response was: isn’t the very purpose of installation to get your software to run in our environment?
  • If something breaks, you’re guilty until proven innocent. Yup, it’s like that porcelain shop: you break, you pay. In this case, you pay for support. And if something breaks you have to convince support that it’s not due to your environment.
  • You can’t make changes when you need them. And despite all this effort, if you need a new feature, you’ll have to wait until the next release - that is, if your feature is on the feature list. If not, you may be waiting a looooong time.

Yup, running software you didn’t build isn’t actually all that great. It’s amazing how enterprise IT has gotten so used to this model that many don’t even question it.

SaaS - Software as a Service

Luckily the world of cloud has brought us new options. Software-as-a-service (SaaS) makes the vendor run the applications for you; and apply patches; and upgrades; and scale; and replace faulty hardware. Now that sounds a lot better!

Interestingly Salesforce was really the first one to lead us that route around 2005, but is by far no longer the only company following this model: you can handle all your communications and documents in the cloud thanks to Google G Suite (which started 2006 as “Google Apps for Your Domain”), HR and performance management with SAP SuccessFactors, ERP with SAP Cloud ERP, service management with ServiceNow, and integrate it all with Mulesoft CloudHub (note: these are just examples; I have no affiliation with these companies and Google pays me regardless of whether I mention G Suite or not :-) ).

But what about…

Naturally, enterprise IT tends to have a long list of “buts”, so let’s look at some of these. The goal isn’t to dismiss these points, but to see what has changed to make them a lesser (or no) concern:

  • Security: The days where having stuff on your premises means they are more secure, are over. Attack vectors like microprocessor vulnerabilities (Spectre, Meltdown), compromised hardware, large-scale denial-of-service-attacks and nation-state attackers, just to name a few, make it nearly impossible to protect IT assets without the scale and operational automation of large cloud providers. Plus, on-premises often isn’t actually on on premise - it’s just another data center.

  • Latency: Latency isn’t just a matter of distance, but also a matter of the number of hops, and the size of the pipes (saturation drives up latency or brings a service down altogether). Most of your customers and partners will access your services from the internet, so often the cloud is closer to them than your ISP and your data center.

  • Control: Control is when reality matches what you tell it to be. In many enterprises, manual processes severely limit control: someone files a request, which gets approved, followed by a manual action. Who guarantees the action matches what was approved? A jump server and session recording?

  • Cost: Most enterprises reduce cost by moving to the cloud thanks to better economies of scale and higher levels of automation.

  • Integration: One could write whole books about integration - oh, wait! Naturally, a significant part of installing software isn’t just about getting it to run, but also to connect it to other systems. A SaaS model doesn’t make this work go away completely, but the availability of APIs and pre-built interfaces (e.g. Salesforce and GSuite) makes it a good bit easier. From that perspective, it’s also no surprise that Salesforce acquired Mulesoft.

What about the software you do build?

Naturally, there’s going to be some software that you do want to build, for example because it provides a competitive advantage. For that software, delivery velocity, availability, and scalability are key criteria. Luckily, cloud isn’t just about infrastructure: it delivers here in form of Platform-as-a-Service that combines integrated CI/CD pipelines and container orchestration with Kubernetes or a fully-managed setup like Google Kubernetes Engine.

Strategy = Setting the vector

Not all your on premise software will disappear tomorrow. But strategy is a direction, not current reality. I am convinced that not running software you didn’t build has become a viable IT strategy that’ll help you slim down your IT!