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

Some thoughts on microservices

filipnikolovski.com

Post reply on HN
Print view View original

41–50 of 139 posts

Re: Some thoughts on microservices

#41

Post by WJW »

foobarian wrote: post #28
wongarsu wrote: post #18

Earlier quoted context omitted.

Plenty of languages offer modularity, message queues and asynchronous events within a monolith. They are quite idiomatic in go, rust and elixir

Splitting a system into microservices can help individual teams be better stewards of their part of the system. They can release on their own schedule, they can use their own linting rules, heck even a different language, and they can have better control of incoming code changes. With a monolith any random developer can go and flip some private method to public, import it way across the modules, and presto you are no…

If you don't even have CI/CD yet I'll argue that your team has not reached the operational sophistication required for microservices yet. There are many ways in which microservices

Also if individual devs can reach out across the codebase and turn private methods public, it is the pull request review procedure that you need to improve, not the architecture.

Re: Some thoughts on microservices

#42

Post by bestcoder69 »

samwillis wrote: post #32

“The longer I’m in tech, the more I’m convinced microservices were a technical solution to an organizational problem.” @carnage4life on Twitter https://mobile.twitter.com/carnage4life/status/1311702322024... Now, I’ve not had the pleasure of working in an organisation using Microservices and so I’m only informed anecdotally. But I always assumed they where best used as an API boundary between teams, rather than addin…

Imagine if all of AWS was a single executable file, but had to handle all the same scale, complexity, and release velocity. The S3 team would have to patiently coordinate with the… like… SageMaker team to figure out how big of servers they need, along with every other single possible shared concern.

I picked a ridiculous example there. But just trying to show that if you need services, it should be easy to argue for them on the merits, because it’s gonna be the least bad option.

Re: Some thoughts on microservices

#44

Post by drunkpotato »

foobarian wrote: post #28
wongarsu wrote: post #18

Earlier quoted context omitted.

Plenty of languages offer modularity, message queues and asynchronous events within a monolith. They are quite idiomatic in go, rust and elixir

Splitting a system into microservices can help individual teams be better stewards of their part of the system. They can release on their own schedule, they can use their own linting rules, heck even a different language, and they can have better control of incoming code changes. With a monolith any random developer can go and flip some private method to public, import it way across the modules, and presto you are no…

Yes, that is the marketing brochure pitch for microservices.

In the real world, poorly designed microservices make the ball of mud problem much, much worse, and whatever pain you had in deployments in a monolith are now magnified ten-fold. I have not been fortunate enough to see well-designed microservices, so I suspect the ball of mud is the default. Can this be rectified through discipline? Probably, but I haven't seen it.

Asynchronous? Doesn't save you, when an upstream service changes event definitions and emits events with unexpected structure, and a downstream service starts failing. Can this be rectified through Async OpenAPI and rigorous contract testing? Probably, but I haven't seen this happen in a way that helps.

I have seen large companies survive perfectly well on a monolithic ball of mud, and small companies get lost in a mud pit of microservices.

My point is not that microservices are bad, they're not, they're just a tool, but they are a tool that is a poor fit for most companies, in my opinion. I can't speak to the few giant companies that need them and use them effectively; there is a good reason the tool exists.

Re: Some thoughts on microservices

#45

Post by tomrod »

Hey! I enjoyed this post a lot. I agree with almost all your points raised except for single-team == no microservices. Your prose makes your points easy to understand.

I have a couple layout comments:

First, I love that you have a high contract text-to-background. That is really helpful for me. There was/is a trend to have light gray on white backgrounds for blogs; this is absolutely a terrible pattern. I appreciate that you did not go this route.

Second: serif fonts are difficult to read when the font size is relatively small. Something like Jura or similar could maintain the "terminal" feel without getting bogged down in serifs.

Third: I have a really hard time reading content when it uses smaller fonts and uses a minor fraction of the screen. This is what I see: https://imgur.com/a/NPCBkHJ -- I am getting older, and reading smaller fonts is increasingly difficult for me. I tend to keep my zoom at 150%, something about this page forced it back to 100%. I am not well versed in responsive design, so I don't know the technical details for it, but having zoom maintain or using a larger font would save some cognitive cost to older users like myself needing to zoom in.

Thanks for your thoughts on microservices!

Re: Some thoughts on microservices

#46

Post by amelius »

