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

421–430 of 782 posts

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

#421

Post by akamaozu »

Getting the feeling Segment didn't really stop using microservices.

Sounds like they just redrew their service boundary, from Integration APIs to Business Function.

Centrifuge sounds like a new service deals with connecting to integration APIs, so they've replaced 140+ services with one.

Another service they've spun up is Traffic Recorder, and its responsibility is to eliminate the need for http requests when testing integrations.

Feels like the biggest change is going from so many repos to a monorepo.

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

#422

Post by Marazan »

madrox wrote: post #74
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…

Microservices aren't some magic bullet for scaling. If anything, they conform to Conway's Law [1]. I'd agree, though, if a single engineer is singularly responsible for 2+ microservices that are only supporting a single product...you're doing it wrong. [1] https://en.wikipedia.org/wiki/Conway%27s_law

I think that's possibly wrong as a key advantage of micro service over monolith is scaling. We have a 'single' product built as 2 micro services which is basically an external facing orchestration service that calls the compute heavy backend and it allows the external facing service to serve all the incoming traffic out of (on average) 4 containers whilst the backend computes with 32 containers and scales independently - very small changes to the incoming traffic can have large effects on the volume of traffic going to the compute service.

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

#423

Post by mlevental »

systemizer wrote: post #207
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…

yup. basically Hegel's dialectic: https://en.wikipedia.org/wiki/Dialectic#Hegelian_dialectic Thesis --> Antithesis --> Synthesis

Hegel's produces new things though

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

#424

Post by BurritoAlPastor »

dlevine wrote: post #197
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…

And, in the end, everyone starts writing Java again...

A coworker of mine likes to say that Java developers never stop writing Java – they just start writing Java in other languages.

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

#425

Post by LovelyWaste »

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…

The grandiose tone of your message suggests you believe you are giving some insteful advice but all I see is a single suggestion grouped with a lot of that weird marketingspeak every single programmer, for whatever reason, feels they need to emulate on their blogs.

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

#426

Post by sgslo »

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…

Regarding #2, the Ruby sensibility on pulling in dependencies is very different than the Node world's.

As an arbitrary example, consider the deps of two similar packages, delayed_job (Ruby, https://github.com/collectiveidea/delayed_job) and Kue (JS, https://github.com/Automattic/kue).

Delayed_job has two dependencies if you're running on Ruby (rather than JRuby): rake and sqlite3. Neither rake nor sqlite3 have any dependencies of their own - in production mode, of course.

On the other hand, Kue has nine direct dependencies, each of which have their own. The full dependency tree of Kue has one hundred and eighty two separate dependencies.

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

#427

Post by aenigmaclamo »

eric_b wrote: post #363
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.

Have you ever tried to go back to no longer writing SPAs?

Sure, it's easy to work with at first but then you start to realize that every framework and every language has different ways of doing all the niceties that you now expect. Asset pipelining, layouts, conditional rendering, and template helpers all end up becoming stuff that every language has to individually develop with varying levels of success.

Even with those features baked in, you probably still want to modify the page using JavaScript, anyway, so then you have to re-render parts of the page without the aid of the expansive view system that rendered your page. And, of course, the more JS you put in your app, the more you have some bastardized hybrid of a SPA and a server rendered page.

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

#428

Post by exclusiv »

I found the frustrations with microservices too setting up a pretty substantial ETL system using Amazon Lambda among other services.

Originally you couldn't trigger Lambda functions from SQS (seemingly the most obvious integration). You could use Kinesis but small print says Lambda concurrency is restricted to the Kinesis streams which gets very expensive.

Visibility/monitoring into most microservices is not good (Iron.io is quite nice but any concurrency is really expensive). I don't like the workflow for deployment and testing either.

So I shifted to single EC2 instance with my application and Beanstalkd w/ my own configurable workers. Way cheaper, easier to manage, normal programming workflow, etc.

For some use-cases Lambda and other services are really nice and efficient but there's usually a lot of hidden limitations so be sure to spend a lot of time evaluating before committing. You often spend way more time fighting the microservice drawbacks than the benefits are worth.

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

#429

Post by pjmlp »

Symbiote wrote: post #373
pjmlp wrote: post #308

Earlier quoted context omitted.

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.

It's not an English language problem, terms like informatics[0], computing, computation or engineering are valid and used by some universities. My degree is simply "MEng Computing". It's recognized[1] by the engineering association, although that's so irrelevant in most IT that I had to look up the organization: the "BCS (BCS - Chartered Institute for IT) and the IET (Institute of Engineering and Technology)." [0] My…

Thanks for the clarification, guess got it wrong. :)

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

#430

Post by myth_drannon »

tluyben2 wrote: post #417
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 have been doing some tech advice jobs on the side to see what's going on in the world and it's really scary what I found. Only yesterday I was talking with the cto of a niche social networking company that has a handful of users and probably won't get much more who was telling me the tech they use; Node, Go, Rust, Mongo, Kafka, some graph db I forgot, Redis, Python, React, Graphql, Cassandra, Blockchain (for their…

Resume driven development. I've worked for a similar small company with barely any users/data but the tech choices were driven by how useful is the tech for their future job prospects and not the current or future needs of an organization.
Post reply on HN