System Compleat.

'Pivotal Labs'에 해당되는 글 3건

  1. GE digital hiring commercial - Korean sub
  2. Pivotal Labs 에서 일하기 (4)
  3. Pivotal Cloud Foundry - PaaS (3)

GE digital hiring commercial - Korean sub

Stories


(younjin.jeong@gmail.com, 정윤진) 


아는 사람들 사이에서는 GE 의 소프트웨어 기업으로의 혁신이 좋은 이야기 거리다. 항공기 엔진, 플랜트, 금융, 헬스케어 등등등 다양한 사업을 진행하고 있는 GE 는, 몇년 전 부터 소프트웨어 및 데이터의 분석 기술이 자사의 사업에 엄청난 도움이 될 것이라는 확신을 바탕으로 차곡 차곡 변화를 준비해 왔다. 



이 변화는 처음 GE 스스로 진행했었으나, 원래 소프트웨어 기업이 아닌 회사에서 스스로 관련 기술을 내재화 하기 위해서는 수많은 시간과 인력, 그리고 비용을 투자하더라도 성공에 이르는 길이 명확하지 않았기 때문에, 피보탈을 파트너로 선택했다. 따라서 GE는 Predix 라 불리는 소프트웨어 및 데이터 플랫폼의 구현을 위해 Pivotal Labs 와 함께 애플리케이션을 Pivotal 이 제안하는 방법으로 만들기 시작했고, 그 효과는 놀라웠다. GE의 개발자와 제품 매니저들이 Pivotal Labs 에서 함께 애플리케이션을 만들고, 테스트하고, 배포하는 방법은 놀라운 속도와 소프트웨어 품질, 데이터 분석 기술 그리고 비용 효과를 가져왔으며 이로 인해 GE는 Pivotal 의 대주주중 하나가 되기로 결심한다. 그렇게 105 밀리언 달러를 투자한 것이 벌써 2013년. 그리고 지금, GE digital 의 사무실은 Pivotal Labs 의 사무실과 그 모양과 형태, 그리고 사용하는 도구와 문화가 매우 유사하다. 



Glassdoor 에 올라온 GE Digital 오피스 - 피보탈 랩과 매우 유사한 개방적 업무 환경을 볼 수 있다. 

https://www.glassdoor.com/Photos/GE-Digital-Office-Photos-IMG216059.htm



관련 월 스트리트 저널의 기사 - "This is not your dad's software company." 

http://blogs.wsj.com/digits/2013/04/24/ge-joins-emc-and-vmware-in-backing-pivotal-venture/ 


그리하여 GE Digital 이라는 전문 소프트웨어 회사가 준비되고, 현재 매우 공격적으로 개발자를 채용하고 있다. 이들은 Industrial Internet 이라는 산업 인터넷이라는 새로운 테마로, 즉 기존의 다양한 산업과 소프트웨어 그리고 데이터 기술을 결합하여 제조업의 핵심인 생산 비용 절감, 품질 향상, 그리고 문제 발생의 사전 예측 등을 구현했다. 그리고 이제 마치 아마존과 같이, 그들의 경험을 서비스로 내어 놓고 이를 다른 회사들에 제공하려고 하기 시작했는데, 그것이 바로 Predix. 


http://www.ge.com/digital/predix 



GE의 Predix 는 기본적으로 AWS 위에 Pivotal 의 Cloud Foundry 와 각종 데이터 관련 제품을 함께 사용하여 이룩한 플랫폼이다. 내부 직원의 피드백에 따르면 인터페이스는 Cloud Foundry 와 거의 동일하다고 한다. 아무튼 이렇게 GE 역시 그들의 산업군에서 소프트웨어와 데이터 기술을 바탕으로 서비스를 판매하는 비지니스 모델을 갖추었고, 이것이 가지는 파워는 매우 막강하다. 전세계에 비행중인 GE 생산 엔진이 달린 항공기의 연비가 1% 좋아진다고 상상해 보라. 그 비용효과가 과연 어떨런지. 


GE 의 인더스트리얼 인터넷 관련 pdf. 2012년, 그들은 이미 그 시작의 당위성에 대해 알고 있었다. 

http://www.ge.com/docs/chapters/Industrial_Internet.pdf 


엑센추어의 2015년 인더스트리얼 인터넷 리포트 

http://www.ge.com/digital/sites/default/files/industrial-internet-insights-report.pdf


2014년 10월, GE Minds and Machines 

https://www.ge.com/sites/default/files/GE%20Services_%26_Industrial_Internet_Investor_Meeting%20100914_FINAL_0.pdf



위의 세가지 레포트를 보면 이 분야가 어떻게 성장하고 있는지 쉽게 알 수 있다. 

