Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Microservices Architecture on Google Cloud

cloud.google.com

Post reply on HN
Print view View original

21–30 of 49 posts

Re: Microservices Architecture on Google Cloud

#21

Post by qaq »

westoque wrote: post #19

> It is extremely difficult to change a monolith’s technology or language or framework because all components are tightly coupled and dependent on each other. As a result, even relatively small changes can require lengthy development and deployment times. I disagree with this so much. I have personally worked with Rails application monoliths and Node.js microservices and I can tell you that making changes on the mono…

It's obvious BS driven by cloud marketing because in monolith case you pay them for way fewer services. In Micro Services case a single client request will generate a number of downstream requests to multiple services driving the cloud provider's profits up. You also have a higher chance of using their highest margin tracing/telemetry offerings.

Re: Microservices Architecture on Google Cloud

#22

Post by dikei »

I think many developers like microservices partly because they get to do green-field projects constantly: just start a fresh service when you need a new functionality, etc.

Of course, in time, this might spiral into an uncontrollable mess without discipline, but it feels good at the beginning.

Re: Microservices Architecture on Google Cloud

#23

Post by qaq »

Paying MS overhead is basically justifiable if you will need to scale your product development team for a single product to some ungodly size so not really applicable to 99.99% of the projects. The original hard constraint of not having a scalable enough RDBMS no longer exist you can use Spanner, CockroachDB etc.

Re: Microservices Architecture on Google Cloud

#24

Post by aliswe »

rackjack wrote: post #20
stevefan1999 wrote: post #4

The more services you have, the higher the latency, to a point it is unbearable. So you know what the engineers do? They have to go back and make some services monolithic again. This is also applicable to microkernel model, where everything is almost processes intercommunicating either locally or remotely, but their performance is so bad they are either academically significant only or are simply abandoned. There are…

Microkernels are not a good example. The assertion that they have worse performance in a way that can be meaningfully measured is a rumor, especially since we now have Fuchsia, not even mentioning other microkernels like seL4 and QNX.

Yes Fuchsia, also why the downvotes? strange!

Re: Microservices Architecture on Google Cloud

#25

Post by aliswe »

latch wrote: post #17

I don't think you can have a serious conversation about microservices without talking about poison messages and ordering guarantees (both with respect to each other and not). What does Pub/Sub provider to deal with those? (If you're interviewing somewhere and they say they have microservices, ask how they deal with poison messages. The answer can be telling).

Whats a good answer? I want more information ...

Re: Microservices Architecture on Google Cloud

#26

Post by detaro »

junon wrote: post #15
stevefan1999 wrote: post #4

The more services you have, the higher the latency, to a point it is unbearable. So you know what the engineers do? They have to go back and make some services monolithic again. This is also applicable to microkernel model, where everything is almost processes intercommunicating either locally or remotely, but their performance is so bad they are either academically significant only or are simply abandoned. There are…

> This is also applicable to microkernel model This isn't a fair comparison. Microkernels can still be performant if done correctly. Syscalls have become slower over time as Spectre/Meltdown mitigations are added.

Don't you also need Spectre/Meltdown mitigation on microkernel IPC if an untrusted process is involved?

Re: Microservices Architecture on Google Cloud

#27

Post by thatsamonad »

latch wrote: post #17

I don't think you can have a serious conversation about microservices without talking about poison messages and ordering guarantees (both with respect to each other and not). What does Pub/Sub provider to deal with those? (If you're interviewing somewhere and they say they have microservices, ask how they deal with poison messages. The answer can be telling).

I’m not sure if this fully addresses your comment but, similar to AWS SQS, Google Cloud Pub/Sub supports both message ordering[0] and dead letter topics[1].

[0](https://cloud.google.com/pubsub/docs/ordering#receiving_mess...)

[1](https://cloud.google.com/pubsub/docs/handling-failures#setti...)

Re: Microservices Architecture on Google Cloud

#28

Post by latch »

aliswe wrote: post #25
latch wrote: post #17

I don't think you can have a serious conversation about microservices without talking about poison messages and ordering guarantees (both with respect to each other and not). What does Pub/Sub provider to deal with those? (If you're interviewing somewhere and they say they have microservices, ask how they deal with poison messages. The answer can be telling).

Whats a good answer? I want more information ...

Tongue-in-cheek answer (but really what I believe):

Don't use microservices.

Short answer:

It's extremely difficult and, there isn't always a good solution. Different approaches are used on a _per consumer_ basis. That's the gist of what you want to hear.

Long answer:

In some cases ordering and lost messages don't matter so much, so any failed messages can just be thrown out.

For some queues lost messages matters, but not ordering. So you can put the message at the back of the queue (possibly delayed if that's support), so you don't block other messages.

Partitioning helps isolated poison messages to a vertical (e.g., customer_id).

Always adding id and timestamp to each message can let consumers behave more smartly (e.g. throwing away out of order or already processed messages).

But when none of that helps and ordering and delivery matter (which I think will make up most cases for any non-trivial system)...I'd love to know too. Good alerts to wake up developers?

Then there's how to scale this and making it reliable What's the ordering guarantee across N consumers? What if a consumer nack's a message. What if there's prefetching?

Re: Microservices Architecture on Google Cloud

#29

Post by mrighele »

westoque wrote: post #19

> It is extremely difficult to change a monolith’s technology or language or framework because all components are tightly coupled and dependent on each other. As a result, even relatively small changes can require lengthy development and deployment times. I disagree with this so much. I have personally worked with Rails application monoliths and Node.js microservices and I can tell you that making changes on the mono…

> technology or language or framework

Note what they are talking about. They are right: of course if you want to change your Rails monolith to a Spring Boot java project it will be extremely difficult. The point is, how often do you want to do that ? Maybe in google it happens often, but for most smaller companies that is "very rarely"

Re: Microservices Architecture on Google Cloud

#30

Post by da39a3ee »

qaq wrote: post #21
westoque wrote: post #19

> It is extremely difficult to change a monolith’s technology or language or framework because all components are tightly coupled and dependent on each other. As a result, even relatively small changes can require lengthy development and deployment times. I disagree with this so much. I have personally worked with Rails application monoliths and Node.js microservices and I can tell you that making changes on the mono…

It's obvious BS driven by cloud marketing because in monolith case you pay them for way fewer services. In Micro Services case a single client request will generate a number of downstream requests to multiple services driving the cloud provider's profits up. You also have a higher chance of using their highest margin tracing/telemetry offerings.

Not sure whether you just meant that as humorous cynicism, but I think it has more to do with pain experienced by teams working on monoliths and them thinking “there has to be a better way”.
Post reply on HN