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

The End of Microservices

lightstep.com

Post reply on HN
Print view View original

111–120 of 154 posts

Re: The End of Microservices

#111

Post by reitanqild »

r2dnb wrote: post #86
hibikir wrote: post #33

Earlier quoted context omitted.

You say it as if it's a bad thing... Compared to the alternative, fiefdoms really are a wonderful thing! I once work for a giant fortune 500 corporation. Our department had a good 300 developers, and had been writing code for years. They had built the whose system using the classic, box-box-cylinder architecture. There were hundreds of little top tier 'services', but in practice, they all shared the same database, ha…

I really value your contribution, thanks for sharing. I give the proponents/consultants credit for proposing a practical and incremental solution to these people instead of just insulting them or saying "you're doing it wrong". That being said, the issue I have with microservices is the fact that the below is repeatedly used as a core technical argument : > They had built the whose system using the classic, box-box-c…

You could even use Java on JVM and let your ops team decide which OS should be used.

Although unless Oracle changes its way it seems we will soon be a point were Apache will port Tomcat etc to .Net and we can use the best language with the best servers from the best communities.

Re: The End of Microservices

#112

Post by jazzyk »

mk89 wrote: post #100
r2dnb wrote: post #77

Earlier quoted context omitted.

>In fact, that's how most non-web software is still written and done. I can even add that we only do web software, but we do them exactly that way. >If anything, it adds more complexity because now we need to do all kinds of data marshaling, error checking, monitoring, have more infrastructure for something that should have been done in shared memory/in-process to begin with. I couldn't agree more. Martin Fowler warn…

> I couldn't agree more. Martin Fowler warned us a long time ago : "The first rule of distributed objects : don't distribute them". Funny that now the same person carries the flag with the symbol of microservices, which are seen as a way to "get rid of architects". That's exactly what Thoughtworks believes in - and you will understand more if you read the first chapters of the book "Building Microservices", or if you…

Not to take anything from Martin Fowler, but the "do not distribute (unless you absolutely have to)" rule originated at Sun much, much earlier. I have a hardcopy of the paper somewhere, it was a conclusion drawn from acknowledging the fallacies of distributed computing.

https://en.wikipedia.org/wiki/Fallacies_of_distributed_compu...

Re: The End of Microservices

#113

Post by asdfaoeu »

PJDK wrote: post #109
jordwest wrote: post #30

Earlier quoted context omitted.

Any organization that designs a system ... will inevitably produce a design whose structure is a copy of the organization's communication structure — M. Conway

I've heard this said a few times, but never really felt it rung true to systems I've seen/designed. Anyone have any examples?

Damn, can I get a job where you work?

Re: The End of Microservices

#114

Post by [deleted] »

PJDK wrote: post #109
jordwest wrote: post #30

Earlier quoted context omitted.

Any organization that designs a system ... will inevitably produce a design whose structure is a copy of the organization's communication structure — M. Conway

I've heard this said a few times, but never really felt it rung true to systems I've seen/designed. Anyone have any examples?

[deleted]

Re: The End of Microservices

#115

Post by justinhj »

I joined a company where the proof of concept had, inevitably, become the monolithic application we would work on for the next two years. Everyone on the team agreed that the monolith would be a liability so we started to share knowledge on microservices and plan for that in the future. To do this we stuck to a handful of rules. Systems should do one thing and do it well, with a well defined api and protocol. Whilst all the data may be in the same redis and MySQL instance we made the data store configurable as well its location, and made sure systems did not read or write each other's data. We wrote generic systems as libraries with no dependencies on the rest of the monolith. The results of this work, which was a lot of refactoring, is that when we decided to farm some work out to a contractor we could do so as a microservice. They worked in their favourite language with their own tools, implementing the api we wanted over a specified protocol. At any point it would be possible to split out services to scale them horizontally, but we didn't have to until we need to, because every split increases the operational costs and complexities a little.

Re: The End of Microservices

#116

Post by CuriouslyC »

iamleppert wrote: post #28

I'll tell you the real reason behind microservices: developer fiefdoms. "Faux-Specialization". It allows developers to feel like they have control over certain pieces of infrastructure and run the gambit on their strategy for getting ever more increasing pieces of the pie. It has nothing to do with building reliable software. You could just as easily build and deploy a single networked application (so called "monolit…

I do agree that people tend to over-complicate their architectures initially, this is premature optimization of another form. That being said:

* Microservices don't need to be written in the host language, nor do you need to deal with creating wrappers. Granted interacting with kafka/ampq isn't frictionless.

* Microservices can be upgraded or scaled out individually without touching the larger application as a whole.

* Microservice calls can be deferred and scheduled easily.

Re: The End of Microservices

#117

Post by quantumhobbit »

iamleppert wrote: post #28

I'll tell you the real reason behind microservices: developer fiefdoms. "Faux-Specialization". It allows developers to feel like they have control over certain pieces of infrastructure and run the gambit on their strategy for getting ever more increasing pieces of the pie. It has nothing to do with building reliable software. You could just as easily build and deploy a single networked application (so called "monolit…

Microservices are for organizations that can't seem to enforce encapsulation at the object level.

Devs not creating good interfaces in OO design? Stick them on a different server, that ought to show them. Of course now your spaghettified object hierarchies are spaghettified api call hierarchies.

Re: The End of Microservices

#118

Post by dmreedy »

iamleppert wrote: post #28

I'll tell you the real reason behind microservices: developer fiefdoms. "Faux-Specialization". It allows developers to feel like they have control over certain pieces of infrastructure and run the gambit on their strategy for getting ever more increasing pieces of the pie. It has nothing to do with building reliable software. You could just as easily build and deploy a single networked application (so called "monolit…