이것이 바로 Digital Transformation 이 가지는 힘이며, 여기에 소프트웨어 개발과 데이터의 분석 기술이 반드시 필요한 이유가 있다. 우리 피보탈은 이러한 역량 확보가 엔터프라이즈 스스로 이룩해 내는것이 매우 쉽지 않음을 알고 있으며, 따라서 엔터프라이즈에 스타트업의 속도로, 안전하고 견고한 고품질의 소프트웨어 데이터 서비스 기반의 역량을 내재화 할 수 있는 파트너 회사인 것이다. 


아무튼 이런식으로 GE digital 이 많은 개발자를 확보하면서, 결국에는 텔레비전 광고에 채용 공고를 내기 시작한다. 이 광고를 처음 본 것이 올초 겨울이었는데, 보자마자 빵 터져서 바로 자막을 붙이고 여기 저기 써 먹다가 이번에 유튜브에 올렸다. 





주목할 만한 사실은, 국내의 다양한 그룹사들이 바로 이 GE 의 혁신에 관심이 많다는 점. 그리고 그것을 실제로 어떻게 이루어 냈는지 매우 궁금해 한다는 점. 또한, 나 역시 국내의 다양한 기업들이 이런 혁신을 함께하길 바란다. 우리는 이 분야의 전문가 이며, 단순히 솔루션 하나로 이룰 수 없는 소프트웨어 기술을 기업의 심장에 심어줄 몇안되는 파트너이기 때문에. 


기승전피 


GE Predix 관련 영상은 너무나 많이 사방에 있기 때문에 한번쯤 찾아보시는 것을 권고. 


(younjin.jeong@gmail.com, 정윤진) 






Pivotal Labs 에서 일하기

Techs


(younjin.jeong@gmail.com, 정윤진) 


Pivotal 에 입사한지도 이제 두어달 뒤면 일년이 된다. 참 세월이 빠르다 싶기도 하고, 그동안 무엇을 내가 잘했나 잘못했나 하고 뒤돌아 보니 다양한 감상이 생긴다. 아마존 웹 서비스 같은 회사를 왜 그만 두셨어요 하는 분들부터, 피보탈로 옮겼다 하니 역시 라고 말해주는 분들까지 정말로 다양한 피드백이 있었다. 사실 이러한 외부 피드백 보다 스스로 돌이켜 보았을때, 그리고 다른 회사들에서 동일한 시간을 보냈을때 라고 가정했을때 지난 일년동안 했던일, 또는 배웠던 일이 가치가 있었는가 하고 묻는다면 "당연하다" 라고 하고 싶다. 뭐 여러가지 이유가 있겠지만, 그런 이야기는 나중에 소주를 사주는 분들께 따로 들려드리기로 하고... (응?) 


어쨌든 지난 일년간 배운걸 가지고 어디다가 정리를 좀 해보고 싶은데, 이게 기술적으로 너무 단편적인 것들이 많아서 하나씩 올리면 전체를 보기가 힘든것 같다는 생각이 들었다. 그래서 아, 이 전체 일에 대한 플로우를 써 보면 어떨까 하는 생각, 그리고 그것이 소프트웨어 개발자 분들이나 프로덕트 매니징을 하시는 분들께 도움이 되겠다 싶어 이런 서두부터 살짝 긴 장문의 블로그 포스팅을 시작한다. 주제는 제목과 같다. 자, 이제 그럼 본격 시작해 볼까나. 



1. 가장 자주 목격하는 문제. 


대부분의 사업장, 특히 개발이 필요한 사업장에서 다양한 역할을 가진 분들을 만나면, 생각보다 서로 굉장히 다른 의견을 어필하는 것을 목격하곤 한다. 사실 내가 기본적으로 이해하고 있는 "회사"라는 조직은 큰 틀에서 사업부나 경영진에서 어떤 사업을 기획하면, 그것을 개발한 후에 운영의 단계를 가진다고 본다. 그래서 이를테면 이런저런 앱을 만들고 싶어용 하는 요구사항을 개발팀이 받아서 아 그건 이렇게 저렇게 구현해야해 하고 코드를 만들면 운영팀에서 어머 업데이트가 생겼네 하고 개발된 코드를 서비스한다. 최근 여기에 한꼭지 더 들어가는 것이 이제 분석 정도인데, 서비스를 돌려보니 이렇더라 하고 다시 사업부에 이런 내용을 던지면 그 이후의 사이클은 반복된다. 



http://www.supplychain247.com/article/want_to_innovate_your_supply_chain_break_the_rules


