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

301–310 of 356 posts

Re: Microservices are hard

#301

Post by hot_gril »

John23832 wrote: post #298
hot_gril wrote: post #278

Earlier quoted context omitted.

My org did this, and it ended in disaster because that monolith was shoving everything in the world into a single database the whole time. This created horrible APIs: one team writing into tables that another team is expected to read. They tried to split this later on and created an even bigger mess. There are reasonable places before then to stop and say, we need to keep X new features in a separate service.

That’s still not a microservices vs monolith problem. That’s a bad data stewardship problem. If your data is a mess before you decided to break out functionality, then it’s gonna be hard regardless. You should have good schemas and db organization always.

This issue is about microservices because the one alternative to this DB-level data sharing is having proper RPCs (or more specialized things like pubsub in some cases) between cleanly separated services. If logically separate things are sharing data through the DB itself, you will get a mess even if you're very careful, which they were.

Re: Microservices are hard

#302

Post by dagss »

waselighis wrote: post #130

All of these articles against microservices are so annoying because I rarely see a good argument against microservices. Often the arguments are purely anecdotal and without substance. There are only two good arguments I can make against microservices. First, it's not the right architecture choice for all projects. Second, microservices don't magically solve the problem of complexity. But I can name countless benefits…

"Individual microservices are less complex than monoliths" ... but the sum of microservices is still as complex as the monolith. (But better hope you got your division of domains and services correct!)

"A single developer and work and test it on their local machine" ... OK I've never encountered a monolith that couldn't be run and developed locally. I don't say it was never a problem, but that there must have been other solutions to it than microservices. Surely today's laptops can easily compile and run a million lines of code...

And as the counterpint, I've encountered cases of having to orchestrate 15 different micro-services locally to do anything USEFUL and non-contrived. Something to help you gain some understanding of how the WHOLE system work, and not rely on other people with the full overview to tell you can evolve your small piece of it.

"rapid development" -- fix your build and test caching

"only ... testing a small part of the entire architecture" -- again, with a monolith surely you can focus on a single test function / sub-component and figure out how that works. With micro-services it gets a lot harder to do integration testing across the whole system, and people tend to not do it or argue why it "isn't needed". But keep in mind that also with monoliths it is entirely possible to simple delete/not write the system integration tests. It is just that people tend to want to have them (for good reasons), but with microservices there's a much higher investment needed to get them (and they don't execute any faster, but slower, if you invest in them).

This comes down to an argument of "we make such perfect code we don't need tests..."... just because it is network calls and APIs, doesn't mean that noone ever messes up and does a backwards-incompatible change.

Simply dropping system integration tests and discovering bugs like that in production is an option for monoliths too.

Re: Microservices are hard

#303

Post by hbrn »

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…

> I really do not understand the debate on monoliths and microservice anymore.

> Don't go extreme in any direction. Context context context

That is exactly why debate occurs. All religions, be it microservices or TDD, are taking some good ideas to an extreme and removing context from the decision making process.

Otherwise the term "microservices" wound never be invented: people were doing "services" since the dawn of time. But you can't create hype out of common sense, you have to go to the extremes.

Re: Microservices are hard

#304

Post by Sohcahtoa82 »

John23832 wrote: post #252

Start with a monolith, that will take you VERY far. When the organization gets big enough (AND ONLY THEN), add an additional domain oriented service. FULLY implement deployment and infra. Only once you do that can you think about adding another (using the pattern you just built out). Micro-monoliths. Organizations explode the number of services, half ass the infrastructure (the hard part of microservices), and then c…

> Micro-monoliths.

Would those be the same as macroservices?

Re: Microservices are hard

#305

Post by randomdata »

quonn wrote: post #190
KyeRussell wrote: post #143

Earlier quoted context omitted.

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

It‘s not that young. Chemistry (once it became a real science) is perhaps 250 years old. Computer science is 50-70 years old.

The industry of which we speak is not in the sciences. Maybe engineering. The earliest recognition of software engineering seems to only go back to the 1980s, but there is a lot of debate as to whether it is even that. It's probably closer to gardening. Unfortunately, the industry is too new to have yet fully recognized what it is.

Re: Microservices are hard

#306

Post by John23832 »

hot_gril wrote: post #301
John23832 wrote: post #298

Earlier quoted context omitted.

That’s still not a microservices vs monolith problem. That’s a bad data stewardship problem. If your data is a mess before you decided to break out functionality, then it’s gonna be hard regardless. You should have good schemas and db organization always.

