Serverless Design..really no Servers?

Key Takeaways at a Geek Night event and my own perspective

Nov 30, 2019 was marked with yet another amazing meetup organized by Thoughtworks. This is the Geek Night, one of the favorites of many tech enthusiasts interested with Java, Spring Boot, Microservices, Cloud Computing and so on.

This edition of Geek Night was dedicated to the serverless architecture of today’s world equipped with Cloud Computing options provided primarily by AWS(Amazon Web Services), Microsoft Azure and Google Cloud Platform.

This was almost a full day event, comprising of hands-on with AWS Lambda, demo and presentations on using Functions-as-a-service (FaaS), Azure Functions and other serverless options provided using Kubernetes.

So what exactly is serverless-design ?

First of all, when we say serverless it doesn’t actually mean there are no servers! There are servers to respond to the client requests, but neither you own those servers nor do you manage them. Talking about serverless architecture/design/trends we come across many other paradigms such as nano-services, functions-as-a-service(FaaS) and Lambdas(by AWS).

When we start thinking of separate functions (with single responsibilities) as separate services, we start moving towards the idea of serverless architecture. Think about any of your PUT,GET,POST or DELETE requests and imagine them as separate services. If you are able to imagine, then there is a good chance of you being able to deploy them as separate Lambdas. The best part is that Amazon will be charging you only for the duration of time your Lambda or function takes to execute (compute time).

When you start thinking on these lines you will observe that we are gradually moving from the micro-services architecture towards a nano-services design. Which is actually good but does my application or product needs to follow this design paradigm totally depends on the way my services are structured, how much interdependent they are and do I even need to put my logic on some alien machine!

The World is full of Events

When all our functions are actually atomic particles of a micro service broken down into nano services it will be a real challenge to achieve a working product out of it wherever there are cases that one function is dependent on some other function to execute. But not to worry since we know that our world is driven by Events! Imagine a payment service dependent on an order service. An order placed event pushed to an Event Bus can be subscribed by the payment service which can get this message and go on with the payment operations! Our Lambdas can be publishing to an Event Bus or can subscribe to one as the case may be. Coming to Event Bus we can think of RabbitMQ, Amazon SNS, Amazon SQS, Kafka, etc

So from now on, whenever you think of event listeners as a bridge of communication between two services do remember that these kind of listeners can be replaced by a Lambda and save much of your cost to manage servers and at the same time ensuring the benefits below -

1. Decouple our services (All services work as separate unit and at the same time connected using some messaging service or notification service)
2. Segregate Faults (An issue in the order service can be caught and handled easier rather than when all these services are merged into one)
3. Better User Experience (by using the serveless design we make sure that none of our services are down ever, also if by chance a payment service is down when the order service is waiting for confirmation, there is not much to worry because these messages are not lost by the queue until they are consumed)
4. Adding new consumers are easy (we can always add or introduce a new service without affecting the functionality of other running services and need no down time for doing the same)

Microsoft’s approach towards FaaS

Declarative way of creating functions!

Microsoft too is not left behind in the race of Cloud Computing as it comes with its own unique solutions for achieving serverless design with its own cloud platform Azure!

The Azure way of doing Lambdas or FaaS is what they call a Function App. Just like a Lambda, a function app is the unit of deployment when it comes to Azure. They have broken down a function further into
1. Triggers (The event or events which will trigger the function, for eg., a function can be triggered by an http call or a timer)
2. Input Bindings (All channels which can act as an input to the function)
3. Output Bindings (eg., A messaging Queue can be an output channel)
4. Function Body (The logic itself)

So in short, in Azure we keep the function separate from its configurations and the same function app can be used to run multiple functions!

Bringing it All Together : The Knative Eventing System

The Knative by Kubernetes is a very unique solution to bring the flavors of AWS, AZURE, GCP and such other cloud platforms on a same plate. Actually its much more than that (explore their documentation here https://knative.dev/docs/ ). Think of a service which subscribes to an Event Bus which is deployed on Azure and on execution it triggers a function which is deployed on Google Cloud. These type of custom designs can be made possible using the Knative eventing!

So we understand that we are in a constant process of breaking down our services into more granular details and trying to achieve the benefits of performance, availability, scaling, cost and risk mitigations using several different cloud solutions. As a developer, System designer, tech team manager, product visionaries or even a CEO it is essential to keep learning and keep ourselves upgraded with the latest trends and paradigms in the market!