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

141–150 of 356 posts

Re: Microservices are hard

#141

Post by naasking »

bradhe wrote: post #93
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?

> Microservices - let’s replace as many interfaces as possible with the slowest, flakiest, most complex mechanism - the network layer You do realise that most calls to block storage in AWS result in network traffic, right? The point is, abstraction is your friend.

> The point is, abstraction is your friend.

Yes, but the point they were making is that you don't have to abstract across a network boundary. A proper module system and package management can divide work and organization without introducing IPC overheads.

Re: Microservices are hard

#142

Post by shapefrog »

ranting-moth wrote: post #54
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?

I've seen quite a few people use the argument that their system wouldn't cope otherwise when they reach the size of Google. 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 softwa…

Reaching Google scale means you'll be sat on a beach wondering how to spend your multiple billions - scale is someone else's problem, might as well leave something in it for the next person.

Re: Microservices are hard

#143

Post by KyeRussell »

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?

…Yes?

So many people have very little respect for the effects of the fact that this field is so ridiculously young, including the fact that all of these definitions are incredibly wishy washy.

Being able to take a statement like “an external dependency is a microservice” and not completely discounting the point being made is incredibly valuable.

Re: Microservices are hard

#144

Post by ketchupdebugger »

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 repo when we can have 200 tiny repos?

you could have a monorepo. you just need to build each service independently, which you can do with bazel/gradle/make or other build tools.

Re: Microservices are hard

#145

Post by mgaunard »

There is nothing about microservices that require them to be distributed over the network, it's just something that they enable.

Most of the pain points I hear about microservices are to do with versioning and deploying them independently. But again, this is just enhanced flexibility, you don't have to use it.

Re: Microservices are hard

#146

Post by Retric »

bradhe wrote: post #93
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?

> Microservices - let’s replace as many interfaces as possible with the slowest, flakiest, most complex mechanism - the network layer You do realise that most calls to block storage in AWS result in network traffic, right? The point is, abstraction is your friend.

Latency is additive. You get a small window within which people don’t notice and network calls quickly consume all of it.

Micro services have a few advantages but unless you desperately need them it’s a huge hit to performance, productivity, and reliability unless it’s your only option. Netflix needed it because of their complicated network architecture with servers distributed inside various ISP’s, why do you?

Re: Microservices are hard

#147

Post by dralley »

candiddevmike wrote: post #105
ericalexander0 wrote: post #53

Earlier quoted context omitted.

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...

Linux kernel has a huge amount of contributors with their own goals and they seem to coordinate just fine. Monoliths can scale, but they can't be "owned"/leveraged by leaders/sociopaths into a bigger budget/team/etc, IMO.

The linux kernel is more siloed than one might expect, a lot of code is architecture specific or in drivers, which facilitates having a wide group of maintainers.

Re: Microservices are hard

#148

Post by okamiueru »

esailija wrote: post #134
jerf wrote: post #78

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…

> It may be the sloppiest, crappiest definition every, with dynamic types Funny you said that since a microservice API is always dynamically typed and its usage cannot be checked by compiler. And the more microservices you use the more dynamically typed the whole project gets overall. While you can opt into a free for all everything importing everything, all languages do also support creating modules which define API…

Although true to some extent, this is also a tooling issue. We use OpenAPI and generate clients. Strictly speaking the interoperability layer doesn't know the truth on the other side, but when generated correctly, the developer doesn't need to worry about it.

Re: Microservices are hard

#149

Post by DavorDK »

Trying to keep it simple (to a degree). First of all, I would say that its OK to still have a monolith and even build a whole product as a monolith and break it down as the need for microservices arises.

My understanding of whether or not you should take a monolith and cut it into pieces is that it depends on what you want to achieve.

Every monolith is specific, or are they? Without knowing what your product does I bet you have an API, a UI layer or two, some business logic and maybe throw emailing or a payment service. Well, guess what? We all have those!

How to decide. For myself, I’ve tried to boil it down to 3 questions:

1. Will I need to scale this part of the monolith more (often) than others? 2. Does this part of the monolith handle an entire process on its own from start to finish? 3. Does this part of the monolith require a lot of different code or resources than the other parts?

The questions are simple. They aren't philosophical. They don’t have a hidden meaning. Rather, a series of simple booleans. If something needs to be a microservice it'll most likely hit 3 out of 3 of those.

Re: Microservices are hard

#150

Post by sidlls »

bradhe wrote: post #93
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?

> Microservices - let’s replace as many interfaces as possible with the slowest, flakiest, most complex mechanism - the network layer You do realise that most calls to block storage in AWS result in network traffic, right? The point is, abstraction is your friend.

Overcomplicated abstraction (e.g., DI frameworks) and unnecessary abstraction are not anyone's friends.
Post reply on HN