Infrastructure and Business Logic in Serverless: Exploring the Relationship

Achieving the right balance is key

Last week, we discussed how serverless has made infrastructure development more feasible and has given developers more control. 

This week, I want to discuss the relationship between infrastructure and business logic in serverless architectures.

Photo by Eran Menashri on Unsplash

Yan Cui and Jeremy Daly (two serverless legends from whom I have learnt much), have recently written about this topic from different perspectives.

Yan Cui argues that infrastructure and business logic are not separate entities. He believes that the choice of infrastructure is inevitably based on business requirements rather than being down to engineering/architectural "taste". In his article, Yan quotes Ben Kehoe from a conversation the two of them had:

choosing one service (SQS) over another (SNS) is down to business requirements, as are the authorization decisions in your application. This angle of looking at serverless architectures really blurs the line between infrastructure and business logic. 

Jeremy Daly, on the other hand, believes that infrastructure is really just an implementation detail. In an ideal world, the focus of developers should be on the application logic and business value. This is of course a sentiment that everyone who understands serverless will wholeheartedly agree with. So the real difference is in how Jeremy defines business value here:

Choosing SQS over SNS is not a business decision, it's an architectural one. Choosing the behavioral semantics of how events get delivered, retried, and handled if they fail is the business decision

Finding the Right Balance

I agree with Yan Cui that infrastructure and business logic are not separate entities. However, I also agree with Jeremy Daly that there is value in automating and hiding (i.e. abstracting) away as much infrastructure as is reasonably possible.

And this is where the conversation gets interesting. 

Undoubtedly, a major reason for serverless is how much infrastructural complexity it takes off our plate. But, teams and companies can get anxious about giving away too much control (this concern may or may not always be warranted, but we can acknowledge it as a reality).

So, the question that naturally arises is: how much control should be given away (let's say, to a cloud provider), and how important is it to keep some control for ourselves?

The Sweet Spot

I believe that serverless offers a sweet spot between simplicity and control. 

On the one hand, the infrastructure is simple enough that developers can understand it and make informed decisions about it. On the other hand, you have enough control over this infrastructure that allows teams and companies to meet their specific business requirements.

https://twitter.com/MarcoTroisi/status/1679076461657968640

The comparison between serverless and more complex infrastructure choices (e.g. Kubernetes) is a classic, textbook one. Clearly enough, serverless reduces the amount of complexity to the extent that developers can own their infrastructure without delegating to "experts".

But there is probably a danger in going too far to the other side. Too much abstraction can lead to a loss of control. If the infrastructure is too abstracted, developers may not be able to understand how it works or make changes to it as needed. This can lead to problems down the road.

Where Do We Land?

The relationship between infrastructure and business logic in serverless architectures is a complex one. There is no one-size-fits-all answer. The best approach will vary depending on the specific application and business requirements. 

However, I believe that it is important to find a balance between simplicity and control in order to create a scalable, resilient, and secure architecture. 

Serverless as we currently understand it fulfils that requirement, which makes it an ideal (dare I say, default) choice for most teams and especially startups. 

Given very specific (dare I say, atypical) requirements, some teams may decide that they, in fact, need more control. In other contexts (e.g. a very small application) one may decide that using serverless adds too much complexity, and that's where things like Heroku, WordPress, Wix, etc may well be valid options.

Additional Thoughts

• I think it is important to remember that infrastructure is not just about the underlying hardware and software. It also includes the policies, procedures, and tools that are used to manage it.

• Serverless architectures can make it easier to manage infrastructure, but it is still important to have a clear understanding of how it works.

• A great way to learn about serverless infrastructure is to experiment with it. There are many resources available online (free or otherwise).