Moar Semantics - MicroServices Edition

Software development is hard enough as it is — 
• there is always a “flavor of the month” language,
• everybody has their favorite flavor,
• there is always the inevitable #CowboyDeveloper who Knows The Correct Flavor,
…oh, it’s crazier than a sack full of clams.
And that’s before you even get to the semantics, where everybody has their own definition of what “flavor” means!

The thing is, semantics are important, they allow us to share the meaning behind words, the understanding if you will. And towards this, herewith a glossary of some of the more common terms you see used out there in the world of (not necessarily) MicroServices. (•)

• • Ambassador — Modules that offload common connectivity tasks such as monitoring, logging, routing, and security (such as TLS) agnostically. Think of these as out-of-process proxies that are co-located with the clients.
• • Anti-corruption Layer — A layer between two different components, typically New and Legacy, that serves to isolate (or eliminate!) dependencies. The layer translates New → Legacy requests, using only Newsemantics, so that there is no leakage from Legacy → New (e.g., protocols, APIs, etc.)
• • Backend for Frontend — Backend layers used to isolate backend semantics (e.g., really goofy stuff) from the Frontend. This can also be used to isolate the backend from the differences between different types of Frontend(mobile, API, web, whatever). Also called BFF (I know, I know)
• • Backend in Frontend — An layer in the Frontend that is used to abstract away goofy Backend semantics (like crazy APIs), or even just simplify access. Basically the same as BFF above, except that the abstraction layer is moved from the Backend to the Frontend. Also called BIF (seriously, whocomes up with these things?)
• • Bulkhead — Components or layers that isolate shared/sharing resources (connection pools, memory, queues) by service or workload. This way, a single bad actor can’t nuke everything (e.g., a memory leak on one service consumes all memory leaving none for any of the other services. More information here)
• • Gateway Aggregation — Aggregates multiple individual inbound requests into one single outbound request, typically used to to reduce communication overhead. Typically used to reduce traffic over high latency/low-bandwidth networks, or when a single client transaction involves multiple back-end services.
• • Gateway Offloading — Offload common functionality to a different service — think “SSL certificates” or “encryption”). Incidentally, this is where the greatest likelihood of coupling creeps in…
• • Gateway Routing — One single endpoint for consumers to get at services, so that they don’t need to manage a whole passel of endpoints. In short, One endpoint to rule them all, and in the darkness route them…
• • Sidecar — Separate — and encapsulated — helper components for an application that are used to provide supporting features. The key here is that the sidecar provides additional capability without interfering with the normal functioning of the parent application (e.g. the Thanos sidecar that adds query and object storage capability to Prometheus)
• • Strangler — Replacing a system by incrementally swapping out components, instead of BigBanging the whole thing. Think “Ship of Theseus”

(•) Borrowed liberally from the Azure docs.