Detangling the wires

Cloud and related technologies have seen a lot of entrants in the last 2-3 years and because these technologies are gaining momentum it seems that the pace of innovation has taken precedence over defining ‘who are we building this for?’  This post offers  my perspective on how things like cloud, containers, resource poolers and platforms as a service fit together to build a supply chain.  

It is important to define what we are building first before we can discuss how the supply chain might look.  The product in our scenario is an end-user facing application (e.g. mobile app, intranet widget, LOB system, etc.) whose purpose is to provide value (benefits > cost) to the end-user.   With this product definition in mind, let’s look at the ‘possible suppliers’*.

  •      Configuration Management tools
  •      Cloud
  •      Container Orchestration Systems
  •      Platform as a Service
* This is a simplified list of suppliers, as it does not include infrastructure, continuous Integration tools, service registries, and other suppliers in the full chain.

The ‘application’ will be built, staged, and deployed before it can serve its purpose of providing value to the end-user.  In order to accommodate the lifecycle… we will need to provide infrastructure resources, deploy the necessary dependencies and runtimes, conduct tests to validate functionality, ensure connectivity and let users know how to find it.

Many of the suppliers are pursuing vertical integration strategies in terms of trying to provide a single tool that does too much and it becomes hard to select the right supplier since they are all stronger in certain areas while weaker in others.  Ideally, we should be able to understand the strengths of suppliers and ensure that their relationship and delegation to the next player in the supply chain is seamless.

Here’s how I believe some tools are being positioned:


Here’s how I believe they ideally provide value in the supply chain:


Cloud should focus primarily on the operators and platform developers experience to provide a solid foundation of services/APIs that can be leveraged by the other suppliers in the chain to minimize scope creep. Container orchestration systems and PaaS should focus on delivering/deploying code as efficiently as possible.  They should not have to recreate the lower-level services provided by the cloud, the primary audience here should be the teams responsible for providing the development platform for the organization.  The application developer should only be interfacing with the container orchestration system or PaaS while focusing on the end-user application.  The user themselves should be unaware (as much as possible) of the underlying systems.  It is also important to note that, while not depicted in the diagram, resource pooling systems should also focus on the operator experience.

If this supply chain view holds then it would make sense for adjacent suppliers to work closely with each other to provide as much integration as possible while having clear demarcation points. This is simply my take and I understand that it may not be right but hopefully it will spark a good discussion.