Don't build what you can buy

The last post described the parallels between the old Build v Buy debate with the current IaaS v PaaS discussion. Here I'll attempt to justify the Buy (or PaaS) approach, or at least define the circumstances in which this makes sense.

What are we buying?

When running a business, we want to buy as much generic and non-'domain-specific' resources as possible. Specialization and scale lead to efficiency, and businesses that specialize are typically able to provide specific resources to you at a price well below your cost to produce the resource yourself. This is why we don't make our own paper and pens, or build our own computers.

Buying a platform is a little different. We aren't buying something completely generic, but instead something proprietary and specialized. Our systems will both leverage the efficiency that the platform provides, and completely depend on that platform.

Organizational efficiency

In the same way that we can't make a better pen, desk, or computer than can be bought from a vendor, we also can't run a server more efficiently than a vendor. We need a large number of people with a range of expertise; we need specific systems and tools that must be configured; and we need to manage capacity correctly. This is the basic premise of the cloud.

But what about maintaining a system? Let's take an easy example - storage. We can either run a large number of servers to host data, or we can pay (for example) AWS to store data on S3. In addition to the billable costs, own servers require OS maintenance, usage monitoring, capacity planning, configuration, backup and disaster recovery, and upgrade planning. With S3 we simply pay for what we use.

Does S3 provide the utter flexibility that we can achieve with managing data ourselves? It may not. But in most cases it is foolish to insist on that flexibility given the huge cost of data management. This is cutting off your nose to spite your face.

Serverless examples

Extending the scenario, consider the need for some invocable code. We can either run a server (or two) to host the code, or we can pay (for example) Google to host it in their Cloud Functions product. With the former, we again need to configure a server, perform OS maintenance, monitoring, managing capacity and scaling, perform disaster recovery and have a failover, and generally have a group of people making sure it is working. With a Cloud Function implementation, we upload code and pay per invocation. It is cheaper to develop, cheaper to operate, and cheaper to maintain.

The trade off is that our Cloud Function deployment isn't portable. We can't simply change some configuration value and run it on AWS! This seems trivial for a single function (the code can run inside Cloud Functions or Lambda with minimal changes), but becomes important as part of a large system. And it's true - we might have to reconfigure huge parts of our system to run it in another cloud.

General solutions are more complex

It is faster and cheaper to build cloud specific solutions than a general solution.

Consider the above; deploy some functions natively and build a system. Using cloud native components you can do this in days, instead of weeks. You can support the system with part time attention, instead of requiring a team of administrators. You can scale easily (or automatically), instead of having to plan and build your own scaling. And so on.

There's no doubt that the build time is a fraction of doing it yourself, and the support gap is even more stark. So if you need to deploy to another cloud, just do it again. Hopefully you can keep and re-use the so-called 'business logic', but even if that needs to be reproduced you are still (a) getting that first cloud deployment to market much sooner, (b) deploying two stacks at lower operating cost due to more efficient platform native components, and (c) reducing your support cost by minimizing support tooling, server maintainence, etc.

Don't build your own platform

You can defer to the speed of development, the economics of supporting and building a platform, the previous decisions made by others, or the sheer complexity of planning and managing your own platform. On each of these measures you should objectively buy a platform instead of building your own.

The only exceptions here - which are exceedingly rare - are when (a) your entire system needs to be portable, (b) platforms do not support your use cases, or (c) you operate at scale sufficient to achieve some operational efficiency at managing your own platform.

social