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

Goodbye Microservices: From 100s of problem children to 1 superstar

segment.com

Post reply on HN
Print view View original

601–610 of 782 posts

Re: Goodbye Microservices: From 100s of problem children to 1 superstar

#601

Post by kohlerm »

alexrbarlow wrote: post #2

I'm not sure what they've been left with is a monolith after all. I would say they just have a new service, which is the size of what they should have originally attempted before splitting. In particular, as to their original problem, the shared library seems to be the main source of pain and that isn't technically solved by a monolith, along with not following the basic rule of services "put together first, split la…

It looks to me that the shared library issue got solved by the monorepo approach. They could have gone the monorepo way and still have microservices. Managing a lot of repos and keeping them consistent with regards do dependencies is not easy. In reality you do not want everyone to use a different version of a dependency. You might allow deviations but ultimately you wand to minimize them.

They also just might have had too many repos.

Re: Goodbye Microservices: From 100s of problem children to 1 superstar

#602

Post by matsemann »

Floegipoky wrote: post #558

It seems like splitting into separate repos was a rash response to low-value automated tests. If tests don't actually increase confidence in the correctness of the code they're negative value. Maybe they should have deleted or rewritten a bunch of tests instead. Which is what they did in the end anyway. >> A huge point of frustration was that a single broken test caused tests to fail across all destinations. When we…

> To summarize, it seems like they made some mistakes, microed their services in a knee-jerk attempt to alleviate the symptoms of the mistakes, realized microservices didn't fix their mistakes, finally addressed the mistakes, then wrote a blog post about microservices.

You try to remove the critique from microservices, but for me these issues are actually good arguments against microservices. It's hard to do right.

Re: Goodbye Microservices: From 100s of problem children to 1 superstar

#605

Post by ChicagoDave »

I’ve been tracking the comments and my sense is that almost no one here believes the business domain drives the technical solution.

Microservices, when constructed from a well-designed model, provides a level of agility I’ve never seen in 33 years of software development. It also walls off change control between domains.

My take from the Segment article is that they never modeled their business and just put services together using their best judgment on the fly.

That’s the core reason for doing domain driven design. When you have a highly complex system, you should be focused on properly modeling your business. Then test this against UX, reporting, and throughput and build after you’ve identified the proper model.

As for databases, there are complexities. Some microservices can be backed by a key-value store at a significantly lower cost, but some high-throughput services require a 12-cylinder relational database engine. The data store should match the needs of the service.

One complexity of microservices I’ve seen is when real-time reporting is a requirement. This is the one thing that would make me balk at how I construct a service oriented architecture.

See Eric Evans book and Vaughn Vernon’s follow up.

Re: Goodbye Microservices: From 100s of problem children to 1 superstar

#606

Post by marvin »

aidenn0 wrote: post #599
stickfigure wrote: post #581

Earlier quoted context omitted.

it seems like they made some mistakes, microed their services in a knee-jerk attempt to alleviate the symptoms of the mistakes, realized microservices didn't fix their mistakes, finally addressed the mistakes, then wrote a blog post about microservices. That seems... appropriate? This is the general problem with the microservices bandwagon: Most of the people touting it have no idea when or why it's appropriate. I on…

X was sold as the answer but wasn't is true for pretty much all X that have ever been sold as The Answer. It's almost like engineering techniques aren't magic pixie dust that you can sprinkle over your project and get amazing results...

This is a problem you get when senior leadership is excessively confident, don’t know enough about engineering and underestimate the difficulties of software. «Why not just do this to solve your problems?» The response will often be «won’t work/already doing it/will have unintended consequences/impossible to do cheaply».

Re: Goodbye Microservices: From 100s of problem children to 1 superstar

#607

Post by mrep »

crimsonalucard wrote: post #500
allwein wrote: post #350

Earlier quoted context omitted.

I strongly disagree with your assessment of SQL. All of the questions that you asked have actual answers, but I read (from what I perceive as your tone) that you think these are all mysteries generated by an unknowable black box. While some of them may be implementation dependent (like "What algorithm does a select search execute?"), others have common and knowable answers. > Why does using select * slow down a query…

Those are rhetorical questions. I ask them because these are questions you need to know in order to work well with SQL. I cannot become a master of SQL by only learning SQL. I have to learn the specific implementations, I have to run EXPLAIN... etc... A good abstraction only requires you to know the abstraction not what lies underneath. What we have with SQL is a leaky abstraction. My argument that a high level leaky…

Lol, of course you need a general understanding of how your database works on the inside. There are a million different ways you can store your data and I would argue that choosing your data storage is the most important and tricky decision we have to make as software engineers.

Back at my first big tech company, I remember reading the best document I have ever read related to software engineering. It was entirely devoted to choosing your database/storage system. The very first paragraph of the document was entirely devoted to engraining in your head that "choosing a database is all about tradeoffs". They even had a picture where it just repeated that sentence over and over to really engrain it in you.

Why? Because every database has different performance characteristics such as consistency, latency, scalability, typing, indexing, data duplication and more. You really need to think about each and every one because choosing the wrong database/not using it correctly usually cause the biggest problems/most work to solve that you will ever have to face.

Re: Goodbye Microservices: From 100s of problem children to 1 superstar

#608

Post by Cthulhu_ »

matsemann wrote: post #602
Floegipoky wrote: post #558

It seems like splitting into separate repos was a rash response to low-value automated tests. If tests don't actually increase confidence in the correctness of the code they're negative value. Maybe they should have deleted or rewritten a bunch of tests instead. Which is what they did in the end anyway. >> A huge point of frustration was that a single broken test caused tests to fail across all destinations. When we…

> To summarize, it seems like they made some mistakes, microed their services in a knee-jerk attempt to alleviate the symptoms of the mistakes, realized microservices didn't fix their mistakes, finally addressed the mistakes, then wrote a blog post about microservices. You try to remove the critique from microservices, but for me these issues are actually good arguments against microservices. It's hard to do right.

> It's hard to do right.

This is correct; I'd argue doing microservices right is even harder than doing a monolith right (like, keeping the code base clean).

Re: Goodbye Microservices: From 100s of problem children to 1 superstar

#609

Post by collyw »

wsy wrote: post #419
ljw1001 wrote: post #399

Earlier quoted context omitted.

like all those simple airline reservation and banking systems?

Yes, they do fine as examples. I have worked both on decades old booking systems and banking software. Both were dependency hells. Refactoring was impossible. Everybody was super-careful even with tiny changes because the risk to break something was just too high. If it could be avoided, these systems were not touched anymore. Instead, other applications where attached to the front and sides.

Isn't that a feature of old systems in general?

Re: Goodbye Microservices: From 100s of problem children to 1 superstar

#610

Post by PaulRobinson »

api wrote: post #357
StavrosK wrote: post #164

Let me write a meta technology hype roadmap, so we can place these sorts of articles: * Old technology is deemed by people too troublesome or restrictive. * They come up with a new technology that has great long-term disadvantages, but is either easy to get started with short-term, or plays to people's ego about long-term prospects. * Everyone adopts this new technology and raves about how great it is now that they h…

I'm watching this unfold with "serverless," which trades system administration for lock-in and other problems.

It's possible to do serverless without lock-in, in the same way it's possible to do containers without lock-in.

At the moment serverless vendors make that hard, and the frameworks (like serverless.com) are still emerging to make that simple.

For me the problem is most people don't think through the cost/benefits. Amazon don't ever get tired of saying "never pay for idle" in their sales pitches, but quite a lot of applications out there are never idle and can be quite accurately managed in terms of scaling, and therefore you're actually paying a premium for something you don't need.

Post reply on HN