Build vs buy conversations often start with cost. Specifically, “Can we build and maintain this in-house for less than a vendor wants to charge?” And that’s a pretty good opener. In fact, we’ll tackle that in the next post in this series.
But as we saw in our previous installment, building your own realtime experience infrastructure is complex. Comparing costs makes little sense if you haven’t already considered the risk that this complexity brings. That’s because increased risk usually leads to increased costs.
What makes delivering realtime experiences high risk?
Build vs buy typically comes down to four key questions:
- Does your team have the capacity and the expertise to build it?
- Can you accurately anticipate the functionality you’ll need at launch and then as user needs change?
- What is the opportunity cost of building rather than buying?
- Do you have the capacity and the expertise to maintain it in production?
For realtime projects, the risks behind these questions are particularly stark. That’s because realtime is complex, requiring specialized engineering expertise. Often, engineering teams discover the full depth of the challenge only once they are part way through, leading to budget and deadline overruns that impact on the ability to deliver core functionality.
And for those teams that do deliver, operating realtime infrastructure is fraught with downtime and service degradation.
This isn’t to discredit software engineers but rather to emphasize the high risk of building realtime infrastructure in-house. Time and again, engineering teams set out with great confidence when building a realtime solution. But then requirements become more complex, new features get grafted on, and suddenly the whole thing falls over.
Delivering realtime at scale is complex
Experienced software developers can turn their hands to most engineering problems, given enough time. But the word “realtime” sets unusually high expectations. End users now see flawless, instant delivery of data as a must have, while product teams are doubling down on that expectation by building products with realtime as a core feature.
The margin for error is razor thin. And that leads to two potential hazards:
- High expectations and low experience reduce your engineering team’s ability to deliver the software side on time and to the quality needed.
- The ops complexity of managing realtime infrastructure leads to outages and technical debt as demand increases.
According to our report on the state of serverless WebSocket infrastructure, 38% of engineering decision makers reported that their in-house realtime infrastructure proved too complex to use or update. Perhaps more starkly, 65% of DIY solutions had significant downtime in the preceding 12-18 months.
Building realtime infrastructure takes time away from other work
That combination of high expectations and the fundamental complexity of the problem means that building realtime infrastructure takes time.
According to our survey data, nearly 93% of such self-build projects had an engineering headcount of up to ten people. Almost 70% took three months to build and 20% took six months. In some cases, teams had to increase headcount to more than ten in order to keep the project under six months.
The financial cost is clear but so is the opportunity cost. Time spent building a home grown realtime solution is time that could be spent delivering the core functionality of the product. In our survey, 55% of respondents said they’d switched to a PaaS solution so that they could redeploy engineers to that core product functionality.
It’s easy to underestimate cost and resource requirements
No one goes into a realtime infrastructure project expecting it to be easy. But it seems that many engineering leaders and program managers do underestimate just how hard it can be.
The data in our State of Serverless Websocket Infrastructure report shows that teams building their own realtime infrastructure tend to miss deadlines, need to add more engineers part way through, and overshoot on costs. More than half of projects required more engineers and more time than originally forecast. Just under half of survey respondents described the cost of their project as a major challenge.
In the worst cases, 16% of projects took up to six months longer than planned and needed as many as three additional engineers.
Once delivered, self-builds are prone to outages
Many teams choose to self-build because they believe that they can meet their specific needs better than a third-party solution. But a consistent theme of self-build realtime infrastructure is that it fails to meet expectations.
The name realtime sets a bar for both reliability and timeliness. Each item of data must be delivered instantly every second of every day.
But as mentioned earlier, close to two thirds of respondents to our survey said that their DIY realtime solution had experienced an outage or significant downtime in the 12-18 months prior. That’s downtime that impacted core infrastructure, often taking products out of service.
To satisfy expectations–––global replication that just works, automatic failsafes to route around issues, messages delivered exactly once, and more–––takes specialized architectural, engineering, and operational expertise. And even if your organization has that expertise in-house, directing those people towards delivering competitive features will give you a greater return on your investment when compared to building and maintaining the infrastructure to power them.
Reduce the risk of delivering realtime experiences with a PaaS provider
While building in-house can be tempting, the risk is that your self build realtime project will be late, cost more than expected, distract from core functionality, and perform poorly once delivered.
Choosing a realtime PaaS provider instead reduces risk in three ways:
- Integration with the PaaS is a relatively simple engineering task.
- Ongoing costs are known.
- Reliability is in the hands of dedicated specialists.
Of the survey’s respondents, 56% reported that risk reduction was their top motivation for moving to a realtime PaaS, while 55% said that redeploying engineers to more productive work as a critical factor.
Choosing Ably’s realtime PaaS lets you minimize the risk of integrating realtime infrastructure into your products. With Ably, you get the functionality and operational stability you need to deliver at scale. Specifically:
- 100% guaranteed message delivery and onwards processing
- 5x9s (99.999% uptime SLA)
- <65ms median global latencies ensures consistent user experience
- Millions simultaneous incoming new connections absorb per minute
That’s why companies including Hubspot and Toyota have chosen to implement realtime experience infrastructure at scale with Ably. Discover if Ably is the realtime PaaS to power your business critical experiences by signing up for free today.
In case you haven’t read it yet, check out the first article of this blog series, where we talk about the different types of realtime experience use cases, and the capabilities needed to deliver them.
Coming soon: Part four, where we will see how to reduce the cost of delivering realtime experiences.
