Serverless & SaaS — Part 1: The New Build Versus Buy

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...

Build vs. Buy

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.

• Primarily build: Build using a combination of proprietary code, open source.
• Primarily buy: Buy SaaS and cloud provider services and build only the last mile of solution integration.

If you plan on primarily building a solution, you’re tasking an engineer or team of engineers to spend time:
 

• understanding the problem to be solved
• the problem domain
• architecting a solution
• building the given solution (typically through a combination of internally developed code and free open source software)

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:

• understanding the problem to be solved and then finding and assessing products

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.

Decision-Making Process

How do you go about deciding whether to build or buy? These factors should be a part of your decision-making process:

• Problem scope: How big is the problem you’re trying to solve? Is this problem going to require deep expertise in the space? And how long will an appropriate solution take?
• Available resources: Do you have the expertise in-house, or can you at least develop that expertise, around both the problem domain and solution space?
• Budget: What is the cost of outright buying versus building a solution? And while engineering time costs money, you’re going to spend it anyways.
• Problem uniqueness: Is this problem unique to your organization or is this something everyone struggles with? Is your time better spent solving a problem everyone else has to solve or should you focus your efforts on solving problems that are unique to you and your organization?

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.

Enter Serverless

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.

What Makes Serverless Different?

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.

• Build: Build using a combination of proprietary code, open source.
• Combination build plus buy: Buy cloud managed services, build proprietary code to glue together and fill in missing functionality.
• Buy: Buy SaaS and cloud provider services and build only the last mile of solution integration.

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.