블로그 이미지
평범하게 살고 싶은 월급쟁이 기술적인 토론 환영합니다.같이 이야기 하고 싶으시면 부담 말고 연락주세요:이메일-bwcho75골뱅이지메일 닷컴. 조대협


Archive»


 

'세미나'에 해당되는 글 3

  1. 2016.03.17 IBM Bluemix 클라우드의 Openwhisk 소개 (1)
  2. 2016.02.25 MSA의 중복 개발에 대한 단상 (3)
  3. 2008.10.20 웹세미나 주제 추천 받습니다. (5)
 

 IBM 블루믹스의 openwhisk 에 대한 소개


조대협 (http://bcho.tistory.com)


오늘 IBM의 블루믹스 세미나에 다녀왔습니다.

세미나 내용중에서 흥미로운 기술들이 있어서 간단하게 소개합니다.

IBM 블루믹스 클라우드의 새로운 기능으로 Openwhisk 라는 서비스입니다http://www.ibm.com/cloud-computing/bluemix/openwhisk/

https://developer.ibm.com/openwhisk/ 아마존의 람다 기능과 유사한 기능인데 개념을 보면 다음과 같다.

 

이벤트가 발생하면, 이벤트 내용을 받아서 비지니스 로직이 들어 있는 액션을 수행한다.

아래 그림을 보면 REST API로 호출하거나 또는 데이타 베이스에 어떤 내용이 변경이 되거나 또는 Kafka와 같은 메세지 큐에 새로운 메세지가 들어오면 정해진 규칙 (이를 Openwhisk에서 Rule이라고 한다.)에 따라서 비지니스 로직을 호출한다. 이 비지니스 로직 덩어리를 Action이라고 하는데, Action을 여러개로 묶어서 아래 그림과 같이 체이닝이 가능하다.



 

이벤트 방식으로 비지니스 로직을 Invoke해주는 방식인데, 뒷단에 ActionAuto scaling이 가능해서 시스템의 용량등에 상관 없이 사용이 가능하다.

또한 이 ActionSwift, node.js, Java 와 같이 다양한 언어로 구현이 가능하다.

개발자는 아래 인프라를 신경쓸 필요가 없이 비지니스 로직만 구현하면 된다는 것이다.

 

과금 정책은 실제 Action이 실행되는 시간만 과금이 된다. 해당 로직을 수행하는데 30ms만 걸렸다면 30ms에 대한 금액만 과금된다. 유사한 기능을 EC2와 같은 VM위에 올리면, CPU를 많이 사용하는 로직일 경우 계속 CPU가 큰 CM을 켜놔야 하기 때문에 비용이 많이 나오지만 이 구조를 사용하면 비용이 딱 사용한 부분만 나온다.

 

다른 흥미로운 점은 IBM이 이 기능을 개발하면서 이 Openwhisk를 오픈소스화 했다는 것이다.

소스는 https://github.com/openwhisk/openwhisk 에 있는데, 이 말은 블루믹스를 사용하지 않더라도 AWS나 구글 글라우드에 Openwhisk를 옮길 수 있다는 것이다. 즉 클라우드 락인에 대한 문제를 해결하고 시작했다는 것이다.

 

AWS 람다와 유사한데, 근래 들어서 이런 형태의 기능들이 클라우드에 많이 나오는 것 같다.

톰캣이나 파이썬 장고와 같은 웹서버나 미들웨어를 알필요도 없고 복잡한 설정이나 스케일링에 대한 고려를 할필요도 없고 클라우드 자체를 플랫폼으로 그위에 비지니스 로직만 올리는 형태로 점점 클라우드가 발전해 가는 모습이 보인다.  나중에는 미들웨어 없이 클라우드 자체에 코드만 올리는 형태가 되지 않을까? 이미 AWS에서는 람다, 다니나모, S3, API 게이트웨이등을 조합하면 별도의 미들웨어 없이 왠만한 API들은 구현이 가능하다.

 

저작자 표시 비영리
신고

MSA의 중복 개발에 대한 단상


조대협 (http://bcho.tistory.com)


어제 우연한 기회로, API Academy 세미나에 다녀왔습니다.

발표자는 Mike Amundsen  이라는 분으로, CA의 API 아카데미의 일원이며, OReilly 출판사를 통해서 REST API에 대한 저서를 집필한 분이기도 합니다.

http://www.oreilly.com/pub/au/1192





API 아카데미였지만, 결국 MSA와 조직 문화 소통으로 수렴되는 내용이었습니다만, MSA 에 관련하여 재미있는 접근이 있어서 남겨놓고자 합니다.


예로 든것중의 하나가 API를 외부용, 내부용, 그리고 특정한 파트너용 3가지로 나누어서 접근을 하였는데, 이 접근 방식보다 특이했던 것이 구현의 주체입니다.


일반적인 생각으로는 유사한 API라면, API를 만들어놓고, 차이가 나는 부분만 Mediation을 통해서 재 사용하는 개념을 접근하였습니다.


예를 들어 GET /users/{userid} 라는 API가 있을때, 이 API를 내부용으로 만들어놓고, 이 API를 wrapping해서, 추가 인증/인가 기능을 추가하여 외부용, 파트너용으로 제공하는 방법이 일반적인 방식인데,


Amunsen 은 다른 접근 방법을 제시했습니다. "외부용,내부용,파트너용 API를 각각의 팀이 따로 만든다"

였습니다. 데이타가 같으니 일관성은 보장이 될터이고, 각 팀으로 서비스를 나눠서 각팀이 각각의 API를 만들게 되면, 기동성이 늘어나고, 고객의 요구 사항이 각각 다르니 거기에 기민하게 대응할 수 있다는 논리입니다.


중복 개발이나, 종속성에 대한 문제가 발생할 수 는 있겠지만, 오히려 이게 맞는 접근 방법이 아닌가도 싶습니다.

MSA의 근본적인 목적은 작은 서비스로 나눠서 개발의 기민성을 확보하고, 고객의 요구 사항을 빠르게 반영하는데 있는데, 공통 API를 재사용하게 되면, 재 사용성 자체는 올라갈지 모르겠지만, 반대로 의존성때문에 전체 프로젝트 일정에 문제가 생길 수 있습니다.


같은 논리로, 웹,모바일 백앤드가 있을때, 팀의 크기가 크다면, 공통 API 시스템을 쓸것이 아니라, 각자 API 백앤드 시스템을 만들어서 기민성을 확보하는 것도 하나의 예가 되겠습니다.


중복 개발과 낭비는 있겠지만, 기민성 확보와 각각의 팀이 컨택스트와 도메인을 완전하게 이해할 수 있다는 점에서, 이 방식도 충분히 고려해볼만한 가치가 있지 않을까 합니다.

저작자 표시 비영리
신고

웹세미나 주제 추천 받습니다.

사는 이야기 | 2008.10.20 11:48 | Posted by 조대협
11월 21일날 웹 세미나 합니다. ALM (빌드 배포 자동화)를 할 예정인데… 주제를 하나 더할 수도 있을 것 같습니다. JVM 튜닝, J2EE 애플리케이션의 병목 발견, What is SOA? How to SOA? 이 3개 주제중 어떤것이 좋을까요?
이외에도 혹시 관심 있으신 부분 있으면 의견 따라서 준비 해볼까 합니다.
의견 많이 많이 주세요.

신고

'사는 이야기' 카테고리의 다른 글

휴대용 유모차  (0) 2008.10.29
01  (0) 2008.10.23
웹세미나 주제 추천 받습니다.  (5) 2008.10.20
강의 자료 월요일에 올립니다.  (0) 2008.09.27
새로운 세상을 접한다는것...  (1) 2008.09.16
사는 이야기  (4) 2008.09.03