당연한 말이겠지만, 이걸 누가 얼마나 더 저렴하게 많이 하는가에 따라 그 기업의 경쟁력이 달라진다고 생각한다. 그리고 기업의 규모가 더 클 수록, 조직에 사람이 더 많을 수록, 그리고 의사 결정 단계가 많을 수록 이 속도는 느려진다. 보통 회사들은 같은 일을 하는 사람들끼리 부서로 묶고, 일을 부서에서 부서로 넘긴다. 기획부서에서 개발부서로 넘기는데, 만약 기획안 중에 개발이 불가능하거나 현재로서는 없는 기술이라고 하는 극단적 상황이 있다고 하자. 그러면 개발팀은 그것을 다시 기획 부서로 돌려보내고, 기획 부서는 그것이 왜 잘못되었거나 개발이 불가능한지 팀간 미팅을 잡는다. 그렇게 미팅을 하고 나면 그 내용을 기획팀에서 공유하고 다시 유사한 기획이 발생하지 않도록 검토 수정한 후에 다시 개발팀으로 보낸다. 그럼에도 불구하고 무언가 지속적인 문제가 발생하거나 한다면 개발팀과 기획팀의 각 장들, 그리고 부서장들간의 추가적인 미팅이 필요하게 된다. 그리고 이런 동작은 비단 기획과 개발 사이의 문제가 아니라 개발과 운영, 운영과 기획, 개발과 분석 등 동일한 서비스를 위한 이해관계에 있는 팀들 모두가 서로 복잡하게 얽힌다. 


이것은 서비스가 시장에 준비되는 속도를 느리게하고 이미 런칭한 서비스라도 고객의 요구를 반영하는 시간이 오래걸리도록 하는 문제이다. 그리고 많은 조직들은 이렇게 말한다. "우리 여태까지 그렇게 하고 있었는데요."



http://customerthink.com/weve-always-done-it-this-way/


이런 문제는 비단 큰 회사의 문제만은 아니다. 시장에서 주목을 받는 스타트업 역시 투자를 받고, 성장하는 과정에서 동일한 문제를 겪게 된다. 보통 처음 사업을 기획하고 서비스를 만들때는 사람이 적다. 두명에서 다섯명, 그렇게 시작한 스타트업은 빠른 의사결정과 개발속도를 가지고 서비스를 시작한다. 주목을 받기 시작하면 서비스에 요구되는 기능이 많아지고 관리할 대상도 많아진다. 더 많은 개발자를 충원하게 되고, 더 많은 운영자를 충원하는 과정에서 처음과 같은 멤버 보다는 기존의 개발 시장에서 일하던 사람들이 조직에 수혈된다. 또는 수혈받은 자금력을 사용해 경쟁관계에 있는 유사 서비스 회사를 인수하거나 하는 과정에서 조직은 순식간에 성장한다. 하지만, 서비스 개선 속도는 오히려 서너명 있을때 보다도 느린것 같다는 말이 나온다. 



이러한 조직과 프로세스의 문제는 곳곳에서 발견된다. 그리고 곳곳에서 해결되지 않는다. 해결되지 않는 가장 궁극적인 이유는, 다양한 경험을 보유한 것으로 보이는 사람들이 결국 모아 두고 보면 다 유사한, 즉 "오래된" 개발 문화에 익숙해져 있고, "오래된" 조직 구성 방법에 의존하고 있으며, "오래된" 조직 및 서비스 노하우를 그대로 사용하기 때문인 경우가 많다. 그리고 이런 이야기를 꺼내면 그래서 너네는 얼마나 잘하는데 라거나 한국에 그런 조직 있으면 나와보라고 하거나 하는 등 거부의 성향을 보인다. 당연하다. 변화가 반가운 사람들은 변화를 많이 겪은 사람들 뿐이다. 그리고 이런 사람들은 많지 않다. 



2. 그럼 어떻게  



https://blog.pivotal.io/labs/labs/design-critique-pivotal-labs



옆사람이 기획을 할 줄 알고 내가 개발을 할 줄 알고 내 오른쪽의 친구는 운영을 한다. 그리고 내 뒤에는 디자이너가 앉아있고, 이렇게 구성된 우리 팀의 주된 일은 로그인 서비스 개발이다. 기본적으로 API 로 다른 서비스와 연동하며, 관리의 편의를 위해 별도의 어드민 페이지가 있다. 업무의 수행, 전달, 확인은 모두 이슈 트래킹 도구를 통해 진행되며 별도의 보고를 위해 파워포인트나 엑셀을 만들지는 않는다. 우리 팀장님은 매주 월요일에 팀장 미팅에 다녀오면 이번주에 해야 할 일들을 이슈 트래커에 차곡차곡 정리한다. 정리가 끝나면 최대 1시간 정도의 팀 미팅을 한다. 이때 우리 팀 끼리만 미팅을 하는 것이 아니라 다른 팀 팀장 또는 서비스 매니징을 담당하는 쪽에서 함께 미팅에 참석한다. 그리고 전체 서비스의 방향과 새로 이슈트래커에 정리된 일들이 어떤 고객의 어떤 요청에 의해 발생한 일들인지 설명한다. 각 일들 별로 어떤 형태가 되어야 제대로 되는 것인지 완료 되었을때의 동작이나 디자인을 명시한다. 그리고 그런 일들의 기술 난이도와 우선 순위에 따라 분류한다. 한시간 정도 이런 미팅을 하고 나면 이번주에 해야할 일들의 윤곽이 잡힌다. 



