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

21–30 of 48 posts

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

#21

Post by seperman »

budabudimir wrote: post #20
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".

What is the difference between each team owning a microservice and owning a part of the monolith? There is common release process, but with proper infra in place, that shouldn't be a problem.

I was just disagreeing with "Microservices are almost completely opposed to agile development". You can be agile in both monolith architecture and micro-services. I don't see why microservices can be opposed to agile.

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

#22

Post by simplify »

seperman wrote: post #10
trishume wrote: post #7

It seems like most or all of the benefits listed in this post could have been achieved just as easily by changing code in their monolith. Like the ElasticSearch optimizations and the decoupling from the relational database. Similarly the benefits they do tie explicitly to microservices like scoped errors and tests can also be achieved in monoliths with simple filters on the errors and tests being run, without all the…

I do not disagree with your comment. As I mentioned in the article the main reasons to break into micro-services are: 1. Independent releases 2. Easier for on-boarding new engineers 3. Scale micro-services independently The rest of the article is about how to use the breakout opportunity to make major changes to the code and the data-structure. The goal is for the users of the service to have an aha moment of "Search…

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

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

#23

Post by aylmao »

ryan_j_naughton wrote: post #5
seperman wrote: post #3

Earlier quoted context omitted.

Mainly saved in infrastructure costs: Elasticsearch and Kubernetes resources.

Also from Fair here. A lot of the cost savings were because we could decrease the size of our elasticsearch cluster. This was mostly due to the flattening of the elasticsearch document schema, which improved performance dramatically but also allowed us to run significantly fewer ES nodes.

Gotcha, thanks for reaching back!

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

#24

Post by ryan_j_naughton »

drbojingle wrote: post #14
seperman wrote: post #10

Earlier quoted context omitted.

I do not disagree with your comment. As I mentioned in the article the main reasons to break into micro-services are: 1. Independent releases 2. Easier for on-boarding new engineers 3. Scale micro-services independently The rest of the article is about how to use the breakout opportunity to make major changes to the code and the data-structure. The goal is for the users of the service to have an aha moment of "Search…

How many engineers do you have and what's your growth in manpower like?

Our entire product, engineering, data science, design org is around 80-90. Engineering is about 50-65% of that.

But search/merchandising is a small fraction of the team. We have 2 dedicated backend engineers on the search team.

We are growing rapidly. We are aiming to double the size of the eng org in the next 8 months.

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

#25

Post by yandrypozo »

I went straight searching for advises on how to avoid a distributed monolith, but no luck, looks like most of the micro-services now days are just distributed monolith.

Let's share advises about it: https://medium.com/unbabel/your-distributed-monoliths-are-se...

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

#26

Post by fouc »

simplify wrote: post #22
seperman wrote: post #10

Earlier quoted context omitted.

I do not disagree with your comment. As I mentioned in the article the main reasons to break into micro-services are: 1. Independent releases 2. Easier for on-boarding new engineers 3. Scale micro-services independently The rest of the article is about how to use the breakout opportunity to make major changes to the code and the data-structure. The goal is for the users of the service to have an aha moment of "Search…

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.

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

#27

Post by gitgud »

seperman wrote: post #18
gitgud wrote: post #17

Earlier quoted context omitted.

Microservices are almost completely opposed to agile development. They require a strong architecture before implementation and are much harder to reconfigure regardless of versioning. The running system is also hard to manage.

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 is hard to change...

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

#28

Post by argd678 »

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

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

#29

Post by BurningFrog »

gitgud wrote: post #17
seperman wrote: post #10

Earlier quoted context omitted.

I do not disagree with your comment. As I mentioned in the article the main reasons to break into micro-services are: 1. Independent releases 2. Easier for on-boarding new engineers 3. Scale micro-services independently The rest of the article is about how to use the breakout opportunity to make major changes to the code and the data-structure. The goal is for the users of the service to have an aha moment of "Search…

Microservices are almost completely opposed to agile development. They require a strong architecture before implementation and are much harder to reconfigure regardless of versioning. The running system is also hard to manage.

Microservices are typically an organizational rather than technical feature.

If each team are given their own microservice to manage the way they choose, things can work smoothly.

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

#30

Post by [deleted] »

ryan_j_naughton wrote: post #5
seperman wrote: post #3

Earlier quoted context omitted.

Mainly saved in infrastructure costs: Elasticsearch and Kubernetes resources.

Also from Fair here. A lot of the cost savings were because we could decrease the size of our elasticsearch cluster. This was mostly due to the flattening of the elasticsearch document schema, which improved performance dramatically but also allowed us to run significantly fewer ES nodes.

[deleted]
Post reply on HN