Pop your eXperience. Share It.
답이 없는 문제지만, 시작할 때 도움이 되는 cheatsheet 정도를 제공할 목적으로 글을 쓴다. 참조 모델 결론은 아래 그림이다. 물론, 모든 상황에 맞는 답은 없다. 우리 환경에 맞추면 REST 형태로 API를 제공하는 웹 서비스를 모듈이라는 단위로 부른다. 위 그림에서 Foundational capability와 같다. 하지만, 모듈이 하나로 배포되는지 사실은 유사한 API 묶음이 여러
아키텍처, 시스템 구성, 모델링, 개발 프로세스를 고민하고 만들었다기 보다는 현재의 조직 구성원으로 서비스를 만들 수 있는 가장 최선의 방법을 선택한 것입니다. 복잡한 것은 만들기 어려우니 아주 잘게 쪼개고, 잘 만들고 있는지도 모르겠으니 일주일에 한번씩 확인하는 방식이었던 것입니다. 우리의 여정이 11개월째로 접어들 때 합류한 김형준님이 내 의도를 너무나 잘 정의했다.[1]
최근 개발 또는 운영하고 있는 서비스가 여러개의 작은 서비스로 의미 있는 서비스를 제공하고 있는 시스템 구성으로 되어 있습니다. 이를 최근 트렌드에 맞추어 보면 마이크로서비스 아키텍처 기반이라고도 이야기 할 수 있습니다. 최근 스타트업들이야 구성원들이 믿는 방식, 구성원들이 좋아하는 방식으로 진행하기 때문에 그것을 무엇이라 부르던 별로 신경을 쓰지 않겠지만 아직도 많은 큰
안녕하세요. devpools의 도경태입니다. medium에 먼저 간단하게 글을 올렸구요. 시리즈 물이 될 거 같은 예감입니다. 바로 그냥 들어가겠습니다. 프로젝트를 진행하며 MSA 를 적용하게 되었습니다. MSA를 적용하면서 맞닥들이는 실제 사례를 들어 시작해 볼까합니다. MSA를 왜 적용하게 되었는지, 어떻게 적용하는지 이것을 하기 위해서 팀은 어떤일을 해야 하는지, 기술적인 검증은 어떻게 진행되는지 진지하게 살펴보도록
이글은 Why Microservices?(https://dzone.com/articles/microservices-basics?edition=213185)의 번역글 입니다. 해당 기사는 마이크로서비스 아키텍처를 적용할 때의 장점과 단점 모두를 많은 사람들이 익숙한 모놀리스(monolithic) 방식의 소프트웨어와 비교해 개략적으로 설명하고 있습니다. 혹시라도 번역에 대한 오류, 오타등을 발견하시면 댓글에 남겨주시길 부탁드립니다. 이 번역글을 읽고 나서 마이크로서비스에 대해 좀
마이크로서비스 아키텍처 마이크로서비스 아키텍처는 하나의 큰 애플리케이션을 여러 개의 작은 애플리케이션으로 쪼개어 변경과 조합이 가능하도록 만든 아키텍처를 말합니다. 애플리케이션을 특화된 기능별로 나누게 되면 자연스럽게 애플리케이션의 추상화(abstraction)가 가능해집니다. 다시 말해, ‘인증’을 담당하는 서비스(예, auth.example.com)는 그 구체적인 구현 내용을 모르더라도 다른 서비스에서 약속된 인터페이스를 이용해