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

Microservices Are Something You Grow Into, Not Begin With

nickjanetakis.com

Post reply on HN
Print view View original

11–20 of 159 posts

Re: Microservices Are Something You Grow Into, Not Begin With

#11

Post by lbriner »

I agree that microservices is the new "must have" technology but actually it isn't a great deal different from a monolith. The monolith can have separation between services and still requires interfaces to work between them.

As others have said, microservices bring a lot of baggage that you might never have seen before (i.e. big learning curve) and the myth of isolated changes is just that, a myth. Unless it is some low level thing, you cannot change it without impacting other services and this is no different than a monolith.

Like the article yesterday about OOP, the same principles exist to write a good application whatever you use to do it.

Re: Microservices Are Something You Grow Into, Not Begin With

#12

Post by majidazimi »

microwhat wrote: post #8
majidazimi wrote: post #2

Why not? I mean we don't use micro-services for what it is supposed to do. The application would perfectly be a monolith. We do it, just because it lets us experiment newer technologies in not-so-important services in a smaller scale without undergoing major re-work since when the change is big, everyone in management layer understandably becomes conservative.

Sounds like resume-driven-development. I worked at a company with this disease before. The system was an abomination of vastly different technologies over the years stitched together loosely. Development was slowed substantially by having such a mess and the company couldn't move fast enough to compete so the startup died. Usually tech isn't the reason for a startup's death. In this case, it was.

> Sounds like resume-driven-development.

Sure. That's one of the responsibilities of a team lead: to help team members to work and gradually build up their CVs. I want my team to experiment new stuff and learn while working. But I also want to limit the risk boundary. The whole reason why younger people are leaving dinosaur companies is that no one in management layer lets juniors experiment and fail. End of the day junior devs also want to improve and develop.

Re: Microservices Are Something You Grow Into, Not Begin With

#13

Post by hoffs »

IMTDb wrote: post #4
js4ever wrote: post #3

What I love about microservices is isolation and forcing you to do thing well from the beginning. Monoliths tend to become horrible to maintain after few years. On the opposite change one small 50 lines microservice is a lot less risky!

What I love about monolith is coherence and forcing you to do things well from the beginning. Microservice mesh tend to become horrible to maintain after a few years when no one really measure which components will be impacted by a single change. On the opposite, change one small 50 line function and your IDE will happily show you all the calls to that specific function.

Just like you have tests between monolith modules you can have integration tests between microservices

Re: Microservices Are Something You Grow Into, Not Begin With

#14

Post by lmz »

INTPenis wrote: post #5

I grew out of microservices because it felt like I was doing the same boilerplate REST service over and over. So I made a modular REST API service that could load plugins. The plugins can contain anything from simple endpoints to database schemas with sqlalchemy. All this is loaded into the main app at runtime. So the main app can handle authentication against LDAP for example while all the various deployed microserv…

So a Python version of a J2EE app server?

Re: Microservices Are Something You Grow Into, Not Begin With

#16

Post by joshschreuder »

hoffs wrote: post #13
IMTDb wrote: post #4

Earlier quoted context omitted.

What I love about monolith is coherence and forcing you to do things well from the beginning. Microservice mesh tend to become horrible to maintain after a few years when no one really measure which components will be impacted by a single change. On the opposite, change one small 50 line function and your IDE will happily show you all the calls to that specific function.

Just like you have tests between monolith modules you can have integration tests between microservices

The more layers you are testing, the slower and harder it is to write tests and the feedback loop is way longer also.

Re: Microservices Are Something You Grow Into, Not Begin With

#17

Post by z3t4 »

There's trade-off's. They are using a fairly complex CI while with micro-services you release each service individually. It's hard to turn a monolith architecture into a architecture with micro-services. So it all depends on what works best for you. The idea with micro-services is that with a much smaller service - development is faster and cheaper, you can for example rewrite the entire service, use different software stacks (the best tool for the job), etc. Where as a total rewrite is not feasible in a monolith.

Re: Microservices Are Something You Grow Into, Not Begin With

#18

Post by kabes »

lbriner wrote: post #11

I agree that microservices is the new "must have" technology but actually it isn't a great deal different from a monolith. The monolith can have separation between services and still requires interfaces to work between them. As others have said, microservices bring a lot of baggage that you might never have seen before (i.e. big learning curve) and the myth of isolated changes is just that, a myth. Unless it is some…

Indeed. It just replaces internal calls between services of your monolith with flaky and slower network calls.

Re: Microservices Are Something You Grow Into, Not Begin With

#19

Post by arendtio »

There are many ways to slice an apple.

Sometimes it is a good idea to build something as microservices, but you just have taken the wrong approach, and therefore it is a pain in the *. So slicing it a different way might still be a microservice architecture but feel much better.

Recently I thought about setting up a Firefox Sync server. The first bumper was when I learnt that the sync server has a dependency on the accounts server... But the full-featured accounts server, in turn, consists of a bunch of services of its own [1]:

- fxa-content-server

- fxa-profile-server

- fxa-auth-server

- fxa-oauth-server

- browserid-verifier

- fxa-auth-db-mysql

After seeing that I decided to tackle that project another day.

For Mozilla that architecture might be perfect, but for most people who just want to run a separate server for [1]: https://github.com/michielbdejong/fxa-self-hosting

Re: Microservices Are Something You Grow Into, Not Begin With

#20

Post by icebraining »

lmz wrote: post #14
INTPenis wrote: post #5

I grew out of microservices because it felt like I was doing the same boilerplate REST service over and over. So I made a modular REST API service that could load plugins. The plugins can contain anything from simple endpoints to database schemas with sqlalchemy. All this is loaded into the main app at runtime. So the main app can handle authentication against LDAP for example while all the various deployed microserv…

So a Python version of a J2EE app server?

Or a framework like Django.
Post reply on HN