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

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

#391

Post by thermodynthrway » Tue, Jul 10, 2018, 9:09 PM UTC

chrisco255 wrote: post #283

joshvm wrote: post #217

Earlier quoted context omitted.

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.

I've worked on a system that used Kafka in-between. It makes consistency issues a ton worse because everything is async. At least with HTTP you can do synchronous calls

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

#392

Post by ljw1001 » Tue, Jul 10, 2018, 9:10 PM UTC

acroback wrote: post #329

ljw1001 wrote: post #219

Earlier quoted context omitted.

what happens when the java code breaks the c code? Or does everyone roll-their-own everything in each language?

This means either your contract agreement between services is not language agonistic or someone did not do their job when Interface schema was changed during reviews. Just like any other software, interfaces live in separate repos e.g protoplasm/ for proto-buf definitions. avrobber/ for avro and so on so forth. So, any change to protoplasm/ triggers automated tests on all other services irrespective of boundaries.

ok. But _much_ easier to have compile time checking between projects in the same language/repo. Not saying this approach is wrong, but it's a little like riding a unicycle when a perfectly good bicycle is sitting right there.

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

#393

Post by SahAssar » Tue, Jul 10, 2018, 9:10 PM UTC

Zooper wrote: post #226

johnchristopher wrote: post #178

Earlier quoted context omitted.

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

WebAssembly.

WebAssembly is a compiler target, not a language you write.

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

#394

Post by xg15 » Tue, Jul 10, 2018, 9:10 PM UTC

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…

> A select search over an index is an abstraction that is too high level to be placed over a bottleneck.

The high-level was the point because, in the original idea, there was a separation of concerns assumed: The dev writes, in SQL, what the DB should do and the DBA decides how the DB does it.

Of course that assumes there is a competent DBA...

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

#395

Post by thermodynthrway » Tue, Jul 10, 2018, 9:11 PM UTC

y4mi wrote: post #342

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.

It's neither new nor insane... Putting everything on the same server becomes a scalability nightmare at some point. This video is strangely relevant in this thread... https://www.youtube.com/watch?v=X0tjziAQfNQ

Nah, just use a database that can scale with your app and run a ton of instances. You'll be hard pressed to find any size app that doesn't fit in RAM these days.

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

#396

Post by tabtab » Tue, Jul 10, 2018, 9:11 PM UTC

tetha wrote: post #323

johnchristopher wrote: post #178

Earlier quoted context omitted.

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

Make fun of PHP as much as I like or liked to. But I have some easily readable, rock-solid, easily operated php applications in my infrastructure.

I believe good architectures/stacks depend far more on the skill of the architects than the languages involved. Domain fit also matters.

As far as PHP, it's an ugly language from a language-only perspective, but easy to deploy and has lots of existing web-oriented libraries/functions. Think of PHP has a glue language for its libraries and some front-end JavaScript to improve the UI. Python and server-side JavaScript may someday catch up, but still have a lot of ground to make up.

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

#397

Post by strken » Tue, Jul 10, 2018, 9:11 PM UTC

dnautics wrote: post #267

rstefanic wrote: post #242

Earlier quoted context omitted.

How is this an example of the Hegelian Dialectic?

exactly, root comment's point is that 'synthesis' is missing, so there is no forward progress unlike the dialectic!

Thesis: monoliths in one repo

Antithesis: microservices in separate repos

Synthesis: microservices in a monorepo

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

#398

Post by TeMPOraL » Tue, Jul 10, 2018, 9:12 PM UTC

stcredzero wrote: post #298

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…

"But if he was shocked, he wouldn't bother to keep typing!" "Maybe he was taking dictation?!"

Watch out for the more science-minded developers, though. https://xkcd.com/242/.

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

#399

Post by ljw1001 » Tue, Jul 10, 2018, 9:12 PM UTC

wsy wrote: post #378

ljw1001 wrote: post #252

Earlier quoted context omitted.

This is another way of saying that micro-services are for easy problems, where you can avoid having many processes share the same complex database.

It's exactly the other way around: If you can afford all your components sharing the same database without creating a big dependency hell, then your problem is _too small_ for microservices. If your problem is so large that you have to split it up to manage its complexity, start considering microservices (it might still not be the right option for you).

like all those simple airline reservation and banking systems?

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

#400

Post by randomsofr » Tue, Jul 10, 2018, 9:13 PM UTC

eropple wrote: post #330

randomsofr wrote: post #307

Earlier quoted context omitted.

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

1) React is frontend JS which can be consumed on the server side--but I think a reasonable person might hang Express on Node and raise eyebrows at React. 2) Can you explain to me how updating a Gemfile or composer.json file is not going to result in a similar dependency cascade? 'Cause, from experience, it certainly will if the project isn't dead . About the only environment I've ever worked in where keeping up on yo…

I know this can be the case for any project with dependencies, but the js community is know for introducing breaking changes even on small releases. There's not such thing as security patches on most js packages.