Thread by @jesterxl

Part 5 of this:

https://twitter.com/jesterxl/status/1310245921419034625

Rehan van der Merwe has a great example here describing not only how to build a distributed monolith, but how to refactor it to microservices.

rehanvdm.com/serverless/ref…

Like me, he prefers Lambdaliths for API's despite the ease of API Gateway or Application Load Balancers make it to point to Lambda functions. I have other reasons because of the CICD pipeline my company forces us to use and our restricted list of AWS we can use.

It's important because he illustrates tight coupling that can happen. However, more important is how he _was_ able to build and deploy 3 microservices each on their own route hitting downstream systems, with e2e tests in place, ready to refactor.😀

Interestingly I'd actually consider his first iteration a success. The latency in place, sure, but great job! I ponder what type of events would transpire to allow my team to refactor to EventBridge in a version. I always hated hearing "Phase 2" because it never arrived.

Oddly, he cites principles from OOP as justification. I say odd, but it's not odd; OOP is notorious for "encompassing all of programming as the one, true way". Yeah, ok, sounds great just don't hurt me. 👍🏼

For what I would consider a small application, this would still take 3 months or more at some places I've worked. I can understand why developers who've experienced this, & never get the 3 months, write blog posts with prophetic warnings of Distributed Monoliths.

... that said, dude, chill out, your app works, is almost BASE, and you've done a great job documenting & coding it with e2e tests. Developers are so focused on clawing their way out of technical debt, they forget to stop, breathe, and embrace their awesome victories.

Sam Newman recently attacked Microservices directly: theregister.com/2020/03/04/mic…
If you want an article citing the pro's and con's of monolith vs microservice, this helps. Key message: It's "hard to do microservices well". Dude, it's hard to do software well.

He cites lockstep release. If you can deploy pieces of a Distributed Monolith independently, is it still a Distributed Monolith? "Coordinating between multiple teams"; what if it's just you, but your data changes 3 services?

His message appears too heavily lean on continuous delivery actually being real. Meaning, if it works in QA, then it'll work in prod because you have the same environments, your tests are 2 legit to quit, and all the things are automated.

The audience? Again, fear and loathing of "the big ball of mud". Consensus, to me, developers like little code bases. Details of how they work together... perhaps a John Stuart Mill Utilitarianism compromise? A bit of cognitive load pain for coding pleasure?

I like how he acknowledges if u know your domain, u can slice & dice to microservices easily. Is that a problem that going to that architecture is easy? If we can't easily define our domain boundaries and create hard to deploy balls of mud, is it better we just follow our hearts?

I sadly say this as a Functional Programming fan amongst a world of Object Oriented Programmers, lol. They have a saying in Sociology, people's interpretations of events may be wrong, but their reaction to it is real. This natural aversion to monoliths; hype or something more?

Interestingly, others have noted that Lambdaliths can be great ways for developers to learn Serverless. While they may not like monoliths, it's the evil they know vs. the distributed monolith being the evil they don't yet know.

In summary it appears Distributed Monoliths have no good definitions with recent Continuous Deployment tools like AWS SAM & Serverless Framework negating some of the previous problems. It appears the best I can currently do is the following:

Code change requiring other services to change? It's bad IF those other services are hard to change. SAM? Easy. Coordinating with another team causing deploy delay? Bad.

Deploying one service requires deploying others in lockstep? In SAM or Serverless: easy. If require coordination with another team, hard to test app, or low monitoring visbility, bad.

Service overly chatty: Pssffff, it's just version 1 and you wouldn't have built it that way intentionally if you knew the business domain; refactor! 😃

Same developers work across multiple services: Seems like a good thing for knowledge share, but this one is confusing; don't you have tests and schemas? Maybe they're worried about Continuous Integration being a mess because 5 PR's have to be merged in order for "app to work".

Many services share a datastore? I get this from a resiliency perspective, but from a source of truth and test perspective, I get confused.

Microservice sharing a lot of the same code and models: Using SAM / Serverless for libraries and common util functions - awesome. Sharing Models, though... "Model" I'm assuming being a Model from the OOP world meaning "data of your business domain", yeah, that seems red flag.

Hopefully you can see why I'm confused. Many of the perceptions written about the past 3 years about Distributed Monoliths can be fixed with schemas, deployment tools, and testing. What's also left out is scope. If you build "just an app" full of microservices...

... on your team, and it's deployed as a single app in AWS (look on left hand nav in Lambda in AWS Console), and that "app" interfaces with some other team... how is that any different from 2 monoliths talking to each other?

Maybe 1 team likes SAM and microservices, and other likes the AWS CDK and Docker with their monolith? I can't say I succeeded in finding totally why Distributed Monoliths are bad, but I sure did learn a lot! I hope you did too.

To learn more, beyond rando googling, I found a lot of @theburningmonk articles just "get me" theburningmonk.com