Microservice coding guide

Microservice coding guide

• 1.
  About Microservice Coding Style 부제:하드코딩하자
• 2.
  1년차 재미 즐거움
• 3.
  2년차 이동성
• 4.
  3년차 재사용성
• 5.
  5년차 객체지향 스프링 패턴 … 어려운걸 잘아는게 좋은거?
• 6.
  유엔진솔루션즈 • 2013년 부터기업용 패키지 솔루션 개발 • BPM, SNS, ALM 등 BPM을 기반한 다양한 파생상품 개발 • (국내) 고객입장의 밸류: 커스터마이징이 잘되는 제품 • 수익모델: 온-프레미스 기반 프로덕트 제공
• 7.
  소프트웨어의 구조 Metaworks Framework (나이:15년) BPM Process Modeler BPM Process Engine (나이: 12년) BPM Process Portal (나이: 10년) ALM Pipeline Modeler Business Rule Modeler Business Rule Engine Enterprise Social Network Portal 고객사1 고객사2 고객사3 고객사4 고객사5 Key Strategies: - DRY (Don’t Repeat Yourself) Rule : 가능한 공통구현 코드는 중복이 없어야 - White-box Inheritance : 한번 구현된 것은 추상화하여 상위 클래스에 정의 • 메타데이터 기반 UI생성 • DB접근 • 컨트롤 역전처리 • 프로세스 모델링 • 프로세스 실행 • 프로세스 분석/통계 • 특화된 제 품의 요구 사항 반영 • 특화된 고 객의 요구 사항 반영 상속 상속 상속 상속 상속 상속 상속
• 8.
  10년의 경과보고 • 개발자수급: • 자체 프레임워크와 개발표준에 익숙해지는데 최소 3년 소요 • 객체 지향과 AOP 개념, 빌드 등 기반 기술 이해에 그중 1.5 년 이상 소요 • 빌드/통합: • 1회 Integration, End-to-End Test 를 위한 Maven Dependency 버전 일치에 적어도 4시간(반 나절) 이상 소요 • Maven Dependency Hell • 기술적용: • 많은 오픈소스들의 기능들을 통합함에 있어 상이한 라이브러리 디펜던시 충돌로 인한 통합의 어려움 • OSGi 시도 • OSGi 의 복잡한 버전관리, 기반 기술 러닝커브로 포기
• 9.
  통합 빌드 주기:1개월  망한다  결론: 소프트웨어 품질 저하
• 10.
  기회: MSA 의발견
• 11.
  MSA architecture 의두가지 관점 Outer: 개발자가 공히 겪게 되는 복 잡성들 (e.g. 멀티스레딩, 탄력성, 장 애내성, 공통처리) 을 네트워 크단에서 처리해주고 Inner: 코드내부는 가능한 무식, 간결, 명확하게 단순화
• 12.
  MSA Design Principles •SoC—Separation of concerns. : 고생해서 분리를 왜 했느냐? 관심사를 분리해서 개발할 수 있어야 한다 • DDD—Domain Driven Design. : 도메인을 알면, 관심사를 어떻게 분리할지 작전이 나온다. • KISS — Keep it simple, stupid. : 작은 사이즈의 매력이 뭐냐? 무식하게 두라. 때론 하드코드도 괜찮아. 스프링부트를 보 라, Bean 설정을 메서드로-하드코드로 한다 • YAGNI—You aren’t gonna need it. : 머리를 어지럽히는 복잡한 기술? 지금 당장 필요한 것만 써라. 너무 미래를 보지마라. 보 통 복잡한 설계와 기술은 하나의 언어와 표준을 준수하기 위해 등장한다. 당장 돌아가는 코드와 언어가 있다면 그걸 사용하자 Polyglot 이 좋은게 그거다. 필요할때 복잡해져라. 애자일이 그거다.
• 13.
  Write Simple • 단위마이크로 서비스는 의도적으로 크기를 작게 한다 • 이미 모듈화 되었으므로, 내부는 읽기 좋게 (단순하게) 작성한다 • 작은 크기내에 복잡한 추상화, 일반화, 모듈화는 사족이다 • 데이터베이스 또한 단순화한다 (Denormalization, Materialized) • 적당한 하드코드는 읽기가 생각보다 좋다 (property 화의 최소 화) – 위험한가? • 설정을 통한 분기 보다 하드코드로 된 펑션이 읽기가 좋다
• 14.
  받아들이기 힘들었던 이야기들 •공통화 하지 말라? • DRY X  KISS O • Shared Kernel X  Polyglot • 네이밍(패키지명) 멋지게 짓지말라? • Ubiquitous Language • Bounded Context • 하드코딩 하라? • Inline Bean Definition • 백엔드가 꼭 필요한가? • MVC X  Front + Gateway + DB ?
• 15.
  그렇다면 객체지향이 죽은것인가?아니 면 어디로 갔는가? 네트워크단으로 갔다. Proxy Pattern  API Gateway Polymorphism  Traffic Routing Multi-threading  Container Orchestrator Aspect Cross-cutting  PubSub, Event-driven Spring  Istio Multi-threading  Kubernetes Aspect Cross-cutting  Kafka 누가 해주느냐?
• 16.
  받아들이니 깨닫게 된것들 • 내 소프트웨어는 어려운 것이 아니었다 • 그냥 복잡하게 엉켜있는 것이었다. • 너무 깊은 추상화, 공통화는 오히려 내 발목을 잡았던 것이다. • 하지만, Inner Architecture 내에서도 • 여전히 주석, 완전한 코드, 테스팅은 ”어느정도” 중요하다. • 그 정도는 “필요한 만큼” 이라고 정의하고 싶다.
• 17.
  Agile Principle: 팔리지 않을것은만들지도 마라
• 18.
  결론 • 서비스 사업뿐만 아니라, 솔루션 개발 및 Product-Line Management 에서도 MSA 를 적용했을때 효율이 발생 • 단위개발 (Inner Architecture) 의 단순성 추구 • 결론적으로 작전의 변경: 형상에 대한 과도한 표준화, 공통화, 기술 검증의 노력과 에너지  비즈니스 기회의 빠른 시장 검증의 노력과 에너지
• 19.
  10년차: 다시 즐거움을되찾다