Microservices are hard • Hacker News Board

Re: Microservices are hard

#331

Post by nullsense » Thu, Jan 12, 2023, 4:18 AM UTC

avip wrote: post #165

sisve wrote: post #158

I really do not understand the debate on monoliths and microservice anymore. Context matters so much. Should you have absolutely everything in 1 system. No. And I think no one thinks that anymore. Should you spilt your system into as many pieces as possible? No, of course not. You are prop. storing files one place and have a data in a database another place. And most likely none are on the webserver receiving request…

Like any other well reasoned, balanced and pragmatic POV, the problem with your boring approach is you can’t wrap it in a clickbaitable blog and no flame war can emerge from it.

It turns out the One Weird Trick is just considering the context.

Re: Microservices are hard

#332

Post by aryehof » Thu, Jan 12, 2023, 5:43 AM UTC

Of course they are hard. Instead of a well modularized application where applicable, lets create multiple distributed programs that need to communicate across an unreliable network.

Why? Because its fashionable, others are doing it, its a safe answer in an interview, its a buzzword (like “agile”) that management loves, and it seems that the only way many can introduce modularity is by making each module a separate program.

Re: Microservices are hard

#333

Post by foepys » Thu, Jan 12, 2023, 6:20 AM UTC

ranting-moth wrote: post #241

foepys wrote: post #136

Earlier quoted context omitted.

If you plan your architecture carefully and modularize a lot, there is very little that will prevent you from branching out modules of a monolith into microservices when the time comes. If you produce spaghetti code with tightly coupled components, well, then you are going to have a problem.

Especially in small startups, you need to make a sensible balance. If you only have funding for 2 months, you need to hack together whatever you can get away with. This is not against modularisation. By all means designs your system well. But don't lose sight of the goal.

If you bet everything on crappy code you will have to rewrite anyways and then I don't see why this discussion matters.

Re: Microservices are hard

#334

Post by gloosx » Thu, Jan 12, 2023, 8:22 AM UTC

Someone tell this boy K8S EXISTS!

My Ingress yaml uses just 50 lines to slice all domains i need, not hard at all. Even if i don't know what to build or do i can spin up ping-pong micro-services in minutes just to let em play and have fun. All this complexity is abstracted to neat things now, like Ingresses, Services, Deployments and so on.

Re: Microservices are hard

#335

Post by nokya » Thu, Jan 12, 2023, 9:50 AM UTC

What a waste of time. Anyone who's not an architect or developer, but regularly works with architects and developers, intuitively reaches these conclusions. And this has been going on and on for almost ten years.

