A Serverless Sequence Diagram

Paul Hammant has a quick and simple blog post illustrating the request-response sequence in the web application on a serverless infrastructure.  I find it quite useful as a reference, when explaining serverless to people who are considering it for the first time.

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.

Stop Learning Frameworks

Stop Learning Frameworks” is exactly what I’ve been saying and doing for years.

Technology come and go, but it has a lot in common. Set priorities right. Invest 80% of your learning time in fundamentals. Leave 20% for frameworks, libraries and tools.

After 20 or so years working with technology, it always amazes me how most of the new and cool tech is actually another iteration on something that existed and has been used since forever.

Cloud computing, and even the newest hype of serverless architectures, are just another iteration on the ever-going problem of large and centralized versus small and decentralized (mainframes, PC, terminal servers and thin clients, and on, and on, and on).  NoSQL databases have a very familiar feeling to anyone who have worked with LDAP.  All the modern instant messengers iterate over the same problems (and often solutions) from the ancient protocols – NNTP, email (POP, IMAP, SMTP), IRC, and tools that implemented them for different purposes.  And on, and on it goes.

There isn’t enough time in the world to learn even a fraction of all that technology.  But focusing on the fundamentals helps a lot.  If there was one thing to add, I’d also prioritize open technologies and formats versus proprietary.  Open technologies survive the longest and tend to be reused a lot more.

The Book of Secret Knowledge

The Book of Secret Knowledge” is a collection of awesome lists, manuals, blogs, hacks, one-liners, cli/web tools and more.  It is intended for everyone and anyone – especially for System and Network Administrators, DevOps, Pentesters or Security Researchers.

While you are at it, also have a look at:

Well-Known URIs

Back when Let’s Encrypt started giving out free SSL certificates, one bit that visible all over the web was the “well-known” directory.  I never thought much about it – it’s just a name after all.

Turns out, there is actually an RFC 5785 that defines a standard for the well-known uniform resource identifiers (URIs).  And that’s a lot more generic than just the bit that Let’s Encrypt needs.

Accidentally stumbled upon this while reading “A Well-Known URL for Changing Passwords” draft.

Faces of Open Source

Faces of Open Source is an on-going photographic documentation of the people behind the development and advancement of the open source revolution that has transformed the technology industry.

Given the immense contribution of these people to the world around us, I find it surprising that they are so far from the celebrity status and most people in the world won’t know any of these faces.  Even people in technology sector itself, won’t probably name even half of these people by the picture alone.  For some, even the name won’t mean anything.

Kudos to this project for trying to make these faces slightly more familiar and for giving credit where credit is due.