Should you build or buy microservices?
Tags: microservices
Published: 2018-08-01 21:24:44

---
title: Should you build or buy microservices?
published: true
description: Many developers want to build a microservice because they can, but should they? This article looks at the costs of building versus buying to help CTOs make thoughtful decisions
tags: microservices
---
<div class="post-body">

<span style="font-weight: 400;">As our previous chapters illustrate, there’s a lot to consider when it comes to investing in a microservice architecture, from the</span> [<span style="font-weight: 400;">culture inside your camp</span>](https://buttercms.com/books/microservices-for-startups/designing-a-successful-microservices-engineering-culture) <span style="font-weight: 400;">to the</span> [<span style="font-weight: 400;">microservice testing strategies</span>](https://buttercms.com/books/microservices-for-startups/five-microservice-testing-strategies-for-startups) <span style="font-weight: 400;">to adopt. Another consideration, so fundamental that it’s easy to overlook, is not whether you</span> **_can_** <span style="font-weight: 400;">build a microservice but whether you</span> **_should_** <span style="font-weight: 400;">from a business perspective. In short:</span>

**Should you build that microservice or buy it?**

<span style="font-weight: 400;">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.</span>

## <span style="font-weight: 400;">Build vs buy: the traditional framework for decision-making</span><span style="font-weight: 400;"></span>

<span style="font-weight: 400;">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?</span><span style="font-weight: 400;"></span>

<span style="font-weight: 400;">For most developers, the urge to build is overwhelming. I’m as guilty of this as anyone.</span>

<span style="font-weight: 400;"></span><span style="font-weight: 400;">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.</span><span style="font-weight: 400;"></span>

<span style="font-weight: 400;">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.</span>

<span style="font-weight: 400;">And here’s the thing, in some cases, those stubborn developers are actually right. They</span> _<span style="font-weight: 400;">could</span> _<span style="font-weight: 400;">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.</span><span style="font-weight: 400;"></span>

<span style="font-weight: 400;">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.</span>

## <span style="font-weight: 400;">Factors to consider when building microservices</span><span style="font-weight: 400;"></span>

<span style="font-weight: 400;">If you do decide to build microservices from scratch, there are costs involved that you’ll need to consider before taking the plunge.</span>

### <span style="font-weight: 400;">Development costs</span><span style="font-weight: 400;"></span>

<span style="font-weight: 400;">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.</span><span style="font-weight: 400;"></span>

<span style="font-weight: 400;">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.</span>

<figure class="image align-center">![](https://cdn.buttercms.com/C7fPZDoQzOaVNjfUplvd)

<figcaption><span style="font-weight: 400;">Source: https://baremetrics.com/startup-calculator</span></figcaption>

</figure>

<span style="font-weight: 400;"></span>

<span style="font-weight: 400;">Also consider the issue we of</span> [<span style="font-weight: 400;">how much technological freedom to give</span>](https://buttercms.com/books/microservices-for-startups/designing-a-successful-microservices-engineering-culture) <span style="font-weight: 400;">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.</span>

### <span style="font-weight: 400;">Maintenance costs</span>

<span style="font-weight: 400;">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.</span>

<span style="font-weight: 400;">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.</span>

<span style="font-weight: 400;">But following through on these responsibilities is a case of whether there is enough capacity to do so. According to</span> [<span style="font-weight: 400;">Galrath</span>](http://galorath.com/software_maintenance_cost)<span style="font-weight: 400;">, 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.</span>

<span style="font-weight: 400;">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?</span>

<figure class="image align-center">![](https://cdn.buttercms.com/dWFDQ1rgRq2a3JAtjdok)

<figcaption><span style="font-weight: 400;">Source: https://baremetrics.com/startup-calculator</span></figcaption>

</figure>

### <span style="font-weight: 400;">Scaling Costs</span>

<span style="font-weight: 400;">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.</span>

### <span style="font-weight: 400;">Slower time-to-market</span>

<span style="font-weight: 400;">Putting the dollar costs of having your team build it aside, let’s consider the reputational cost of building instead of buying.</span>

<span style="font-weight: 400;">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.</span>

<span style="font-weight: 400;">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?</span>

### <span style="font-weight: 400;">Reputational costs</span>

<span style="font-weight: 400;">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.</span>

## <span style="font-weight: 400;">Factors to consider when buying microservices</span>

<span style="font-weight: 400;">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:</span>

### <span style="font-weight: 400;">Vendor reputation</span><span style="font-weight: 400;">  
</span>

<span style="font-weight: 400;">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.</span>

<span style="font-weight: 400;">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.</span>

### <span style="font-weight: 400;">Support</span>

<span style="font-weight: 400;">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.</span>

### <span style="font-weight: 400;">Integrations</span>

<span style="font-weight: 400;">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.</span>

## <span style="font-weight: 400;">When it Makes Sense to Build</span>

<span style="font-weight: 400;">There are two scenarios when opting to build is the best solution.</span>

<span style="font-weight: 400;">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.</span>

<span style="font-weight: 400;">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.</span>

## <span style="font-weight: 400;">When it Makes Sense to Buy</span>

<span style="font-weight: 400;">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.</span>

<span style="font-weight: 400;">It’s also wiser to buy if you find a quality third-party service or API that can add functionality to your product.</span>

<span style="font-weight: 400;">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.”</span>

## <span style="font-weight: 400;">The Market is Revealing</span>

<span style="font-weight: 400;">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.</span>

<span style="font-weight: 400;">But don’t take my word for it. The 2018</span> [<span style="font-weight: 400;">MarTech Supergraphic</span>](https://chiefmartec.com/2018/04/marketing-technology-landscape-supergraphic-2018/) <span style="font-weight: 400;">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.</span>

<span style="font-weight: 400;">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](https://buttercms.com/blog/omnichannel-customer-experience), a CMS is never what sets you apart from your competition.</span>

<span style="font-weight: 400;">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</span> [<span style="font-weight: 400;">content as a microservice</span>](https://buttercms.com/blog/buttercms-vs-wordpress-headless-cms-vs-traditional-cms) <span style="font-weight: 400;">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.</span>

<span style="font-weight: 400;">For other examples we can look to companies featured in this book including</span> [<span style="font-weight: 400;">Algolia</span>](https://www.algolia.com/) <span style="font-weight: 400;">for search,</span> [<span style="font-weight: 400;">Scalyr</span>](https://www.scalyr.com/) <span style="font-weight: 400;">and</span> [<span style="font-weight: 400;">Sumo Logic</span>](https://www.sumologic.com/) <span style="font-weight: 400;">for log management,</span> [<span style="font-weight: 400;">Pusher</span>](https://pusher.com/) <span style="font-weight: 400;">and</span> [<span style="font-weight: 400;">PubNub</span>](https://www.pubnub.com/) <span style="font-weight: 400;">for real-time data streaming, etc.</span>

## <span style="font-weight: 400;">Reinventing the Wheel is Never Cost Effective</span>

<span style="font-weight: 400;">To recap, let’s quickly revist the two scenarios where building is better, and the three scenarios where buying microservices makes more sense:</span>

### <span style="font-weight: 400;">Build microservices when</span>

1.  <span style="font-weight: 400;">The microservices make up the core functionality of your product, service, or organization, and are therefore a key differentiator for your business</span><span style="font-weight: 400;"></span>
2.  <span style="font-weight: 400;">You are unable to find a product in the market that meets your needs</span>

### <span style="font-weight: 400;">Buy microservices when</span>

1.  <span style="font-weight: 400;">The functionality you need is not part of your product’s core, and is therefore not a key differentiator in the market</span><span style="font-weight: 400;">  
    </span>
2.  <span style="font-weight: 400;">You find a quality third-party service or API that can add functionality and depth to your product or service</span><span style="font-weight: 400;">  
    </span>
3.  <span style="font-weight: 400;">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</span>

<span style="font-weight: 400;">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.</span>

<span style="font-weight: 400;">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:</span>

<figure class="image align-center">![](https://cdn.buttercms.com/dwJJBJeVSoGKutu0Yx3d)

<figcaption><span style="font-weight: 400;">Source: https://baremetrics.com/startup-calculator</span></figcaption>

</figure>

<span style="font-weight: 400;"></span>

<span style="font-weight: 400;">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</span> _<span style="font-weight: 400;">prove</span>_ <span style="font-weight: 400;">we can build it.</span>

_<span style="font-weight: 400;">Thanks to the following individuals for their contributions to this chapter: <span> </span>[Ben Curtis](https://twitter.com/stympy?lang=en),<span> </span>[Stephen Blum](https://twitter.com/stephenlb?lang=en),<span> </span>[Darby Frey](https://twitter.com/darbyfrey),<span> </span>[Christian Beedgen](https://twitter.com/raychaser),<span> </span>[Stefan Zier](https://twitter.com/stefanzier), [Isaac Mosquera](https://twitter.com/imosquera), [Chris McFadden](https://twitter.com/cristoirmac), [Sam Stagg](https://twitter.com/swstagg), and<span> </span>[Sierra Sterling](http://www.linkedin.com/in/sierrasterling). [](https://twitter.com/stympy?lang=en)</span>_<span style="font-weight: 400;"></span>

<div class="chapter-cta well">