마이크로서비스 Just Do It!
최근 개발 또는 운영하고 있는 서비스가 여러개의 작은 서비스로 의미 있는 서비스를 제공하고 있는 시스템 구성으로 되어 있습니다. 이를 최근 트렌드에 맞추어 보면 마이크로서비스 아키텍처 기반이라고도 이야기 할 수 있습니다. 최근 스타트업들이야 구성원들이 믿는 방식, 구성원들이 좋아하는 방식으로 진행하기 때문에 그것을 무엇이라 부르던 별로 신경을 쓰지 않겠지만 아직도 많은 큰
Latest
DDD의 Bounded Context와 객체 지향의 객체
내용이 빈약했는데, 2019년 1월 18일자로 사례를 섞은 다른 글을 올려 낡은 내용은 지웁니다. https://bit.ly/2sBaDxP
kubernetes 어디까지 써봤니? 삽질기(2)
Kubernetes 삽질하다 일어난일 kubernetes 삽질의 시작은 이전글을 참조하기 바란다. 이번 글에서는 나의 작은 실수로 인해 분석가를 식겁하게 한 에피소드에 대해 이야기 해 보려 한다. 그전에 k8s에 deploy하기 위한 기본 개념에 대해 살펴볼 예정이다. pod로 띄우기 pod는 한개 이상의 컨테이너로 구성되는 k8s에서 가장작은 deploy를 위한 단위이다. 이는 자신의 어플리케이션 스택에 서로
진짜 아키텍트가 없는 EA 시장 잠재력을 알리는 글 (2)
앞서 올린 글, 진짜 아키텍트가 없는 EA 시장 잠재력을 알리는 글이 (popit 운영자가) 상당한 조회수를 올렸다고 한다. 원래는 작년 6월 개인 블로그에 썼던 글을 다시 쓰기 한 것이다. 그러나, 목표는 조회수가 아니라 소통을 끌어내려 했는데 성공했다. (중국에선 읽기 어려운) 페이스북 댓글이 달렸음을 운영자를 통해 들었다. 반가운 마음에 어렵게 댓글을 읽을
아키텍처
진짜 아키텍트가 없는 EA 시장 잠재력을 알리는 글
이 글은 작년 6월 뉴스피드로 받는 기사 제목 Architects Don’t Decide만 보고 내가 중요하다 생각하는 어떤 것(모호한 것은 모호한 상태라고 명확하게 해두고 개발하는 노하우)과 비슷한 글이라 짐작하고 클릭한 행동에서 비롯한 글이다. 원문 기사는 보다 지루해서 그만뒀고, 결과적으로 한동안 잊고 살던 '아키텍트'에 대한 생각을 끄집어내게
코드가 아닌 개념 레이어링과 폴리몰피즘
지난 글에 이어서 또 두 명의 개발자와 함께한 설계 개선이야기다. 어쩌다 보니 시리즈물이 되고 있다. 우리 팀은 새로운 도전으로 SaaS를 릴리즈 한 후, 비즈니스 속도를 맞추느라 개발 품질이 낮아지는 부담을 안고 있다. 비즈니스 속도를 늦추지 않는 선에서 틈틈이 이를 복구하는 상황이다. SW 본토인 미국(?) 표현으로 바꾸면 Technical Debt이 쌓여 있고,
함께 그리고 가볍게 하는 소프트웨어 설계의 즐거움
어느날 2층 사무실로 들어오는데 친한 두 개발자가 열띤 이야기를 하고 있었다. 흥미 있어 보여 안그래도 끼여들려는 찰나에 그들도 마침 내 의견을 물었다. 벽에 붙은 화이트보드에 아래 그림과 같은 것을 이제 막 쓰면서 새로 개발에 참여한 개발자 김형준님이 기존 개발자 장재휴님에게 JSON 형식 데이터 필드의 현재 뜻을 묻다가 '모호한 용어&
클라우드 비즈니스 - 사업자 관점에서 본 SaaS
중국에서 리테일 기업용 SaaS 서비스를 공급하며 겪은 일을 토대로 클라우드와 SaaS가 기업의 IT 의사결정에 어떤 의미를 가지는지 독자들의 생각이 더 발전되길 기대하며 글을 쓴다. 올해 5월경에 시범 서비스를 공급하고, 11월에 매출과 연동한 수수료 계약을 체결했다. 개인적으로는 한국에서 배운 노하우를 낯선 중국에 와서야 활용할 수 있던 묘한 상황이다. 일단 이 글에서는