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

281–290 of 782 posts

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

#281

Post by user68858788 »

VBprogrammer wrote: post #175
kgwgk wrote: post #161

Earlier quoted context omitted.

Between “database servers” and “database tables” there is another level of granularity: “database users”.

While that's true. It also means you are only one grant away from sharing database tables. Maybe with good discipline you will be ok but all it take is for one dev to take that one shortcut.

Agreed. I've only seen proper user separation happen when legal gets involved. Usually it's an all-access free-for-all, and after all, why shouldn't it be? It's a lot easier to pull data and logs from adjacent services yourself rather than taking a ticket and hoping the team still exists for a response.

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

#282

Post by eropple »

samsonradu wrote: post #194
johnchristopher wrote: post #178

Earlier quoted context omitted.

So, should we stick to PHP for web stuff or is JS here to stay ?

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 completely and perfectly acceptably. You don't have to throw out Grunt if you like it, you don't have to rush onto Parcel if Webpack works for you. Because other people still use them and other people still maintain them.

Node is no less stable, today, than Ruby or PHP, and is only arguably less stable than Python because Python has largely ossified.

SQL database usage is still an ongoing bummer, though.

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

#283

Post by chrisco255 »

joshvm wrote: post #217
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…

One example I'm familiar with that sounds like microservices is the Robot Operating System (ROS). At its heart it's just a framework for pub/sub over IP, it just happens to be targeted towards robotics. A ROS system comprises of 'nodes' for each logical operation e.g. image acquisition -> camera calibration -> analysis -> output. The system is defined by a graph of these nodes, since you can pipe messages wherever th…

There's actually no reason you can't architect microservices like this. You can put RabbitMQ or some AMQP service as a comm layer between services. But then you have to architect your system to be event-driven. It's not a bad approach.

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

#284

Post by sanderjd »

Dirlewanger wrote: post #213
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 was never really a major leap forward in anything, more so an evolution with convention-over-configuration and a strong community presence that established best practices early. It also hasn't been "cool" for years, it's an entrenched player that "just works". One could argue with all the Rubyists going to Elixir that's part of the cycle, but for many people that's been a net positive. And then there's those al…

Yeah, I think this is actually calling out a major weakness in the original comment's hype cycle model. Sometimes step #5 ("Five years pass...") doesn't happen in that way. Sometimes what happens is that the new technology has been found to be generally useful, though imperfect, as everything is. People may be evolving it in different directions, perhaps incorporating elements of the old technology the new one replaced, but it isn't being fundamentally abandoned. The tough part is that you don't know which version of step #5 will happen when you're surveying the world at step #4.

If it was easy to figure this stuff out, they wouldn't pay us to try :)

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

#286

Post by crimsonalucard »

We should bring Categorical concepts into microservices. Maintain compose-ability between entities rather than forming a graph of intercommunicating objects similar to OOP.

I don't know if adhering to these principles will make microservices better.

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

#287

Post by chrisco255 »

jspash wrote: post #23
framebit wrote: post #15

"2020 prediction: Monolithic applications will be back in style after people discover the drawbacks of distributed monolithic applications." -Kelsey Hightower on Twitter https://twitter.com/kelseyhightower/status/94025989833123840...

I'm waiting for the day that this becomes a standard refrain: "Javascript. What were we thinking?!"

Been using JS for years and still loving it. The only thing I would move towards from here is some kind of ML like Elm, Reason, Haskell, etc. Certainly wouldn't go back to Java.

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

#288

Post by dvlsg »

kgwgk wrote: post #161
kolpa wrote: post #113

Earlier quoted context omitted.

> Usually microservices have their own databases That's news to me, and seems insane. Unless you mean "their own database tables", not "database servers". But that's just the same as having multiple directories and files in a Unix filesystem.

Between “database servers” and “database tables” there is another level of granularity: “database users”.

Separating by schema would work, too. At least, they would be separated from each other but still on the same database.

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

#289

Post by sanderjd »

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.

This is apples and oranges. The production profile of operating system kernels and web applications are so dissimilar that the analogy is not useful. It may be true that most web applications don't need to be split into multiple services, but the Linux kernel provides no evidence either way.

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

#290

Post by [deleted] »

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…

[deleted]
Post reply on HN