Should you build or buy microservices?

As our previous chapters illustrate, there’s a lot to consider when it comes to investing in a microservice architecture, from the culture inside your camp to the microservice testing strategies to adopt. Another consideration, so fundamental that it’s easy to overlook, is not whether you can build a microservice but whether you should from a business perspective. In short:

Should you build that microservice or buy it?

Because this is a decision that heavily involves all company stakeholders, I’ve penned this chapter for CTOs who aren’t just leading a team of engineers toward their technical vision but for those who also interface with the rest of the business. It’s a multi-faceted question, so let’s dive in.

Build vs buy: the traditional framework for decision-making

During the initial phase of designing a microservice architecture, you will identify the different components and functionalities required for the success of your project. Some of these components will have their own individual life cycles and will evolve at different speeds, while others will remain largely untouched. During this process, you’ll have to make a choice: build, or buy?

For most developers, the urge to build is overwhelming. I’m as guilty of this as anyone.

We take great pride in our ability to plow through complex obstacles and projects. We can code our way out of anything, we just need a little more time. So when the prospect of buying infrastructure comes up, the typical developer scoffs.

Statements like, “Whatever, I can build that in a couple of weeks, tops!” and, “Why pay that much, when I can build it myself?” are regularly thrown around the office.

And here’s the thing, in some cases, those stubborn developers are actually right. They could build a solid solution from scratch. But at other times, they might overestimate their own capabilities, or the time it will take, or the costs it will incur. For example, a talented set of developers might build a microservice during a weekend hackathon, but they might end up spending a month or so finalizing it. It’s like a slightly modified Dunning-Kruger effect: you have a talented team, but they may have trouble objectively determining the cost (in time and dollars) of building something from scratch.

Even if your team of developers can build the microservice architecture, you have to think about the bigger picture and foresee whether building or buying can help your business deliver value to your customer both efficiently and prudently.

Factors to consider when building microservices

If you do decide to build microservices from scratch, there are costs involved that you’ll need to consider before taking the plunge.

Development costs

As a CTO, you know developers aren’t cheap and dev costs can quickly add up. You need to commit developers to create and test the new microservice. You’ll also need to factor in the possibility of the development time taking longer than originally anticipated. Whatever effort is estimated, add a 2-3x fudge factor.

For example, let’s say your team of 3 engineers, who all make $100,000 / year,  estimates it will take 2 weeks to build a new microservice. In reality before it’s production ready, when all said and done, let’s say it takes 4 weeks (2x fudge factor). That’s going to cost $23,000 in development time to build that microservice.

Also consider the issue we of how much technological freedom to give when building new microservices. If you allowed one developer, who was skilled in a bleed edge framework to single handedly build the new service, and they leave. That will lead to some real costs in headaches in terms of solving that knowledge gap.

Maintenance costs

Once your team has created the microservice, now it’s your baby. It’s your responsibility to look after it and maintain it. As with any software, you’ll need to resolve any bugs and issues that arise.

Besides maintaining the system, it is also your team’s responsibility to add any necessary improvements as and when required. If your service executes a marketing function, the marketing team will want to have specific features added onto the service so they are able to carry out their objectives.

But following through on these responsibilities is a case of whether there is enough capacity to do so. According to Galrath, software maintenance makes up 75 percent of the total cost of ownership, which means a large proportion of your developers’ time is taken up looking after the service.

Continuing with the example above, let’s conservatively assume that your team will spend 1 day per month maintaining (bug fixes) and improving (new features) this microservice. How does that look cost wise?

Scaling Costs

As your business grows, your microservices will face more demand and will need to scale up over time. V1 of your microservice may have worked well when you had 100 customers but what happens when you have 1,000 or 10,000 customers?  Your microservices will need to scale to meet that demand which means at minimum DevOps time figuring out how to horizontally scale.

Slower time-to-market

Putting the dollar costs of having your team build it aside, let’s consider the reputational cost of building instead of buying.

First off, building your microservice architecture from scratch entails a slower time to market. Slower time to market means a later launch date of your product or service — which in turn postpones any revenue coming in.

Worse yet, your brand itself may suffer as competitors reach your target market more swiftly, leaving you at a disadvantage in the market — when you eventually get there.  If it isn't part of your core functionality, why are you spending your time doing it when you can just buy it?

Reputational costs

Let’s be frank, building out new capability — particularly when you’re trying to do it on a budget and within a strict time frame — can be difficult. Worse, despite how hard your team works on it, if in the end it functions like a product of a rushed timeline, it’s a bad look for your company. If it doesn’t work or isn’t polished, customers don’t care how many late nights were spent building it.

