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

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

#491

Post by mburst » Tue, Jul 10, 2018, 11:41 PM UTC

jarfil wrote: post #236

The whole article reads like BS to me. So the initial problem was a single queue? Well, then split the queue, no need to go all crazy splitting all the code. Switching to 100+ microservices? There is no need to switch to 100+ repos too, runtime services don't need to have one repo per service, just use a modular approach, or even feature flags. 100+ microservices, some of them with much lower load than others? Then c…

> Library inconsistencies between services? No, just no, always use the same library version for all services. Automate importing/updating the libraries if you need to.

If you did this then you'd have to go and update all services whenever you wanted to introduce a breaking change. I don't think what you're suggesting is as easy as it sounds.

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

#492

Post by woahthere123 » Tue, Jul 10, 2018, 11:41 PM UTC

akamaozu wrote: post #421

Getting the feeling Segment didn't really stop using microservices. Sounds like they just redrew their service boundary, from Integration APIs to Business Function. Centrifuge sounds like a new service deals with connecting to integration APIs, so they've replaced 140+ services with one. Another service they've spun up is Traffic Recorder, and its responsibility is to eliminate the need for http requests when testing…

Segment is very much built around microservices. They just consolidated 100+ of these destination services into a single one. That's it.

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

#493

Post by jacques_chester » Tue, Jul 10, 2018, 11:48 PM UTC

stelfer wrote: post #320

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…

Also, write a treatise about how they discovered queueing theory... seems to be part of the pattern.

I noticed this too, but I have to admit that for someone with a weak mathematical background (like me), queueing theory is a bit hard to apply.

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

#494

Post by jacques_chester » Tue, Jul 10, 2018, 11:53 PM UTC

thermodynthrway wrote: post #487

bsder wrote: post #466

Earlier quoted context omitted.

Repeat after me: there is no such thing as a synchronous network. I get where you are coming from. But you will go async sooner or later if you need any reasonable error recovery or reliability. The only question is how much pain you will suffer before you do so.

This is just not true. Google uses almost entirely immediately consistent databases and gRPC internally. Eventual consistency is hardly ever required for REST type calls even at massive scale. gRPC has no queuing and the connection is held open until the call returns. All of Google's cloud databases are immediately consistent for most operations

My understanding is that Spanner is optimistically immediately consistent, with very clever logic for deciding on whether to bounce the attempted transaction (TrueTime).

But strictly speaking, even inside a single multicore CPU, there is no such thing as immediate consistency. The universe doesn't allow you to update information in two places simultaneously. You can only propagate at the speed of light.

Oh, and the concept of "simultaneous" is suspect too.

Our hardware cousins have striven mightily and mostly successfully for decades to create the illusion that code runs in a Newtonian universe. But it is very much a relativistic one.

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

#495

Post by jacques_chester » Tue, Jul 10, 2018, 11:55 PM UTC

blablabla123 wrote: post #106

NickBusey wrote: post #72

Earlier quoted context omitted.

Right, but the thing that makes Linux actually useful isn't really the kernel is it? I would say what makes it useful is all the various small, targeted programs (some might call them microservices) it lets you interact with to solve real world problems. If Linux tried to be an entire computing system all in one code base, (sed, vim, grep, top, etc., etc.) what do you think that would look like code base/maintainabil…

But there is a big difference. These small targeted programs are invoked in user land, usually by the user. Microservices get invoked directly by the user when debugging is going on. Otherwise they are expected to automagically talk to each other and depending on the abstraction even discovery each other automatically. Also I can pipe these tools together from the same terminal session, like tail -f foo | grep someth…

We are there: https://docs.spring.io/spring-cloud-dataflow/docs/1.5.2.RELE...

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

#496

Post by XR0CSWV3h3kZWg » Tue, Jul 10, 2018, 11:57 PM UTC

tluyben2 wrote: post #417

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

I saw this at my last company. Even worse breaking it into microservices allowed teams of 2 or 3 to start building entire realms where only they could commit and used it for internal politics.

I witnessed someone that wanted to leverage their service into a promotion so they started pushing for an architecture where everything flowed through their service.

It was the slowest part of our stack and capped at 10tps.

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

#497

Post by mavelikara » Tue, Jul 10, 2018, 11:57 PM UTC

mavelikara wrote: post #403

copperx wrote: post #187

Earlier quoted context omitted.

I can't find the right place for Ruby on Rails here. It doesn't fit.

Rails' extensive use of monkey patching to implement features is currently out of favor, from what I understand. Also, by merging Merb in Rails 3, Rails got a fresh lease of life. This is similar to how Struts lived on by rebranding WebWork as itself. Finally, Ruby shows up prominently as a language developers dislike: https://stackoverflow.blog/2017/10/31/disliked-programming-l...

Edit: Also, some of those features providing better development ergonomics turned out to cause massive security issues in production systems (eg: https://gist.github.com/peternixey/1978249).

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

#498

Post by JamesBarney » Tue, Jul 10, 2018, 11:58 PM UTC

spraak wrote: post #488

asdsa5325 wrote: post #293

Earlier quoted context omitted.

badlanguage/ is too long

Such a tired view/joke. Python is just as bad but doesn't receive nearly as much hate

JavaScript is a great language because you can run it on pretty much any machine.

Buts it's especially terrible because it was designed by a guy without much language expertise in a handful of weeks.

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

#499

Post by scarface74 » Wed, Jul 11, 2018, 12:01 AM UTC

wsy wrote: post #468

scarface74 wrote: post #434

Earlier quoted context omitted.

See the below response for more details. But that’s not how modern testing works (neither is my feature flag suggestion). https://www.developerhandbook.com/unit-testing/writing-unit-... It works similarly in almost every language. For a certain class of applications and organizational constraints, I also would prefer it. But it requires a much tighter alignment of implementation than microservices (e.g., you can't ju…

> It’s easier to just press a button and have your application go to all of your servers based on a deployment group. It's not so much about the deployment process itself (I agree with you that this can be easily automated), but rather about the deployment granularity. In a large system, your features (provided by either components or by independent microservices) usually have very different SLAs. For example, credit…

With separate microservices and databases, you could just pause that microservice. With one application and one database, all teams need to be aware of the highest SLA requirements when doing their respective deployments, and design for it. It is certainly doable, but requires a higher level of alignment between the development teams.

That’s easily accomplished with a Blue-Green deployment. As far as the database, you’re going to usually have a replication set up anyway. So your data is going to live in multiple databases anyway.

Once you are comfortable that your “blue” environment is good, you can slowly start moving traffic over. I know you can gradually move x% of traffic every y hours with AWS. I am assuming on prem load balancers can do something similar.

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

#500

Post by crimsonalucard » Wed, Jul 11, 2018, 12:05 AM UTC

allwein wrote: post #350

crimsonalucard wrote: post #276

Earlier quoted context omitted.

The test of time isn't always a good metric. html, css and javascript is a huge hack, yet it has withstood the test of time. SQL to me is a huge design flaw despite it's ubiquity. On the web bottlenecks happen at IO and algorithmic searches. Databases are essentially the bottlenecks of the web and how do we handle such bottlenecks? SQL; A high level almost functional language that is further away from the metal than…

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 abstraction placed over a critical bottleneck in the web is a design mistake.