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

361–370 of 782 posts

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

#361

Post by clon »

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 had managed to instill into my brain that Webpack is the JS moving target du jour. I am blown away that it has already been "surpassed" before our team managed to even have a serious review of it. Parcel it is then.

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

#362

Post by johndubchak »

crimsonalucard wrote: post #314
johndubchak wrote: post #235

Earlier quoted context omitted.

I think what was missed, in the article, is that the fundamental problem was centered around a shared architecture of destinations and shared code. You cannot possibly have every destination be a separate repo and then have the development lifecycle of your shared code be so active that it ultimately puts at risk the architecture of your entire organization. What makes shared code so perfect is having stability such…

No we need science and theory to definitively define necessary architectures that are appropriate to certain use cases. An architect is just a another man with an opinion.

We have these things. A better architect implies that one is trained in analyzing and producing these architectures using the science she/he was trained with: https://www.sei.cmu.edu/education-outreach/credentials/crede...

The certificate means nothing, the training and instruction is priceless. Add to that things like TOGAF and a deep understanding of the current state of existing architectures and you'll understand what I originally meant, but failed to explain.

UPDATE: misspelled "meant"

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

#363

Post by eric_b »

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…

Prediction: SPAs and GraphQL are quickly heading towards the last few bullet points.

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

#364

Post by barkingcat »

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…

FTP workflows are so extremely widely used in today's world that it's inconceivable you think it's behind us.

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

#365

Post by m-localhost »

pjmlp wrote: post #300
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…

Still doing jQuery with server side rendering, not bothering with React. Yep dinosaur here.

It's so nice to build something that works without JS in the first place and then just add some JS and CSS3 animations.

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

#366

Post by wsy »

crimsonalucard wrote: post #314
johndubchak wrote: post #235

Earlier quoted context omitted.

I think what was missed, in the article, is that the fundamental problem was centered around a shared architecture of destinations and shared code. You cannot possibly have every destination be a separate repo and then have the development lifecycle of your shared code be so active that it ultimately puts at risk the architecture of your entire organization. What makes shared code so perfect is having stability such…

No we need science and theory to definitively define necessary architectures that are appropriate to certain use cases. An architect is just a another man with an opinion.

It's a bit like asking to replace medical doctors with science and theory.

We need science and theory, and skilled architects who can apply it to the problem at hand.

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

#367

Post by deanCommie »

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 missed a crucial detail:

> * Everyone slowly goes back to the old technology, forgetting the new technology.

This step is just as misguided as cult-y as "Everyone adopts this new technology and raves about how great it is now that they have just adopted it."

In some cases the technology WAS the right idea, just implemented incorrectly or not sufficiently broadly, and the baby ends up getting thrown out with the bathwater.

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

#368

Post by imhoguy »

closed wrote: post #351
bumholio wrote: post #280

Earlier quoted context omitted.

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

That reminds me the six word story: "World's first real AI commits suicide" [0].

[0] https://www.reddit.com/r/sixwordstories/comments/1xp4wt/worl...

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

#369

Post by Beldur »

copperx wrote: post #190
_ea1k wrote: post #148

Earlier quoted context omitted.

To be blunt, its news to a lot of people, but it also isn't wrong. Microservices really shouldn't share a database, and if they do then they aren't "microservices".

What is that called, then? Having small programs, each responding to a different part of the API, all storing data in a single shared DB?

Distributed Monolith
Post reply on HN