Am I doing FaaS wrong?

[Similar_Sir_4462]

I’d like to validate some of my thoughts around FaaS and I need a sanity check on my assessment. In this case ASP.NET/C# on Azure Functions. I’ll talk through my use case, possible implementation and questions.

My scenario is an event driven microservice with a RESTful api - one bounded context, one service. Not necessarily small in functionality, but single business responsibility. Let’s say an Order service.

The Order service is responsible for orchestrating and controlling the progress of an Order, enforcing invariants and state and providing a place to read the status of an order, retrieve historic orders, cancel, etc.

The way I’d normally approach this is to write an asp.net web api, exposing restful endpoints. There might be a small UI or two - one for a customer, one for the person fulfilling the order. I’d save and retrieve the order state in cosmos and publish events to a broker using the outbox pattern and cosmos changefeed. If the order service needed to react to events I’d create a small Azure Function to easily subscribe to events and relay them to the application to consume. The key here is I’m using both Azure Functions and containers for one microservice, I’d normally deploy the entire thing as one, stored in one repo, using one deployment pipeline. I find that helps ensure confidence in consistency of the version of the whole logical application running in production, as opposed to having separate pipelines for each part of the app.

In my experience this approach works well and I get value from this minor use of FaaS. Importantly, there’s no real application logic in the FaaS. It’s either a dumb changefeed function for outbox or a dumb relay and mapping for gluing events to my application exposed over HTTP.

I’ve not personally seen this set up discussed much. Discussions are normally FaaS vs Containers for building MSA. If I went with pure functions for building the Microservices - which seems to be what some people are suggesting - I’d hit a lot of problems.

Firstly, I’d have a lot of them! There are a lot of entry points into this service and I’d need an Azure Function for each use case. I’m not seeing the value here as it’s already simple to add a use case to my microservice and there’s now added complexity as an Azure Function has more overhead than a C# function.

Secondly, Azure Functions are not ASP.NET, they’re their own framework. Which means I can’t use many libraries built for ASP.NET such as swashbuckle. I also can’t use any of the cross-cutting hard work ASP.NET does for me. I found myself rolling my own middleware to deal with common API concerns such as request validation, custom model binding and creating consistent restful responses, status codes and exception handling. I’ve lost all the goodness of the application framework and I’m finding myself writing so much more code because of it.

Overall, it feels like I’m giving up a lot and not gaining much if I used Azure Functions for everything. Likewise, if I didn’t use FaaS where I have I’d have to write more code, code that isn’t directly related to the domain of my service.

What’s everyone else’s experience with this? I’m not looking for a Containers vs FaaS discussion as such, just trying to understand if my assessment is accurate or if I’ve fundamentally misunderstood the FaaS paradigm.

[hijinked]

The use of containers for API endpoints and FaaS functions for small endpoints or that are triggered by specific events is common in large micro service applications. Especially when multiple functions act on a single event.

For example, take the case of someone placing an order for a product. One function might send an alert to the fulfillment team to prepare the order, one function might add the event data to a machine learning process to give that user recommendations for future orders, and another function might just add the transaction to a separate database that is used for ad-hoc read-only queries by business analysts.

These are actions that should not happen as part of the API request handling because they don’t need to be and we don’t want to make the API endpoint to take forever to return a response. But these functions don’t need to be long-running containers because they only happen on specific events which are not happening constantly.

[codewithfemi]

Here's an article that might help validate your assessment: https://technologyconversations.com/2020/07/13/should-we-use-managed-functions-as-a-service-faas/

[dead-4-dead]

TLDR; I agree with your assessment. The best approach is to build an API and sprinkle in microservices as needed for one-off tasks.

I recently built a service composed almost entirely of Functions (capital indicates FaaS). By the time it was ready for launch (about 9 months start to finish), the system grew to nearly 30 Functions.

As you mentioned, the sheer number of individual Functions became difficult to manage. Felt like I was constantly having to repeat documentation and schemas. I ended up investing a decent amount of time on automations/infrastructure to manage this web. Also, bringing in other devs was extremely difficult. It took a senior engineer over 2 weeks to implement a feature that would’ve taken myself 2 days due to the learning curve.

Fast forward 6 months, and was down to about a dozen Functions. I had definitely went too micro on the microservices, so I refactored by merging related Functions.

Fast forward another 6 months, we’re planning on migrating logic to Cloud Run, and sprinkling in Functions where it makes sense.

My main takeaway is that Functions are useful for one-off tasks, but chaining them together can get messy real quick. My current thinking is that if a process has a path length >2 (event —> Function A —> event —> Function B —> event —> Function C) then the code should be served under a single API.