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

You Don't Need Microservices

medium.com

Post reply on HN
Print view View original

161–169 of 169 posts

Re: You Don't Need Microservices

#161

Post by barking_biscuit »

_hcuq wrote: post #147
barking_biscuit wrote: post #130

Earlier quoted context omitted.

It turns out the secret is just not writing crappy software and having crappy processes. It turns out the caveat is that the conditional probability of those two things is vanishingly small, so regardless of monolith or microservices, most devs are exposed to crappy stuff and because their sample sizes are tiny they assume well we just did it wrong, when in fact they did it average and average is crappy for any and a…

I wonder if part of the problem is the always new technologies used. Maybe if the world had stuck with some sort of improved version of C and got really good at it, with all kinds of great tools and techniques, we might be able to deliver code efficiently.

I definitely think that's an aspect of it, but it's not one we can really do a whole lot about. The nature of what we do and the skillsets we have mean when we encounter problems we then come up with solutions and those solutions have their own problems, so it just infinitely recurses.

I think that's a lot more controllable on an individual level than on an industry level. I'm sort of attempting to do that myself in some ways by just picking a stack and working my way through building something in it end to end covering absolutely every aspect I can imagine in terms of software engineering "jobs to be done" and as I build it, going through industry go-to resources of how to best do X and properly implementing the advice. I think if more of us bothered to do that we'd be far more capable of starting software companies off at a much more advanced stage of technical maturity and hence with less problems that arise from the hacky shit we cobble together under financial pressure to ship, ship, ship. That would ideally result in significantly less churn.

Essentially, yes. Just take something and get ultra good at it and then stick with that thing.

Re: You Don't Need Microservices

#162

Post by throwaway894345 »

jnash wrote: post #150
throwaway894345 wrote: post #76

Earlier quoted context omitted.

