전 GitHub CTO, "지난 10년간 가장 큰 아키텍처 실수는 풀 마이크로서비스로 전환한 것" (twitter.com/jasoncwarner)

 geeknews에서 가져온 내용. 원본 링크는 아래에 기재. https://news.hada.io/topic?id=7839 지난 10년간 가장 큰 아키텍처 실수는 풀 마이크로서비스로 전환한 것 "Monolith > apps > services > microservices" 첫째, 이건 규칙은 아니고 내 생각이 그렇다는 것. 대규모 분산 시스템을 구축해 본 사람은 실제로 그대로 작동하지 않으며, 적응해야 한다는 것을 알고 있음 둘째, 단계가 중요함 5-50인 회사라면 그냥 Monolith로 가세요 1만명 회사라면, 위의 모든 것들을 다 가지고 있을 것. 근데 예전과 달라진 생각들을 얘기해보자면.. 먼저 정의(Definition) 부터 monolith - xyz.com apps - abc.xyz.com services - 앱/모노리스를 지원, 핵심 인프라, 핵심 컴플라이언스 기능, 앱팀에서 작성하지 않을 수 있음(인프라에서 유지관리) microserivces - 몇백라인의 코드, 대부분 일회성, 라이브러리 또는 SDK 일수/있어야(could/should) 함 Why ? : 기본적으로 "Speed & Risk" 때문 #1 전체 개발팀이 하나의 빅앱(전체 사이트가 Rails앱 이라고 생각해 볼 것)에서 개발하는게 더 쉬움 #2 성장하면 필수로 가지게 될 분산시스템은, 자체적으로 위험한 수백개의 마이크로서비스 없이도 이미 추론하기가 어려움 #3 완전히 마이크로로 간다면, 무분별한 확장을 처리하기 위해 새로운 개념을 도입해야 함 #4 맞춤형(Bespoke) 인프라 서비스 또는 마이크로서비스는 부채의 극단적 개념임. 코드도 부채이지만 서비스가 그것의 극단적인 버전. 이게 뭘 의미하는지 생각해 볼 것. 레버리지 포인트가 되게 할 것 분산 시스템 엔지니어들은 중복되는걸 싫어하기 때문에 뭔가가 여러데서 이뤄진다면 "이걸 빼내서 마이크로 서비스를 만들자" 라고 생각함 이론적으로는 이게 맞고, 일이십개

일런 머스크의 '미친 생산성을 위한 6가지 법칙' (twitter.com/LiamKircher)

 이 또한 geeknews에 올라온 내용이다. 원문 링크는 아래에 기재하고 개인용도로 관련내용을 이곳에 옮겨적는다.

https://news.hada.io/topic?id=7860&utm_source=slack&utm_medium=bot&utm_campaign=T13KRBZU4

#1 대규모 미팅은 피하라

  • 참여자가 많은 미팅은 시간과 에너지의 낭비
    • 토론을 방해
    • 사람들을 방어적으로 만듦
    • 모든 사람이 기여하기엔 시간이 부족
  • 모든 사람에게 가치를 주는게 아니라면 대규모 미팅을 잡지 말 것

#2 미팅에 기여하는게 없다면 중간에라도 나가라

  • 미팅이 당신의 "자료나 정보(Input), 가치, 의사결정"을 필요로 하지 않는다면 미팅에 참여할 이유가 없음
  • 미팅 중간에 나가는 것은 무례한게 아님. 사람들의 시간을 낭비하는게 무례한 짓

#3 명령 체계(Chain of Command)는 잊어라

  • 동료들과 직접 대화할 것
  • 슈퍼바이저나 매니저를 통하지 말 것
  • 빠른 소통이 빠른 의사 결정을 만듦
  • 빠른 의사결정은 곧 경쟁 우위임

#4 똑똑해 보이려 하지말고, 명확히 할 것

  • 기술 용어(Technical Jargon)와 이상한 단어(넌센스)는 피할 것
  • 이런 것들은 의사소통을 느리게함
  • 간결하고(Concise), 요점을 설명하는(To the Point), 이해하기 쉬운 단어를 선택할 것
  • 똑똑해보이려 하지 말고, 효율적으로 일할 것

#5 미팅을 자주하지 말 것

  • 모든 사람의 시간을 낭비하는 데 이것보다 좋은게 없음
  • 미팅은 '협업하고, 직면한 문제를 돌파하고, 긴급한 문제를 해결할 때" 사용할 것
  • 이슈가 해결되었다면, 자주 미팅하는 것은 더 이상 필요없음
  • 대부분의 이슈는 미팅없이도 해결가능. 미팅 대신 '문자나 이메일을 보내거나, 슬랙/디스코드 채널에서 얘기할 것'
  • 필요한게 아니라면 팀의 워크플로우를 방해하지 말 것

#6 상식적으로 해라

  • 만약 회사 규칙이:
    • 말이 안 되거나
    • 일을 진행하는데 도움이 안되거나
    • 당신의 특정 상황에 맞지 않는 다면
  • 규칙을 따르지 않아도 됨
  • 규칙이 아니라 원칙(Principle)을 따를 것

현재 재직중인 회사가 하지말아야 할 것들을 하고 있는 중이다. 물론 회사마다 프로젝트마다 상황이 틀리기 때문에 위 내용이 항상 옳다고는 할 수 없겠지만 말이다.

특히 규칙을 따르지 않아도 되고 원칙을 따를 것이란 구절이 아주 와닿는 편인데, 원칙을 회사차원에서 Vision 이나 Misson 으로서 구체적으로 사원들에게 제시를 해주어야 할 듯 하다.

댓글

이 블로그의 인기 게시물

curl 명령어 옵션

CISCO 2960s 초기화 후 기본 설정

맥북 카라비너 영어/한글/일본어 전환하기