191–200 of 469 posts
Great article, but I'd like to dispute one point: > A new version of the subscriptions service may store data in the subscriptions database in a different shape. If you are running both services in parallel, you are running the system with two schemas at once. Microservices should manage their own separate data stores and communicate with others through a well-defined API. Only then services can evolve independently,…
Independent development - just stick to your own part of the app.
Reusability - write a library
Isolated deployments and deployment velocity - I suppose not isolated but there’s no reason you can't achieve great velocity with a monolith.
A less often cited advantage that I do think has a lot of merrit is the ability to choose different languages and tools for different problem domains.
Earlier quoted context omitted.
10 people managing a single "micro service" does raise a red flag to me as well. It may be normal based on the complexity, but my first thought is, why is the codebase require so many people to maintain and add features to? Are they just adding features like mad, or something squirrelly in there where most modifications take a lot of man hours?
How micro can it possibly be if it takes 10 people to deal with it? Seriously.
Earlier quoted context omitted.
Why was this downvoted? I think this is a valid argument. There are plenty of small teams or individuals who have been managing a bunch of small services. Before this was called microservices.
Because it's not a "valid argument", it's snark. The contempt is unnecessary and uninformed.
Earlier quoted context omitted.
Once when starting a new gig I inherited a "microservices" architecture. They were having performance problems and "needed" to migrate to microservices. They developed 12 seperate applications, all in the same repo, deployed independently it's own JVM. Of course if you were using microservices, you needed docker as well, so they had also developed a giant docker container containing all 12 microservices which they de…
> They developed 12 seperate applications, all in the same repo, deployed independently it's own JVM. I've dealt with an even worse system, with a dozen separate applications, each in its own repo, then with various repos containing shared code. But the whole thing was really one interconnected system, such that a change to one component often required changes to the shared code, which required updates to all the oth…
Earlier quoted context omitted.
Jesus, 10 people on a team? What are you doing that you need 10 people to work on it? I manage like 8 services by myself.
Well, I've also worked for places where I'm on call for some service maintained by one person that's built their little impregnable abstraction castle because nobody else had to work on it so they could just yak-shave and bike-shed with their self. These days I kinda wince at "I run 8 services myself."
Earlier quoted context omitted.
10 people managing a single "micro service" does raise a red flag to me as well. It may be normal based on the complexity, but my first thought is, why is the codebase require so many people to maintain and add features to? Are they just adding features like mad, or something squirrelly in there where most modifications take a lot of man hours?
How micro can it possibly be if it takes 10 people to deal with it? Seriously.
Earlier quoted context omitted.
This is the 9th time it's been posted: https://hn.algolia.com/?query=The%20Death%20of%20Microservic...
An improvement to the Hacker news website would be to compute and compare hashes of weblinks so that the same link is not reposted multiple times. Later posters of links could then be redirected to the first post of a link.
Earlier quoted context omitted.
Jesus, 10 people on a team? What are you doing that you need 10 people to work on it? I manage like 8 services by myself.
That's nothing. I once ran 20 services before breakfast.
seq 21 | while read port; do
python2 -m SimpleHTTPServer 80$port &
doneBiggest issue with microservices: "Microservices can be monoliths in disguise" -- I'd omit the can and say 99% of the time are . It's not a microservice if you have API dependencies. It's (probably) not a microservice if you access a global data store. A microservice should generally not have side effects. Microservices are supposed to be great not just because of the ease of deployment, but it's also supposed to mak…
> A microservice should generally not have side effects I gotta ask, how is this realistic? A salient feature of most of the software I've worked on is that it has useful side effects.
Whether it should consume other microservices is less clear, and gets into the choreography vs. orchestration issue; choreography provides lower coupling, but may be less scalable.