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

Faster, cheaper, and better: A story of breaking a monolith

zepworks.com

Post reply on HN
Print view View original

31–40 of 48 posts

Re: Faster, cheaper, and better: A story of breaking a monolith

#31

Post by seperman »

argd678 wrote: post #28

This is cutting it close to say microservice, it’s just two services and they don’t fan out or have a lot of the complexity that causes the down sides; such as fan outs that require tracing to debug, requires too many services to startup on your laptop for dev, load testing and tuning, common libraries that cause systemic failures or require world rebuilds when modified, service to service authentication...

This is a very simplified version of our architecture just for the purpose of this article. We have exactly 83 micro-services currently.

Re: Faster, cheaper, and better: A story of breaking a monolith

#32

Post by seperman »

fouc wrote: post #26
simplify wrote: post #22

Earlier quoted context omitted.

How is it easier to on-board new engineers? You mentioned but did not explain this point.

Easier to on-board in the sense of limiting what new engineers can see, only giving them smaller pieces of access. Otherwise it's probably the opposite, takes a lot longer for new engineers to understand the full system. Perhaps even reduces the bus factor, since less people understand all the moving parts.

Exactly. I could not have explained it better than you.

Re: Faster, cheaper, and better: A story of breaking a monolith

#33

Post by seperman »

gitgud wrote: post #27
seperman wrote: post #18

Earlier quoted context omitted.

Not sure if I agree with you regarding the agile part. If each team owns their "micro-service", then they can have their own "sprints".

Yes in very large systems that's true. But in the other systems, there's huge overheads which restrict systems from changing. - Multiple execution environments - Complexity in communication between services - Managing the versioning of each service and it's dependent services. Although services are easily to scale and change independently, they are hard to reconfigure globally , which means the application as a whole…

There are pros and cons to the micro-services architecture. To your point it is not a black or white solution. Our systems are fairly large and over-engineered.

Often switching to microservices means reducing the complexity of communication between teams at the expense of increasing the complexity of communication between services.

Re: Faster, cheaper, and better: A story of breaking a monolith

#35

Post by seperman »

profalseidol wrote: post #34

Can you view Microservices in the same light as multiple companies? Just like when your monolith calls on a third party API that does the payment for you - ain't that also a microservices that happens to involves 2 different individual companies?

Hmm, not sure if I'm completely following... Yeah you can consider them separate entities if they are truly decoupled.

Re: Faster, cheaper, and better: A story of breaking a monolith

#36

Post by bobm_kite9 »

Why is microservices so much more popular right now than, say, distributed processing via the actor model? It feels like splitting things up with HTTP boundaries is a lot of work, less flexible and precludes a lot of re-use. Is it just because of advances in tooling lately like Kubernetes and docker?

Re: Faster, cheaper, and better: A story of breaking a monolith

#38

Post by seperman »

bobm_kite9 wrote: post #36

Why is microservices so much more popular right now than, say, distributed processing via the actor model? It feels like splitting things up with HTTP boundaries is a lot of work, less flexible and precludes a lot of re-use. Is it just because of advances in tooling lately like Kubernetes and docker?

That is a great question. Kubernetes and docker and the recent addition of service mesh layer definitely do make things easier for micro-services. However as another commenter mentioned, Microservices are typically an organizational rather than technical feature. We do use pubsub pattern for distributed processing widely. Regarding the http boundaries point that you brought up, we use gRPC instead of HTTP for most services.

Re: Faster, cheaper, and better: A story of breaking a monolith

#39

Post by seperman »

raptorraver wrote: post #37

Good read, thanks! I’d be interested to know how long this all took and how many developers were involved.

It took over a quarter of the year with one engineer 100% dedicated to it and between 1 to 3 other engineers involved part-time over different stages of the project.
Post reply on HN