Live data from Hacker News

Ten Years and Counting: My Affair with Microservices

blog.allegro.tech

21–30 of 52 posts

Re: Ten Years and Counting: My Affair with Microservices

#21
post #3

As a side note, the management of this company a while go announced they would cancel WFH. A standard story - they built a huge office nobody wanted to use. So whoever could, tried to find a new job. The rest have to go to the office 3 days a week by default. Which is plain stupid because they could get much more talent if they weren't that inflexible.

Perhaps they like working together in a physical space. It's not all about attracting sociopathic talent.

Who, the management or employees? Because many employees left after this announcement.

Leaving aside your unnecessary name-calling, many tech people indeed do enjoy working together, but not necessarily always in the same physical space.

Re: Ten Years and Counting: My Affair with Microservices

#22

Earlier quoted context omitted.

What about demanding WFH makes the talent sociopathic?

Both sides of this argument are being dogmatic.

I don't think it is true, because one side says: "You absolutely must come to the office at least N days a week", and the other side doesn't say "Nobody must come to the office" but "Why don't you let people decide for themselves"?

In other words, it is a discussion between inflexible dogmatism and elasticity.

Re: Ten Years and Counting: My Affair with Microservices

#23
post #9

I missed the part where the person describes that they have a very large development team which justified a non-monolithic architecture. True microservices (with independent development and inter-service contracts) are a reflection of the makeup and scale of the development team. Using true microservices for performance reasons is a misnomer these days: A modular monolith (one codebase that can be deployed into multi…

It's a long article but they do mention it a few times.

Re: Ten Years and Counting: My Affair with Microservices

#24

Earlier quoted context omitted.

Both sides of this argument are being dogmatic.

I don't think it is true, because one side says: "You absolutely must come to the office at least N days a week", and the other side doesn't say "Nobody must come to the office" but "Why don't you let people decide for themselves"? In other words, it is a discussion between inflexible dogmatism and elasticity.

To suggest that everyone should be allowed to decide their own situation is either ignorant or dogmatic. Pretending everyone that works from home gets as much done as in person is either ignorant or dogmatic. Context is important. There are people working from home that shouldn't be. There are people working from an office that don't need to be. There is no single rule that will make everyone happy, nor should there be.

Re: Ten Years and Counting: My Affair with Microservices

#25
post #9

I missed the part where the person describes that they have a very large development team which justified a non-monolithic architecture. True microservices (with independent development and inter-service contracts) are a reflection of the makeup and scale of the development team. Using true microservices for performance reasons is a misnomer these days: A modular monolith (one codebase that can be deployed into multi…

> missed the part where the person describes that they have a very large development team which justified a non-monolithic architecture. I am not agreeing with the author, but they said it here: > the number of pull requests produced daily by a few hundred developers was so large

Oh, thanks. I still don't necessarily agree with the author either, but at least there's a passing justification.

Re: Ten Years and Counting: My Affair with Microservices

#26
post #17

Having 1000+ services seems like an overkill for an ecommerce company. I certainly hope they aren't doing something silly like a service for each payment type or a service to manage inventory and another service to manage orders.

I've worked on many projects with far more services and it's often because of environments.

e.g. we had a process where every PR would spin up a full environment for automation and manual testing to work from.

Re: Ten Years and Counting: My Affair with Microservices

#27
post #9

I missed the part where the person describes that they have a very large development team which justified a non-monolithic architecture. True microservices (with independent development and inter-service contracts) are a reflection of the makeup and scale of the development team. Using true microservices for performance reasons is a misnomer these days: A modular monolith (one codebase that can be deployed into multi…

I'm currently working in an environment where the company I work for has a quite limited IT department that has responsibilities covering hardware and software. One of our investor has a bigger headcount for IT only that's bigger than our company size and we're trying to integrate with them... they're on micro service. It's funny because even though it seemed very well engineered, it create a bureaucratic environment…

The problem you describe is one of a lack of ownership. I'm at a company that has a quite small engineering team, but other departments have their own services (dashboards that read from our database, marketing CRM, etc) which means any change at all to any database table requires bringing together multiple departments to make sure nobody gets upset by the change.

It's easier to have a single owner at a smaller scale (something we should do) but even at a company with a large engineering team, there needs to be someone whose responsibility is to manage dependencies. Otherwise, it falls back to design by committee, and that's how you end up in your situation: nobody actually knows how anything works, and there is literally no way to find out.

Re: Ten Years and Counting: My Affair with Microservices

#28
post #5

I assume Hacker News has a bot that automatically posts this skit for every microservice article, but it case it doesn't https://www.youtube.com/watch?v=y8OnoxKotPQ . We should all know Galactus' pain.

From experience this happens just as often inside monoliths.

It's a symptom of over-engineering and building for the future rather than anything inherent to microservices. Java had a whole decade of being obsessed with design patterns e.g Facade, Decorator that resulted in the same spaghetti architecture.

Re: Ten Years and Counting: My Affair with Microservices

#29
post #14
post #5

I assume Hacker News has a bot that automatically posts this skit for every microservice article, but it case it doesn't https://www.youtube.com/watch?v=y8OnoxKotPQ . We should all know Galactus' pain.

I’d love to hear from more people who just don’t use micro services at all and vertically scale Elixir/Phoenix

The only sane microservice amalgamation I worked on was with Elixir/Phoenix. It was event driven and that was the key. I think event driven microservices are an extemely powerful architecture but it’s still the early days for them until we can get really good open source support for replays, sectioning off events from a period, and lots of utilities like that as well as figure out all of the best practices.

I’ve built monoliths but never at scale, but don’t see why they wouldn’t have scaled incredibly well. I have built macroservices that have scaled super well (5ish services IIRC).

Re: Ten Years and Counting: My Affair with Microservices

#30
post #17

Having 1000+ services seems like an overkill for an ecommerce company. I certainly hope they aren't doing something silly like a service for each payment type or a service to manage inventory and another service to manage orders.

I have no clue if it's too much but allegro is biggest ecomerce website in Poland and it works amazingly. I'm currently in Spain and I'm forced to use Amazon and oh lord - I can't event star to wrap my head aourd how on earth people can use that crap - it is slow AF, it's search functionality is abysmal and filtering results almost doesn't. exist... o_X
Post reply on HN