This issue is about microservices because the one alternative to this DB-level data sharing is having proper RPCs (or more specialized things like pubsub in some cases) between cleanly separated services. If logically separate things are sharing data through the DB itself, you will get a mess even if you're very careful, which they were.

You should have a well curated DB regardless of whether one or many domain specific services sit in front of it. That is what would enable you to break a monolith up. Good code and architecture is the result of discipline. Your data is your most valuable asset. What you're describing is a mess.

You mentioned RPC's. Your service interface has nothing to do with the data organization.

But if you think microservices is what would work for you, then you should pursue that next time. My original post was a path to a multiple service architecture that approached service expansion with technical rhyme and reason. It really wasn't aimed at your organizations messy database.

Re: Microservices are hard

#307

Post by Sohcahtoa82 »

sidlls wrote: post #150
bradhe wrote: post #93

Earlier quoted context omitted.

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

From what I understand, DI simply turns this:

    public class MyClass {
       private Dep myDep;
       void MyClass(){
           this.myDep = GetDep();
       }
    }
into this:

    public class MyClass {
       private Dep myDep;
       void MyClass(Dep dep){
           this.myDep = dep;
       }
    }
Why this needs an entire framework is beyond me. It feels like all they do is convert explicit code into boilerplate which then becomes much harder to reason about.

Re: Microservices are hard

#308

Post by __jem »

throwaway9870 wrote: post #258
JAlexoid wrote: post #87

Earlier quoted context omitted.

Microservices is not the same, though.

I don't see that distinction being made. The counter argument is things like libraries vs microservices. Those articles ignore the common case that probably is true for 99% of the apps - we live in a service based architecture. The Internet is service based. Everything an app talks to is service based. So quit arguing about it. Microservices don't address any of the issues I ever faced or people on Hacker News talks…

The idea that no true monolith exists because you didn't write your own kernel is really strange and peculiar. No one has ever claimed that a monolith has 0 external dependencies.

Re: Microservices are hard

#309

Post by JAlexoid »

sisve wrote: post #271
JAlexoid wrote: post #259

Earlier quoted context omitted.

> Should you have absolutely everything in 1 system. Yes, you should build your system initially like that. One team builds one system and splits it out as necessary.

For your core service. I think you are right most of the time. But you are probably not talking about the website marketing wants to build. And you are maybe using S3 or similar for documents storage? And your logging system are probably not on the same machine? But if by "system" you mean the main API + SaaS website or similar yeah. Sounds reasonable. in reality we do so much more now. That I think some part of what…

Using S3 to store and serve documents, RDBMS and Datadog for monitoring+logs - doesn't make a microservice architecture.

That's quite typical "monolith", as the term monolith never means that literally everything is in the codebase.

Re: Microservices are hard

#310

Post by dkarl »

This article doesn't provide any insight into when monoliths might be a better choice than microservices. It just says that if you do microservices you'll make awful mistakes and end up with a bad result.

The word "macroservices" sort of sums up the whole conversation to me. People are so convinced that microservices can't be done right that when they start to do microservices right, they think they need to invent a new name for it.

Everything that can be done successfully can also be done poorly and unsuccessfully. What's the word for walking successfully? Walking. Can you imagine what babies would say about walking if they could blog?

"Walking is an extremely popular and hyped activity that has achieved an impressive amount of mindshare in the past several months. Caregivers appear to be highly invested in walking as a key to unlock unprecedented mobility. However, if you look past the hype to the reality, walking is mostly about falling down, hitting your head, running into things, and crying because you suddenly realized you can't see your caregiver. At DoodooHeadCorp, we have developed a new approach that delivers on the promise of walking, without miring you in all of its failures. We call it realwalking. Realwalking consists of moving from place to place while propelling yourself forward in a dynamically balanced bipedal fashion. Note that by definition realwalking involves moving from place to place, a crucial distinction that guides you away from one of the biggest pitfalls (no pun intended) of walking. Traditional approaches to walking have often resulted in babies standing up and immediately falling backwards into the same place where they started. Horizontal displacement is crucial and too often ignored by babies who have gone down the rabbit hole of walking. This is where realwalking innovates, by leveraging the power of dynamically balanced bipedalism."

Just freakin' say it's hard, you should be prepared to learn along the way, and at every moment your ambitions should be scoped to your capabilities. There's no alternative that can claim differently.

The factors you should consider when considering whether you will be successful with microservices seem to be outside the scope of this blog post, so I won't address them either.

Post reply on HN