Why does it have to be "Serverless or Microservices"? It should be "Microservices with Serverless"! Based on some of the generally accepted principles of microservices, we can use serverless architectures and technologies to build highly focused microservices. Let's take a pragmatic and concise approach to building microservices with Azure Functions, Azure Service Bus, Azure Storage, and other services and tools. And it works for almost all software developers: Java, .NET, Node.js, and even Python.

Microservices have been on everyone’s mind for a number of years now. There has been a heated debate about their advantages, but also the disadvantages associated with them. If one decides to take a microservices approach, the question of the technological solution stack arises relatively quickly. With Serverless and Functions as a Service, an alternative way to implement them has existed for a relatively short time.

Microservices – but pragmatic

Without wanting to celebrate a complete treatise on microservices here – I would like to discuss some of the central principles for successful microservices architectures, in order to be able to make the transition to the serverless world. The four most important ones for me from an architectural point of view are:

• Single responsibility: A microservice does one (business) thing and does it right. It is a fine art to tailor microservices correctly and to find the balance between responsibility and complexity.
• Isolation: A microservice is isolated from other services. This requires physical separation and the possibility to communicate with the microservice via well-defined and technology-independent interfaces. In addition, it sometimes makes sense to use a special technology within a microservice in order to implement use cases optimally – the choice of technologies per microservice should be guaranteed via isolation.
• Autonomy: The supreme discipline in the design of microservices architectures – each service has its own data storage and does not share a database or similar with other services. Implementing this principle consistently means decoupling the services to a large extent – but at a price.

Probably the easiest way for you as a reader to get an idea of the microservices principles in a serverless world is with a small example. So let’s take a look at one. The sample application is also available with complete source code in a GitHub repository [1].

End-to-end considerations

An end-to-end view of a system is important for the consideration of microservices – whether serverless or not. It usually doesn’t really help to look at just individual services or even individual implementation details of services: An overall view includes client applications as well as non-specialist services, such as authentication or notification services.

Our exemplary order monitoring system (Figure 1) – which was of course simplified and implemented for the purpose of this article – is quite simple in its basic concept: Whenever a registered user makes a purchase on the shopping website and places an order, we want to be notified by a mobile app – implemented as a cross-platform SPA – as an equally registered user. We can also use this SPA to view the current list of orders and their delivery status.

Fig. 1: Serverless microservices example architecture (order monitoring)

As can be seen in Figure 1, five microservices are involved here. The interactions can be traced via numbered steps. In this case, the client SPA is not implemented as a hodgepodge of microfrontends, which would go far beyond the scope of the example. Instead, the SPA uses the different APIs of the microservices. For a simplified URL management and a better decoupling of the physical services, an API gateway [2] is used in the overall architecture. Of course, an API gateway is not necessary in such an architecture, but it is often used for further abstraction.

The first question that arises when looking at the application from the end user’s point of view: Where does the SPA come from and how does it get into my browser?

Home for SPAs: Azure Blob Storage

At the end of the day, a SPA is a package consisting of HTML, CSS, images and other assets. You don’t have to deploy this package to a web server or even an application server in a complicated and expensive way. Every cloud platform offers the very slim and cost-effective option of simply providing the SPA as a static overall structure via a storage service. In the case of Microsoft’s cloud this is Azure Blob Storage.

PRACTICAL TIP: AZURE PORTAL, CLI AND REST API

For all Azure Services, creation, and configuration can be configured and automated either via the Azure Portal, via a REST API or via the very powerful Azure CLI (Command Line Interface) [3].

Once the storage account is created, you can enable the static website feature. After that a container named $web is available. This serves as a kind of root directory for a static web server, but is only provided by Blob Storage. Figure 2 shows the client SPA from the example, here deployed manually to the cloud using the Azure Storage Explorer [4] tool.

Fig. 2: Angular SPA provided via Azure Blob Storage

Of course, the endpoints for the blob storage-based web server are published via HTTPS. With additional Azure services such as Azure DNS and Azure CDN, it is also possible to establish your own domains, SSL certificates, and ultimately super fast CDN cache nodes. This is all done without having to touch or even know a single server.

So if the SPA is running in our browser via HTTPS and wants to retrieve data, then we need APIs and interfaces in our services. We will now implement and provide them serverless-like.

Microservice Code and Serverless – Azure Functions

Serverless code for your business logic or business processes can be executed via Azure Functions. Boris Wilhelms presents the basics of Azure Functions in his article on Azure Functions in this magazine (p. 40). Azure Functions can do even more than is presented there. An important feature is that you can not only write, upload and execute .NET Core and C# code – no, you can also use F#, Java, JavaScript, TypeScript, PowerShell, or Python. For details on the platforms and languages supported at the time of writing this article, see Table 1.

Table 1: Platforms and languages supported in Azure Functions

Free choice of technology

The platform and language diversity in a microservices world should not be underestimated. Because as we have learned, the free choice of technologies that fit the problem at hand is a possible success factor. If, for example, you have a lot of Java code and want to take it with you into the serverless cloud, then simply do so with Azure Functions. Or if you want to implement algorithms in the Data Science Serverless environment, you can do so with Azure Functions Python Support. Or if you want to use the almost infinite universe of node modules, then write JavaScript or TypeScript code for Azure Functions.

Physical isolation

In order to ensure that each individual microservice really runs isolated...