And you are here why?

Irreducible Complexity Swapping out your monolith for micro-services — or just using micro-services in the first place — is, in theory an obvious thing to do. After all, the larger your monolith (“one big thing”!) gets, the harder it is to for you to keep track of everything in it. The architecture eventually get to a place where you just can’t visualize it all in your head. Oh, loose-coupling helps, as does componentization, layered architectures, queues/service-buses, and whatnot, but, in the end, you’re limited by the irreducible complexity of the system. So, you do the obvious. You extend loose-coupling to the breaking point, by, literally, breaking apart the individual components into distinct micro-services. Now, each of these micro-services can be visualized in entirety by  its development team, and you can task somebody else with visualizing how all the individual components fit together. So simple, right? You’ve basically  decoupled  the individual compo...

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...

In the world of (micro?)services, a   Backend For Frontend   ( BFF ) is a layer that gets used to isolate the backend semantics (e.g., whatever goofy stuff your resident   #CowboyDeveloper   came up with) from the   Frontend For example, say you’re running an (exclusive! boutique-y!) clothing store, and the resident genius set up a whole bunch of individual services that return each type of clothing.   get_shirts()   for shirts,   get_slacks()   for slacks, and so forth. You   could   just invoke these individually from the   Frontend , it might make sense in some situations. However, if you don’t (and won’t ever!) care about all these wee services, you could slap in a layer that would translate one single   get_clothes()   call into the individual   get_shirts() ,   get_slacks() , etc. calls. The major advantage here is that it allows you to abstract away the details of all the various services that...

In todays episode of “ Lets Talk About Stuff You Already Know ” we cover  Loose-Coupling . The  baseline definition  is kinda obvious — it’s a system is which each component has limited knowledge (and use!) of the other components. That said, if that was the extent of it, I would just have linked to  the Wiki page , and have been done with it. The thing is,  semantics are important , and what the term means to me is not necessarily what it means to somebody else. Given that the most costly software issues tend to be the ones made earliest, it behooves you to limit misunderstandings in the  Design  stage! Consider a simplified take on the development cycle, viz.  Design → Develop → Test → Deploy . With a loosely-couple system, you can • Design  your component with limited involvement from other components. Whats more, you can update this design without  other  folks having to change  their  stuff. • Develop  y...

“ I already have enough logging, tracing is just redundant ”  —  #CowboyDeveloper   Logging works — oh yes it does — but only up to a point. The moment you start dealing with interactions that span systems and services all hell breaks loose.  Causality  becomes increasingly hard to track down ( which request caused this response? ), and “ before-after ” relationships are just a PITA. With tracing, you can — trivially — isolate the service and the relevant span, allowing you to drill into the behavior of your system without worrying about other concurrent requests cluttering your analysis. (And no, don’t get started with timestamps. These are distributed systems we are talking about!) Enter  OpenTracing , with which you can track the journey taken by the request as it bounces through your increasingly elaborate service. The general idea started with the  Dapper  project at Google, which inspired the OSS  Zipkin , and has ended with  it be...

You know what a bulkhead is, right? You know — in ships, where they create watertight compartments so that in case there is a leak, it is isolated to just one part of the ship, instead of the whole thing pulling a Titanic? Well, pretty much the same applies to software, where “bulkheading” is where you isolate parts of the system so that if one part of it barfs, it doesn’t infect and/or clobber the other parts of the system. It’s one of the core-precepts of building fault-tolerant systems, viz.,   Error Encapsulation . From a “big-picture” architectural perspective, yes, this does mean all the usual stuff about “loose-coupling”, “component-driven architecture”, “microservices”, and pretty much any other buzz-word in this vein that you can think of. However, the actual   functionality   associated with this is something that you should keep in mind — and towards that, let’s look at a specific example You’ve got a connection pool, serving two sets of back end se...