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

171–180 of 782 posts

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

#171

Post by perlgeek »

Two things come to mind:

* splitting everything up into separate repos and services seems like a pretty radical move. You could start with separate queues that are handled by a single service, potentially with many instances, or you could try to break out a few parts that change often or have a very high load

* A big chunk of the complexity seems to be in transforming one message format to another. That is something that should be very easy to write tests for. So you need a CI that tests all the services when you change the base libraries, and then it's pretty easy to find out if a change to a base library is backwards compatible or not. And for libraries that are shared between many services, you should mostly stick to backwards compatible changes.

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

#172

Post by JustSomeNobody »

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…

Great summary! I wonder if you could fit Resume Driven Design in there somewhere.

This should be the top post on articles like this. Just to keep it fresh always in everyone's mind.

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

#173

Post by madamelic »

topicseed wrote: post #10

I think that with the rise in popularity of functions as a service (lambda, gcf, azure), we are heading more and more towards nanoservices. Small services are easier to develop with several teams, in my opinion. Each team knows what to input, and output. They can do whatever in between as long as these two contracts are respected. But the overlooking of all these moving pieces changing at different paces is tough. An…

>I think that with the rise in popularity of functions as a service (lambda, gcf, azure), we are heading more and more towards nanoservices.

There are some pretty big asterisks next to running "nanoservices". Mostly how expensive they actually are to run at large scale and the weird caveats that can happen due to them not always being up.

And I wouldn't advocate for "always-up nanoservices".

The basic answer to both "nanoservices" and microservices is do what you think is right but don't go too far. There are good reasons to make a nanoservice and good reasons not to, same with microservices.

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

#174

Post by StavrosK »

JustSomeNobody wrote: post #172
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…

Great summary! I wonder if you could fit Resume Driven Design in there somewhere. This should be the top post on articles like this. Just to keep it fresh always in everyone's mind.

In my experience, this is driven more about engineers wanting to play with the "new shiny thing" than people wanting to pad their resume, but I'm sure that happens a lot too.

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

#175

Post by VBprogrammer »

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

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.

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

#176

Post by guu »

catchmeifyoucan wrote: post #39

I wonder what language they're using? > if a bug is introduced in one destination that causes the service to crash, the service will crash for all destinations. This sounds dangerous. If I was a destination provider, and returned some garbage, could that take system down? Also, reading up on centrifuge, instead of breaking up by source, destination; would it be more spatially conservant to create queues by response t…

The examples are written in JavaScript but it also looks like they use Go. Not sure which language this service is using specifically.

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

#177

Post by merinowool »

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 wonder why those fancy names for all except JS? I would have called it jizz/

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

#178

Post by johnchristopher »

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…

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

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

#179

Post by acroback »

thelastidiot wrote: post #159
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…

Amen to that. Just by curiosity, what is the barrier of entry for adding a new language in your ecosystem?

Totally technical considerations which engineers must present and justify.

e.g When we added Go, we had to present what it brings? A good testing framework, light weight(subjective), goroutines(which fit our use case), in built benchmark support, mature support of third party packages etc etc.

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

#180

Post by acroback »

merinowool wrote: post #177
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 wonder why those fancy names for all except JS? I would have called it jizz/

Haha, I made that up to gain free internet points ;)
Post reply on HN