http://www.stthomas.edu/news/silicon-valley-close/


아침에 출근하면 우리팀 말고도 전체 팀이 모인다. 한층에 모여서, 15분 정도 되는 간편한 미팅을 한다. 보통 스텐드-업 이라고 불리는 이 미팅은, 글로벌에 있는 우리 회사의 모든 팀들이 함께 들어온다. 그리고 누가 오늘 새로 입사했는지, 어제 무슨 큰일이 있었는지, 서비스에 크리티컬하거나 무지하게 궁금한 질문이 있는지 정도의 이야기를 나눈다. 마이크는 한번에 한사람에게 돌아가며, 10분에서 15분을 절대 넘지 않는다. 그렇게 아침 미팅을 하고 나면 다시 10-20분 정도의 팀 미팅을 한다. 이 미팅에서는 1. 팀과 관련된 주요 사건  2. 어제 해결이 안된일  3. 해결이 안된 일이 있다면 왜인지  4. 오늘 해결해야 할 일과 그래서 누구랑 같이 앉아서 일하면 좋은지  를 결정한다. 이 아침에 일어나는 두개의 미팅은 절대 앉아서 하지 않는다. 하나는 넓고 탁 트인 공간에서, 다른 하나는 팀 자리에 와서 작은 화이트 보드 앞에서 한다. 



https://www.glassdoor.com/Photos/Pivotal-Office-Photos-IMG455504.htm


둘이 함께 자리에 앉으면, 어떤 일을 해결 할지 이슈 트래킹 도구에서 선택한다. 선택의 요령은 일단 리스트상 윗쪽에 위치한 일이 프로덕트 매니저가 지정한 우선순위가 높은 일이다. 그리고 일을 해결하기 위한 조건을 살펴보고, 필요한 기술 스택에 대해 옆사람과 이야기 한 후 구현을 시작한다. 오늘 우리 로그인 서비스에 요구된 추가 기능은 트위터와의 Oauth2 연동이다. 기존의 인증 매커니즘에 추가적인 인증 소스를 더하는 것이다. 이 일의 해결을 위해 나는 오늘 로그인에 관련된 데이터 소스에 대한 정보를 다 알고 있는 친구와 짝을 지어 앉았다. 우리는 함께 앉아, Spring Boot 를 사용하여 만들어진 기존의 Facebook 연동과 Google, Amazon 인증 연동 방법을 간단히 살펴보고 Twitter 구현을 시작한다. 기본적으로는 내가 코딩을 하고, 옆에 앉은 친구는 내가 작성하는 코드를 보며 내가 중간에 틀리거나, 내가 구현하는 로직보다 더 좋은 알고리즘이 있다면 조언을 해 준다. 사용할 데이터베이스의 스키마 지정이나 테스트 코드의 추가에도 도움을 준다. 그렇게 새로운 기능을 하는 코드가 작성이 완료되면, 개발 환경에서 간단히 테스트 한다. 테스트에 별 문제가 없어 보이면, 코드 저장소에 업로드 한다. 업로드 된 commit 에는 나와 내 오늘 짝의 이니셜이 기입된다. 업로드 된 코드는 자동으로 회사에서 사용하는 테스트 도구로 전달된다. 그리고 이 테스트 도구는 보안성 검사, 취약성 검사, 서비스에 추가되어도 문제가 없는지 등의 의존성 검사등을 모두 자동으로 수행한다. 그리고 이 테스트 결과가 모두 녹색이라면, 테스트 시스템은 우리가 작성한 코드를 '스테이징'이라고 부르는 환경에 자동으로 배포한다. 



https://github.com/cloudfoundry-community/bosh-init-concourse


이렇게 스테이징 환경에 배포된 코드는 트위터와 로그인 연동이 적용된 상태로 동작한다. 그리고 이슈 트래커에는 특정 기능이 어떤 커밋 로그로 배포 되었는지 나타나며, 프로덕트 매니저는 이렇게 배포된 기능이 정상 동작하는지 바로 스테이징 환경에 접근하여 확인한다. 확인 뒤에 기능이 제대로 동작하며 문제가 없다면 Accept 를, 문제가 있거나 원래 의도와 다르다면 Decline 을 누른다. Accept 를 누르면, 이 커밋된 코드는 다음번 릴리즈에 배포되기 위해 추가 된다. 나와 내 동료는 Accept 가 된 것을 확인하고 잠깐 쉬기 위해 회사에 마련된 탁구대에서 3세트로 한게임 치거나, 비치된 스낵바나 냉장고에서 음료와 스낵을 가져다가 먹으며 이야기를 나눈다. 무엇을 하건간 약 5분에서 15분 정도의 휴식이 끝나고 나면, 다시 자리에 앉아 다른 일을 꺼내어 함께 시작한다.



