Rube Goldberg Microservices
Complexity our old friend
Why does this illustration capture software development so perfectly? Software engineers should be battling to minimse the amount of complexity in their systems but it seems everywhere I look, there is an eagerness to lather it on.
At a previous employer, this hit particularly hard whilst building familiarity with a new platform to serve a web page. To serve this page there are 10+ highly coupled microservices. A distributed monolith in this case (due to the tight coupling). Most of these services hardly do anything. 70% or more of the code is boilerplate to make HTTP calls to the other services.
Instead of having a single service to encapsulate the concept of URLs & routing we have…
- The reverse proxy
- The “route file generator” service that creates “route files” for the reverse proxy
- The “url reader service” that can fetch urls from the “url database”
- The “url writer service” that writes URLs to the “url database”
- The “url available service” that defines if a URL is publically available for users
- The “sitemap service” that pulls all the URLs into sitemaps for crawlers / SEO
- The “seo url meta service” that provides the localised URLs for SEO metadata (hreflangs)
I could go on but I’m sure you already get the point.
All of these services call into eachother. Back and forth. To and fro. This urge to break up systems into such discrete and granular chunks is far more problematic than starting with a larger system and carving off chunks when a use case clearly emerges. The cognitive overhead and burden to onramp to these systems is a nightmare.
Such a heavy price to pay to show a web page.