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

111–120 of 410 posts

Re: The costs of microservices (2020)

#111

Post by jacquesm »

insanitybit wrote: post #99
jacquesm wrote: post #95

Earlier quoted context omitted.

You establish a process before you need it, and code review, especially when starting up is a fantastic way to make sure that everybody is on the same page and that you don't end up with a bunch of latent issues further down the line. The fact that they have no customers today doesn't mean that they won't have any in the future and mistakes made today can cause downtime further down the line. If you're wondering why…

I'm not advocating for having no processes, I'm advocating for a process that matches their situation. A company with no customers should not be worrying about causing a production outage, they should be worried about getting a demoable product out. Dogmatic adherence to a process that limits developer velocity and optimizes for correct code is very likely the wrong call when you have no customers.

If it is dogmatic, then yes: but you have no knowledge of that and besides there are always people who believe there is too much process and there are people that there is too little. If you want to challenge the process you do that by talking about it not by breaking the process on purpose. That's an excellent way to get fired.

I don't know the context and I don't know the particular business the OP is talking about. What I do know is that if you feel that your management is cargo culting development methodology (which really does happen) you can either engage them constructively or you can leave for a better company. Going in with a confrontational mindset isn't going to be a good experience for anybody involved. Case in point: the OP is still upset enough that he feels it necessary to vent about this in an online forum.

Note that this is the same person who in another comment wrote:

"On the flip side I’m trying to convince my CTO to fire half our engineering team - a group of jokers he hired during the run-up who are now wildly overpaid and massively under-delivering. With all the tech talent out there I’m convinced we’d replace them all within a week."

Re: The costs of microservices (2020)

#112

Post by nevinera »

insanitybit wrote: post #54
nevinera wrote: post #46

Earlier quoted context omitted.

That's technical, and not architectural. I'm _all about_ technical solutions to lack of discipline, and in fact I think technical and process solutions are the only immediate way to create cultural solutions (which are the long-term ones). I'd even consider minor increases to architectural complexity for that purpose justifiable - it's a real problem, and trading to solve it is reasonable. But architectural complexit…

Can you explain the salient distinction between a "technical" versus "architectural" solution? Candidly, I'm not convinced that there is one. > But architectural complexity has outsized long-term cost As do technical solutions, of course. CI/CD systems are very expensive, just from a monetary perspective, but also impose significant burdens to developers in terms of blocking PRs, especially if there are flaky or expe…

> Can you explain the salient distinction between a "technical" versus "architectural" solution? Candidly, I'm not convinced that there is one.

Not concisely in the general case, but in this case the difference is fairly straightforward - CI/CD doesn't affect the structure of your executing application at all, only the surrounding context. I don't want to spend the hours it would take to characterize architecture as distinct from implementation, but the vast number of textbooks on the topic all generally agree that there is one, though they draw the lines in slightly different places.

> I think what you're saying amounts to,

Very much no - my point is about the process of implementation. The services.. _do_ enforce boundaries, but the boundaries they enforce may not be good ones.

In order to successfully extract services from a monolith, you have to go through a process that includes finding and creating those domain boundaries for the domain being extracted. If it's your first time, you might be doing that implicitly and without realizing it's what you're doing, but under the hood it's the bulk of the mental effort.

The part where you actually _introduce a service_ can be anywhere from a tenth to half of the work (that fraction varies a lot by technical stack and depending on how coupled the domain in question is to the central behavioral tangle in the monolith), but by the time you've gotten the domain boundary created you've _already solved_ the original problem. Now you're facing a trade of "extract this well-factored domain out to a separate service application, to prevent its now-clear boundaries from being violated in the future". And I contend that that's a trade that should rarely be made.

Re: The costs of microservices (2020)

#113

Post by elzbardico »

vrosas wrote: post #40
insanitybit wrote: post #26

Earlier quoted context omitted.

> Increasing architectural complexity to enforce boundaries is never a solution to a lack of organizational discipline, And yet we do this all the time. Your CI/CD blocking your PRs until tests pass? That's a costly technical solution to solve an issue of organizational discipline.

The other problem is that these self-imposed roadblocks are so engrained in the modern SDLC that developers literally cannot imagine a world where they do not exist. I got _reamed_ by some "senior" engineers for merging a small PR without an approval recently. And we're not some megacorp, we're a 12 person engineering startup! We can make our own rules! We don't even have any customers...

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 completely unexpected consequences, and sometimes all it would take to avoid would someone else seeing it from another perspective.