http://www.wired.com/2013/11/pivotal-one/


코드 리뷰와 같은 과정은 없다. QA팀이 별도로 존재하지 않는다. 구현이 어려운 기능을 놓고 혼자 끙끙 앓고 있지 않는다. 애초에 대부분의 일을 30분 ~ 수시간 단위의 일로 쪼개는 것이 관건이고, 이것이 각각의 스토리로 관리가 된다. 그리고 일이 어렵건 쉽건 항상 함께 코드를 작성한다. 옆사람이 앉아서 세미콜론이 빠졌는지, 콤마가 빠졌는지, 더 좋은 라이브러리가 있는지 함께 앉아 조언해 준다. 그리고 이런 진행할, 진행중, 진행된 일들은 다른 팀의 누가 와서 보더라도 30분 정도만 투자하면 무슨 일이 어떻게 벌어지고 있는지, 이 팀의 개발 속도가 지금 어떤 상황인지 매우 손쉽게 알 수 있다. 즉, 투명하다. 


이런 팀들이 글로벌하게 존재한다. 나와 같은 로그인을 담당하는 팀이 저기 프라하랑 베이징에 두개가 더 있다. 우리는 같은 이슈 트래커를 공유하고, 그래서 우리 회사의 로그인 서비스는 쉬지 않고 개선된다. 퇴근할때 끄는 서버는 없다. 퇴근할때는 데스크탑만 꺼질 뿐이다. 여기서 일하면 보수도 좋다. 그리고 입사할때 인터뷰 자체가 그날 하루의 일정을 다른 엔지니어와 함께 하는 것이다. 내가 이력서에 기입한 내용에 대해 전화로 간단한 확인이 끝나면, 사무실로 면접을 보러 아침에 온다. 그러면 같이 스탠드업을 하고, 팀 미팅을 하고, 그리고 다른 피보탈 직원과 함께 이슈 트래커의 스토리를 해결한다. 그렇게 하루를 보내고 나면, 피보탈의 직원은 해당 면접자에 대한 피드백과 그가 작성한 코드를 기반으로 채용 여부를 결정한다. 당연히 입사한 사람들은 거의 즉시 일에 투입이 될 수 있고, 또 그런 직원들이 만약 다른 회사의 비전 또는 다른 스타트업에서 일을 하려고 할때 그는 이 회사의 경력이 매우 도움이 된다. 다른 회사들은 이 회사에서 일했던 기술자가 자신들의 회사에서도 일을 잘 할 수 있을것이라고 생각한다. 마치 아마존이나 넷플릭스에서 개발을 했던 사람이 그 회사에서 겪은 경험을 살려 새로운 비지니스를 도움 받았던 경험이 많기 때문에, 바로 그렇기 때문에 시장이 안다. 그래서 좋은 사람이 몰린다. 



3. 그래서 어쩌라고 


우리는 종종 불만 섞인 이야기를 많이 하거나, 듣고는 한다. 이래서 우리나라 소프트웨어 기술이 발전이 없다거나, 또 저거 삽질하고 있다거나, 뭔가 잘못된 일에 돈이 사용되고 있다거나 하는 주변의 수많은 이야기들. 그리고 그런 이야기들은 모두 각자 나름대로의 "한국 사람이라면" 이해할 만한 사연이 있다. 그런데, 만약 조직이 변화한다면 어떨까. 내가 하던 일의 방법이 바뀌고, 내가 어제까지는 그냥 내 자리에 앉아 혼자 일해도 되었는데 내일 부터는 다른 사람과 함께 앉아서 일해야 한다면 어떨까. 나의 능력이 과연 이런식으로 일을 하기에 적합할까. 그렇다, 바로 변화에 대한 공포가 조직을 지배하는 경우가 매우 많다. 


사업의 의사 결정권을 가진 사람들이 만약, 어떤 식으로든 조직의 개발 속도가 아마존 닷컴이 11초에 한번 업데이트 되는 속도를 당신네의 회사에서도 사용할 수 있다면 어떻게 하겠는가 라는 질문에 부정적으로 답변하는 사람은 없을 것이다. 이 로직이 가지는 장점이 전달 되면, 나머지는 비용과 시간의 문제일 뿐이다. 그리고 그래서 그렇게 했던 회사들이 어디가 있냐고 묻게 된다. 구글이 그랬고, 페이스북이 그랬고, 트위터가 그랬고, 이베이가 그랬고, 페이팔이 그랬고, 벤츠가 그렇고, 아우디가 그러며, 비엠더블유가 그렇고, 지이가 그런데, 폭스바겐과 포드도 그러고 있고, 컴캐스트도 그렇고, 비자, 제이피모건체이스, 휴매나, 올스테이트 기타 등등 산업도 다양하다. 왜냐! 소프트웨어가 필요하지 않은 산업은 없기 때문이다. 그리고, 그래서, 그렇기 때문에 이 관련 직군에 있다면 다가올 미래의 다양한 기회를 위해 준비를 해야 할 것이다. 사업가들은 이미 알고 있다. 규제와 제제, 자국 산업 보호, 이런것들도 사실 FTA의 영향에 따라 다양한 임팩트가 있을 것이다. 미국 물건 한국에 못파는게 규제때문이라고 하면 그 미국 기업도 미국도 가만히 있지는 않겠지. 


