홈

마이크로 서비스는 대규모 소프트웨어 프로젝트를 마이크로 단위의 모듈로 분리하여 loosely-coupled한 구조로 만들고 API를 통해 서로 통신합니다. 지난 몇 년동안 마이크로 서비스에 대해서 많은 이야기가 있었습니다. 모듈형 아키텍처 스타일은 클라우드 기반 환경에 적합하며 인기가 높아지고 있습니다. 마이크로 서비스는 대형 소프트웨어 프로젝트의 기능들을 작고 독립적이며 느슨하게 결합 된 모듈로 분해하여 서비스를 제공하는 아키텍처 입니다. 각 개별 모듈은 개별적인 작업을 담당하며 간단하고 보편적으로 엑세스 할 수 있는 API를 통해 다른 모듈과 통신 합니다. 마이크로 서비스는 웹 기반의 복잡한 응용 프로그...

프로젝트내에서 만든 Java Util class를 Python에서 사용해야 하는 케이스가 발생했다. py4j, jnius, subprocess .., 등등의 방법이 있었다. py4j GatewayConnection 방식으로 진행하기에 내부적으로 socket을 사용함. Fault 발생 여지가 있어서 부적절하다고 판단 jnius Java class를 수행전에 JVM을 start 해야하고 종료시 shutdown 해야 함. Fault 발생 여지가 있어서 부적절하다고 판단 subprocess os command를 수행하는 방법, 별도의 package를 설치하지 않아도 되고, 위의 package에 비해 fault 발생 ...

RESTful API를 만들 경우에는 문서화가 중요하고, API문서와 코드와의 변경 사항을 반영하는 것은 지루한 일입니다. 일반적으로 Swagger를 사용할 경우에는 @Api, @ApiOperation과 같은 Annotation을 사용하여Swagger에 보여질 내용을 설정하게 됩니다. Swagger2의 구현체인 Springfox를 사용할 경우에는 이런 부분들이 자동화되게 됩니다. 타겟 프로젝트 REST 서비스는 아래의 URL을 참조하여 Swagger2를 적용할 수 있도록 생성해야 합니다. (본 문서의 범주가 아니므로 링크로 대체합니다.) Build a REST API with Spring 4 and Ja...

Lettuce는 synchronous, asynchronous, reactive usage를 지원하는 scalable thread-safe한 Redis Java client 입니다. lettuce — IntroductionLettuce is a scalable thread-safe Redis client for synchronous, asynchronous and reactive usage. Multiple threads may… redis.paluch.biz Micro Service Architecture(MSA)를 적용하면서, 앞단의 Gateway의 Discovery영역에 redis로부터 active...

요즘 주위에 애자일(특히 스트럼)로 프로젝트를 진행하는 곳이 많아지고 있지만, 대부분은 실패로 마무리 됩니다. 이유는 무엇일까? 방법론을 올바르게 숙지하지 못해서? 아니면 팀 문화가 따라주지 않아서? 아래의 내용은 개인적인 생각임을 미리 밝혀둡니다. 저는 “사기(士氣)”의 문제라고 생각합니다. 스크럼을 이용할 경우 아래의 장점들을 취할 수 있습니다. 진척 사항의 시각화 관리자 측면에서는 일이 잘 진행되고 있다는 느낌을 받는다 해야할 업무에 대해서 놓치지 않게된다 위의 장점들은 그냥 만들어지는 것이 아닙니다. 스크럼의 근본 취지는 work 시간에 제한을 두고 최대한 생산성을 끌어내는 것이 핵심입니다....

onem2m release 2가 published 되었다. 관련하여 webinar가 진행됨. 등록은 이곳에서 => https://www.brighttalk.com/webcast/11949/226333

Websocket proxy가 필요한 케이스가 생겼다. 일반적으로는 독립된 proxy server를 통해 지원하면 되지만, Servlet단에서 지원을 해야 하는 상황이다. 아래의 그림처럼 제공되는 것이 중간의 Gateway를 통해 Communication이 되어야 하는 상황이다. 아래의 그림처럼 중간에 다른 서버를 거쳐야 한다. 가장 편하게 할 수 있는 방법은 jetty-proxy library를 이용하는 방법이다. 이미 구현체가 존재하기 때문에, 필요한 부분만 customizing하여 Servlet으로 등록하면 된다.

Cloud Computing의 발전으로 인해 과거와는 달리 더 이상 많은 인력이 필요없게 되는 것 같다. 구글 트렌드에서 “programmer”와 “software engineer”의 검색량을 2004년 부터 현재까지 추출해보았다. 점점 검색량이 줄어들고 있다. 예전에는 리눅스 전문가, DB 전문가, Backend 전문가, Frontend 전문가 등등이 필요했지만, 이제는 적은 인력으로 충분히 해결 가능하다. 이런 현상이 발생한 이유중에 하나는 “Serverless” 일 것이다. (아직 초창기이긴 하지만…) Serverless는 서버가 없다라는 의미가 아니고, 관리해야 할 Server가 0으로 수렴한다는 의...