I’ve been into AWS Lambda, but this thing is a useless toothpick after busting some ribs due to their performance limitations.

I came to the conclusion that if your design fits the serverless approach, then you got a fine-grained microservice architecture and this whole post will elaborate how and why.

Some would say this post will hijack your prefrontal cortex. I say it will UPGRADE your architecture design skills.

Coarse-grained design

yes, since a serverless design will not allow you going wild toward your monolith suicidal tendencies which you have adopted in the last decade.

1. No Chatty Apps: with Azure Function, being the building unit of a serverless design, you will come to conclusion pretty fast that forward-backward chit chat between functions is pretty complicated to implement: on each direction you need to trigger a bind(Http request for example).

2. Loosely Coupled: Say your design is built of 3 services, one receives the order and place them into a Queue, the second pick the orders and reserves items from the inventory, the third draw the money from the account and send it to the user, last one prepares a receipt and email it to the user, as you can see, if you have to deploy a change for one component, the rest won’t be affected.

3. Bounded Context: Wise men said that a giant turtle was carrying the world. when they were asked about what’s carrying that giant turtle, the answer was all the way down. This is the case with the colorful rectangles from the sketch above. you can split them to more functions to fill your requirements. but these rectangles are the bounded context that isolates different components from each other.

Function State

You can whether build stateless or stateful functions. With a stateful function app, the state is maintained in a relational database which is partitioned into three more databases for scaling out purposes(Durable functions).

Function Plan

The plan is an important factor to determine your computing capability. it is the infrastructure that will host the Function app.

Consumption plan

useful for small apps or prototyping. the function will run up to 10 minutes, scaling out will reach up to 200 function app instances where a 1.5GB of RAM will be dedicated to each instance. The maximum number of concurrent connections is 300 per instance.

App Service Plan

This is the resource provider which inject the steroid into the Function app. App Service enables you to scale out VMs from Standard to Premium, up to 100+ VM Instances.

Security and Compliance

This is what I LOVE about the Service App, you don’t need to deal with all the VM Configurations, like assigning a KeyVault to store the passwords and rotating them, configuring a firewall, DNS, ports,…For the Admin, The Function App infrastructure is a black box with superpowers.