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

The costs of microservices (2020)

robertovitillo.com

Post reply on HN
Print view View original

401–410 of 410 posts

Re: The costs of microservices (2020)

#401

Post by jeltz »

vrosas wrote: post #149
elzbardico wrote: post #113

Earlier quoted context omitted.

Really man. I have almost two decades developing software and yet, I feel a lot more comfortable having all my code reviewed. If anything I get annoyed by junior developers in my team when they just rub-stamp my PRs because supposedly I am this super senior guy that can't err. Code Reviews are supposed to give you peace of mind, not being a hassle. During all this time, I've seen plenty of "small changes" having comp…

Not a man. I’m not convinced bad code would get merged more often if we didn’t require approvals. I am convinced we’d deliver code faster though, and that’s what I’m trying to optimize for. Your company and engineering problems are not the same as mine.

Optimizing for delivering faster is usually the wrong thing to optimize for. Usually the issue is making sure the right things are delivered.

Re: The costs of microservices (2020)

#402

Post by namaria »

shados wrote: post #342
eduction wrote: post #89

Earlier quoted context omitted.

Wouldn't this just be "having one or two services"? I don't think that's the same as "microservices". Correct me if I'm wrong, but isn't "microservices" when you make internal components into services by default , instead of defaulting to making a library or class?

It's a pretty common issue. If you have 2-3 services, it's pretty easy to manage. And if you have 1000, you likely have the infra to manage them and get the full benefit. But if you have 20 engineers and 60 services, you're likely in a world of pain. That's not microservices, it's distributed monolith and it's the one model that doesn't work (but everyone seems to do)

I have worked with a company that had around 8 developers and 30 'microservices'. They wanted the front end team (fully remote, overseas, different language, culture) to go micro front end. They are awesome at presentations and getting funded tho. A common theme in European startups.

Re: The costs of microservices (2020)

#403

Post by sazz »

buster wrote: post #391
sazz wrote: post #369

Earlier quoted context omitted.

"There might be a good reason to have independent deployable, testable and releaseable units" Of course this is the bottom line. But everything you define in the sentence can be achieved with a proper pipeline and repository architecture based on a monolith as well. For example teams could use a branch setup where they own their own team branches capable of merging to master and deploying. Each team could then define…

First, you offer technical solutions (pipelines, branching...).. The cost of having multiple teams branching and merging the same code base can be significant. It's often not as easy as you make it sound.

In the end it is exactly the same technical complexity, it is just shifting complexity from point to another.

A proper branching strategy is not a technical solution but a social alignment of people contributing to common product. And it doesn't matter if they are contributing on different repositories or on the different branches. The technical complexity of aligning interfaces is the same in both cases.

"It's often not as easy as you make it sound."

No, it's of course not easy. But the costs in splitting teams up into different repositories and aligning their interfaces is not easy either. My point is they are both the same - just expressed differently.

Re: The costs of microservices (2020)

#405

Post by shados »

alrs wrote: post #344
shados wrote: post #342

Earlier quoted context omitted.

It's a pretty common issue. If you have 2-3 services, it's pretty easy to manage. And if you have 1000, you likely have the infra to manage them and get the full benefit. But if you have 20 engineers and 60 services, you're likely in a world of pain. That's not microservices, it's distributed monolith and it's the one model that doesn't work (but everyone seems to do)

A "microservice" solves scaling issues for huge companies. If you have 60 microservices, you should probably have 600 engineers (10 per) to deal with them. If you're completely underwater and have 10 services per engineer, you're 100% absolutely play-acting "web-scale" for an audience of really dumb managers/investors.

With proper devops tooling and a half decent design, even a junior engineer can manage several microservices without issues. Since microservices are about scaling people as much as they are about scaling tech, 10 people in one service is a lot to me in that world.

The best company I worked at had about 5-10 deployable per engineers on average and it worked really well. They were small, deployed almost instantly, dependencies were straightforward, etc.

Monoliths work fine too, it's just different tradeoffs.

Re: The costs of microservices (2020)

#406

Post by shados »

jabradoodle wrote: post #351
devjab wrote: post #347

Earlier quoted context omitted.

It depends on how you do it. We have 5 engineers and around 50 services and it’s much easier for us to maintain that than it was when it was monolith with a couple of services on top. Though to understand why this is, you would have to know just how poorly our monolith was designed. That’s sometimes the issue with monoliths though, they allow you to “cut corners” and suddenly you end up with this huge spiderweb mess…

> designed. That’s sometimes the issue with monoliths though, they allow you to “cut corners” I find this hard to relate to, the idea you have the discipline and culture to do microservices well if you can't do it with a monolith. More likely is you migrate away from the monolith you never invested in fixing, and once you get to microservices you either call it a mistake and migrate back, or you have to eventually fi…

