홈

PaaS (Platform as a Service)는 Runtime환경과 Backend service 관리를 자동화한 개념이다. PaaS에 대한 제품은 여러가지가 존재하며 아래는 우리가 알고있는 제품들이다. PaaS는 Deployment의 고민으로 부터 등장하기 시작했다. PaaS는 iPaaS(Integration PaaS)와 aPaaS(Application PaaS)로 구분되며 각 역할은 아래와 같다. Gartner에서 정의한 iPaaS관련 Reference Architecture 모델의 구성요소는 크게 6가지로 나뉜다. Integration Platform Services Gove...

IoT(Internet of Things)가 B2C영역의 일반 소비자 중심이라면 IIoT(Industrial Internet of Things)는 B2B영역에 속하는 산업용 IoT라고 할 수 있다. B2C영역의 IoT는 웨어러블 피트니스, 스마트홈, 무인 자동차와 같이 최종 소비자에게 편의성을 제공하는 기기들이 떠오르며 해당 유즈케이스가 아직까지는 우리 생활에 크게 와닿지 않는 부분들이 존재한다. 반면, B2B영역의 IIoT는 스마트 도시, 스마트 농업, 스마트 공장, 스마트 그리드등 산업계내에서 유용한 혁신들이 일어나고 있다. IIoT의 핵심은 다수의 산업 시스템들이 서로 연결되어 여기서 발생하는 활동 데이터...

GE는 AT&T, Cisco, Intel과의 Partnership을 체결하고 산업 사물 인터넷 플랫폼(IIoT) Predix를 발표했습니다. IoT Value Chain중 Devices에 특화되어 있던 GE는 아래의 기업들과의 파트너쉽으로 chain을 구성 했습니다. AT&T: 유/무선 통신, WiFi 등의 접속 인프라 제공 Cisco: 네트워크 분야 협력, Oil&Gas, 교통, 헬스케어, 전력 분야까지 확산된 산업군에 걸친 협력을 강화 Intel: Predix 플랫폼의 가상화, Cloud, 표준 인터페이스 기술 개발 Pivotal: Pivotal의 CloudFoundry를...

이 글은 “유쾌한 브레인스토밍의 7가지 비밀”에 상반되는 내용이다. 브레인스토밍은 좋은 아이디어를 취하기 위한 활동이다. 하지만 자칫 잘못하면 시간만 허비하게 된다. 다음은 경계해야 할 브레인스토밍 방법이다. 1.(반드시)보스가 먼저 말한다. 세상에 존재하지 않은 아이디어를 내놓으시오. 이런 배경 설정에 마주치면 주눅이 들어 말이 이어지지 않는다. 2.참여 인원 모두에게 차례가 돌아간다. 시계 방향으로 돌아가며 각자 2분 동안 본인의 아이디어를 말한다. 이런 방식은 고통스럽다. (민주적이긴 하지만…) 3.전문가만 발언한다. 브레인스토밍에서는 전문가만 찾지 마라. 실무자에게 발언 기회를 주자. 4.특별한 장소...

브레인스토밍은 연습이 필요하다. 연습을 통해 잘할 수 있는 방법을 찾게되고 결국 잘하게 된다. 1.초점을 명확히 한다. 문제를 명확하게 묘사하여, 참여하는 사람들이 쉽게 주제에 접근 할 수 있도록 해라. 가령 “개인 정보 유출에 대한 보상”은 브레인스토밍 주제로는 좋지 않다. “개인 정보를 유출당한 사람들의 화를 삭힐 수 있도록 도와주는 방법” 처럼 적극적으로 참여할 수 있는 구체적 주제를 제시해야 한다. 2.규칙을 만든다. 아이디어를 비판하거나 반박하면서 시작하지 마라. 이런 부분은 “활기 약화”로 이어질 수 있다. 3.아이디어에 번호를 매긴다. 가장 중요한 것은 아이디어의 질이지만 브레인스토밍 진행전에 참...

제품 개발에는 비용, 품질, 기간, 범위라는 네가지 제약 조건이 있다. 기간을 무시하고 빨리 개발하려고 밀어붙이면 품질이 저하되거나 개발 인력이 늘어나 폭발적인 비용을 감수해야 한다. 물론, 기간만 단축시키고 개발 인력을 늘리지 않는 곳도 존재한다. 같은 비용으로 더 나은 품질의 소프트웨어를 만들려면 기능을 축소하거나, 소수 정예의 개발자들이 충분한 시간을 가지고 개발을 하는 것이 현실적이다. (맨먼스 미신도 있지 않은가?) 비즈니스의 성격에 따라 위 변수중 어떤것을 우선해야 할지 결정해야 한다. 좋은 시스템을 만든다는 것은 위 변수의 값이 타당해야 한다. 비즈니스/시장상황에 의해 위의 방정식이 무의미한 극단...

이제까지 MongoDB를 로그 분석용으로 주로 활용했었고 다른 용도로 사용 할 경우에 스키마를 어떻게 구성해야 하는지에 대해서 검색한 결과를 정리한다. RDBMS의 스키마 디자인과는 다른 전략으로 접근해야 하고 아래 사항을 고려해야 한다. User requirement 기반으로 스키마를 디자인한다. 데이터를 read할 때 join하는 것이 아니라 데이타를 write할때 join해야 한다. 객체간의 관계를 고려한다. (Multiple collection과 Embedded) MongoDB는 아래의 방법으로 관계를 표현 할 수 있다. db.person.findOne() { name: ‘Kate...