Thread by @matteofigus

For me a serverless (S-) architecture is much more than a event-driven function as a service (FaaS)...

(Thread)
#serverless #faas #architectures #thread #lambda #fastMovingTeams #ownership #devops

A S- architecture is an abstraction on top of a (potentially very complex) infrastructure, so that devs can focus on building great features and products and run their code in production without focusing on boring configuration and scalability.

This doesn't mean there are no servers and there is no care for infrastructure: quite the opposite indeed.

Good S- architectures are robust and resilient modular applications composed by many building blocks. They have great monitoring, operate with great performance, and are very cost effective.

An example of popular S- architectures are CDNs. CDNs are quite complex and handle scale in a transparent way so that organisations can abstract that layer of complexity and delegate a series of tasks to a third party by paying a monthly or per-usage cost...

CDNs in fact are running some code somewhere, but the developer doesn't possibly need to care about it - apart from one-off config. After that, maintenance should be smooth and costs should definitely pay off compared to implementing a in-house solution.

So, containers and S- aren't mutually exclusive. In fact, when an engineering organisation invests resources in tooling and great developer experience (DX) a great S- architecture can be based on containers underneath...

The point is not to not have the servers. The point is to enable autonomous teams to operate smoothly and effectively, with a DX that resembles their own local dev environment, but in production - with the minimum amount of steps to get there.

Event-driven FaaS are another great example of S- architecture, because they allow devs to run and extend a modular system in a cost-effective way (if that model applies to their problem) - but that's not the only one. Let me give you another example...

Let's think of an engineering organisation of 500 engineers pushing code to prod every day. They invest time and resources to build tooling around teams developing, testing, and deploying Java based Spring-boot http services...

One click in a web UI to setup the project name, et voila', you have a github repo with all the stuff scaffolded, auth, logging, monitoring, CI pipeline, alerting, etc...

Now anyone can clone, make changes, locally run unit and manual tests and then commit, push and then automatically that gets to run the tests in a staging environment and then gets to prod in a friction-less way. Well, for me that's a S- architecture too...

By making this investment, the management can centralise the tooling for scaffolding, so that everybody still deploys their apps in a docker container and then implement canary deployments and autoscaling all the fancy stuff...

But from a DX point of view, there is no need to know all the details between that code from running locally to prod, the number of servers, the docker image, the regions where to deploy...

In a medium-to-big organisation, similar tooling allow us to lead toward tech standardisation, a very important double-edged sword in the SOA or micro-services world...

As you can imagine, this may be controversial because for many people, when we refer to S- we refer to cloud. In the previous example, if you run your infra in a self-managed data-centre (DC), you may have no cloud at all, but is that really relevant? ...

In a 500 engineers organisation, isn't a self-managed DC a sort of cloud anyways? What I mean is that the devs that write the code that runs there, don't know all the details about the operational aspects and the cost-related matters...

In fact, that code may go 30% on Azure, 60% on AWS and 10% on self-hosted DC depending on the config, and most devs don't really need to care. And I don't mean to be rude saying they don't need to care because they are not smart or stuff like that...

I mean that there is value on centralising the tooling for allowing many teams to consistently release code in a smooth way so that they can focus on writing great features instead - and S- architectures are all based on this very principle.

So, let's wrap this up in these last 3 points:

1) Serverless doesn't mean no servers. Serverless means servers are there but you don't need to care about it - unless you are deeply involved on building and maintaining tooling and infrastructure for other devs

2) Serverless is not really a how but more of a why. It's in fact more of a paradigm that an architecture (but I would say that the paradigm really shapes your architecture as a consequence).

3) What's today popular as "serverless" may be completely different from tomorrow's. Personally, I would bet we'll see in the future great chances for S- to emerge for Front-End modularised Web, virtual testing environments, bots, machine learning, and more.

Disclaimer: all of this is very personal and based on around 4 years exploring and navigating the dark waters of S-, but I obviously still have lots to learn. Please share your comments below.