microservices / 전환 / 모노리식 / 언제 분리 / 왜 사용 /
언제 마이크로서비스를 사용하는 것이 맞는가
우리는 처음에 구조를 잡을 때 고민을 많이 한다. 특히나 확장성에 대한 고민들을 한다. 그런데 어디까지 확장을 고민해야 하는가. 이 물음에 대해 어느정도 정리를 해줄만한 글들에 대한 링크다.
- Modules, monoliths, and microservices · Tailscale, 2021-02-23 이야기는 길지만, 결론은 가장 마지막 문단인듯 하다. 계속 쉬운길을 유지하다가 어려운길을 해야만 하는 경우가 오면 그것을 해라.
- Keep the monolith, but split the workloads | incident.io :
- 한 코드에서 workload 를 나눠서 옵션으로 해당역할을 해서 띄울 수 있게 하고,
- db처럼, 모두가 사용하는 것은 각 application 마다 pool size 에 제한을 둘 수 있게 했다.
- 대부분의 경우 '가드레일'을 추가하거나 코드에 '제한을 구축'하여 마이크로서비스의 장점을 모방하는 동시에 단일 코드베이스를 유지하고 RPC 복잡성을 피할 수 있다.
이전 github CTO였던, Jason Warner의 트위터 글, 2022-11-15
이전 github CTO였던, Jason Warner의 트위터 글, 트위터 글이 읽기 불편해서 퍼왔다.
I’m convinced that one of the biggest architectural mistakes of the past decade was going full microservice
On a spectrum of monolith to microservices, I suggest the following:
Monolith > apps > services > microservices
So, some thoughts
First, these are thoughts, not rules. Anyone that has built a large distributed system knows they don’t really work that way and have to adapt with it
Second, stage will be important. If you are reading this at a 5-50 person company…just stick with a monolith. Trust me
If you are reading this at a 10k person company, likely have all of these to some degree but here is where my quick thoughts might differ from what has been done in the past
Now, diversion. Let’s talk definitions. There exist no exact definitions for these all
I think a challenge we dist systems engineers have is we really like to not have duplication so we see something being done in a few places and think “let’s just pull this out and make a microservice out of it”.
In theory this is fine. And if done for a few tens of instances, it is fine. When it goes to several dozen microservices or…way worse…across massive company boundaries (think one color service for all of Microsoft/Google/Apple) it becomes less technical and more org challenge
And I know what I’m presenting so many feels like some false dichotomies but in practice I find there are definite tech challenges with microservices, but there are even more org challenges with them
And of all the things I worry about it’s this
First, infra (unless company is led by unusually with-it CEO) almost always gets short end of priority stick
Second, too many services typically leads to a lack of ownership problem and boundary issues
Third, you introduce even more tooling to deal with too many microservices
And most importantly, each microservice that could/should have been a library or sdk or something introduces production risk
more code is indeed overhead, more services is customer facing prod/experience risk. Both approaches have overhead/risk but the % distribution is diff
So this is typically what I recommend
- Be a monolith as long as possible
- Services start in infra for infra reasons, not app eng typically
- If breaking out mono, break to large apps, not small services
- Think that each new app is a virtual wall in your company
- Prefer libraries to microservices where possible
The classic “we introduced a color service” is my favorite extreme example of where I would choose a library over a service. Yes extreme example but hey, it gets very talked about as quintessential example
“But Jason, what about Amazon and Uber and ..?”
- Hey, you do you. I’m just saying what I’ve gone through in experience
- If you have the success of Amazon when that mandate came down for services, go nuts
- These are more guidelines than rules
90% of all companies in the world could probably just be a monolith running against a primary db cluster with db backups, some caches and proxies and be done with it
For the 10% of companies that hit planet scale (no pun intended here Sam) it’s gonna be art figuring this out
Distributed systems combined with scaling companies is so complex and so few people have done it that it’s hard to draw specific lessons from those companies. Each context and instance is different. What I’m talking about here is more thoughts on how to approach the problems
And going back to this
Monolith > apps > services > microservices
It’s basically an approach to scale: be one big thing for as long as possible. Never overcorrect to too small of things, go through it as you grow (even hyper growth). This is for org and tech
Again, it’s art
I was trying to get that with this: Monolith > apps > services > microservices
But I realize now that the ‘>’ means “over” and not “prefer before going to”. monolith with several apps around it & 10-12 services over dozens of small services is great
Should draw a pic probably
댓글 없음:
댓글 쓰기