When you watch this from the outside (e.g., let's say, as a consultant called to advise on a very specific aspect of software architectures) it feels like they all follow a secret agreement that instructs them to go full microservices route. Questioning this, even as a consultant paid to do exactly that, is considered unacceptable. It's like questioning your client's religious or political beliefs.

I observe a similar trend with CIOs hired to help institutions digitally transform themselves. Many operate on an "innovative" reasoning that consists in going full cloud and lay off IT personnel, which inevitably leads to increased operating and maintenance costs without exploiting the actual benefits of cloud computing. But it's already too late, Mr/Mrs CIO has already left the org when this happens. And self-congratulating words are already published in their LinkedIn profile.

I often have two thoughts when I attend a pre-sales meeting with a prospect customer that shows us a beautiful microservices architecture:

1. Oh my...

2. Shut up and just take the money they are throwing at your face.

Re: Microservices are hard

#336

Post by nicolaslem » Thu, Jan 12, 2023, 11:34 AM UTC

thatwasunusual wrote: post #325

dagss wrote: post #299

Earlier quoted context omitted.

You mean the few extra megabytes of RAM for some extra compiled code on each node? If you refer to databases: Splitting one service into two services can at most give you a 2x scale-up potential (usually a lot less), and the effect diminishes for 3th, 4th service. Mathematically and logically. Splitting services = vertical scaling. If you want 100x, 1000x scaling you need to invest in true horizontal scaling anyway,…

> You mean the few extra megabytes of RAM for some extra compiled code on each node? Few extra? Have you not considered applications where you need to spin up/down _extremely_ resource intensive instances? A year++ ago I worked on a health-related application which used a system for processing X-ray images. During typical work hour (6 am-6 pm) it required a _huge_ amount of CPU and RAM instances. By shifting those sp…

A monolith is not a giant blob that has to run fully on one instance or else nothing works. Although I'm sure plenty of horrible enterprise software works that way, it is not a property of a monolith.

I maintain a SaaS written as a monolith and I can absolutely spin instances that only load one part of the code and do a single thing, for example some instances only handle MQTT messages while others only serve HTTP endpoints. That does not make it microservices, it is all one code base sharing one database.

Re: Microservices are hard

#337

Post by jredwards » Thu, Jan 12, 2023, 3:32 PM UTC

sisve wrote: post #158

I really do not understand the debate on monoliths and microservice anymore. Context matters so much. Should you have absolutely everything in 1 system. No. And I think no one thinks that anymore. Should you spilt your system into as many pieces as possible? No, of course not. You are prop. storing files one place and have a data in a database another place. And most likely none are on the webserver receiving request…

> My advice would be to split your application up into enough pices so that;

> 1.your engineers feels like they have control over the code and are not afraid of doing changes.

I'd add: split your team up into a similar number of pieces. Your application will come to resemble the shape of your teams, over time. Design your teams based on where you want the boundaries of your application to fall.

Re: Microservices are hard

#338

Post by Lord_Zero » Thu, Jan 12, 2023, 4:18 PM UTC

com2kid wrote: post #263

esailija wrote: post #134

Earlier quoted context omitted.

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

> Funny you said that since a microservice API is always dynamically typed and its usage cannot be checked by compiler. Not true at all, I have a build system in place that when changes are made to Typescript, the JSON Schema on the endpoints is updated, and client libraries are updated. Types are validated at both compile time and runtime. This is just one of many solutions to the problem, there are a lot of ways to…

That sounds like a regular monolith but with extra steps.

Re: Microservices are hard

#339

Post by tetha » Thu, Jan 12, 2023, 4:32 PM UTC

hinkley wrote: post #233

jonhohle wrote: post #174

Earlier quoted context omitted.

I agree completely. The current FAA outage is a good example of this. What if the system responsible for NOTAMs was the same system responsible for sending system outage messages. They weren’t so that status could be communicated while mitigation was done on a system with unrelated concerns. At the same time, a few person startup should probably focus on what allows them to deliver the fastest. I’ve seen that work wi…

We had a major cockup at work a few years ago caused by bad organizational choices and Conway’s Law. We had a disk array go sideways, which is when we learned that some dumb motherfucker had put our wiki on the same SAN with production traffic. You know, the wiki where you keep all your run books for solving production issues? Everyone was furious and that team lost some prestige that day. How dumb do you have to be?

Yeah. For our ops-documentation I also have more of a bottom up approach of keeping it stable, which has resulted in the company having two documentation standards.

Pretty much all of our docs, and everything concerning more than one team is stored in an instance of our own software running on the software plattform. And it works well.

However, the core operational teams document their core operational knowledge in different git-based systems, all of which are backed up into the archiving as well. This way, if we really lose access to all documentation, we probably lost all workstations of a team to some incident, as well as a repository host, as well as two archive hosts in different parts of europe. At that point, the disaster recovery plan is a bar, to be honest.

Re: Microservices are hard

#340

Post by com2kid » Thu, Jan 12, 2023, 6:31 PM UTC

Lord_Zero wrote: post #338

com2kid wrote: post #263

Earlier quoted context omitted.

> Funny you said that since a microservice API is always dynamically typed and its usage cannot be checked by compiler. Not true at all, I have a build system in place that when changes are made to Typescript, the JSON Schema on the endpoints is updated, and client libraries are updated. Types are validated at both compile time and runtime. This is just one of many solutions to the problem, there are a lot of ways to…

That sounds like a regular monolith but with extra steps.

Except each service scales independently, can be updated independently (e.g. pri0 security bugs that require a breaking change can be applied to public IP facing services first), can be written in a different programming language, and can be rolled back/deployed independently.

Working in a microservice environment is nice, newly created services get the latest version of whatever tools are needed, older services can be upgraded as needed. Avoids the problem of being stuck on some ancient version of the JVM or Node.