Factors to consider when buying microservices

Buying helps you leap-frog most, if not all, of the negative factors associated with building microservices. Yet, there’s still a lot to consider before deciding to buy capability over building:

Vendor reputation

There are many tools and products that are readily available for you to plug straight into your stack. But in an ideal world, you want something that has been tried-and-tested and has an established reputation.

A good way to confirm the reliability of a service is via social proof. Look out for testimonials, reviews, ratings and recommendations. The more positive and authentic the social proofing, then you know it is a reliable service.

Support

If anything were to go wrong with the service, you want to make sure you can readily access support if anything were to happen. It’s also wise to see if the support is readily accessible. Check to see if the service provides supports through web chat, email or phone. Ideally, you want something that has 24/7 emergency support.

Integrations

You want a service that can easily plug into your stack. Check for compatibility when shopping around for microservices. You should also look for something that will be, to the extent possible, be future proof as the technology landscape evolves.

When it Makes Sense to Build

There are two scenarios when opting to build is the best solution.

The first is if your microservices make up the core functionality of your organization and are the key differentiator for your business. When it comes to technology, keeping the core of your product or service proprietary is always preferred.

Secondly, it makes more sense to build if you are simply unable to find a product in the market that suits your needs. That’s rare in today’s market, but not impossible.

When it Makes Sense to Buy

If the functionality you need is not part of your product’s core, and is therefore not a key differentiator in the marker — like authentication or content management software for example — it makes a whole lot more sense to buy. That’s especially true if you come across a high-quality vendor that can easily integrate with your existing stack.

It’s also wiser to buy if you find a quality third-party service or API that can add functionality to your product.

Finally, perfect is the enemy of good enough. Not every dimension of your company needs perfectly bespoke functionality — sometimes, it’s better to get something off the shelf that does a good job, rather than spending time and money on trying to build something “perfect.”

The Market is Revealing

There’s a booming market out there for APIs and SaaS products right now, because they work. They plug the gap that stubborn developers try to fill with good intentions, talent — and unfortunately for the company — a whole lot of time and money.

But don’t take my word for it. The 2018 MarTech Supergraphic documents 6,829 marketing technology solutions, an increase of 27 percent from the previous year. It’s clear that there’s a growing demand from companies looking to buy rather than build — especially when it comes to technologies that aren’t key differentiators.

A CMS is the perfect example of a microservice (or set of microservices) that is not a differentiator for most businesses. It’s an internal tool used to help you create, manage and publish content, so although it impacts the customer experience, a CMS is never what sets you apart from your competition.

Thus, a CMS is the right kind of technology to buy, rather than build, especially if you can find a CMS that serves a purpose today, as well as tomorrow. ButterCMS, for example, is a headless CMS that enables brands to use content as a microservice by decoupling content from the front-end delivery layer. Moreover, since ButterCMS is SaaS and leverages CDNs and APIs so that as your customers and traffic grow, all of the content scaling is handled for you.

For other examples we can look to companies featured in this book including Algolia for search, Scalyr and Sumo Logic for log management, Pusher and PubNub for real-time data streaming, etc.

Reinventing the Wheel is Never Cost Effective

To recap, let’s quickly revist the two scenarios where building is better, and the three scenarios where buying microservices makes more sense:

Build microservices when

1. The microservices make up the core functionality of your product, service, or organization, and are therefore a key differentiator for your business
2. You are unable to find a product in the market that meets your needs

Buy microservices when

1. The functionality you need is not part of your product’s core, and is therefore not a key differentiator in the market
   
2. You find a quality third-party service or API that can add functionality and depth to your product or service
   
3. You want to escape the chase for perfection, and need a solution that gets the job done today, rather than an abstract “perfect” idea that will take months to build and maintain

Although technical ability plays a role in this decision, it really comes down to cost and efficiency and letting your team focus on what your company does best and letting others handle the stuff you aren’t excited about.

Going back to our earlier build economics example, let’s assume you found a SaaS service that costs $200/month that you’re considering buying as an alternative to building it yourself.  Admittedly, if you’re a startup, $200/month is enough to pause and thinking about as it seems like a lot of money. Let’s see how it compares to building:

When you boil it down, and look at the real costs in the macro, the question of build versus buy can be straightforward. As CTOs, we need to always take a strategic view of what’s best for the business, even if deep down our inner software developer (and/or our team) is chomping at the bit to prove we can build it.

Thanks to the following individuals for their contributions to this chapter:  Ben Curtis, Stephen Blum, Darby Frey, Christian Beedgen, Stefan Zier, Isaac Mosquera, Chris McFadden, Sam Stagg, and Sierra Sterling.