Goodbye Microservices: From 100s of problem children to 1 superstar • Hacker News Board

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

#591

Post by pdimitar » Wed, Jul 11, 2018, 6:01 AM UTC

chx wrote: post #474

tluyben2 wrote: post #417

Earlier quoted context omitted.

I have been doing some tech advice jobs on the side to see what's going on in the world and it's really scary what I found. Only yesterday I was talking with the cto of a niche social networking company that has a handful of users and probably won't get much more who was telling me the tech they use; Node, Go, Rust, Mongo, Kafka, some graph db I forgot, Redis, Python, React, Graphql, Cassandra, Blockchain (for their…

Look, for most websites renting less than a handful of dedicated boxes would be enough for all purposes -- dev, staging, production. Instead they rack up an astonishing cloud bill from Amazon. It's not hype. It's boring. But it goddamn works. Sometimes I feel I am the last warrior of the YAGNI tribe.

You are not. I am only 38 and I only work professionally as a programmer for 16.5 years but I am already quite conservative in terms of ruthlessly eliminating complexity and removing any tech that can be consolidated in a monolith repo without huge amounts of effort.

Experience helps a lot. When you know that complexity and too much diversity breeds tech debt, you learn to say "No" decisively.

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

#592

Post by markatkinson » Wed, Jul 11, 2018, 6:02 AM UTC

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…

You could apply that pattern to a lot more than just the tech sector. It seems humans are doomed to this cyclical process of 3 steps forward 2 steps back.

Maybe someone needs to create a cloud based serverless SaaS SPA web app developed in F# to help track this stuff and prevent it happening in the future.

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

#593

Post by shub » Wed, Jul 11, 2018, 6:05 AM UTC

codedokode wrote: post #510

tabtab wrote: post #396

Earlier quoted context omitted.

I believe good architectures/stacks depend far more on the skill of the architects than the languages involved. Domain fit also matters. As far as PHP, it's an ugly language from a language-only perspective, but easy to deploy and has lots of existing web-oriented libraries/functions. Think of PHP has a glue language for its libraries and some front-end JavaScript to improve the UI. Python and server-side JavaScript…

PHP might be not the best designed or nice looking language out there, but you cannot even compare it to JS. It has real classes, doesn't require you to put underscore before private methods and type checking. And it issues a warning if you divide by zero or try to access array index that doesn't exist

Is `empty("0")` still true in PHP?

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

#594

Post by tannhaeuser » Wed, Jul 11, 2018, 6:06 AM UTC

eropple wrote: post #534

kapv89 wrote: post #515

Earlier quoted context omitted.

"SQL database usage is still an ongoing bummer, though." ... have you looked at Typeorm ( http://typeorm.io/ )?

I have, actually. This week has made me decide to move away from it. I have been using it, and filed an issue[0] asking them to document the schemas emitted by their entity-tree code; I was then told that I was doing it wrong and that I should use their code-first/synchronization feature and trust in their magic rather than writing my own explicit migrations which are informed by my (tbh, pretty extensive) understand…

That's a common pitfall with ORMs and dumb stacks like Spring data: they're made for unexperienced developers who can't be bothered to understand other technology than their favourite programming language. When it comes to databases however, SQL is the standard, is already at a higher level of abstraction than a primitive record-like abstraction build on top of it, and direct SQL access will be required for any meaningful data manipulation at scale, for locking, for schema evolution, BI, etc. anyway.

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

#595

Post by dalbasal » Wed, Jul 11, 2018, 6:17 AM UTC

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 understand anything real to a useful degree or not. It's a lot easier to have opinions about something using agile or microservice standard terms, than using your own words. I've seen heated debates between people who would not be able to articulate any part of the debate without these clichés, they have no idea what they are actually debating.

For a case in point, if this article described architecture A, B & C without mentioning microservices, monoliths and their associated terms... (1) Far fewer people would have read it or had an opinion about it. (2) The people who do, will be the ones that actually had similar experiences and can relate or disagree in their own words/thoughts.

What makes these quasi-ideological in my view is how things are contrasted, generally dichotomously. Agile Vs Waterfall. Microservices Vs Monolithic Architecture. This mentally limits the field of possibilities, of thought.

So sure, it's very possible that architecture style is/was totally besides the point. Dropping the labels of microservices architecture frees you up to (1) think in your own terms and (2) focus on the problems themselves, not the clichéd abstract version of the problem.

Basically, microservice architecture can be great. Agile HR policies can be fine. Just... don't call them that, and don't read past the first few paragraphs.

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

#596

Post by VintageCool » Wed, Jul 11, 2018, 6:27 AM UTC

topicseed wrote: post #12

hinkley wrote: post #7

Earlier quoted context omitted.

unless they have 100 developers for 100 services. That cure is worse than the disease. Every service works differently and 80% of them are just wrong, and there’s nothing you can do because Tim owns that bit.

But if you can explain to the team or the CTO why Tim is doing it wrong and how it is impacting X, Y and Z, then Tim will fix or be sent else where, no?

Each developer works in their own little silo and doesn't bother to learn the code outside their silo. Each team member developers their own idiosyncratic style. If they have to work with someone else's code, it's unfamiliar and they make slow progress and get cranky.

Now all the developers are going to the CTO or CEO and undermining the other developers, trying to persuade the CTO that so-and-so's code is shit.

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

#597

Post by _Codemonkeyism » Wed, Jul 11, 2018, 6:28 AM UTC

"[...] the small team found themselves mired in exploding complexity."

Key sentence. Using the wrong tool for a small team, blaming the tool.

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

#598

Post by noahsark769 » Wed, Jul 11, 2018, 6:28 AM UTC

ronjouch wrote: post #526

mikekchar wrote: post #486

Earlier quoted context omitted.

> ... the fundamental problem was centered around a shared architecture of destinations and shared code. From an architectural perspective, there is absolutely no difference between a micro service and a library. The only real difference is in the dispatch mechanism. The problems around configuration management are the same problems we've had as programmers for decades. It's just that the people who are keen on micro…

> "should we implement ld.so for micro services? :-)" Working exactly along those lines this week on multiple services exposed over REST APIs, I was wondering if tools exist to check compatibility between them. Said differently, - I have a `swagger.yaml` for my service A managing chipmunks and it says endpoint `/chipmunks` supports an 'color' query parameter. - In service B, I have a `handleToServiceA` that encapsula…

At work, to alleviate this issue, we use a client library for service A (i.e., one that provides service.getChipmunks(color='blue')). This gives you the compile time check, assuming the client library is a compiled language.

One step better is autogenerated client libraries where a new version is created every time a new version of swagger.yaml is deployed. However, I don't know an open source project that does this.

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

#599

Post by aidenn0 » Wed, Jul 11, 2018, 6:33 AM UTC

stickfigure wrote: post #581

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…

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

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

#600

Post by seabrookmx » Wed, Jul 11, 2018, 6:37 AM UTC

jdoliner wrote: post #547

jiveturkey wrote: post #376

Earlier quoted context omitted.

> This means, everytime you touch something under a repo, it affects everyone. This is horrible at scale. > This is a classic case of not understanding micro services and trying to fit a problem around a tool. That much I agree with. TFA even acknowledges that, in the conclusion. Not in so many words, but they basically admit they did it wrong.

> This is horrible at scale. This can work fine at scale, Google does it with however many tens of thousands of engineers they have these days. Having everything in a monorepo doesn't solve the communication problem, it doesn't prevent solving it either.

> all code deployed to all servers This is the main point of the post. Google most certainly doesn't do this, even if they have all their code (or at least, all their private code) in one repo (piper).