Conway’s law in Multi-Cloud Compute

Shawn R. Hartsock
4 min readFeb 3, 2021


I can’t see the forest, there’s too many trees

Software as a Service (SaaS), Platform as a Service (PaaS), and Infrastructure as a Service (IaaS), why do we use those terms? Is it some fundamental tenant of Cloud Computing? How does it fit with Developer-Operations (DevOps) and why we should care? What do these designations really tell us about what’s going on in computing and what changes when we introduce multi-cloud narratives into this mix of terms?


All “as a Service” layers are accidental complexity placed on a program which exists as a service or utility for its customers. These layers aren’t intrinsic to solving the core objective of the service and can be removed. These layers change as the environment changes.

Conway’s Law

If you have three teams working on a compiler, you’ll have a three pass compiler.

Companies that grow beyond just a few employees naturally have specialization in roles. The larger the organization, the higher the specialization the organization requires and can benefit from. This explosion of additional employees results in increasing need for coordination. Now you need managers. And, managers to manage the managers.

This tree-like structure will reflect the model of the business that the top management believes they need. But, it does not necessarily reflect the actual business that the company is in. The two should ideally match but may not.

As long as the belief and reality are closely matched enough there will be some harmony with the business and its operations. Changing environmental factors will naturally force reorganization. Changing belief at the organization will also alter its organizational tree.

And the organizational tree will change how, what, where, and when software is created.

Conway’s Law as a Service

Why do the concepts of SaaS, PaaS, and IaaS exist? Because those often delineate organizational boundaries inside a company or even boundaries between companies. When you engage with a cloud provider for IaaS there’s an explicit and implicit contract between the organizations and teams represented. The cloud provider’s job is to provide you with whatever IaaS is defined as between the two of you.

DevOps and DevSecOps are often sold as “bringing together developers and operations” or even some how “blurring the lines” of the two sets of roles. In some mental models of the space this fits in the PaaS category. That would be less work to imagine. We can just see PaaS as a formalization of taking infrastructure and building it up into a platform that we then build up into a service.

But, what if you were wrong about something or something changes?

Kubernetes at VMware

I was involved with OpenStack at VMware in its beginnings. The slogan for us internally was “Be the best place to run OpenStack.” This fits well with VMware.

VMware has a simple value proposition as a company: we’re going to be the best way for you to deliver computing services to your organization. In practice that value proposition usually encompasses Hypervisors but in the era of Kubernetes that is starting to include things like Tanzu.

Is Kubernetes IaaS or PaaS?

DevOps and DevSecOps don’t remove the Developer, Operations, or Security roles from a company. They redefine the boundaries. Kubernetes is a scheduler matching API driven demand with API driven supply. The tool kubectl and its API surfaces abstract implementation details underneath how a demand is met. Those details are still there, the knowledge, skill, and dedication that makes those details function are all still there, just hidden.

I’ve written previously that Linux is the new JVM because of how Containers and Kubernetes shift the organizational dynamics around development and operations. The new alignment is necessary because the reality of what constitutes Development, Operations, and Security have changed by how much more interconnected our world is now.

It will only get more so. And, when it does we need to recognize that the layers we put in place are just conveniences to recognize pragmatic operational concerns that do not actually involve the real customer problem.


Today, multi-cloud workload migration is still technically a future looking concept. I am aware of a few organizations actually doing this, but there’s not enough real practice to observe new patterns in yet. If we apply Conway’s Law in reverse again, what layers are accidental and which are really needed?

There’s another shift coming. Metaphorically the cloud computing we see today is the three pass compiler. We should be asking if those three passes is really necessary or is that is an artifact of the initial team organization? Does the new business need three passes?

Do we need IaaS, PaaS, and SaaS as separate layers? Now? In the future? And what does that do to security, privacy, and confidentiality if we eliminate a layer?

This will change everything. Yet again.