And it triggered me :) not what he wrote because it was neutral an comprehensive and well put.
I would go for the term network-reliant services. Since you can have multiple other protocols to communicate over the WAN which have similar constraints.
Now to my ranting/whining about 'microservice to soon'.
You should almost never start with a microservice architecture from scratch. The idea of scalabilty and isolation is beautiful on paper and I love it. The reality is rather good summarized from Richard Uie in his article about sub-surface Baggage
That's where my pain-point starts. I work as a consultant / freelancer and I was joining an existing company. to help them develop features. It's a rather simple task, if someone wants to reschedule a date
- you need to check if it's possible
- give a list of alternative dates
- if a date is selected cancel the old date and create an entry with the new data
Rather straight forward :) now lets get to the microservice part:
If you cannot start your application and test it on your pc - I know there are certain scales where this is not possible - you already take away a lot of development velocity just for design vanity. Most of the time you don't even have the metrics to prove the design decision.
I currently work on an over engineered microservice system. Beautifully isolated, DTOs, MQ, persistence layers, UIDs, containerized scaleable, really nice.
All I need to start it up locally is 60+GB of RAM and 24 cores of CPUs to send a simple HTTP-Request from my web interface to an endpoint.
For every test I have to wait 1sec+ to mock the circuit-breaker, MQ, routing, websever, database so I can see one single request.
For the infrastructure I needed openshift, my own nexus proxy server and a prebuild routine.
The point I dramatize here is .... don't go microservice unless you have data where you can prove you actually need it.
You push complexity to the architecture and this can drastically impede the velocity and onboarding process of other developers.
This is not an inherent microservice problem it's a design problem I know.
Rather build a good modular monolith that can be decomposed if needed. The modules are your communication membranes only DTOs can pass. So everything works and isolation of state is achievable without extremes.
You can at least test it locally.
The system I work on is a really nice piece of architecture based on a software-design perspective.
And now guess the load it handles? 1000+ requests a day .... 60GB and 24 cores for 1000+ requests a day. To be fair that's a java problem not an architecture problem. I am not sure, but I would have to measure if the overhead of running this computational model is bigger than the computation of the model itself.
it basically idles till xmas has 1 peak.
You have to compile artifacts deploy them to a cluster just to test 1 request.
And I am not hating about the system I hate that we tend to make things overly complicated before we need it to be complicated.
- start reasonable
- scale only if you KNOW the data
- keep it as simple as possible
thx for reading :)
I am thinking ...
I love this. Over the last months (if not years) I really focused more and more on managing complexity. (I think I already shared John Ousterhout’s great 'A Philosophy Of Software Design' book here... which is all about understanding, managing and anticipating software complexity)
At the end of the day, it always comes down to pragmatism.
A splendid design which does not solve a problem we have is useless, and usually brings unneeded complexity which makes updating/maintaining/modifying the system more difficult, costly and error-prone.
I recently read again Tef’s blog post about code: Write code that’s easy to delete, and easy to debug too and Write code that is easy to delete, not easy to extend.
Complex designs often become necessary.... after some time. But we should always start with something simple (e.g. a small monolith) and only split it (or add another part alongside rather than extending it) when we have good reasons to do so, and when we already have the tools in place to be able to use it and test it easily (which is usually not the case if we want the full microservice experience from the beginning... because we have everything else to build too)
This makes a great context to remind people about Gall’s Law:
"A complex system that works is invariably found to have evolved from a simple system that worked. The inverse proposition also appears to be true: A complex system designed from scratch never works and cannot be made to work." - John Gall