Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Microservices are hard

code-held.com

Post reply on HN
Print view View original

31–40 of 356 posts

Re: Microservices are hard

#31

Post by hdjjhhvvhga »

monero-xmr wrote: post #10

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?

> Why have a single database when we can silo our data across 200 mini databases?

First, many orgs using, say, Kubernetes still run their database separately in a traditional way with replicas etc. Second, those who do run their DB inside Kubernetes, probably using an operator, gain scalability and additional resiliency (it also depends on the DB, but these days even PostgreSQL operator works quite reliably).

Re: Microservices are hard

#32

Post by randomdata »

quonn wrote: post #26
randomdata wrote: post #7

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?

Microservices is a collection of independent teams who only communicate using well defined APIs. Those teams may produce libraries, perhaps. That's up to Conway.

Re: Microservices are hard

#33

Post by mirekrusin »

mozey wrote: post #18
gryn wrote: post #15

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

You can organize teams of developers around services.

Re: Microservices are hard

#34

Post by randomdata »

gryn wrote: post #15
randomdata wrote: post #7

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…

So using your definition what is the difference between a module, a service, and a microservice ?

A service is something someone provides. A microservice is much the same, but serves those who offer services to the end user – roughly analogous to a supplier in the physical goods space. A module may be the product of the service rendered.

Re: Microservices are hard

#36

Post by csomar »

jameshart wrote: post #16

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…

What the author or many people miss is that this is still an unsolved problem. We still don’t know how to do this right. Doing it either way results in unmanageable complexity. The same still goes for the front-end. It’s too complex that someone decides to start another JS framework to fix the status quo.

What many people miss is that these attempts are the solution to the problem. People will keep trying different ways until they find the “optimal” (or close) solution and the problem space is solved. React, in some sense, made front-end development at this level of complexity accessible to so many people with little engineering know-how.

Re: Microservices are hard

#37

Post by jacquesm »

jameshart wrote: post #16

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…

This happens a lot. Otoh, sometimes you come across cases where you wonder if you accidentally landed on a different planet. Mid sized project, 500 microservices, 800 repositories...

Re: Microservices are hard

#38

Post by kemiller2002 »

jameshart wrote: post #16

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 don't understand. Why would I build something that isn't correct?

(jk, excellent comment.)

Re: Microservices are hard

#40

Post by jacquesm »

csomar wrote: post #36
jameshart wrote: post #16

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…

What the author or many people miss is that this is still an unsolved problem. We still don’t know how to do this right. Doing it either way results in unmanageable complexity. The same still goes for the front-end. It’s too complex that someone decides to start another JS framework to fix the status quo. What many people miss is that these attempts are the solution to the problem. People will keep trying different w…

Hello there, long time no see! Hope you are doing well! Yes, you are spot on it is an unsolved problem, especially for a business that starts off small and then grows. No matter what stage you observe them at some things will be undersized because they were built in the past, some oversized anticipating growth that may never materialize and hardly any of it will hit the sweet spot. Growth is the killer for any architecture.
Post reply on HN