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

351–360 of 782 posts

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

#351

Post by closed »

bumholio wrote: post #280
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…

> Now that everyone forgot why the new technology was bad, we're free to begin the cycle again. We can very easily break the cycle by training a deep learning TensorFlow brain in the cloud, that will be fed the daily mouse gestures and key presses of all developers in the world. It's an awesome new technology that can solve any problem. Pretty soon the global brain will start to see patterns emerging, for example whe…

5 years later, tensor flow brain writes a medium post about why its very creation was a bad idea, then follows up with a quick rebuttal article about how it is just using itself incorrectly.

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

#352

Post by w4tson »

stickfigure wrote: post #40
davidkellis wrote: post #5

Earlier quoted context omitted.

> You push data consistency concerns out of the database and between service boundaries. Sing that from the rooftops. That is exactly my observation as well. All the vanilla "track some resource"-style webapps I've worked on were never designed to cope with a consistency boundary that spans across service boundaries. Turning a monolith into distributed services is hard for that reason - you have to redesign your data…

It's worse than that; it's my observation that most microservice architectures just ignore consistency altogether ("we don't need no stinking transactions!") and blindly follow the happy path. I've never quite understood why people think that taking software modules and separating them by a slow, unreliable network connection with tedious hand-wired REST processing should somehow make an architecture better. I think…

Yes! But it’s worse again. Because some bright spark comes along and says “hey there’s some commonality between these n services. I’ll make a shared library that will remove that duplicated code.

Then before you know it there are a dozen more shared libraries and you have the distributed monolith.

Then either have to Stand up every micro service every time integration test or make changes and hope for the best.

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

#353

Post by JustSomeNobody »

crimsonalucard wrote: post #276
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…

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…

> Different permutations of identical queries causes slow downs or speed ups for no apparent reason in SQL.

EXPLAIN does a very good job of explaining why one query is faster than another.

> SQL is a leaky abstraction that has created a whole generation of SQL admins or people who memorize a bunch of SQL hacks rather than understand algorithms.

This just smacks of sound bite material.

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

#354

Post by gaius »

thermodynthrway wrote: post #3

I've always said if the Linux kernel can be a giant monolith, in C no less, than there's maybe 100 web applications in the world that need to be split into multiple services. I've worked with microservices a lot. It's a never-ending nightmare. You push data consistency concerns out of the database and between service boundaries. Fanning out one big service in parallel with a matching scalable DB is by far the most sa…

I've always said if the Linux kernel can be a giant monolith, in C no less, than there's maybe 100 web applications in the world that need to be split into multiple services.

Similarly it’s made with make. If anyone has a project more complex than the Linux kernel or GCC I’ll gladly listen to why they need some exotic build system... never met anyone yet...

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

#355

Post by tetha »

YawningAngel wrote: post #331
acroback wrote: post #179

Earlier quoted context omitted.

Totally technical considerations which engineers must present and justify. e.g When we added Go, we had to present what it brings? A good testing framework, light weight(subjective), goroutines(which fit our use case), in built benchmark support, mature support of third party packages etc etc.

Aren't literally all of the above present in Java?

They are. Add around 1.5 gig of necessary heap per feature you use.

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

#356

Post by grey-area »

spyspy wrote: post #200
matwood wrote: post #96

Earlier quoted context omitted.

Great point. I like separate services, but would cringe at 100s of services in any system I have seen.

I can't believe this made it out of any planning meetings. Engineer 1: "We'll have one repo per downstream service." Engineer 2: "But we have hundreds of those, so now we have to manage hundreds of github repos???" Anyone sane: "That doesn't sound right, we should rethink this..."

Probably because when they suggested it they had about 10, growing by 1 per 6 months. Then a few years later they end up with 100, growing by a few a month, and need to rethink.

I though this was an honest and interesting look at a decision which in retrospect was a bad idea. Hopefully it'll stop some other people making similar mistakes (too many repos, too many services, fast changing libraries shared between many services, etc...).

It'd be better if it wasn't framed as having found that the one true way is the monolith, but there are some lessons here for most devs.

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

#357

Post by api »

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.

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

#358

Post by wolco »

toddmorey wrote: post #333
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…

This cycle blankets every new technology as a misstep that we’ll revert back from. The real cycle is that we continually test new ideas and new approaches, learn their strengths and weakness, and ultimately keep what works and discard what doesn’t. Sure we miss the ball more than we connect. But take this example: We now have native JSON support since Postgres 9.2. So did we abandon the document model or learn more a…

Git centric workflows are ripe for change. FTP or sftp is still used very often.

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

#359

Post by taurath »

eropple wrote: post #282
samsonradu wrote: post #194

Earlier quoted context omitted.

I’d still pick PHP between the two for usual web apps. There is beauty in the statelessness of PHP and also leverage on Nginx (+ Lua) for more critical and high-speed work. The issue I have with Node JS is that the entire ecosystem moves way too fast. However, when I need realtime interaction via WebSockets fe. it really feels like a good choice.

The notion that the node.js ecosystem moves way too fast is a time-traveling statement from, like, 2012. When it really was, in a lot of ways, true. But today it really has congregated on a relatively small set of best practices and the tools you see today are mostly the tools you would have seen two years ago. They're also mostly the same tools you would have seen five years ago, and plenty of people use "old" tools…

I've been working about the same way with Node for the past 4-5 years, with only minor adjustments, most of which have been QOL net increases. The paradigm hasn't changed much, and it solve's my employer's problems.

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

#360

Post by anxiouspete »

YawningAngel wrote: post #331
acroback wrote: post #179

Earlier quoted context omitted.

Totally technical considerations which engineers must present and justify. e.g When we added Go, we had to present what it brings? A good testing framework, light weight(subjective), goroutines(which fit our use case), in built benchmark support, mature support of third party packages etc etc.

Aren't literally all of the above present in Java?

Like the others said, our JVM apps would require at least 1GB for the JVM and then 1-4GB for heap, depending on the service. This made the average JVM service require about 4GB of RAM in the container scheduler.

Meanwhile our Go services almost never had a working set larger than 256MB and most didn't even need that. We could schedule on average 16 Go services for each JVM service.

Post reply on HN