acjohnson55 wrote: post #24

Microservices are not a solution, they're a capability. It's powerful for a team to be able to deploy a tiny service with the absolute minimum amount of explicit plumbing to meet operational requirements. Whether they should break their system up this way is a case by case judgment. Every place I've been, the costs of microservices get overlooked in favor of the illusion of decoupling. Microservices will absolutely m…

Your first question in a job interview should be: "do you use microservices?" If the answer is yes, you can save yourself a lot of time.

Re: Some thoughts on microservices

#47

Post by mumblemumble »

amelius wrote: post #46
acjohnson55 wrote: post #24

Microservices are not a solution, they're a capability. It's powerful for a team to be able to deploy a tiny service with the absolute minimum amount of explicit plumbing to meet operational requirements. Whether they should break their system up this way is a case by case judgment. Every place I've been, the costs of microservices get overlooked in favor of the illusion of decoupling. Microservices will absolutely m…

Your first question in a job interview should be: "do you use microservices?" If the answer is yes, you can save yourself a lot of time.

I know microservices have passed the excitement phase of the hype cycle, but they're not useless. One of the most enjoyable systems I've worked on was a microservice architecture.

That said, I'm going make some wild inferences about what you were getting at in ordet to say that I agree that a microservice architecture is probably a solution in search of a problem in most cases. And, even in the cases where it is a good option, I can see all sorts of ways to mess up the implementation. The article is right; the trickiest things to get right about microservices are actually organizational issues, not technical ones. My hot take is that dev teams who are considering adopting microservices should take a serious look at how much ability they have to influence the org chart and inter-team and inter-departmental communication. If management is strictly something that happens to them, I would not give them stellar odds of achieving sustainable success with microservices. Perhaps some other form of SOA, but not actual microservices.

Re: Some thoughts on microservices

#48

Post by ratww »

foobarian wrote: post #28
wongarsu wrote: post #18

Earlier quoted context omitted.

Plenty of languages offer modularity, message queues and asynchronous events within a monolith. They are quite idiomatic in go, rust and elixir

Splitting a system into microservices can help individual teams be better stewards of their part of the system. They can release on their own schedule, they can use their own linting rules, heck even a different language, and they can have better control of incoming code changes. With a monolith any random developer can go and flip some private method to public, import it way across the modules, and presto you are no…

> With a monolith any random developer can go and flip some private method to public, import it way across the modules, and presto you are now building a ball of mud.

If "any developer" can do it, then the problem is not with monoliths, but rather with your pull request reviews process and lack of code ownership. This can even be helped by Github and other platforms with a CODEOWNERS file.

Microservices by themselves doesn't solve this problem. If anyone has commit access to all micro services, then they can make an even bigger mess, the same way.

Re: Some thoughts on microservices

#49

Post by nunez »

OP makes a really good point in that dev teams also need to own their infrastructure when everything is a microservice. Asking "DevOps" to change an infra component prior to a release just shifts the monolith under the rug while also completely defeating the point of DevOps.

Lots of devs don't know infrastructure that well, though this is changing with the adoption of Kubernetes. Additionally, most devs don't want to go on-call when their app crashes unexpectedly.

Re: Some thoughts on microservices

#50

Post by throwaway984393 »

recursivedoubts wrote: post #25

Microservices means just that: tiny, single purpose services that deploy and scale on their own. I often see appeals to Conway's Law when discussing microservices, but teams don't organize themselves this way. Instead, teams work on a macro services: the email delivery team, or the monitoring team, or whatever. In most cases these macroservices would be best implemented and deployed as a monolith, and then presented…

^ This. Microservices are introduced because it seems like they'll be able to decouple and scale well, and then they make mistakes that make everything even harder than if it'd stayed a monolith.

Usually they don't plan for how they'll coordinate their work, and that leaves gaps in the design, and puts more risk on the business.

  Team A:
       ↑                    Email product:
     __|_____________        ↑          Service C
On top of that, they don't even make a true microservice. They start directly calling into each others' data rather than interface at an API layer, they make assumptions about how each other works, they don't do load testing or set limits or quotas... and because none of them understand the rest of the system, they don't see that their mutual lack of understanding is the cause of their problems.

Even with multiple teams, if they're forced to work inside a monolith, there's a much better chance they will by accident come to understand the rest of the system.

Post reply on HN