Mastodawn

gbsills May 19

@MichalBryxi Hmmm.... two things.

Thing 1. The only valid reason that there has every been to divide an application into microservices is to split the work across multiple development teams.

Thing 2. Developing microservices software is a lot of work, but you can definitely avoid the the problems of coupling he was describing with a lot of upfront design.

**Thing 2.5. People generally don't want to spend any time on upfront design.

Michal Bryxí May 19

@gbsills I believe he addresses both of the points in his video.

gbsills

@MichalBryxi Yeah he did. I am "triggered" by this topic I think.😂 Situations like a team in Indonesia, China, and the US working on a monolith, a single team using a microservice because it wt as the "right thing to do", but using an "Agile Architecture" methodology instead of designing things up front. Troubled times.

@gbsills Oh wow. I didn’t think anything would feel more like anti pattern than microservices, but microservice (singular) is next level 😬

@gbsills I just don’t see this type of architecture as net positive for any size of project I’d like to work on.
- A laptop can expedite 100s to lower 1000s RPM from a monolith per second without breaking a sweat
- Does your API absolutely need 10k-100k RPS or is that actually imposed by the chattiness of your microservices?
- Using multiple languages/frameworks/etc. sounds like a win, but it has so many traps that I would just sum it up as: perceived gains now vs huge costs later

gbsills May 20

@MichalBryxi The problem is that while the micro-service architecture does work for some situations, those situations are edge conditions. For example, would you even consider building the entire Amazon customer facing website as a single monolithic application? It isn't a matter performance, it is the scale of the complexity and workforce. You'd be insane to build something like that as a monolith. On the other hand, you are unlikely to be building another Amazon.

I think the problem is that people try to apply architectures to situations that they don't match. It is often a matter of programmers trying to impress other programmers with their brilliance. 😉

@gbsills Wait. Are we really trying to run a thought experiment where anything user facing from Amazon would be rebuilt and the outcome wouldn’t be instanteniously better (UX wise)? 🙃
Entire businesses are made to just make Amazon’s user facing websites less shit. 🫣

gbsills May 20

@MichalBryxi I've never been a fan of composite user interface layers. It has always seemed a bit masochistic to me. I do believe that a motivation at Amazon was a support strategy that involved the man abusing the programming team. The basic idea is you'd have a really small team (think 2-3) responsible for a bit of the user interface tier. If that bit broke, the development team for that bit would be responsible to fix it immediately. Now, this wouldn't work for a monolithic UI application for obvious reasons. but if you were the 2 or 3 guys responsible for making the project suggestion panel work it would. The secondary idea behind this strategy is that it would motivate those 2 or 3 guys to get it right before they deployed, because it would be their nights they'd be wasting.

I have no idea if this is still a thing there, but it is a good illustration that sometime applications are architected to meet management priorities rather than easy of programming and support or even user experience.

@gbsills What do you mean under "composite UIs"? If you're talking about devs making multiple FE frameworks work together using multiple styling frameworks, then agree. It's just a lose on both sides. And it's only ever a corporate politics to blame for that.

If you're talking about someone wrapping shitty UX of a service and re-selling it: Know #heroku?

@gbsills

> Now, this wouldn't work for a monolithic UI application for obvious reasons.

Why not? Technically, not politically.

- Monolith enforces tighter rules, narrower space to navigate.
- If monolith breaks you are able to see it on PR pipeline directly. Before merge. Before deploy.
- Debugging, fix (not hotfix) and deployment of a monolith happens in one(tm) step.
- In monolith release commit IS the state of known universe.

@gbsills
> their nights they'd be wasting...

I have a feeling, and correct me if I'm wrong, that we live a bit different experience. I have not touched anything but fully automated CI/CD for past ~10 years. And when I had to, I quickly converted it to CI/CD.

Even in my biggest corporate job, just our team did 20+ unattended deployments per day. Overall UI org did likely 100s per day.

There is no "motivation", there is just "process".

@gbsills And my biggest gripe of that org was that they kidna had micro service-like UI architecture. And it was political and technological hell.
The only good part of the codebases was what was in "common" and thanks to politics it was barely useable / used.

@gbsills
> I have no idea if this is still a thing there, but it is a good illustration that sometime applications are architected to meet management priorities rather than easy of programming and support or even user experience.

^^ Amen to that. Politics AND dev egos are the two biggest handbrakes on the projects I've seen.

@MichalBryxi I think that the Amazon situation takes things to its limit. Imagine that you have a suggestion panel on your website. There is a service that backed a data store of a user's purchasing history and much, much more. Think of all that privacy data Amazon buys from Google. OK, so business wants people to see suggestions and how it get's displayed gets changed by marketing bi-momently. Also, the algorithm for creating the suggestion product list is constantly evolving. You could have two teams, the web team and the back-end team (and probably the database team and data import team, yada yada) build the thing, but releases becomes a pain. Also, when things go wrong there will inevitably be finger pointing.

So Amazon used the "microservice" approach that considered UX as part of the service. The markup and script is served up by suggestion service. It's now possible (in theory, there were problems) to create the suggestion service in isolation, and the customer facing website just loads it up. Notice how this enables a support policy of "you developed it you own it". Management would have a hard time selling that if the code was all mixed in with everybody else's but this vision of a microservice is only coupled by the code that loads the suggestion UX, and by product IDs.

@MichalBryxi The obvious problem with this example is that with the exception of maybe Temu, it doesn't apply to anyone else.

@gbsills I see the same story but I see no advantages to that approach. Just fail for the UX, the user, the data security, …
Maybe just the beaurocrats will win 😅

@MichalBryxi technically a monolith will always work if you throw enough time and money into it.Same with micro service
There can be some organizational situations that make a monolith unshippable. Again, remember that the driver behind micro services is dividing work between teams, not dividing code in a program.

@MichalBryxi Yes, and as long as the monolith is small enough everything works just fine.

Again, I'm not arguing for microservices, in most cases a monolith is the simplest solution. People often use microservices to be cool. But there really are situations where using a monolith would be sport death. (And buy the way, I have used an application that was deployed without a CI/CD pipeline for 25 years. I was using it before there was a cloud 🙂 )