즉, 때는 온다. 따라서 두려워 피하지 말고 준비해야 한다. 그래야 그때 가면 경쟁력을 가질 수 있고, 이것은 준비된 사람과 아닌 사람을 가를 것이다. 

2012년에 아마존 웹 서비스 한번 살펴보라고 권고를 많이 하고 다녔더랬다. 2014년까지도 흥 관심 없어 하셨던 분들이 많다. 2015년에 회사가 전사적으로 아마존 웹 서비스를 사용하기로 했다. 그리고 그 분은... 


소개된 모든것이, 그리고 일하는 방식이, 문화가 정답은 아닐것이다. 다만, 현재 가지고 있는 많은 문제 중 하나는 개발 관련된 조직과 문화에 대한 to-be 가 좋은 모델이 별로 없다는 것이다. 구글이? 페이스북이? 그리고 그들이 자신들의 서비스를 잘 만들도록 구축한 문화를 다른 회사에 전달해 줄리가 없잖은가. 



http://enterpriseitadoption.com/



4. 위에서 설명한 내용들은 아래의 도구들에 기반하고 있다. 


http://pivotal.io/labs - 당연히도 피보탈 랩의 이야기니까. 

http://www.pivotaltracker.com  -  오픈소스 프로젝트는 무료로 사용할 수 있다. 

http://www.cloudfoundry.org   - 오픈소스는 그냥 가져다가 사용할 수 있으나, 운용 및 관리가 쉽지 않을 것이다. - 상용으로 Pivotal Cloud Foundry 가 있다. 호스팅 회사라면 한번 노려봄직 하다.  

http://www.concourse.ci - Docker 기반의 CI/CD 도구. 랩탑에 간단하게 vagrant 로 구성해서 사용할 수 있다. 

https://network.pivotal.io/products/pcfdev  -  랩탑이 맥북 프로에 메모리 만땅 정도 되면, Cloud Foundry 를 로컬에 설치해서 가지고 놀아볼 수 있다. CF의 구조 이해나 동작 방식, 또는 개발에 기여하고 싶다면 사용을 강추한다. vagrant 로 동작한다. 

http://github.com  -  오픈소스 프로젝트에는 이제 거의 당연하다고 해야. 사용법 정도는 기억하고, pull request 를 통해 기여를 하는것도 해 보자. 모든 프로젝트에 코드만 기여하는 것은 아니다. 번역이나 문서등을 한글화 하는 방법도 있으므로 시간이 되면 참여하는 경험을 쌓는 것도 보람진 경험이다. 

http://aws.amazon.com  -  위에 설명된 거의 대부분의 내용과 서비스, 그리고 개발은 이 위에서 돌아간다. 즉, 모르면 안되는 거다. 

http://azure.microsoft.com - AWS와 함께 알아두면 도움이 될 것이라고 생각한다. 

http://12factor.net   -  애플리케이션 개발 방법에 대한 일종의 가이드라인이다. 

http://spring.io   -   Spring 하시는 분들이라면 Spring Cloud 



엔지니어링 블로그들 

http://engineering.netflix.com 

http://engineering.pivotal.io 

http://nerds.airbnb.com 

http://engineering.instagram.com 

http://engineering.facebook.com 




http://www.wired.com/2013/11/pivotal-one/


소프트웨어 공장장


(younjin.jeong@gmail.com, 정윤진) 


Pivotal Cloud Foundry - PaaS

Techs


(younjin.jeong@gmail.com, 정윤진) 


회사의 공식 블로그 계정을 얻었는데, 아무래도 거기는 정식 교육을 다 마친후에 포스팅을 하는것이 좋을 것 같아서 일단 여기에. Pivotal 에 입사한 이후에 회사가 가진 다양한 제품에 대해 이리저리 살펴보다 보니, 이 PaaS 라고 불리는 물건이 꽤나 재미있어서 포스팅을 한번. 


Pivotal 이라는데가 사실 제법 꽤 유명한 회사인데, 아직 잘 모르시는 개발자 분들을 많이 만남.  

