|
|
|
|
|
|
by dacracot
2686 days ago
|
|
|
The cycle repeats over and over. Monolith becomes unmanageable and get chopped into loosely coupled, functionally independent replaceables: mainframes to containers, application servers to micro services, etc. Drag and drop coding hits the wall and gets overrun by old languages: 4GL to C++/Java, HyperCard to Objective C, etc. The monoliths are currently numerous in the single page application realm, choose your framework. Eventually these will succumb to smaller more flexible and purposeful components. |
|
|
They surfed on the "everything must be Google-scalable..." trends. They built hundreds of interconnected micro/nano-services, upgraded networking infrastructure ($$), OAuth federation, ...
What they've got? Network latency/congestion/..., security and API versionning management nightmare, unresponsive applications (tooooo manyyyy APIs calls), performance issues, circuit-breaker, caching, ... Ok you see the big picture.
Now, the returned back to a more "monolith" design. They merged many services together in one application (services that wasn't called by anything else). Everything doesn't need to be exposed as a service. This simplified security management, reduce a lot the network usage and simplified bugs investigation/fix.
The difference is that now, their new monolith designs are more modularized than before. Everything is now in a clear module (call it jar file, lib, package, ...) with a clear contract/interface. This is what I like to call "intra-services" : clear services/features separation minus the networking/security moving parts (and all band-aid solutions to support it like circuit-breakers, distributed caches, ...).
If one day you are the size of Google, Netflix, Facebook, Spotify, ... you will probably have the money/manpower to implement it the "Google way". Until then, KISS!
Note: English is not my first language.