I agree about fiefdoms, and want to address a particular aspect of that pattern, somewhat complementary to yours, that I've seen at least in the (very large) organization that I'm a member of.

Specifically, like a microservice allows encapsulation of functionality, it also allows encapsulation of blame[1]. In a monolith (from whence the org I'm in came), a build failure or test regression could be caused by any number of failures across any number of horizontal bands in the organization. Oh, the build automation crashed because the build team updated to the latest version of Java but the build didn't. Oh, the UI Filters stopped working because the API team changed something without deprecating. It meant that development, in spite of agile efforts, still had a tick-tock cadence, where breaks halted work and tracking down the responsible parties and getting things fixed might take time (a lot of areas with deep specialties required to understand why something might be wrong). This also meant, because of the way the organization was structured and the way the build was structured, that "pressure" was directed along very hierarchical routes. Managers saw bugs from customers and pressured testers and dev-ops people who maintained automation to investigate causes and transfer responsiblity to developers who might be able to actually fix the problems.

As we've been decomposing into microservices, and likewise aligning along feature teams the blame gets allocated at API/service interfaces[2] instead of top-down. Since the build, deployment, uptime, and algorithmic functionality of each service is theoretically the domain of a single team, the blame-flow is more distributed and simple. An algorithmic bug, a build bug, and an availability issue are all addressed the same way: report the issue to the team responsible for that service, and let them work it out.

I'm not advocating that either way is better. There were nice aspects about a single-location debug tree in the monolith. I've seen teams that have become experts at deflecting blame and thus slow down the entire broader effort. And I know I'm possibly conflating two paradigms inappropriately (Feature Teams and Microservices). Just a notable pattern, to my eyes.

---

[1] I don't necessarily mean 'blame' here in a pejorative sense. Perhaps 'responsibility' would be a more neutral term.

[2] Steve Yegge describes to this being a top priority during Amazon's service/platform decomposition.

Re: The End of Microservices

#119

Post by vonmoltke »

StavrosK wrote: post #97
r2dnb wrote: post #77

Earlier quoted context omitted.

>In fact, that's how most non-web software is still written and done. I can even add that we only do web software, but we do them exactly that way. >If anything, it adds more complexity because now we need to do all kinds of data marshaling, error checking, monitoring, have more infrastructure for something that should have been done in shared memory/in-process to begin with. I couldn't agree more. Martin Fowler warn…

> I can even add that we only do web software, but we do them exactly that way. I can even add that not only do we do them exactly that way, but it's many times faster and more reliable than microservices, for reasons I have written about before[1]. The reality is that microservices add a whole host of failure modes, for just one benefit over monoliths: They are easier to scale horizontally. If you don't absolutely n…

> The reality is that microservices add a whole host of failure modes, for just one benefit over monoliths: They are easier to scale horizontally. If you don't absolutely need horizontal scalability, and not many companies do, then you'd be foolish to pay the large cost.

If you are writing and deploying standalone applications, I agree. Microservices do have another benefit, though: forcing the application to be modularized. There are better ways to do that, though, like having proper systems engineering lay out the application architecture.

If you are writing applications that need to be integrated with third-party applications or need to be configured with different functionality for different customers, microservices can still make sense. This is what has pushed my company in that direction. We currently have a set of monolithic applications with varying but overlapping functionality, and customers who want feature X from application Y and feature W from application Z, plus feature V that we are developing just for them. Our code has become a mess of curricular dependencies and duplicated code in order to meet these desires.

The microservice (maybe not micro, but definitely service) architecture we are moving to will allow us to compose applications with reusable building blocks more easily than trying to maintain different git branches and library versions. It also allows us to better manage the non-code resources we need to deploy as we have hundreds of gigs of data resources used by various libraries. Furthermore, we will be able to deploy applications with either our in-house GUI and command line tools, as well as provide the APIs necessary for our customers to integrate our applications into their own third-party frameworks.

Re: The End of Microservices

#120

Post by lobster_johnson »

carterehsmith wrote: post #52
lobster_johnson wrote: post #40

I see several people criticize microservices here. We've been doing it for about 6 years and are extremely happy with it. A core principle which a lot of people and articles ignore, though, is reusability . I bring this up on HN every time there's a discussion about microservices, yet I've never seen any discussion about it. Essentially, you build out the backend to act as a library for your front end. So we have log…

You are not getting more reusability from a bunch of microservices, compared to one big service, I don't see where you got that?

You missed my point. I did not say reusability is the only factor that dictates the use of microservices.

If we wrote everything as one big service, we'd lose the dozen-or-so benefits of microservices.

Hypothetically, if we rewrote what we have today as one big monolith:

* We couldn't selectively open-source parts of it.

* It'd really all have to be a single language, as opposed to the three we use right now.

* ...and if we decided to change the language (like we're in the process of doing with a transition from Ruby to Go + Node.js), we'd have to rewrite all of it.

* Deployment would be potentially more brittle since you're deploying a single codebase. Our apps are designed to gracefully tolerate partial unavailability.

* We'd have to be careful to control individual services' resource footprint. We have some services which are super light and have very few dependencies — they don't carry a monolith on their back.

* We'd have to jam in product-specific stuff for N different products into a single codebase. Some of our microservices aren't reusable; they're completely product-specific. Squishing lots of unrelated concerns into a single codebase is not feasible.

* Developers would be trying to tightly couple services and violate separation of concerns faster than you can spell "technical debt".

...and so forth.

Maybe I didn't articulate it well enough, but my original point was that microservices are great for all sorts of reasons, but also a too-often missed point is the benefits of reusability if you just design thing right.

Put differently, microservices are a lot less powerful if you don't design them for reusability (and, as a prerequisite, multi-tenancy)

Post reply on HN