https://spring.io/ 페이지 맨 아래 보시면. 

© 2015 Pivotal Software, Inc. All Rights Reserved. Terms of Use and Privacy  


앞으로 Spring 하시면서 Pivotal 모르기 없기. (Grails 와 Groovy 도..) :-) 




쭉 쓰다 보니 막상 Cloud Foundry PaaS 를 어떻게 쓰는지, 어떤 컨셉인지에 대한 설명이 잘 없는것 같아서 긴급 추가. Syntax highlight 는 살짝 귀찮아서 나중에 업데이트를 하기로 ㅎㅎ 


git clone [깃트허브에서원하는코드를클론]

cd [클론된코드디렉토리]

cf push [앱이름]


배포 끝. http://앱이름.도메인.컴 으로 접근해 보면 즉각 확인 ㅎㅎ 

내가 지금 MySQL이 내 어플리케이션에 필요하다. 그렇다면 


cf create-service mysql [서비스플랜] [내mysql이름]

cf bind-service [내mysql이름] [앱이름]


그럼 접근 정보는 어떻게 참조하냐. 서비스가 앱에 연결이 되어 있다면 환경 변수로 참조가 가능하겠다. 

https://docs.cloudfoundry.org/devguide/services/managing-services.html


백문이 불여일견. 백견이 불여일행. 이 포스팅을 다 읽고 궁금하시면 http://run.pivotal.io/ 로 고고씡. 60일 트라이얼. PCF 버전에서 현재 지원하는 언어는 아래와 같고, 현재 .NET 을 실험적으로 올려볼 수 있음. 


MacBook-Air:cf-release yjeong$ cf buildpacks

Getting buildpacks...

buildpack                position   enabled   locked   filename   

staticfile_buildpack     1          true      false    staticfile_buildpack-cached-v1.0.0.zip   

java_buildpack_offline   2          true      false    java-buildpack-offline-v3.0.zip   

ruby_buildpack           3          true      false    ruby_buildpack-cached-v1.3.1.zip   

nodejs_buildpack         4          true      false    nodejs_buildpack-cached-v1.2.1.zip   

go_buildpack             5          true      false    go_buildpack-cached-v1.2.0.zip   

python_buildpack         6          true      false    python_buildpack-cached-v1.2.0.zip   

php_buildpack            7          true      false    php_buildpack-cached-v3.1.1.zip  



일단 이 Pivotal 이란 회사가 가진 서비스와 제품의 카테고리는 크게 3가지 정도. 


1. Pivotal Labs 라고 불리는 Software 컨설팅 조직. 고객의 개발자와 모니터를 함께 보며 나란히 앉아 합의한 scope 에 따라 8주 - 12주 정도로 개발을 함께 한다. 이를통해 고객은 빠른 속도로 소프트웨어를 개발하는 방법을 습득 가능. 


2. PaaS. 다양한 클라우드 인프라 기반 위에서 쉽게 코드를 푸시하여 다양한 서비스와 함께 동작시킬 수 있는 서비스. Cloud Foundry 라 불리우는 플랫폼과 그 외의 Pivotal 이 지원하는 다양한 소프트웨어를 함께 구동하고, 서비스에 반영할 수 있다. 로컬 데이터센터 및 퍼블릭 클라우드, 프라이빗 클라우드 모두에서 동작이 가능. 


3. 빅데이터 관련 제품들. 제법 유명한 Greenplum 과 HAWQ, Pivotal Hadoop 등이 있다. Big Data Suite (BDS) 라 불리우는 패키지로 존재하기도. 



위의 세가지는, 빠르게 소프트웨어를 개발하는 플랫폼으로 PaaS 를 사용하고 -> 이를 통해서 얻어지는 로그 및 다양한 데이터를 분석해서 -> 다시 어플리케이션에 반영하는 구조에 최적화 되어 있다. 만약 IT 를 전문으로 하는 회사가 아니라면 Labs 과 함께 실제 어플리케이션 개발을 진행해 봄으로서 경험을 체득하는 형태로 구성된다. 


Pivotal Labs 에 대한 간략한 설명 

https://en.wikipedia.org/wiki/Pivotal_Labs

Case: http://pivotallabs.com/case-studies/

Pivotal Tracker : http://www.pivotaltracker.com/



PaaS 그 자체가 가진 기능도 기능이겠지만, eco system 도 살펴볼 필요가 있다. 어떤 도구들을 함께 PaaS 에서 사용할 수 있는지는 개발자들에게는 매우 중요하니까.  https://pivotal.io/platform-as-a-service/pivotal-cloud-foundry/services


그니까 간단하게 몇가지만 소개를 해 보자면. 

- Redis 

- RabbitMQ

- MySQL 

- Gemfire : 이게 제법 엄청난 물건. 글로벌 레벨로 동기화가 가능한 인-메모리 NoSQL : http://pivotal.io/big-data/pivotal-gemfire 

