51–60 of 356 posts
Earlier quoted context omitted.
Monoliths can also scale horizontally and be restarted automatically when they fail. No need for microservices for that.
> Monoliths can also scale horizontally At a (potentially much) bigger cost.
Don’t you find it weird that everybody else is either over or underengineering, but you , you engineer things exactly the right amount? I bet when you’re driving, you also tend to notice that everyone else is either an idiot driving way too slow in the middle lane or a maniac speeding past you. Nobody else drives as well as you do. It must be exhausting for these people to live in a world surrounded by strawmen, whil…
I would argue the inverse. If you reject both extremes, and are somewhere in the middle, you probably are much closer to something reasonable. (both in engineering and when driving)
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?
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...
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?
If you are one of those, then I have news for you.
1. You are not going to reach the size of Google. Certainly not if you are engineering for it in your 2 person startup. But in case you do, see number 2.
2. Reaching Google scale means you'll have funding to hire good people to scale your software.
Earlier quoted context omitted.
So using your definition what is the difference between a module, a service, and a microservice ?
Modules are for organising your code, services are for organising processes on the OS, and micro-services are for organising teams of developers
I'd say it doesn't have to be. There is a certain kind of "freedom" that is really slavery, but people feel so free when they hear about it is they often squee and hurt themselves with uncontrolled movements. Microservices can be that way. Now that you have 25 different services in 25 different address spaces you can write them in 11 different languages and even use 4 versions of Python and 3 versions of Java. (I got…
I'd say it doesn't have to be. There is a certain kind of "freedom" that is really slavery, but people feel so free when they hear about it is they often squee and hurt themselves with uncontrolled movements. Microservices can be that way. Now that you have 25 different services in 25 different address spaces you can write them in 11 different languages and even use 4 versions of Python and 3 versions of Java. (I got…
> you have to standardize build, deployment, configuration, serialization, logging, and many "little" things that are essential but secondary to the application ...so then you can go reimplementing those standards in 25 different services written in 11 different languages. Sounds like fun! I don't think it's possible to just write a library/framework that would encapsulate all of those standards and re-use it in diff…
I think the problem with microservices is the same as the problem with OO programming (and I say this as a pure OO Rubyist) ... what you are doing is shifting the complexity out of your code, where at least it's under source control and (hopefully) readable. And moving it into the order and timing of the interactions between your services/objects - which isn't readable unless you start hunting through log files.