101–110 of 356 posts
Databases are microservices, S3, Keycloak, Sentry, all sorts of stuff. Also goes for other teams in your company building and maintaining the service.
Or as I like to say "Oh, you have a big ball of mud in your monolith because of poor design and want to move to micro-services?"..."now you have n^n big balls of mud" Poor design is poor design, adding more complexity just makes it a more complicated poor design.
All these design pattern and methodology fads are attempts to get around the simple truth you stated, and one other: No design pattern or methodology will make bad programmers write good code. The only solution for poor skills is practice, education, and experience.
Earlier quoted context omitted.
Don't you find it strange that YOU live in a world where everyone else but YOU thinks that everyone else around them is over engineering or under engineering things? You're not the guy who thinks everyone else is a maniac and is driving too fast or too slow. You're the guy who thinks everyone but you is under this delusion of thinking that everyone else is a maniac and you think you are an exception to the delusion b…
If you ask a room full of 100 engineers if they are better engineers than their peers, 80 of the 100 will say yes.
1. All of us reading this post are more likely to be part of the 80. We are all likely delusional and we are all likely to be wrong.
2. The second thing to realize is that one person out of those 100, is Actually better then everyone else. Who is he and how do we find him? I'm curious about whether this person said yes or no.
Microservices is a team organization technique, whereby disparate teams only communicate by well defined APIs. Any technology choices that come out of that are merely the result of Conway's Law. Any time you lean on code in a random GitHub repository, where you never speak to the author and just use the API you're given, you're doing microservices. This works well enough so long as the product does what you need of i…
> Any time you lean on code in a random GitHub repository, where you never speak to the author and just use the API you're given, you're doing microservices. So a library is a microservice now?
And also - nothing is a microservice, because it's not separated strongly enough.
Microservices - let’s replace as many interfaces as possible with the slowest, flakiest, most complex mechanism - the network layer. Why call a function when you can wrap that function in an entire application and call it via API? Why have a single database when we can silo our data across 200 mini databases? Why have a single repo when we can have 200 tiny repos?
The move to microservices is often more about scaling change management when an organization grows from tens to hundreds of engineers. Change management becomes the bottleneck when organizations exceed Dunbar's Number, and a "reverse Conway maneuver" is needed to counter excessive cost of coordination. https://cloud.google.com/architecture/devops/devops-tech-arc...
Earlier quoted context omitted.
Don't you find it strange that YOU live in a world where everyone else but YOU thinks that everyone else around them is over engineering or under engineering things? You're not the guy who thinks everyone else is a maniac and is driving too fast or too slow. You're the guy who thinks everyone but you is under this delusion of thinking that everyone else is a maniac and you think you are an exception to the delusion b…
If you ask a room full of 100 engineers if they are better engineers than their peers, 80 of the 100 will say yes.
Earlier quoted context omitted.
I get the feeling he really misses the point. The most dangerous thing about microservices is that many people squee when they hear "You can write 45 different microservices in 35 different languages". Writing a new microservice? What a great opportunity to learn a new language! Now it is true that by decoupling the address spaces microservices do let you take advantage of different runtime systems: you might really…
Not having to upgrade in lockstep is great though - the downfall of many monoliths is the ‘forced death match to port to new version of the platform because we put this off so long it’s about to leave LTS’. Being able to use different stacks where appropriate is also great (but needs care). E.g. if you are a Java shop but you want to deploy an ML pipeline you should at least consider carving out a pathway for deployi…
The idea that an org that has hard time maintaining a properly structured monolith, will solve it's problems by shifting to building a distributed system was always strange to me.
No, they aren't. The entire point of the big ball of mud is that there are no meaningful divisions in the code. Everything uses everything willy-nilly, at the smallest possible level of abstraction. There is, metaphorically if not always entirely literally, not a single line of code in the system that you can change without fear of bringing something else down that you may not have even known they existed. Microservi…
Still, crap devs will just find their own ways to mess up with microservices, but at least they limit the blast radius.