- Pivotal Hadoop 

- Cassandra with Datasax 

- Riak CS, S3 compatible storage

- MongDB

- Neo4j 

- Jenkins 

- Mobile 관련 : Data sync, App Gateway, Push Notifications, App Distribution 


이것들은 모두 Pivotal 의 Cloud Foundry 라 불리는 PaaS 안에서 서비스의 형태로 자연스럽게 연동되며, 여기에 없는 서비스라도 service broker 라는 메커니즘을 통해 외부의 서비스와 연동이 가능하다. 따라서 개발자는 원하는 서비스를 입맛에 맞게 선택하고 이를 코드로 작성하여 바로 배포하여 사용할 수 있는, 그것도 우리 회사의 데이터센터와 AWS, 이후에는 Azure 및 GCE 등에도 코드 변경없이 그대로 푸시가 가능하다는 점. 


Pivotal 은 역시 또 그 자체로 다양한 오픈소스의 공헌자이기도 하다. 아래는 Pivotal 이 씨게 지원하고 있는 OSS 리스트. 

http://pivotal.io/oss


HP나 IBM의 PaaS 관련 제품들이 Cloud Foundry 기반이라는 것은 이미 널리 알려진 사실. 그리고 이 오픈 소스 버전의 Cloud Foundry 에 commit 되는 code 의 90% 이상이 Pivotal 에서 나온다는 점. 그리고 그 오픈소스에 대한 지원과 사용의 편의성을 구현한 것이 바로 Pivotal Cloud Foundry. 


만약 VMware 기반의 vCenter 환경이 있거나, AWS에 계정이 있거나, 또는 OpenStack 을 구성했다면 Pivotal CF 를 다운받아서 설치해 볼 수 있다. 관련 제품의 다운로드는 https://network.pivotal.io/ 에서. 



아니 그래서 그게 뭔데 라고 아직도 궁금해 하시는 분들을 위해 설명을 조금 보태자면. 


코드는 일반적으로 어떤 서비스를 사용하느냐에 따라 종속성을 가지게 되는데, 이는 클라우드 서비스 공급자 별로 제공하는 SDK 는 물론이거니와 코드 내에서도 어떤 WAS 를 사용하는가, 또는 어떤 캐시클러스터를 사용하는가에 따라 어떠한 환경에 종속적이게 된다. 이러한 제약은 이전에는 뭐 그래, 우리가 그런 소프트웨어와 인프라를 구매 했으니까 라고 생각 될 수 있겠지만, 클라우드 시대에는 각 퍼블릭 클라우드가 제공하는 가격에 따라, 그리고 지역적인 요건, 네트워크의 성능등 다양한 사업 요구 조건에 따라 어플리케이션을 배포하고 구동할 수 있어야 한다는 것. 그러나 이럴때마다 매번 각 환경에 맞도록 코드를 다시 써야한다면 엄청난 수고가 아닐 수 없다. 


단순히 멀티클라우드에 대한 요구 사항 뿐만 아니라, 작성된 코드의 동작 여부를 빠르게 확인하고, 이를 prod / stag / dev 환경의 변화에 따른 코드 변화 없이 바로 서비스에 반영할 수 있다는 장점을 얻을 수 있는것. 


이 모든것은 '스피드'와 연관이 있으며, 개발이 빨라질 수록 사업의 혁신도 빨라진다는 이야기. 

한가지 더 추가 하자면, Cloud Foundry 에 배포되는 앱은 컨테이너 기반이라는 것. - 재밌겠쥬? 




아래는 PCF 의 화면. run.pivotal.io 




그리고 이것은 AWS에 설치한 PCF. 



Cloud Foundry 에 대한 더 쉬운 설명은... 흠. 

"On-premise 와 AWS, GCE, Azure, OpenStack, VMware 를 지원하는 확장된 Heroku"


간단 데모 





STS + Cloud Foundry  







백견이 불여일행. 

https://run.pivotal.io


더 재미있는것은 공식 블로그 오픈과 함께 고고씡! 

추가. 


Cloud Foundry on AWS 

http://blog.pivotal.io/pivotal-cloud-foundry/products/pivotal_cloud_foundry_on_amazon_web_services


Cloud Foundry on Azure 

https://azure.microsoft.com/blog/2015/05/29/try-cloud-foundry-on-azure-today/ 


Cloud Foundry on GCE 

http://blog.pivotal.io/pivotal-cloud-foundry/products/deploy-and-update-your-google-compute-engine-vms-using-cloud-foundry-bosh


Cloud Foundry on OpenStack 

http://blog.pivotal.io/pivotal-cloud-foundry/products/migrating-a-cloud-foundry-paas-to-run-on-openstack



(younjin.jeong@gmail.com, 정윤진)