Paul Hammant's Blog: A Serverless Sequence Diagram
I thought I’d put a diagram together that shows some of the way I think about the general serverless facility, and a key difference to the old world of application composition and deployment. Two-time former colleague, Mike Roberts, knows serverless stuff way better than me, and hopefully I’m doing a fair job here of showing an alternate diagrammatic description of one piece of it:
Ports, processes and all that
Key (to me) is the fact that the functions deployed to the serverless infra don’t have domain names (even internal ones),
nor TCP/IP addresses, nor listen on ports. At least for us as the users of this system that is true - all routing is by
a logical name alone. If my serverless function needed zipCodeService then that’s all it would need to know before being
able to invoke it (as well as a platform provided API for lookup). This design is so smooth, that it’s easy to have wholly
separated (shared nothing) environments that are easy define the daily cost for. This would include per-developer environments, and plenty for the CI controlled automation that high-throughput dev teams rely on. Ephemeral environments are possible even, as it
matters far less with serverless whether the environment is “up” (by some definition) and yet not used. There’s charges for use
of serverless, but they are fine grained and traceable to each environment’s functional handlers that did the servicing so that
you know where your dollars are going each week.
Back to named dependencies
that are sibling deployments in the serverless infra: there’s no notion of services that would be named to include environment. So you’d not see a zipCodeService_QA1 function. Your functions that would need it look it up by canonical name (zipCodeService) as it
could not use one from an adjacent env for the same application as they’re invisible. There’s no need to thing of that as a
side-firewall constrained capability (although it may be too) because there’s no notion of sockets to the developer/deployer.
Functions in a serverless infrastructure don’t have them. Well there are sockets involved if you’re calling out to the likes of https://api.github.com for some purpose, but that’s a different thing and subject to it’s own best practice / worst practice considerations.
Key advances for our industry
This stuff and the abandonment of names:ports in the config is a key advance for our industry. It is like a limiting Unix problem has been overcome. While it is still is impossible for two processes on one server to listen on the same port (say port 443), it is now not important as we have a mechanism for efficiently stitching together components (functions) of an application together via the simplest thing - a name. A name that is totally open for my naming creativity (ports were restricted if they were numbered below 1024 and also tied to specific purposes) . We’re also relieved of the problem of having to think of processes now, and whether they’ve crashed and won’t be receiving requests any more. Here’s a really great, but rambling, rant on a bunch of related topics by Smash Company that you should read too as it touches on some of the same things but goes much broader.
Notes on the diagram
In the diagram above, I’ve not shown any Backend as a Service (BaaS) pieces for this “meaning of life” invocation, but with functions as a service (Faas, that is shown), is very much part of the “serverless” proposition.
Also not shown in the diagram are some things in the serverless infra itself (right of the vertical dotted line):
- The use of a store during Container Manager’s lookup, and instantiation of function handlers
- The purging of function handler instances/containers on any basis
- Caching at any level.
- Perhaps even the immense scale potential for the hosting infra itself and the apps within it
Mike and John Chapin have a consultancy Symphonia that can help you introduce serverless to your enterprise. They do business globally, but are based in New York like me. Mike of course helped me get this diagram right. Principally by applying a big red pen, and saying “no like this”.