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

Some thoughts on microservices

filipnikolovski.com

Post reply on HN
Print view View original

21–30 of 139 posts

Re: Some thoughts on microservices

#21

Post by wayoutthere »

I have found one other use case: limiting the blast radius of ops and deployment issues. As an example, I once was working with a large telecom client who had their AAA web service (yes, don’t roll your own auth, but this client was big enough and had the right expertise on staff to do so) in the same monolith as their account management web service. The account management service saw active, frequent development to support new functionality while the AAA code only got updated a couple times a year.

Why touch a critical web service relied upon by literally every product you have when you don’t have to? Your business still functions if account management is offline; but not when authentication is offline. Even short outages to auth were unacceptable (millions of customers) and any updates had to be performed in constrained windows due to the criticality of the service.

So we cleaved off the mission-critical parts, stuck them in their own repos to be versioned independently, which let us move faster on the account management work since we could confidently deploy code that wasn’t 100% working because we didn’t need to wait for a maintenance window.

Re: Some thoughts on microservices

#22

Post by koblas »

KronisLV wrote: post #13

> Never start with a microservice architecture if you have a single team. This is probably a good point, however isn't the entirety of the story. Personally, i agree that most teams shouldn't start out with microservices, monoliths can be entirely sufficient and are easier to run and reason about. Otherwise you might end up with so much operational complexity that you don't have much capacity left to actually develop…

There is a huge amount of truth to this. I've been thinking of these as Microliths large monolithic codebases surrounded by service workers (lambda style or queue style).

The biggest problem I've seen is that early applications are not built in a modular fashion. More as a maze of twisty little functions calling each other, where you quickly end up with circular dependancies and other "challenges". If your base monolithic architecture mimics the world of microservices, modular single purpose functions and event busses to pass around information.

Good design is good design.

Re: Some thoughts on microservices

#23

Post by mikro2nd »

KronisLV wrote: post #16
FinanceAnon wrote: post #14

Fundamentally, I don't really see much difference between monoliths and microservices. In a monolith, you just call another function/class, but in microservices that function is a http call. I guess the benefit of microservices is the ability to independently scale different microservices, being able to choose different languages for different microservices and less conflicts in the repo as more people work on it, bu…

> Fundamentally, I don't really see much difference between monoliths and microservices. > but in microservices that function is a http call I think that maybe you're understating the complexity that distributed systems may involve. For example, see all of the following: - https://en.wikipedia.org/wiki/Fallacies_of_distributed_computing - https://blog.erratasec.com/2012/06/falsehoods-programmers-believe-about.html -…

And not forgetting "A Note On Distributed Computing" https://www.cc.gatech.edu/classes/AY2010/cs4210_fall/papers/...

Re: Some thoughts on microservices

#24

Post by acjohnson55 »

Microservices are not a solution, they're a capability. It's powerful for a team to be able to deploy a tiny service with the absolute minimum amount of explicit plumbing to meet operational requirements. Whether they should break their system up this way is a case by case judgment.

Every place I've been, the costs of microservices get overlooked in favor of the illusion of decoupling. Microservices will absolutely make simple features fully contained within a service easier, but as soon as a feature spans services or even impacts the contract of a service, you're in for more pain than in a monolithic architecture. Microservices sieze local simplicity at the cost of integration complexity.

Microservices, as a philosophy, is encoding your org design at the networking layer. I hope you get it the factoring right the first time, because it's going to be painful to change.

I'm all for small services where they make sense. But just like the advice that "all functions should be small" microservices has been myopically adopted as a design principle, rather than a debatable decision.

Re: Some thoughts on microservices

#25

Post by recursivedoubts »

Microservices means just that: tiny, single purpose services that deploy and scale on their own.

I often see appeals to Conway's Law when discussing microservices, but teams don't organize themselves this way. Instead, teams work on a macro services: the email delivery team, or the monitoring team, or whatever. In most cases these macroservices would be best implemented and deployed as a monolith, and then presented to the outside world over a reasonable API.

