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

41–49 of 49 posts

Re: Microservices Architecture on Google Cloud

#41

Post by ehnto »

qaq wrote: post #38
da39a3ee wrote: post #30

Earlier quoted context omitted.

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

It's orders of magnitude easier to architect modular monolith than to build, test, deploy and manage a distributed system (e.g. microservices).

Well made modularity gets you many of the same benefits as microservices, without any of the deployment complexity. The articles argument about changing architecture and language being difficult seems like a red herring, because you shouldn't want to be changing architecture or language particularly frequently.

I'd really wager that you should be building your code to last the full life of the product from the start, with adaptability to changing scope and requirements being delivered by that modularity.

You of course don't always know the full scope of the project from day one, so you don't typically build software like you would build a bridge, with a fully holistic plan. But you can totally account for the future when you initial build a monolith.

Re: Microservices Architecture on Google Cloud

#42

Post by necovek »

Youden wrote: post #39
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…

I think you missed the "technology or language or framework" part. Their argument is that if you have a monolith and want to say move from Ruby to TypeScript, you basically have to rewrite the whole thing and migrate in one go, which is a massive pain. If you have microservices and want to do the same, you can move one service at a time.

But that ain't true either.

You can even move from one monolith to the other. Eg. a single DB store, and you just move a set of APIs (this set of APIs live in Ruby monolith, and it can talk to TypeScript monolith). Just put a reverse proxy in front (which you're likely to already run), and route requests to the proper service. Sure, some things will be trickier, but they'd be tricky anyway (eg. if you want to move user management APIs which tie into privilege handling, it's going to be finicky no matter how you slice it).

The main driver for SOA (and microservices by extension) is to allow independent iteration of components by independent teams. On small teams, it's usually not a win at all because you introduce a lot of overhead and you need to really be on point regarding backwards compatibility (or statelessness) and API specs.

Sure, monoliths do allow unrestricted use of (a particular set of) suboptimal patterns, but I've seen one too many "microservices" which have "custom" protocols that are only ever changed in sync on both sides of the microservice (server and clients).

Re: Microservices Architecture on Google Cloud

#44

Post by blackoil »

necovek wrote: post #42
Youden wrote: post #39

Earlier quoted context omitted.

I think you missed the "technology or language or framework" part. Their argument is that if you have a monolith and want to say move from Ruby to TypeScript, you basically have to rewrite the whole thing and migrate in one go, which is a massive pain. If you have microservices and want to do the same, you can move one service at a time.

But that ain't true either. You can even move from one monolith to the other. Eg. a single DB store, and you just move a set of APIs (this set of APIs live in Ruby monolith, and it can talk to TypeScript monolith). Just put a reverse proxy in front (which you're likely to already run), and route requests to the proper service. Sure, some things will be trick ier , but they'd be tricky anyway (eg. if you want to move…

It is possible but not as simple as you suggest. Take a email/notification service being part of monolith, changing that to a new language / arch. is lot more complex then a similar micro-service connected via Kafka/GRPC.

Re: Microservices Architecture on Google Cloud

#45

Post by isubasinghe »

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…

Isn't sel4 super fast?

Re: Microservices Architecture on Google Cloud

#46

Post by necovek »

blackoil wrote: post #44
necovek wrote: post #42

Earlier quoted context omitted.

But that ain't true either. You can even move from one monolith to the other. Eg. a single DB store, and you just move a set of APIs (this set of APIs live in Ruby monolith, and it can talk to TypeScript monolith). Just put a reverse proxy in front (which you're likely to already run), and route requests to the proper service. Sure, some things will be trick ier , but they'd be tricky anyway (eg. if you want to move…

It is possible but not as simple as you suggest. Take a email/notification service being part of monolith, changing that to a new language / arch. is lot more complex then a similar micro-service connected via Kafka/GRPC.

Depends on how it's structured in the monolith. If it's well encapsulated — eg. one API call to trigger a notification that goes to a job-runner which sends the actual notification, which is the standard way of doing these in the monoliths I've seen — it's going to be similarly simple/hard.

But that was exactly my point: how hard it is depends on the code structure that has no relationship to whether you are in a SOA or a monolith architecture.

Sure, some (bad) patterns are hard in SOA which are trivial in a monolith, but they are bad patterns regardless. What matters is that you replace bad patterns with good patterns.

Re: Microservices Architecture on Google Cloud

#47

Post by ZeroCool2u »

jillesvangurp wrote: post #37

Google does make dealing with dockerized services pretty easy. I'm CTO for a small startup. I actually know how to use Kubernetes, Terraform and have used a lot of configuration languages like puppet, ansible, and chef in the past fifteen years as well. However, what these have in common is that using them properly can more or less become a full time job for a few months. It's never simple or easy. I've been on multi…

Google Cloud Run is so underrated. The only thing you absolutely need to know to deploy is to use the port assigned via the environmental variable Run provides your container and just be aware that your container is stateless. Everything else is up to you. Like you point out, it's completely portable in a way that rarely anything on AWS is.

Re: Microservices Architecture on Google Cloud

#48

Post by thrashh »

blackoil wrote: post #44
necovek wrote: post #42

Earlier quoted context omitted.

But that ain't true either. You can even move from one monolith to the other. Eg. a single DB store, and you just move a set of APIs (this set of APIs live in Ruby monolith, and it can talk to TypeScript monolith). Just put a reverse proxy in front (which you're likely to already run), and route requests to the proper service. Sure, some things will be trick ier , but they'd be tricky anyway (eg. if you want to move…

It is possible but not as simple as you suggest. Take a email/notification service being part of monolith, changing that to a new language / arch. is lot more complex then a similar micro-service connected via Kafka/GRPC.

IMO the only reason why people run into trouble is because they code as if everything completes instantly. For example, they’ll write to disk assuming the operation is quick, because that’s what they’re used to. You see this all the time in all sorts of software when it freezes up and errors cascade.

People just code like everything works all the time. Then when they want to integrate an external service, they have to rewrite everything.

If you understand that network calls have to made and electrical signals have to pass down a bus when you write either a monolith or a microservice, going back and swapping services is super easy.

Re: Microservices Architecture on Google Cloud

#49

Post by tomnipotent »

blackoil wrote: post #44
necovek wrote: post #42

Earlier quoted context omitted.

But that ain't true either. You can even move from one monolith to the other. Eg. a single DB store, and you just move a set of APIs (this set of APIs live in Ruby monolith, and it can talk to TypeScript monolith). Just put a reverse proxy in front (which you're likely to already run), and route requests to the proper service. Sure, some things will be trick ier , but they'd be tricky anyway (eg. if you want to move…

It is possible but not as simple as you suggest. Take a email/notification service being part of monolith, changing that to a new language / arch. is lot more complex then a similar micro-service connected via Kafka/GRPC.

> Take a email/notification service being part of monolith

The only extra work is updating the monolith to call the extracted service, which isn't that hard.

Post reply on HN