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

Ten Years and Counting: My Affair with Microservices

blog.allegro.tech

Post reply on HN
Print view View original

41–50 of 52 posts

Re: Ten Years and Counting: My Affair with Microservices

#41

Post by exe34 »

bobthepanda wrote: post #37
cqqxo4zV46cp wrote: post #31

Earlier quoted context omitted.

Microservices invite over-engineering more than monoliths do. Monoliths are more prone to inviting a lack of a structure. That’s kind of…a big potential advantage of microservices, I guess.

the theoretically nice thing about microservices is that because the API boundary should be well defined, any possible application that can fulfill that API, whether it's Java, Rust, or three raccoons in a trench coat can become the new microservice fairly easy.

All we have are three raccoons in a trashcan, but you'll be able to fit this in the current sprint, right?

Re: Ten Years and Counting: My Affair with Microservices

#42

Post by cultofmetatron »

hmmokidk wrote: post #29
wkyleg wrote: post #14

Earlier quoted context omitted.

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 buil…

having built my own startup in elixir/phoenix, i'd have to agree.

I think it comes down to how you define a microservice/monolith. when it comes down to codebase, our codebase is very much a monolith. however elixir lets you connect nodes together and setup individualized processes that can be communicated with by any other node in your network toplolgy using the BEAM's built in pubsub system. in essence, creating a new microservice is easy. you just define a geneserver file and add it to your application.ex. about as much effort as adding a controller in rails and that makes a big difference. you get a lot of the advantage of microservice architecture where you spread computation across your physical machines but the codebase is a small easy to maintain monolith.

Re: Ten Years and Counting: My Affair with Microservices

#43

Post by smokel »

dvfjsdhgfv wrote: post #22
alex_lav wrote: post #10

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.

I think the idea with companies is that management decides. If you don't like that, you can discuss it, go someplace else, or even start your own company. But demanding it, and calling management stupid would be my last resort.

Re: Ten Years and Counting: My Affair with Microservices

#44

Post by john_the_writer »

bobthepanda wrote: post #37
cqqxo4zV46cp wrote: post #31

Earlier quoted context omitted.

Microservices invite over-engineering more than monoliths do. Monoliths are more prone to inviting a lack of a structure. That’s kind of…a big potential advantage of microservices, I guess.

the theoretically nice thing about microservices is that because the API boundary should be well defined, any possible application that can fulfill that API, whether it's Java, Rust, or three raccoons in a trench coat can become the new microservice fairly easy.

The problem with that. Maintenance. Team X writes a micorservice in Node. Team A->W write in elixir. Bug in Micro_X and tada... company is screwed. No one wants to learn Node, so the bugs stay around, get worked around and then Micro_X gets re-written in elixir, because coders have to fix stuff.

Re: Ten Years and Counting: My Affair with Microservices

#45

Post by thesnide »

john_the_writer wrote: post #44
bobthepanda wrote: post #37

Earlier quoted context omitted.

the theoretically nice thing about microservices is that because the API boundary should be well defined, any possible application that can fulfill that API, whether it's Java, Rust, or three raccoons in a trench coat can become the new microservice fairly easy.

The problem with that. Maintenance. Team X writes a micorservice in Node. Team A->W write in elixir. Bug in Micro_X and tada... company is screwed. No one wants to learn Node, so the bugs stay around, get worked around and then Micro_X gets re-written in elixir, because coders have to fix stuff.

That is painfully accurate. My usual response to it is https://despair.com/products/break-the-rules

It usually gives me angry looks at first, but thanks after several years when there's enough turnover.

Re: Ten Years and Counting: My Affair with Microservices

#46

Post by dvfjsdhgfv »

smokel wrote: post #43
dvfjsdhgfv wrote: post #22

Earlier quoted context omitted.

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.

I think the idea with companies is that management decides. If you don't like that, you can discuss it, go someplace else, or even start your own company. But demanding it, and calling management stupid would be my last resort.

I wouldn't call i stupid if I didn't have direct experience, several times. Once a board asked my opinion regarding RTO and I told them openly if they do that, the top talent will leave. They answered, "Nah, they won't". Well, it turned out I was right. I'm not saying it was the same in the case of Allegro, maybe the board realized this will happen but decided to proceed anyway, but I have the right not to call it a smart strategy.

Re: Ten Years and Counting: My Affair with Microservices

#47

Post by dvfjsdhgfv »

alex_lav wrote: post #24
dvfjsdhgfv wrote: post #22

Earlier quoted context omitted.

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…

> To suggest that everyone should be allowed to decide their own situation is either ignorant or dogmatic.

Yet, this is exactly how the job market works.

Re: Ten Years and Counting: My Affair with Microservices

#48

Post by alex_lav »

dvfjsdhgfv wrote: post #47
alex_lav wrote: post #24

Earlier quoted context omitted.

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…

> To suggest that everyone should be allowed to decide their own situation is either ignorant or dogmatic. Yet, this is exactly how the job market works.

Yes, literally everyone that wants to work from home is able to. That's what you're saying. That every single employable person decides whether to work from home?

Again, dogmatism.

Re: Ten Years and Counting: My Affair with Microservices

#49

Post by pc86 »

zdragnar wrote: post #27
Arcanum-XIII wrote: post #15

Earlier quoted context omitted.

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…

Exactly this - they needs months to respond to "small" changes because nobody knows who at the day is responsible for a given service. They probably need to time to filter the request through the product office, find out which service(s) are affected, find the dev team(s) responsible for those service(s), and beg/harass/bribe the EM(s) for those teams to get the work scheduled.

If they had documented service contracts with ownership information attached they could probably have the GP's team communicate directly with the service devs and it would likely go a lot smoother.

Re: Ten Years and Counting: My Affair with Microservices

#50

Post by bobthepanda »

john_the_writer wrote: post #44
bobthepanda wrote: post #37

Earlier quoted context omitted.

the theoretically nice thing about microservices is that because the API boundary should be well defined, any possible application that can fulfill that API, whether it's Java, Rust, or three raccoons in a trench coat can become the new microservice fairly easy.

The problem with that. Maintenance. Team X writes a micorservice in Node. Team A->W write in elixir. Bug in Micro_X and tada... company is screwed. No one wants to learn Node, so the bugs stay around, get worked around and then Micro_X gets re-written in elixir, because coders have to fix stuff.

Terrible engineering is also possible in the monolith, it’s just significantly harder to rewrite sour bits of monolith independently.
Post reply on HN