Reflections on Serverless:From SOA to Serverless part 3

This is the 3rd part and last one on the series: Reflections on Serverless from SOA to Serverless. On the previous parts 1 and 2 I was explaining how software architecture evolved in several movements and how much we need to change our mindset in the sense of Culture, Movements, and Experiments. Our tools are changing pretty quickly and multi/poly cloud will be soon a reality for most companies. Even if so few companies have this problem in sense of availability and active-active global biz, most of the companies can benefit from multi-poly cloud in sense of getting lock in free from cloud vendors, cost reduction for better and multi offerings, better solutions for specific problems and much much more.

The Deep Dive

For this last post, I want to cover more details around specific issues and promises around Serverless per se. At the end of the post, you will have access to a slide deck with more information and structure in a more fluid and clean way :D

Mind the Lock-in

Remember STATE is not part of serverless and you need to use state someplace else, so serverless could be a potential accelerator for cloud usage, therefore, you could get lock in pretty fast. There are solutions for that like - using open standards, open APIs, there we go on the SOA path again.

Cold Bootstrap 

We need to realize that Serverless has issues like Startup time(also know as cold bootstrap). This problem will be fixed soon and there are ways we can deal with the thios problem right now. So the first thing we need to know and mind startup times for all major serverless providers(aws, Google, and Azure). Secondly, we can use fast startup times in languages like Rust and Go. If you work with java you can use GraalVM and Kubernetes based serverless in order to fix this problem.

Do not use Serverless(FaaS) for

This does not mean you cannot do it but it means actually that this is not the best FIT:

  • High-frequency trading or extremely low latency applications. 
  • Large-Scale in memory Statefull solutions(could be done with Serverless if state if out)
  • Long-running stateful jobs(could be done with Serverless if state if out)

Serverless and FaaS: 2 Different Things

Serverless is a NoOPS cloud billing model where you may use or maybe not use FaaS(Function as a Service) abstraction, model. We can see Aurora for instance in AWS. Where you have a Serverless DB without any new abstraction model for programming, you actually can still use MySQL and PostgreSQL APIs.  FaaS is about runtime abstraction at least until the last google next 19. Now Google is offering a Serverless(with Docker) where you can control the language runtime - called Google Cloud Run.  Google Cloud runs with KVM and gVisor at a low level.

Portability with Serverless

There is a spec called cloudevents -  Which is supported by Azure in production already and allow you to have multi-cloud serverless(Faas) solutions talking to each other without lock-in. This spec still is in the early days but is getting traction as the time pass.

The Deck



Serverless is the future and it's here. We need to keep in mind that Serverless and FaaS are different things and that cloud(single, multi, poly) billing models are changing and we will need to adapt our solutions and thinking. Serverless might become the default model on the cloud. We need re-think our solutions and get ahead in order to take full benefit from the multi-poly cloud world. Serverless makes more sense now them ever.

Cheers,
Diego Pacheco

Popular posts from this blog

C Unit Testing with Check

Having fun with Zig Language

HMAC in Java