I was reading the story of Graham Church about Mircoservices
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.
tl;dr ...
- start reasonable
- scale only if you KNOW the data
- keep it as simple as possible
thx for reading :)