Code quality is only one reason to use microservices; deployment frequency is another (you want people to be able to deploy their service without needing to coordinate with every other service in the system). Moreover, code quality isn't just encumbered by junior devs--in fact, in my experience it's more often managers pressuring developers to take shortcuts (e.g., taking a dependency on another system's private inte…

Nothing you say can't be accomplished by using libraries instead. The largest software on earth (Linux/Windows/...) is created by composing thousands of libraries into a single system. With thousands of developers contributing from all over the world. It works. It's proven.

Composing libraries offers some of the advantages of microservices, but not all of them. For example, a vulnerable library still has access to all of the secrets used by any other library, whereas a vulnerable microservice will only yield the secrets it needs. Similarly, a critical bug in one library can bring the whole process down, even if the library itself is a non-critical component—a critical bug in a microservice will only tank that service (and maybe services that depend on it if they don’t degrade gracefully). Notably, Linux and Windows spend tremendous energy making sure these vulnerabilities and bugs don’t slip through!

Re: You Don't Need Microservices

#163

Post by foobiekr »

smrtinsert wrote: post #102
foobiekr wrote: post #63

Earlier quoted context omitted.

Most of the real world "microservices" usage outside of FAANG has been to legitimize polyglot development (a net negative for most organizations) and the to create heretofore unseen levels of Conway's law. A microservice per person? Sure, why not? It's madness. The solution is to avoid the polyglot issue by fiat and to ensure that there is some actual planning and rationale around when it makes sense to add a service…

I'd love a number attached to that "most"

All but two. And in my previous role that was a very substantial sample set.

Re: You Don't Need Microservices

#164

Post by throwaway894345 »

bb88 wrote: post #98
willcipriano wrote: post #88

Earlier quoted context omitted.

Microservices suck when you need to make a process faster, so you run a profiler and figure out that 90% of the workload is handling the http requests between the services.

I feel like HTTP is too heavyweight for microservices. For monoliths, it's great. And the only way to proceed in your case is to convert microservices into mini-monoliths. Particularly the authentication side, which needs to be revalidated with every request. gRPC might be better, but supposedly so was SOAP, CORBA, DCOM, XMLRPC, and finally REST.

How does gRPC make authentication lighter-weight? Presumably you still have a token in either case which needs to be validated? There aren't many places where parsing HTTP requests is really a significant bottleneck, and I'd guess the majority of the remainder are an architectural problem (someone using a "get" endpoint in a tight loop instead of a "list" endpoint or some such).

Re: You Don't Need Microservices

#165

Post by throwaway894345 »

jnash wrote: post #141
barking_biscuit wrote: post #133

Earlier quoted context omitted.

My 2c is that an experience architect would know that it would be ideal if they could do this and be right, but in practice they aren't likely to get those boundaries correct up-front and it takes time and experience working in the domain to see what those boundaries truly ought to be. Also, it's perfectly possible for monolithic applications to enforce boundaries as strict as microservices do via a "modular monolith…

100% agree. You can write bad code using both Monoliths and Microservices. However Microservices are inherently more complex and slower than Monoliths (because of the added encoding/decoding and network overhead).

This is probably true if you have good engineering discipline in the monolith case such that your team adheres to good architecture. In the microservices case, as long as your architect is competent, you can draw sane lines between components and it's dramatically harder for IDGAF managers and developers to violate them. Everywhere I've worked, the microservices approach ends up being considerably simpler precisely because it makes it difficult to do things that are probably bad ideas in the first place (it's the same concept with static typing, by the way--a sufficiently smart team may not need explicit types, but in practice most teams aren't sufficiently smart, and the types function as rails to keep people from doing dumb things). Every place I've worked, the network and complexity overheads are paid for many times over by the simplicity and performance of preventing people from doing dumb things.

It's also worth noting that microservices are more secure and reliable as well, since there's no vulnerable component that has access to all of the secrets nor a bunch of components that ought to be non-critical but actually are critical because anything can bring down the entire application for all other components (e.g., someone makes a sync call in some leaf component that breaks the event loop for the whole application, with failures cascading across your replicas).

Re: You Don't Need Microservices

#166

Post by barking_biscuit »

throwaway894345 wrote: post #165
jnash wrote: post #141

Earlier quoted context omitted.

100% agree. You can write bad code using both Monoliths and Microservices. However Microservices are inherently more complex and slower than Monoliths (because of the added encoding/decoding and network overhead).

This is probably true if you have good engineering discipline in the monolith case such that your team adheres to good architecture. In the microservices case, as long as your architect is competent, you can draw sane lines between components and it's dramatically harder for IDGAF managers and developers to violate them. Everywhere I've worked, the microservices approach ends up being considerably simpler precisely b…

>It's also worth noting that microservices are more secure and reliable as well, since there's no vulnerable component that has access to all of the secrets nor a bunch of components that ought to be non-critical but actually are critical because anything can bring down the entire application for all other components (e.g., someone makes a sync call in some leaf component that breaks the event loop for the whole application, with failures cascading across your replicas

This is not inherently true. Whether it's true or not is down to your implementation. You can most certainly have reliability and security problems while doing microservices.

Re: You Don't Need Microservices

#167

Post by bb88 »

throwaway894345 wrote: post #164
bb88 wrote: post #98

Earlier quoted context omitted.

I feel like HTTP is too heavyweight for microservices. For monoliths, it's great. And the only way to proceed in your case is to convert microservices into mini-monoliths. Particularly the authentication side, which needs to be revalidated with every request. gRPC might be better, but supposedly so was SOAP, CORBA, DCOM, XMLRPC, and finally REST.

How does gRPC make authentication lighter-weight? Presumably you still have a token in either case which needs to be validated? There aren't many places where parsing HTTP requests is really a significant bottleneck, and I'd guess the majority of the remainder are an architectural problem (someone using a "get" endpoint in a tight loop instead of a "list" endpoint or some such).

Technically you could auth the connection using say, a custom SSL cert, and the connection isn't made unless the SSL cert is recognized.

There are other ways to do it as well where the socket connection is only authed once.

Re: You Don't Need Microservices

#168

Post by throwaway894345 »

barking_biscuit wrote: post #166
throwaway894345 wrote: post #165

Earlier quoted context omitted.

This is probably true if you have good engineering discipline in the monolith case such that your team adheres to good architecture. In the microservices case, as long as your architect is competent, you can draw sane lines between components and it's dramatically harder for IDGAF managers and developers to violate them. Everywhere I've worked, the microservices approach ends up being considerably simpler precisely b…

>It's also worth noting that microservices are more secure and reliable as well, since there's no vulnerable component that has access to all of the secrets nor a bunch of components that ought to be non-critical but actually are critical because anything can bring down the entire application for all other components (e.g., someone makes a sync call in some leaf component that breaks the event loop for the whole appl…

> This is not inherently true. Whether it's true or not is down to your implementation. You can most certainly have reliability and security problems while doing microservices.

Obviously I didn't claim "you cannot have reliability or security problems while doing microservices".

Re: You Don't Need Microservices

#169

Post by throwaway894345 »

jnash wrote: post #142
arinlen wrote: post #107

Earlier quoted context omitted.

> Same. I keep hearing that people have had bad experiences with microservices, but I'm not sure what those bad experiences are. I certainly don't relate to them. Likewise. When I see people complaining about microservices, more often what I see is actually poorly thought-through strawmen aimed at distributed systems, which boil down to "having to do network requests is bad". I wonder why attacking the "microservices…

That sounds like a "True Scotsman" argument. The fact is that microservices are inherently and objectively more complex than Monoliths. So if you can't build a well engineered Monolith then you are pretty much guaranteed to build an even worse Microservices system (because you now have the added encoding/decoding, network hops, latency and timing issues, no guaranteed data consistency, no global commit guarantees etc…

I can believe that monoliths have a lower theoretical complexity floor than microservice architectures, but I don't think any shops are coming close to that theoretical complexity floor irrespective of their architecture, so we need to think about the actual, practical complexity of applications in each architecture.

Specifically, I think the strong boundaries between components better facilitates maintainability--as with dynamic typing, the absence of rails allows people to more easily make bad decisions. In the case of monoliths, this usually looks like an inexperienced developer (especially at the bequest of an unscrupulous manager who swears that we will definitely not do this again and will fix in a subsequent release) taking a dependency on another system's private internals. In other words, I assert that given a good architect and an average team, a microservice architecture will be less complex than a monolith despite marshaling data over a network. In order to have a well-engineered monolith, you need good architects and a good team (no unscrupulous managers who are empowered to compromise the architecture in the name of expedience).

> no guaranteed data consistency, no global commit guarantees

You don't get these for free with monoliths either. I've seen a lot of monoliths choc full of race conditions which don't manifest during development (small contrived test cases running on unburdened systems). Paradoxically, because microservices have to marshal data over a network, these consistency issues are more likely to appear. Moreover, people who work on microservices are more likely to think about race conditions precisely because the system is distributed (indeed, the architects think about this stuff when they lay out the interfaces).

Post reply on HN