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

231–240 of 410 posts

Re: The costs of microservices (2020)

#231

Post by namtab00 »

nevinera wrote: post #134
insanitybit wrote: post #91

Earlier quoted context omitted.

> Your 'senior' engineer is likely right: they are trying to get some kind of process going and you are actively sabotaging that Why? Because it's a "good practice"? They have 12 people and no customers, they can almost certainly adopt a very aggressive developer cycle that optimizes almost exclusively for happy-path velocity. You'd never do that at 50+ engineers with customers but for 12 engineers who have no custom…

With no customers, one of the purposes of code-review is removed, but it's the lesser one anyway. The primary goal of code-review should _not_ be to "catch mistakes" in a well-functioning engineering team - that's a thing that happens, but mostly your CI handles that. Code-review is about unifying approaches, cross-pollinating strategies and techniques, and helping each other to improve as engineers. Your attitude to…

I cannot agree more, and have nothing to add except "can I work with you?"..

Re: The costs of microservices (2020)

#232

Post by starttoaster »

iterateoften wrote: post #226
starttoaster wrote: post #222

Earlier quoted context omitted.

> Wouldn't it be a hell of a lot easier if it was all in one place where each commit is globally consistent? I always find this sentence to be a bit of a laugh. It's so commonly said (by either group of people with a dog in this fight) but seemingly so uncommonly thought of from the other group's perspective. People that prefer microservices say it's easier to change/rewrite code in a microservice because you have a…

Not so much a ball of yarn but more like the cabling coming out of a network cabinet. It can be bad and a big mess if you let it, but most professionals can organize things in such a way that maintenance isn’t that hard.

Well, the point I was making was that the same can easily be true of microservice architectures. If you have people that don't know what they're doing architecting your microservices, you'll have a difficult time maintaining them without clear and strict service contracts.

It's not clear to me that we're ever comparing apples to apples in these discussions. It would seem to me that everyone arguing left a job where they were doing X architecture the wrong way and now they only advocate for Y architecture online and in future shops.

Re: The costs of microservices (2020)

#233

Post by disintegore »

starttoaster wrote: post #222
bob1029 wrote: post #157

> And think of the sheer number of libraries - one for each language adopted - that need to be supported to provide common functionality that all services need, like logging. This is the #1 reason we quit the microservices game. It is simply a complete waste of mental bandwidth to worry about with the kind of tooling we have in 2023 (pure cloud native / infiniscale FaaS), especially when you have a customer base (e.g…

> Wouldn't it be a hell of a lot easier if it was all in one place where each commit is globally consistent? I always find this sentence to be a bit of a laugh. It's so commonly said (by either group of people with a dog in this fight) but seemingly so uncommonly thought of from the other group's perspective. People that prefer microservices say it's easier to change/rewrite code in a microservice because you have a…

I've noticed that a lot of industry practices demonstrate their value in unexpected ways. Code tests, for instance, train you to think of every piece of code you write as having at minimum two integrations, and that makes developers who write unit tests better at separating concerns. Even if they were to stop writing tests altogether, they would still go on to write better code.

Microservices are a bit like that. They make it extremely difficult to insert cross cutting concerns into a code base. Conditioning yourself to think of how to work within these boundaries means you are going to write monolithic applications that are far easier to understand and maintain.

Re: The costs of microservices (2020)

#234

Post by Aerbil313 »

Looking at the “costs” section and considering the recent developments, it seems better tooling will increasingly be helpful in running a software company. See for example Nix Flakes. You can now have instant and performant declaratively defined identical environments in production and development, and across teams.

IMHO widespread use of such technologies (as opposed to heavyweight ones like Docker) could relieve one of the biggest costs of microservices: They are expensive to run.

Re: The costs of microservices (2020)

#235

Post by wholesomepotato »

paulddraper wrote: post #63

> The term micro can be misleading, though - there doesn’t have to be anything micro about the services. In fact, I would argue that if a service doesn’t do much, it just creates more operational toll than benefits. A more appropriate name for this architecture is service-oriented architecture, but unfortunately, that name comes with some old baggage as well. What baggage is that? Because in my experience 90% of the…

https://www.service-architecture.com/articles/web-services/s...

