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

621–630 of 782 posts

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

#621

Post by LolNoGenerics »

Cthulhu_ wrote: post #608
matsemann wrote: post #602

Earlier quoted context omitted.

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

It is weird that they took on some problems so easy. Shared libraries is one point. To get them right for hundreds slightly different services is something I don't even want to think about. The only strategy I can come up with is to maintain them as if they're a 3rd party lib and cannot contain business logic. So you're forced to build solutions around them and not with them.

Then there have been quite a few warnings to not use shared code in microservices.

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

#622

Post by collyw »

chrisco255 wrote: post #274
craigc wrote: post #244

Earlier quoted context omitted.

Yup. Everyone wants to use the latest and greatest, but there is a reason that certain things like SQL have stood the test of time. I think the same could be said of the design world. There was a time not too long ago when designs actually felt polished and had real shapes, shadows, gradients. When you clicked on a button you actually knew you were clicking on a button. Then iOS 7 came along and everything became whi…

Ha, JQuery. I just had to look at a legacy JQuery code base...and I shudder the thought of ever going back to that paradigm. Sometimes new patterns/frameworks/architectures do really change the game for good.

I have an angular codebase to maintain, on Angular 1.3 - probably when it was peak of the hype cycle. Its a spaghetti mess. Using a different framwork doesn't make you immune to these problems. Especially when people don't seem to understand the new tech especially well.

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

#623

Post by [deleted] »

ChicagoDave wrote: post #605

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…

[deleted]

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

#624

Post by collyw »

timr wrote: post #409
chrisco255 wrote: post #274

Earlier quoted context omitted.

Ha, JQuery. I just had to look at a legacy JQuery code base...and I shudder the thought of ever going back to that paradigm. Sometimes new patterns/frameworks/architectures do really change the game for good.

I still use jQuery regularly. It works well and doesn't get in the way. I'd rather work on a jQuery codebase written by a good engineer than a React codebase written by an average engineer, and there's no amount you could pay me to work on a Javascript codebase written by a bad engineer. The problem you've identified is that most code, in general, is terrible. The code written by people who chase trends tends to be w…

> The code written by people who chase trends tends to be worse than average.

This. Instead of learning a handfull of technologies well they learn a lot of technologies very poorly. If I am hiring I now look at it as a red flag when people have too many frameworks listed.

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

#625

Post by [deleted] »

ChicagoDave wrote: post #605

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…

[deleted]

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

#626

Post by ivan_gammel »

scarface74 wrote: post #420
ivan_gammel wrote: post #385

Earlier quoted context omitted.

First of all it is the test code, no matter whether it's implemented as a feature flag or in any other way. Test code and test data shall not be mixed with the production one for many well-documented and well-known reasons: security, additional points of failure, additional memory requirements, impact on architecture etc. >But if you are testing an artifact, why isn’t the artifact testing part of your CI process? It…

What exactly are you trying to accomplish? If you are testing a single microservice and don’t want to test the dependent microservice - if you are trying to do a unit test and not an integration test, you are going to run against mock services. If you are testing a monolith you are going to create separate test assemblies/modules that call your subject under test with mock dependencies. They are both going to be part…

> What exactly are you trying to accomplish? Good test must verify the contract on the system boundaries: in case of the API, it's verification done by calling the API. We are discussing two options here: integrated application, hosting multiple APIs, and microservice architecture. Verification on the system boundaries means running the app, not running a unit test (unit tests are good, but serve different purpose). Feature flags make it only worse, because testing with them covers only non-production branches of your code.

> Your initial assumptions were incorrect. With nearly 20 years of engineering and management experience, I know very well how modern testing is done. :)

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

#627

Post by itsmenotyou »

dalbasal wrote: post #595
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…

This is a common pattern, when it come to semi-idealistic memes like microservices or agile. I think it's a bad idea to have such hairy, abstract ideas travel too far and wide. They become a bucket of clichés and abstract terms. Clichéd descriptions of problems you're encountering, like deployments being hard. Clichéd descriptions of the solutions. This let's everyone in on the debate, whether they actually understan…

Interesting perspective. I think that seeking and naming patterns "microservices", "agile", etc. is useful. It provides something like a domain specific language that allows a higher level conversation to take place.

The problem, as your identify, is that once a pattern has been identified people too easily line up behind it and denigrate the "contrasting" pattern. The abstraction becomes opaque. We're used to simplistic narratives of good vs evil, my team vs your team, etc. and our tendency to embrace these narratives leads to dumb pointless conversations driven more be ideology than any desire to find truth.

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

#628

Post by mpweiher »

testplzignore wrote: post #139
athenot wrote: post #4

Earlier quoted context omitted.

Agreed. Reading about their setup and comparing with some truly large scale services I work with, I'm left with the idea that Segment's service is roughly the size of one microservice on our end. Perhaps the takeaway is don't go overboard with fragmenting services when they conceptually fulfill the same business role. And regardless of the architecture of the system, there are hard state problems to deal with in asso…

The most telling fact is that it "took milliseconds to complete running the tests for all 140+ of our destinations". I've never worked on a single service whose tests ran that fast, given that the time spent by the overhead of the test framework and any other one-time initialization can take a few seconds just itself. It's great to have tests that run fast, but that's a bit ridiculous. Some rules of thumb I just came…

> never worked on a single service whose tests ran that fast

I'd say you've never had good tests.

I have a test-suite for a bunch of my frameworks that dates to the mid 90s, with tests added regularly with new functionality.

It currently takes 4 seconds total for 6 separate frameworks and 1000 individual tests. Which is actually a bit slower than it should be, it used to take around 1-2 seconds, so might have to dig a little to see what's up.

With tests this fast, they become a fixed part of the build-process, so every build runs the tests, and a test failure is essentially treated the same as a compiler error: the project fails to build.

The difference goes beyond quantitative to qualitative, and hard to communicate. Testing becomes much less of a distinct activity but simple an inextricable part of writing code.

So I would posit:

Your tests should not run slower than the time it takes to read this sentence.

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

#629

Post by boubiyeah »

ako wrote: post #616
lolive wrote: post #614

Earlier quoted context omitted.

As a microservice agnostic, i wonder how you can deal elegantly with transactions across services, concurrent access & locks, etc. [Disclaimer: i have not read the article yet]

Reality is that the IT solution of any company consists of multiple separate applications which need to be coordinated into one working solution. From this reality it's good to design everything as if it's a (micro|macro)service part of a larger landscape of apps. Reality is also that you can never have transactions for everything across all your systems, so transaction alternatives like compensations are always some…

Exactly. And there are tons of techniques to do so. For instance, Stripe is a payment service (you would think a payment service is the number one choice for transactions/locks/etc right?) implemented on the good ol unreliable internet. you can look at how they do it (idempotency, etc)

Transactions are a nice and convenient shortcut when they're applicable but they're far from mandatory.

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

#630

Post by threeseed »

lolive wrote: post #614
ChicagoDave wrote: post #605

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…

As a microservice agnostic, i wonder how you can deal elegantly with transactions across services, concurrent access & locks, etc. [Disclaimer: i have not read the article yet]

Many options exist for this e.g. Apache Curator, Redis Distlock, Ignite/Hazelcast

Plus of course options around Paxos etc:

https://github.com/dgryski/awesome-consensus

Post reply on HN