[HN Gopher] Ten Years and Counting: My Affair with Microservices
___________________________________________________________________
Ten Years and Counting: My Affair with Microservices
Author : mkosmul
Score : 63 points
Date : 2024-04-12 08:52 UTC (1 days ago)
(HTM) web link (blog.allegro.tech)
(TXT) w3m dump (blog.allegro.tech)
| dvfjsdhgfv wrote:
| 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.
| smokel wrote:
| Perhaps they like working together in a physical space. It's
| not all about attracting sociopathic talent.
| paulryanrogers wrote:
| What about demanding WFH makes the talent sociopathic?
| alex_lav wrote:
| Both sides of this argument are being dogmatic.
| dvfjsdhgfv wrote:
| 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.
| alex_lav wrote:
| 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.
| smokel wrote:
| I was responding, slightly in jest, to the "Which is plain
| stupid" argument.
| dvfjsdhgfv wrote:
| 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.
| anotherhue wrote:
| Break the office monolith up in to micro offices. Do one thing
| well.
| rezonant wrote:
| You win the Internet today. At least for this morning, it's
| early yet here.
| aetherson wrote:
| Can we please not import the WFH/WIO flamewar to unrelated
| threads?
| hwbunny wrote:
| The developer's vanity and ego is a really big mountain to tear
| down in devspace, really.
| jmugan wrote:
| 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.
| cjk2 wrote:
| This is my life these days :(
| wkyleg wrote:
| I'd love to hear from more people who just don't use micro
| services at all and vertically scale Elixir/Phoenix
| threeseed wrote:
| 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.
| rezonant wrote:
| 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 multiple independently
| scalable services) makes much more sense when the dev team is not
| big enough to justify the added overhead, but some aspects of the
| application require independent horizontal scaling.
| hermanradtke wrote:
| > 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
| rezonant wrote:
| Oh, thanks. I still don't necessarily agree with the author
| either, but at least there's a passing justification.
| Arcanum-XIII wrote:
| 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.
| zdragnar wrote:
| 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.
| dvfjsdhgfv wrote:
| It's a long article but they do mention it a few times.
| damagednoob wrote:
| Did I miss the justification for the switch to Java? That
| decision seemed to come out of the blue.
| KptMarchewa wrote:
| "It's not PHP" is as good justification as it gets
| pylon wrote:
| 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.
| threeseed wrote:
| 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.
| jokethrowaway wrote:
| 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.
___________________________________________________________________
(page generated 2024-04-13 23:01 UTC)