Expanding the Rent/Buy/Build Equation in AWS Serverless

When leading organizations are looking at a technical solution, there is a hierarchy by which solutions are evaluated. Renting is better than buying and buying is better than building. Over the years this approach has proven successful for both large and small organizations, as it tends to reduce the total cost of ownership (TCO) for the organization and allow the organization to focus on the aspects of business that are unique and provide a competitive advantage.

With the introduction of serverless technologies, a lot has changed… but a lot has stayed the same. Having contributed to and led teams that have rented hosted solutions, up purchased products, and built systems from scratch, I’ve experienced both the positives and negatives of the decision-making in this frame. This experience has led me to expand on the concept of Rent/Buy/Build to include Assemble. Below I’ll explain what I mean by Assemble and along the way will try to disprove a couple of myths on serverless technologies in relation to this equation.

What is Assemble?

One of the big changes in serverless technology is the concept that you don’t necessarily need to build all aspects of a system. In theory, you could build entire systems, such as video encoding and delivery, without a single piece of code in AWS or at least with very few lines. Services such as Amazon S3 can be uploaded to directly, and can natively integrate with Amazon Elastic Transcoder, which can result in complex video conversion without having to maintain code. While AWS has this capability, there is a key difference between it and setting up a SaaS contract with a fully fleshed-out solution.

Assemble refers to solutions that are fully managed but are composed of building block components, now seen in most cloud providers, which must be connected to generate the desired result. This distinction requires an adjustment to the evaluation of this option as it closely aligns with “Rent” but doesn’t fully match up in total cost of ownership (TCO). The managed aspect of it also positions it as more desirable than “Buy”, as upgrades, patching, and maintenance of the individual services usually come with very little cost.

Total Cost of Ownership (TCO)

When taking on “Assembly” the TCO will be impacted in a few ways. The chart below shows how an assembly model gains some of the value aspects of the “Rent” model but excludes some aspects of the “Buy” model. In the chart below, we’ll compare Up-Front Cost, Raw Service Expense, Monitoring, Support, Security, Disaster Recovery, and the Domain Knowledge Required. Most of these are easy to understand, but Domain Knowledge Required is one of the more nuanced aspects, and often is either implicitly considered or ignored to the detriment of the organization. To put it simply, if you build everything in your system, owned all the software and services then your team would have to have experience and education in close to 100% of your solution. On the other hand, if your team only needs to know the API, and how to get what they need from a service, then the domain knowledge of how to build, maintain and extend that service no longer has to live inside the team and the overall domain knowledge can drop substantially. An example of this is “Elastic Search”. To use elastic search your team doesn’t need to know how to build a search engine, maintain it, secure it, etc. This then allows your team to focus less on that part of the technology while still making it available for use.

Up Front Cost

This diagram also shows that there is an up-front cost associated with each of the systems. What’s interesting is where that up-front cost is spent. On systems that are rented or assembled, the upfront costs focus on the amount of work necessary to integrate that product into the rest of your organization’s ecosystem. This cost shouldn’t be discounted as it has the potential to exceed the cost of purchasing a product depending on what it is being integrated and how closely the systems align with each other. Purchasing a system does not make the integration effort go away, but quantifying integration effort is difficult to generalize as some systems need little to no integrations and others take a year to complete. Even if you rent a system, the costs around integrations do not completely go away. Systems evolve over time and depending on who you rent from, annual or biannual upgrades can cause integration development to be an ongoing major expense for your company.

One often missed cost of “Buy” is the cost of conforming to a less than ideal set of requirements when implementing in the cloud. This can have an annual cost in the tens of thousands of dollars due to things like restricting support to an MSSQL in Amazon RDS at a high cost per hour. As part of a company in the Financial Sector, we had a system that we could have modified to run using Amazon Aurora for less than $3K a month. The problem was that for our support agreement from the system provider, we had to run our system on MSSQL Enterprise Edition, knocking our AWS spend closer to $20K a month. This cost would get higher as we scaled the MSSQL server, which could run in the hundreds of thousands of dollars at scale.

Raw Service Expense

Raw Service Expense refers to how much it costs to host the system. In rented services, this relates to the annual expense around the service whereas the “Buy” and “Build” options refer to the cost of the infrastructure to host the service. In serverless, hosting most solutions will decrease the overall cost of raw expense, as services are charged only during use, making Assembling and Building more cost-effective in this category.

Monitoring

Ensuring your system is up and usable is extremely important. This is where renting through a SaaS offering becomes much more valuable. Service fluctuations and availability is being supported by an organization that specializes in the system you're using, so your organization can focus on other aspects. In all other approaches, you will incur this expense as your company will be responsible for the availability of the system. With serverless technologies, the odds of the system being unresponsive due to infrastructure is low, but error can cause serverless systems to get bogged down, so this is still important. In some Assembled systems there is already support for alerting built into the AWS Platform through Amazon CloudWatch Alarms and Rules or the services natively having these capabilities built in. This also helps with reducing this cost a bit.

Support

Support refers to who is responsible when the system goes down. Often with the “Rent” and “Assemble”, this is a shared responsibility that involves a third party for the system aspect, and local experts for content and data aspects. For “Buy” support agreements can be purchased, but over time support for a product can often be dropped from the supplier or the creator of the system goes out of business, resulting in your organization being fully responsible for the support of the product.

Security

Securing systems and data is becoming a much larger topic, as hackers are breaking into systems in a variety of ways including non-technical approaches using unsuspecting people. Security is important no matter which route you choose. With “Rent” and “Assemble” security follows a shared model shared responsibility model. With “Buy” and “Build” the security burden is more on your organization.

Disaster Recovery

Having a significant event in a region that brings down your ability to do business is always a risk. More and more AWS has systems like AWS Backup, which can backup Amazon RDS Databases, Amazon S3, Amazon EBS Volumes, Amazon DynamoDB, etc. This and other tools make some forms of disaster recovery much easier and more cost-effective. In the “Rent” option, disaster recovery is partially owned by the service provider in a SaaS solution, but part of disaster recovery can fall on your organization’s plate. In some cases, security measures by your SaaS provider can thwart a quick cutover in the event of a disaster. This means that even in “Rent” making designs for disaster recovery is important.

Domain Knowledge

Domain Knowledge refers to the amount of information around system design, business-related knowledge, and various other aspects. In all cases, your organization will have to maintain some level of domain knowledge, but the inner working of how a system works through “Rent”, “Assemble” and “Buy” help offset detailed domain knowledge in exchange for broad domain knowledge related to your business. This broad domain knowledge can relate to internal processes, business differentiators, and custom integrations. What’s interesting here is that in both “Rent” and “Assemble” the domain knowledge is going to remain roughly the same, as your business will need to understand its overall processes and integrations to make the “Rent” or “Assemble” solution work to your business needs.

How does this relate to serverless?

Serverless systems typically use an “Assemble” approach, rather than a “Build” approach. This difference, which I outline in “7 Guiding Principles of Serverless Systems”, allows serverless systems to be written with less code and higher capabilities while also reducing the operational costs. In some cases, where the existing services are available and align with your company’s goals, these systems can be easy to build and inexpensive to maintain. Other times, when services don’t fully align, the cost of these systems can increase to a point where the “Buy” approach is more prudent. Evaluating the upfront effort and the category of that effort, integrations vs. business customizations vs. industry-specific processes, can help you better understand the “Rent”/”Assemble”/”Buy”/”Build” equation.