Guest post by Tom McLaughlin, ServerlessOps
“Build vs. buy” is an endless argument that keeps popping up in engineering. Is your time better spent building a solution or just buying one? If you’re familiar with serverless development, you probably lean towards the buy solution where possible. But serverless has its own ways of making people opt for the build solution even when they think they’re buying.
I’ve spent some time interested in Simon Wardley’s FinDev and wanted to analyze my AWS billing data. I want to turn cost into a first-class metric of serverless applications, on par with how we treat function invocation duration and memory consumption. Furthermore, I want to assemble that data in a manner that lets me identify trends over time and help me make sense of unexpected changes. I had a few ideas on how I could potentially build this myself, but in the end, I chose to use CHAOSSEARCH to get quick answers to my questions.
But let’s go back to the beginning...
When you are presented with solving a business problem, before you begin work on solving a technical problem, you have a choice between build or buy. But realistically, your options aren’t so black and white. They’re more of a combination of the two, with one being the main approach.
If you plan on primarily building a solution, you’re tasking an engineer or team of engineers to spend time:
Once the solution is delivered, your organization owns that solution entirely and is responsible for its operation as well as further development.
If you decide to buy, then you’re tasking engineers with:
The assessment process involves understanding how completely each product solves a problem as well as how each fits within budget constraints. Once a product is purchased, an engineering team owns the last mile of integrating the product into the environment.
It’s easy to see the cost of buying a solution on paper. The product has a cost and becomes a line item. The cost of implementing the product is much harder to see. The cost of building doesn’t stop at the number of hosts required to run a given solution. Every hour that engineers spend on understanding a problem domain and building a solution is money spent. You have to spend that money of course — but the bigger question is whether you spent the money wisely on having engineers producing something of value. In that same way, free software isn’t entirely free. Using free software means you now own that code and are required to maintain it.
How do you go about deciding whether to build or buy? These factors should be a part of your decision-making process:
None of these ideas are new. They are the basics of the traditional build vs. buy argument that we’ve dealt with for years, particularly with the emergence of SaaS.
But, the question of problem uniqueness combined with the emergence of serverless architecture will now impact your decision making.
Let’s start by defining what the word serverless means for our purposes:
Serverless is a cloud architecture that involves no servers, VMs, or containers to manage. A serverless solution is something typically constructed through the combination of managed services from a cloud provider, which may include a functions-as-a-service (FaaS) platform combined with other services for data storage, messages, queueing, and more.
The focus on unique problems, as mentioned previously, is a familiar refrain in the serverless world. The value of serverless is not functions-as-a-service or event-driven architecture, it’s the clearer focus on unique problems and core value.
What are unique problems? They’re the things that make your organization what it is. They’re what make your company a ride sharing platform, mobile ad delivery network, analytics service, and so on.
Most companies’ unique problems and core value is not in running cloud infrastructure. This is just a byproduct of being a 21st-century organization. (In the 20th-century, electricity delivery evolved from being its own division on an org chart to being something that was just taken for granted.)
Organizations that fully grasp the serverless mentality get all this. By abstracting away problems associated with operating cloud infrastructure, problems everyone else has, they can spend more time focusing on their unique problems. They’ve gained time they can apply early in the solution delivery process for better understanding their issue and the variety of ways to solve it. There’s also time to be applied after delivery to measure your success at building a correct solution. From there, you can decide to continue building on that success or pivot to a different idea.
Serverless introduces a new wrinkle into the build vs. buy equation. It’s no longer a question of primarily building or buying — the options are now more complex.
The typical serverless approach is still heavily slanted towards building. Your cloud provider provides the ability to purchase the building blocks of a serverless solution. It’s up to you to assemble the final solution with your code. It’s therefore easy to find yourself thinking you are buying when in fact you are building.
In Part 2, I will highlight a recent example when I bought vs. built and why.