Azure Functions for the Enterprise - Concept

I've been playing with Azure Functions for a long time and even though I think it's a great piece of technology, I couldn't find a way to justify losing all the best practices just to start playing with a new toy, especially in a big application inside a big company. Well... I was wrong!

You can actually apply all the best practices you have been applying to your projects and still take advantage of a serverless architecture. It's a different paradigm and different way of thinking, but I think it's worth it.

In this series, I'm going to go through each of the areas I think are important for an enterprise application and how to implement them in an Azure Functions context. Some of the things I consider important for an enterprise application are Source control, CI/CD, Multiple environments, Logging, Security, Dependency Injection, Unit Testing, CQRS, Rich front end.

All the source code covered in this series is or will be avaiable here

Here's a common scenario in several big projects I worked on and how it would translate into Azure Functions.

Something to take into consideration is that we usually keep the controllers in the Web API layer very slim, and all the logic is in an application layer. This approach will make the transition to Azure Functions much easier.

The approach I'm proposing here is instead of exposing the endpoints through a web api project, we will expose them through an Azure Functions project. And the cool thing about it is that we don't need a different CI/CD pipeline for each of the projects: api, windows service and scheduled task. Instead, all of the them will be functions, the only difference being the triggers.

The idea of this post is to introduce the concept and the new paradigm, in the other posts of this series I'll go into more details on how to implement them.

NEXT: Exposing Endpoints through Functions

Cheers