Classic business applications

Let us have a look at the classic solution architecture, everybody has been implementing for quite a few years and which worked (and still works!) in our company data centers.

Normally you will find three tiers of application layering:

• Presentation layer
• Business logic
• Storage layer

Presentation Layer serves application content either as a web application hosted on the server or as a single page application (SPA) that calls into APIs on the web server. SPAs have become more and more popular due to their superior user experience and good support within the newest JavaScript frameworks, such as Angular and React. 
Business logic quite often is either a unique (monolithic) API application or is spread across separate microservices providing the technical implementation of use cases. Into these endpoints the web application calls to trigger process, get data etc.. 
Backend of a business application classically is a SQL database, which takes care on efficient data storage as well as data operations to serve the requesting application’s needs.

So far, so good!
This solution architecture works and has proven itself even in highest load scenarios, when implemented correctly and run in a capable data center. Of course there are the standard Cloud versus data center discussion points, but serverless is a bit different, because it is is not necessarily bound to any of these two. One could have a serverless approach in one’s own data center and eg. Azure Stack is Microsoft’s implementation of this approach (there is more to it, of course, but let us leave here for the moment).
The main problems of 3-tier applications are:

• A lot of infrastructure/plumbing code implementation required
• Due to this tight coupling between infrastructure and code – to some extend even dependencies on hardware
• Missing flexibility when it comes to change business logic
• Many people and departments involved
• Therefore lengthy processes required
• Always combined tests for infrastructure and code required
• …

These are just prominent ones and it all boils down to, that 3-tier architectures work, but require quite an investment and are not a quick and easy setup.

What is serverless doing different ?

From a company’s perspective it is only important to implement just the business logic and UI, all the other effort (having data centers, networks, servers and other hardware) is done to run 3-tier applications, because it is necessary, not because anybody really wants to.   
To get out of this dilemma, serverless technologies try to put infrastructure functionality into reusable building blocks, which can be assembled and used independently from the underlying infrastructure and hardware.
With the arrival of the Cloud, this is also what makes it possible for a Cloud vendor to share his infrastructure easily between different customers by dissolving any dependencies between code and infrastructure/hardware as much as possible.

How does it look like, if one migrates a classic solution architecture into a serverless one?
Well here an example (well, high-level ) , but I am going to delve into more of the details in my upcoming posts.

It is easy to see that there is not necessarily a change in the logical tiering, but in platform services (PaaS) or components, which are used in a dedicated tier. Through the re-use of components there may also be more than the 3 classical layers by combing the building blocks, such as Functions or Logic Apps, in a more granular way.
The very striking benefit of this approach is that one has to write only application related code, which ideally is written in componentized form to mirror the building-block like approach of the PaaS services used. Anybody, who has played with Lego bricks growing up, may see an analogy, here.

The ease of use of these functional blocks , who have pre- built connectors into the rich functionality of Cloud services, enables an unprecedented flexibility and speed to adapt an application’s logic to changing market requirements.

As an example for business logic tier, the chain of functionality calls shown below can easily be newly arranged by re-organizing them in configuration, without writing code! Which is fast and cost saving.

This re-combination approach is not limited to business tier in serverless applications, but can be leveraged in all tiers of the solution, making it a fully multi-layered approach.

In the next post I am going to shed some light on the existing as well as new and exciting possibilities to create a serverless presentation layer for an application.

Alexander