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

301–310 of 782 posts

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

#301

Post by nevir »

sanderjd wrote: post #272
nevir wrote: post #254

Earlier quoted context omitted.

This argument is less about specific technologies, and more about patterns and practices. For example: web UI started as declarative (HTML -> PHP), and then transitioned towards more imperative (jQuery, Backbone, Angular), and is now moving back towards declarative (React, Polymer)

I don't really understand calling Perl declarative... I would consider the Perl CGI services I used to work on to be quite a bit more imperative than the Rails applications I've worked on. Similar with PHP, though I can see where peppering the imperative code into the declarative HTML could be considered more declarative.

Yeah, sorry, Perl is probably a bad example (I was really thinking of Mason, and even then it's a bad example). Pulled that from the list!

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

#302

Post by hinkley »

nickthemagicman wrote: post #127
hinkley wrote: post #42

Earlier quoted context omitted.

People look at microservices as a solution to the Big Ball of Mud, and then confuse "a solution" with "the solution". You really do have to modularize. In some languages, you can even use separate compilation units for separate modules to enforce the separation. You can do all of that but get simultaneous deployment, which cuts out whole classes of integration nightmares.

It seems like a Big Ball of mud is much more difficult to deal with than a bunch of small balls of mud just in general?

They're both bad. It feels like a reverse Sophie's Choice to have to pick one.

The real friction in the system is always in the boundaries between systems. With microservices it's all boundaries. Instead of a Ball of Mud you have Trees and No Forest. Refactoring is a bloody nightmare. Perf Analysis is a game of finger pointing that you can't defuse.

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

#303

Post by philwelch »

ljm wrote: post #157
acroback wrote: post #123

This is a classic case of not understanding micro services and trying to fit a problem around a tool. At work, we have close to ~50 services(no one calls them microservices), but they do not suffer from this brittleness. We segregate our services based on languages. So, all C services go under coco/ , all Java services go under jumanji/ , all go services go under goat/ , all JS services go under js/. This means, ever…

I'd wager that microservices, a lot of the time, are basically used as a management structure rather than for their benefits as pure tech, so less mature teams can silo themselves off and avoid communication (e.g. "I can work just on my backend image processing bit without dealing with the React guys now", "now the CTO won't be on my back so much," or whatever). The irony being that anything approaching SOA (or micro…

I would flip this argument around 180 degrees. Once you have any system that's built by large numbers of people, you have to discuss and negotiate your interfaces. You can either do this implicitly, by having a shared codebase and making sure that your test coverage and code reviews guarantee backwards compatibility, or explicitly, by defining service interfaces and black-boxing behind them.

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

#304

Post by nevir »

chrisco255 wrote: post #275
nevir wrote: post #254

Earlier quoted context omitted.

This argument is less about specific technologies, and more about patterns and practices. For example: web UI started as declarative (HTML -> PHP), and then transitioned towards more imperative (jQuery, Backbone, Angular), and is now moving back towards declarative (React, Polymer)

There's nothing declarative about HTML except for its extremely limited use case of rendering text.

HTML is purely declarative.

Each HTML document describes what it wants to have rendered, but does not describe how it should be rendered.

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

#305

Post by LinuxBender »

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 agree with this summary 100%. I have witnessed and survived this cycle for a few decades.

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

#306

Post by crimsonalucard »

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 are describing "design" which encompasses things like modern art, designer clothes and design patterns.

The thing with design is that it isn't a science or formal field of logic. I can use math to determine the shortest distances from point A to point B but I can't prove why a design for product A is definitively better than a design for product B.

With no science we are doomed to iterate over our designs without ever truly knowing which design was the best.

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

#307

Post by randomsofr »

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 just had a project crash that was setup on 2015 (using gulp), i had to update one dependency and that dependency forced me to update the entire package.json to latest versions, so i had to fix the entire build setup and config files.

Same happened with a Rails/React project that was setup last year, i tried to update one package that was marked as vulnerable, but it ended up requiring the same thing. I opted to leave that package.

I've been working with node for a long time, but i feel like is the same level of stability since the start. Thats very different with Ruby or PHP, you can have old setups working just fine, maybe requiring some extra steps to build certain dependencies but overall working.

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

#308

Post by pjmlp »

0x445442 wrote: post #210
resource0x wrote: post #198

Earlier quoted context omitted.

> Old technology is deemed by people too troublesome or restrictive. "deemed" is the keyword here. Old tech is "deemed" bad, new one is "deemed" good. Without any numbers attached, just by way of hand-waving and propaganda. And it's all "deemed" Computer Science :)

Computer Science... Now there's an oxymoron. At most institutions the subject matter is not really about computers nor is it science, at least not in the physics or chemistry sense.

Which is actually an English issue how to describe it.

In Portuguese it is never called Computer Science as such, rather Informatics, Computation or Informatics Engineering if I do a literal translation.

And those that have Engineering in their name, are only allowed to be called that way if recognised by the Engineers country organization as such.

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

#309

Post by dasil003 »

lagadu wrote: post #247

Interesting read, my biggest complaint is: confusing unit testing with integration and system testing. On every build you only run unit testing, you don't rely on any external dependencies. If your test suite relies on querying external servers, you're not testing your software, you're testing your server, your internet connection, your credentials, their internet connection and their servers. That's insane to run on…

Terminology aside, why would you not automate all your testing so you can release more frequently? We're not talking about a martian lander here; for a SaaS startup velocity is much more important than perfect releases, you will have more success by optimizing and de-risking for very frequent releases.
Post reply on HN