Re: The costs of microservices (2020)

#114

Post by hermanradtke »

simonw wrote: post #85
sethammons wrote: post #21

Earlier quoted context omitted.

another reason why you provide data only over API - don't reach into my tables and lock me into an implementation.

An approach I like better than "only access my data via API" is this: The team that maintains the service is also responsible for how that service is represented in the data warehouse. The data warehouse tables - effectively denormalized copies of the data that the service stores - are treated as another API contract - they are clearly documented and tested as such. If the team refactors, they also update the scripts…

This same thing can be applied to contracts when firing events, etc. I point people to https://engineering.linkedin.com/distributed-systems/log-wha... and use the same approach to ownership.

Re: The costs of microservices (2020)

#115

Post by nevinera »

jcstauffer wrote: post #104
nevinera wrote: post #46

Earlier quoted context omitted.

That's technical, and not architectural. I'm _all about_ technical solutions to lack of discipline, and in fact I think technical and process solutions are the only immediate way to create cultural solutions (which are the long-term ones). I'd even consider minor increases to architectural complexity for that purpose justifiable - it's a real problem, and trading to solve it is reasonable. But architectural complexit…

I would hope that there is more process in place protecting against downtime than code review - for example automated tests across several levels, burn-in testing, etc. People are not reliable enough to leave them as the only protection against system failure...

Did you mean to reply to somebody else? I'm a huge believer in automated testing, and if I said something that can be interpreted otherwise I'd like to clarify it.

Re: The costs of microservices (2020)

#116

Post by avandekleut »

We started with a microservices architecture in a greenfield project. In retrospect we really should have started with a monolith. Every 2-3 days we have to deal with breaking changes to API schemas. Since we’re still pre-production it doesn’t make sense to have a dozen major versions up side-by-side, so we’re just sucking up the pain for now. It’s definitely a headache though.

We also are running on AWS API Gateway + lambda so the availability and scalability are the same regardless of monolith or not…

Re: The costs of microservices (2020)

#117

Post by holoduke »

I think that chunking up your application layer into smaller parts is always a good idea. But when do you say its a microservice? When its completely isolated, with its own database etc. Are many small applications running as seperate binaries/processes/on different ports talking to one database endpoint also microservices?

Re: The costs of microservices (2020)

#118

Post by simonw »

hermanradtke wrote: post #114
simonw wrote: post #85

Earlier quoted context omitted.

An approach I like better than "only access my data via API" is this: The team that maintains the service is also responsible for how that service is represented in the data warehouse. The data warehouse tables - effectively denormalized copies of the data that the service stores - are treated as another API contract - they are clearly documented and tested as such. If the team refactors, they also update the scripts…

This same thing can be applied to contracts when firing events, etc. I point people to https://engineering.linkedin.com/distributed-systems/log-wha... and use the same approach to ownership.

Yeah, having a documented stream of published events in Kafka is a similar API contract the team can be responsible for - it might even double as the channel through which the data warehouse is populated.

Re: The costs of microservices (2020)

#119

Post by mjr00 »

simonw wrote: post #61
mjr00 wrote: post #47

Earlier quoted context omitted.

> they were relying on reports generated from a data warehouse which incorporated a copy of that MySQL database and was being populated by an undocumented, not-in-version-control cron script running on a PC under a long-departed team member's desk. This definitely happens but at some point someone with authority needs to show technical leadership and say "you cannot do this no matter how desperately you need those re…

A lot of organizations are screwed.

I do agree with that. Microservices are not a good idea whatsoever for organizations with weak senior technical people. Which is probably 90%+ of businesses.

Re: The costs of microservices (2020)

#120

Post by rmbyrro »

eduction wrote: post #89
lr4444lr wrote: post #27

Don't disagree with the article, but to play Devil's Advocate, here are some examples of when IME the cost IS worth it: 1) there are old 3rd party dependency incompatibilities that you can spin off and let live separately instead of doing a painful refactor, rebuilding in house, or kludgy gluing 2) there are deploy limitations on mission critical high available systems that should not hold up other systems deployment…

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?

Exactly my thoughts
Post reply on HN