Live data from Hacker News

Ten Years and Counting: My Affair with Microservices

blog.allegro.tech

11–20 of 52 posts

Re: Ten Years and Counting: My Affair with Microservices

#11
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

Re: Ten Years and Counting: My Affair with Microservices

#12
post #3

Earlier quoted context omitted.

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

What about demanding WFH makes the talent sociopathic?

I was responding, slightly in jest, to the "Which is plain stupid" argument.

Re: Ten Years and Counting: My Affair with Microservices

#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

Re: Ten Years and Counting: My Affair with Microservices

#15
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. That means it's very hard to have the right people on the table, they're slow to react to any change (if they even can)... For a small change, they requested 3 months. On our side, if a dev is available, this would have been solved in a week.

Neither situation is good: we're under stress for ressources availability, when they're stuck in Kafka's world. Last week I learned that two different team ingest some of our data — which is fine, except that we moved to an API and only the first team use it. The second team was not aware that it exist (well, forgot about it).

I don't know what the good solution when you reach this kind of headcount would be. As a PM/PO, I'm baffled about this kind of complexity. My experience lead me to think that no one is managing that currently... it's kind of working, till it falls, hard.

Re: Ten Years and Counting: My Affair with Microservices

#18
I've been through similar transformation (just 250 microservices) and I'm not sure the end result was actually better. Microservices are ok if things go well and you can maintain a large army of developers - which you didn't really need in the first place.

In my case: Fast forward 5 years and the business growth didn't materialize; the board made working in the content unpleasant enough so that all the good and expensive developers left and outsourced the rest to India. These poor contractors have to deal with 20 microservices per team (while we were juggling 5-10, already to much, I think 1-2 services per team).

The old monolith were fine. Microservices - and transitions to new languages - create a lot of new problems (performance of joins over network, rabbitmq dead letters handling, services ddosing each others, updating a shared library and having to bump it in every service in the entire company)

I feel like it was basically spinning wheels.

Re: Ten Years and Counting: My Affair with Microservices

#19

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.

Can we please not import the WFH/WIO flamewar to unrelated threads?
Post reply on HN