The thing with microservices is that shit doesn't have to infect everything. If someone in another team is clueless, they'll mess up their microservices but not anyone else's. If they are in a monolith, it's 50/50 based on how much clout they have (either they mess it up for everyone, or they get talked down and don't get to mess up their stuff either).

Unless it's a shared library, which is why good microservices architecture limit the shared surface as much as possible.

Re: The costs of microservices (2020)

#407

Post by deterministic »

> As the number of feature teams contributing to the same codebase increases, its components become increasingly coupled over time.

Nope. Not automatically true. Unless your development team is incompetent. And if your development team is incompetent, switching to micro-services will be even worse.

30+ years of experience here working on very large scale software composed of libraries from many teams. I never ever had the kind of monolith problems described in the article.

What I have seen though is a 30+ years old micro-services system that generates more WTF comments per day than most software gets per month. It is literally the worst written software I have ever seen or heard about. 150+ micro-services all failing in new random ways every single day. Solving a problem that monoliths I have worked on solved way better.

Re: The costs of microservices (2020)

#408

Post by lemmsjid »

cpill wrote: post #399
lemmsjid wrote: post #223

Earlier quoted context omitted.

If the monolithic application is written in a language with sufficient encapsulation and good tooling around multi-module projects, then you can indeed have well known and encapsulated interfaces within the monolith. Within the monolith itself you can create a DAG of enforced interfaces and dependencies that is logically identical to a set of services from different codebases. There are well known design issues in mo…

> It takes effort to keep a monolithic application set up this way Yeah, this is the problem and _why_ I think microservices are the way forward as it doesn't take effort because the programmer is forced into do the right thing. On project with many different types of coders (and lets face it we are all different) consistency drops off fast. Of course you can do it with monoliths but I'm coming from a "real world" sc…

My instinct from your response is that if we chatted on this for a bit in person we'd see eye to eye and we're probably thinking of different use cases, because I can see how thoughtful you are and usually it comes down to thinking about particular problems in particular companies. So at the risk of going back into crass generalizations, I do persist in thinking that the TCO of a monolith is lower under a lot of the constraints you're describing, assuming (big emphasis) the tooling of the language you're using for the monolith, i.e. a combination of linters and compiler, can enforce the rules. I've been in service-first environments where the equivalent of not caring about code quality in the monolith is firing up a new service without consideration for refactoring the older service, until I am in endless architecture meetings about how to make cross cutting changes around a bunch of services everyone regrets creating.

I suppose in the end it comes down to the classic issue of needing to pay down of tech debt, which is true in any software ecosystem.

Re: The costs of microservices (2020)

#409

Post by jabradoodle »

shados wrote: post #406
jabradoodle wrote: post #351

Earlier quoted context omitted.

> designed. That’s sometimes the issue with monoliths though, they allow you to “cut corners” I find this hard to relate to, the idea you have the discipline and culture to do microservices well if you can't do it with a monolith. More likely is you migrate away from the monolith you never invested in fixing, and once you get to microservices you either call it a mistake and migrate back, or you have to eventually fi…

The thing with microservices is that shit doesn't have to infect everything. If someone in another team is clueless, they'll mess up their microservices but not anyone else's . If they are in a monolith, it's 50/50 based on how much clout they have (either they mess it up for everyone, or they get talked down and don't get to mess up their stuff either). Unless it's a shared library, which is why good microservices a…

> it's 50/50 based on how much clout they have (either they mess it up for everyone, or they get talked down and don't get to mess up their stuff either

This still happens with microservices though; people can still make terrible architecture decisions and standup terrible services you depend on.

Re: The costs of microservices (2020)

#410

Post by jabradoodle »

devjab wrote: post #374
jabradoodle wrote: post #351

Earlier quoted context omitted.

> designed. That’s sometimes the issue with monoliths though, they allow you to “cut corners” I find this hard to relate to, the idea you have the discipline and culture to do microservices well if you can't do it with a monolith. More likely is you migrate away from the monolith you never invested in fixing, and once you get to microservices you either call it a mistake and migrate back, or you have to eventually fi…

With the microservice architecture it’s easier to lock things down. You can’t have someone outside of your team just give access to a dataset or similar because excel can’t get a connection directly into your DB. Which is an argument you could rightfully make for monoliths, except in my experience, someone always finds a sneaky way into the data on monoliths, but it’s too hard for them to do so with MicroServices. If…

It's not like microservices don't also give you chances to mess your data up. It's hard to do transactions across boundaries, you have to deal with eventual consistency, sometimes there is no single source of truth.

I struggle to see how microservices fix this for people; having worked primarily with them for the past 6 years.

Post reply on HN