Re: Some thoughts on microservices

#26

Post by biglost »

trixie_ wrote: post #19
FinanceAnon wrote: post #14

Fundamentally, I don't really see much difference between monoliths and microservices. In a monolith, you just call another function/class, but in microservices that function is a http call. I guess the benefit of microservices is the ability to independently scale different microservices, being able to choose different languages for different microservices and less conflicts in the repo as more people work on it, bu…

There’s a huge difference between http and function calls. When I call a function there is no chance it fails because the function ‘cannot be reached’. With services there are endless reasons why one service is unable to communicate with another. It’s a huge amount of overhead to build a system to handle inter-service communication and failure that doesn’t exist when only calling a function in the same binary.

And, you add latency issues and overhead. With a function call you pass two int and get a string of length 120 (how much memory is this? little, very little), with microservices you make an api call using http with it headers and get a json, and maybe you could need 2 api calls. For me it's easy, just create a monolith, when you become facebook or netflix, split symfony services into microservices (just an example). Oh, and don't forget the developers who translate a specific function into an endpoint, you need a change in the caller and you must change the api!

Re: Some thoughts on microservices

#27

Post by goodpoint »

FinanceAnon wrote: post #14

Fundamentally, I don't really see much difference between monoliths and microservices. In a monolith, you just call another function/class, but in microservices that function is a http call. I guess the benefit of microservices is the ability to independently scale different microservices, being able to choose different languages for different microservices and less conflicts in the repo as more people work on it, bu…

> you just call another function/class, but in microservices that function is a http call

The difference is enormous.

Re: Some thoughts on microservices

#28

Post by foobarian »

wongarsu wrote: post #18
solmag wrote: post #4

Earlier quoted context omitted.

I like them for modularity, message queues and asynchronous events. But you are correct, esp. last one.

Plenty of languages offer modularity, message queues and asynchronous events within a monolith. They are quite idiomatic in go, rust and elixir

Splitting a system into microservices can help individual teams be better stewards of their part of the system. They can release on their own schedule, they can use their own linting rules, heck even a different language, and they can have better control of incoming code changes. With a monolith any random developer can go and flip some private method to public, import it way across the modules, and presto you are now building a ball of mud. Need an out of cycle release? Hopefully you have CI/CD or now you have to beg the SRE in charge to do it for you.

Re: Some thoughts on microservices

#29

Post by geoduck14 »

FinanceAnon wrote: post #14

Fundamentally, I don't really see much difference between monoliths and microservices. In a monolith, you just call another function/class, but in microservices that function is a http call. I guess the benefit of microservices is the ability to independently scale different microservices, being able to choose different languages for different microservices and less conflicts in the repo as more people work on it, bu…

To be fair, you CAN build a monolith in a way that is very similar to microservice architecture.

You can have a single function that handles all data base writes. A single function that monitors for failures. A single function that sends outbound notifications... etc

If these functions are call in a way that: allows for A/B testing, SUPER high latency (or no response), failure notifications sent to the code owner, automatic retries of failures, independent code deploys

Then, congratulations, you have a monolith made up of microservices!

Re: Some thoughts on microservices

#30

Post by Sebb767 »

foobarian wrote: post #28
wongarsu wrote: post #18

Earlier quoted context omitted.

Plenty of languages offer modularity, message queues and asynchronous events within a monolith. They are quite idiomatic in go, rust and elixir

Splitting a system into microservices can help individual teams be better stewards of their part of the system. They can release on their own schedule, they can use their own linting rules, heck even a different language, and they can have better control of incoming code changes. With a monolith any random developer can go and flip some private method to public, import it way across the modules, and presto you are no…

> Splitting a system into microservices can help individual teams be better stewards of their part of the system.

Team being the keyword here. If you have 3-5 developers per microservice, you're absolutely okay. If you have 3-5 microservices per developer, that's when it gets ugly.

Post reply on HN