After enough people retire that remember how big of a mess this was, we can probably re-use "Service Oriented".

Re: The costs of microservices (2020)

#236

Post by manicennui »

998244353 wrote: post #219
manicennui wrote: post #121

Earlier quoted context omitted.

I just wanted to note that static typing isn't required for autocomplete. JetBrains has IDEs for languages like Ruby and Python that can do it. If you open the REPL in a recent version of Ruby you get much of what you expect from an IDE with a statically typed language (with regards to autocomplete and syntax checking).

You are correct, but static typing does make it a lot easier. Working with Rider feels like working with an IDE that fully understands the code, at least structurally. Working with PyCharm feels like working with an IDE that makes intelligent guesses.

The REPL in current versions of Ruby is probably a better example of how it should be done. Because it is actually running the code it has much better information.

https://ruby-doc.org/core-3.1.0/NEWS_md.html#label-IRB+Autoc...

Re: The costs of microservices (2020)

#237

Post by ValtteriL »

bob1029 wrote: post #197
tsss wrote: post #185

Earlier quoted context omitted.

No one says you can't have all of your microservices use the same language...

Absolutely. This is how we operated when we were at the peak of our tech showmanship phase. We had ~12 different services, all .NET 4.x the exact same way. This sounds like it could work, but then you start to wonder about how you'd get common code into those 12 services. Our answer at the time was nugets, but we operate in a sensitive domain with proprietary code, so public nuget services were a no go. So, we stood…

Can't you share them via shared libraries in .NET?

Re: The costs of microservices (2020)

#238

Post by tsss »

ljm wrote: post #230
tsss wrote: post #185

Earlier quoted context omitted.

No one says you can't have all of your microservices use the same language...

Ideally you would use the same language if it had distributed support. Use Erlang or Elixir for example and you have everything you need for IPC out of the box. Might take a little bit more effort if you're on Kubernetes. One of my problems with microservices isn't really the services themselves, but the insane amount of tooling that creeps in: GRPC, Kafka, custom JSON APIs, protobufs, etc. etc. and a lot of them exi…

If you do so much IPC that you have to design your language around it you're probably doing it wrong. I don't think that moving to a monolith would really cut down that much on other technologies. Maybe you can do without Kafka, but certainly you will need some other kind of persistent message queue. You will still need API docs and E2E integration tests.

Re: The costs of microservices (2020)

#239

Post by Aerbil313 »

elevation wrote: post #193
wnolens wrote: post #123

If a monolith is well-factored, what is the difference between it and co-located microservices? Probably just the interface - function calls become RPC. You accept some overhead for some benefits of treating components individually (patching!) What is the difference between distributed microservices v.s. co-located microservices? Deployment is more complex, but you get to intelligently assign processes to more optima…

Monolith->microservice is not a trivial change no matter how well-factored it is to begin with -- though being poorly architected could certainly make the transition more difficult! > Probably just the interface - function calls become RPC. This sounds simple, but once "function calls become RPC" then your client app also needs to handle: * DNS server unreachable * DNS server reachable but RPC hostname won't resolve…

Honestly we just need better tooling. Where is my micro-service-fleet creator, which handles built-in all these failure modes of RPC calls?

Re: The costs of microservices (2020)

#240

Post by flakes »

ph4evers wrote: post #227

I still don’t fully understand what makes something a monolith. For example, I have a big app which is serving 90% of the API traffic. I also have three separate services, one for a camera, one to run ML inference, and one to drive a laser welding process. They are split up because they all need specific hardware and preferably a separate process (one per gpu for example). Is this a monolothic app or a micro service…

I would call that a micro-service architecture using a mono-repo.

I think a lot of people here are conflating mono-repo/poly-repo with a mono-deployment. You can easily add in extra entrypoint executables to a single mono-repo. That allows initiating parts of the system on different machines, allowing scaling for skewed API rates across your different request handlers.

Similarly, you can create a monolith application building from a poly-repo set of dependencies. This can be easier depending on you version control system, as I find git starts to perform really poorly when you enter multi-million SLOC.

At my job we have a custom build system for poly-repos that analyzes dependencies and rebuilds higher level leaf packages for lower level changes. Failing a dependency rebuild gets your version rejected, keeping the overall set of packages green.

Post reply on HN