Build or Buy? How to Think About Assembling Software in the Cloud

It’s that eternal business dilemma: what do I build, and what do I buy? There have never been as many ways for software organization teams to build and assemble their most critical business applications, which is both exciting and confusing at the same time.

Forward-thinking software teams are taking a new approach these days, compared to how much older monolithic applications were constructed. This approach involves breaking apart complex functionality into small, dedicated services — often referred to as microservices.

Microservice applications might rely on a combination of homegrown code, open-source projects maintained by communities, or third-party managed services. This approach improves reliability by making it easier to identify and fix bad code in one microservice without having an adverse effect on other parts of the application, and makes it easier for applications to fail gracefully when they do run into problems.

Microservices also allows companies to spend one of their most precious assets — a software developer’s time — only on the components that are unique to their business or that differentiate them from the competition. It’s easier than it ever before to find the bits and pieces of your application that aren’t critical to your business and replace them with professionally built components managed by someone else.

But outsourcing these components brings its own risks: how do you know that a certain component — such as a billing system or a logging tool — is going to be around in a few years? Software developers know how to build software; that’s the default. But now that we can shop for software in addition to building it, you can be good at building software and bad at evaluating managed solutions.

If you’re under the gun to modernize an application and need to figure out the best microservices-inspired path forward, first consider the following questions:

• Which parts of your application are you spending way too much time operating?
• Which parts of your application can be replaced by a similar service from a best-in-class third-party service provider?
• Which projects keep getting pushed down your road map because other problems take precedence?

Once you’ve done this triage process, you should have a better understanding of which parts of your application are critical to your business, and which parts are necessary but require far more development time and ongoing management than makes sense.

Those mandatory-but-annoying parts likely make up most of your application, and they’re prime candidates for an external service. At many companies, when you’ve decided what parts of your application you’re going to get from outside your development team, the next steps play out in two ways: open source projects, or managed services.

Open source projects: Drawing from the breadth and depth of open source projects that can be used within applications is a fundamental component of building modern software, and this is a tempting approach for companies that know building a certain component isn’t the best use of their time yet want to avoid the fees associated with managed services. And there’s a growing business opportunity for companies built around open source projects that are heavily invested in providing quality services.

You’ll have to invest some time and effort if you want to take the open source plunge, because implementing and managing open source projects can be complicated. You’ll also want to live up to the spirit of open source development by contributing code that makes that project work in your environment, especially because creating a downstream fork of an open-source project means you’re solely responsible for ongoing maintenance. Look for projects that have active communities with frequent contributions.

This approach works best for components that aren’t the most critical parts of an application, but are still very important; the most critical parts of your application are likely best served by your own developers, who understand your specific needs or managed services with uptime guarantees. Investing in an open source project that helps you run your business appeals to an awful lot of current and potential employees, and could also help you unlock key insights about application performance and reliability.

Managed services: Sometimes it makes more sense for companies to completely outsource parts of their application to third-party providers. Larger, well-funded providers can provide some peace of mind that the component you need is going to be active and maintained for a long time, and in some cases, it’s more than worth it to pay for the convenience.

Another factor to consider: how much customization work are you going to have to do to get a managed service to work with your application? No managed service is truly plug and play; they all require some level of effort around evaluation and integration. But open source projects can be more difficult to implement without professional support, according to studies.

If your application has a lot of custom needs, you’re probably better of starting with an open source project, absorbing everything from that project you can while contributing the changes needed to make it work in your environment back to the community. If your application just needs the basics, a managed service provided by a trustworthy vendor is the best bet.

Once you’ve decided that a managed service is your best option, now comes the hard part. Before any external service touches your application, you’ll need to properly evaluate, price, and integrate that service.

Evaluation: Make sure you understand the problem you’re trying to solve well enough to evaluate the solution; if you don’t understand how the service in question will impact your workflow and business, it doesn’t really matter what you’re trying to compare or evaluate.

Are you looking to replace an important part of your application? Make sure the provider produced clearly written documentation that spells out exactly how the service works, and make sure you understand the support options that will be available to you as a customer. You might not need a strict service-level agreement for a less-critical part of your application, but you don’t want to be surprised by the terms should a costly outage occur.

The next part of the evaluation process involves actually playing around with the code in your application. Does the provider offer a sandbox environment, or a trial period? It’s best to get a feel for how the service was designed and developed, and how those choices will work with your application, before moving any further.

Pricing: Once you understand how the service will work with your application, you need to figure out how much this service will cost over time, especially as your application scales.

Services that charge by the API call can cause unpleasant surprises as customers hit preset limits, so understanding how overages work and how the provider offers billing alerts is another key step. It’s also important to understand how much it will cost to change your plan or implementation details if your business needs change; some managed services are far more complicated and expensive to move past than others, which means you’ll want to make sure such a service will meet your needs as your business grows and changes.

Integration: Once you’re satisfied with the features and the pricing plan, you’ll need to actually get the managed service up and running with your application, and this can be the trickiest part of the whole process. Developers and operations engineers need to be on the same page at this step, which means you’ll need to have an understanding of what will happen to the application if (and when) the service fails.

The basic dashboards provided by managed services might not be enough for your monitoring and observability needs, so understanding how the component fits in with the rest of your tools is also extremely important. Your integration testing process will need to be updated in line with the new managed service, which could introduce new problems that went undetected in the evaluation process.

Bottom line: Around 90% of the time, it makes much more sense to buy than build.

After all, that’s one reason why so many companies are moving to the cloud; managing hardware is expensive in both cost and time, and any of the Big Three cloud providers is most likely much, much better than your company at managing data center infrastructure.

The same is true for a lot of the software components you’ve traditionally used to build an application. What’s important to you today may not be important to you for very long, which means you might have to spend all that time and effort rebuilding and maintaining your own code. And some aspects of your business might change regularly, while others stay constant; understanding which components are which is a very important part of this overall process.

In 2019, your tech organization is likely responsible for driving innovation across your business. Innovation is all about speed, utility, and delivering value, and that’s really difficult to do when you’re sitting around trying to maintain all the tools that are built. External providers are going to push your company forward, because all they care about is delivering new value to their customers.

Even if you only wind up going through this process and coming to the understanding that you need to build your own components, you stand a much better chance of doing the right thing and understanding what it will cost. Software development teams have never had so much choice; embrace the process of understanding what to build and what to buy, and you’ll build better applications.

Feature image via Pixabay.