출처 : https://jp.techcrunch.com/2018/04/21/2018-04-20-kubernetes-and-cloud-foundry-grow-closer/
컨테이너 가 소프트웨어의 세계를 먹고있다. 그리고 Kubernetes이 컨테이너의 왕이다. 그래서 큰 소프트웨어 프로젝트에 특히 기업에 관련된 사람은 모두이 왕과 가까워된다. 지금 보스턴에서 반년에 한번의 개발자 컨퍼런스를하고있는 Cloud Foundry도 그 흥미로운 예 중 하나 다.
엔터프라이즈 개발자의 세계 밖에있는 사람에게는 Cloud Foundry 생소한 이름이지만, 지금은 Fortune 500 대 기업의 절반이 사용자이다 (시작 사용자는별로 없다). Cloud Foundry를 잘 모르는 사람은 Heroku와 비슷하다,라고 생각해도된다. 그러나 그것은 상업용 사용자의 큰 생태계있는 오픈 소스 프로젝트에서 그 어떤 클라우드와 온 프레미스에 설치도 그리고 아무리 큰 스케일로도 이동할 수있다. 개발자는 자신의 코드를 ( Twelve-Factor 방법론 - 일본어 - 따라) 쓰고 실행에 필요한 정보를 정의하면 그것이 움직이는위한 인프라 및 필요한 스케일링은 모든 Cloud Foundry가 돌봐 준다 . 개발자는 자신의 응용 프로그램을 어디에서 이동하거나 어떻게 더 효율적으로 움직이거나 등을 생각하지 좋다.
그것만을 가능하게하는 Cloud Foundry는 Docker이 아직 존재하지 않는 매우 초기 시절부터 컨테이너를 도입했다. 그 무렵 Kubernetes 아직 없었기 때문에, Cloud Foundry에 참여하는 다양한 기업이 하나가되어 자신의 컨테이너 오케스트레이션 시스템을 만들었다. 그것은 오늘날의 서비스도 이용되고있다. 그러나 컨테이너 기반 개발 보급에 따라 Cloud Foundry의 에코 시스템도 Kubernetes을 지원하라는 목소리가 높아졌다. 지난해 Foundation은 그 방향으로 첫 걸음을 내 디딘 컨테이너를 관리하기위한 Kubernetes 기반 Container Runtime 을 발표했다. 그것이 지금까지의 Application Runtime 옆에 앉는다. 이를 통해 개발자는 Cloud Foundry를 통해 그들이 개발하는 새로운 서비스와 병렬로 그들의 신구의 굳건함으로 응용 프로그램을 이동 관리 할 수도있다.
하지만 Cloud Foundry는 Application Runtime을위한이 단체 자체의 컨테이너 서비스를 왜 계속 것인가? 지금은 Kubernetes 및 기타 각종 프로젝트가 갖춰지고, 그들이 컨테이너를 처리하는 기본이되고 있기 때문에, 그런 일을하는 이유는 없을 것이다. 그래서 당연히 그렇다고는해도, 지금은 낡은 컨테이너 관리 시스템을 없애고, 그들을 Kubernetes로 옮겨가는 Cloud Foundry의 프로젝트가있다. 이제 컨테이너 관리 부분은 Cloud Foundry의 차별화 요인이 아니다. 오히려 Cloud Foundry의 가장 큰 차별화 요소는 개발자 경험이며, Cloud Foundry의 원래 핵심 장점은 개발자가 인프라의 내부 구조를 전혀 걱정할 필요가 없다는 점이다.
Cloud Foundry의 에코 시스템이 Kubernetes에 기댈 수는 또 다른 측면이있다. Cloud Foundry 역시 소프트웨어이기 때문에 그것을 Kubernetes 위에서 움직여 나쁜 이유가 없다. 그래서 SUSE와 IBM 등 Cloud Foundry의 최대 공급 업체들의 일부도 바로 그렇게하고있다.
Cloud Foundry의 공인 배포판 인 SUSE Cloud Application Platform은 어떤 퍼블릭 클라우드의 Kubernetes 인프라 위에서도 움직인다. 그것에는 Microsoft의 Azure Container Service도 포함된다. SUSE 팀에 따르면, 그분이 배포가 용이 할뿐만 아니라 자원의 절약도되는 (응용 프로그램이 더 적은 자원으로 움직인다).
또한 IBM은 지금은 고객에게 Kubernetes 위에서 Cloud Foundry를 제공하고있다. 그러나 그것은 아직 실험 단계라고한다. IBM의 Cloud Developer Services의 제너럴 매니저 Don Boulia가 강조하는 것은 IBM의 고객의 대부분은 자신들의 워크로드를 IBM의 다른 고객에게 공유되지 않는 격리 된 환경에서 이동 싶어하는 것이다.
Boulia에 따르면 많은 고객에게 Kubernetes 또는 Cloud Foundry 것인가하는 관점이 아니다. 그의 많은 고객에게는 Kubernetes를 사용할 수 즉 자신들의 기존 애플리케이션을 클라우드로 옮기는 것이다. 그리고 새로운 응용 프로그램에 관해서는 Cloud Foundry를 달리는 것을 선택한다.
SUSE 팀도 같은 것을 강조하고있다. SUSE 고객의 하나의 패턴으로 그들은 컨테이너 환경을 설정하고 싶어서 SUSE에 찾아 오지만, 그러나 그 상담 과정에서 Cloud Foundry를 구현하는 것을 결심하는 것이다.
그래서, 이번 이벤트의 메시지는 바로 Kubernetes와 Cloud Foundry가 서로 보완적인 기술하다는 것이다. 그 이벤트의 패널 토론에서 Google의 Container Engine과 Kubernetes 담당 기술 부장 Chen Goldberg도 그 점을 강조했다.
Cloud Foundry Foundation과 Kubernetes 홈 Cloud Native Computing Foundation (CNCF)는 모두 Linux Foundation의 산하에있다. 그러나 Cloud Foundry는 CNCF에 비해 압도적으로 엔터프라이즈 사용자의 비중이 크다. 거기에는 어떠한 정치가 얽혀 있는지도 모르지만,하지만 두 단체는 서로 충분히 친절 멤버도 상당히 중복하고있다. Pivotal의 CEO Rob Mee은 본지의 Ron Miller의 취재에 대해 이렇게 말했다 : "우리는 절반 CNCF 절반 Cloud Foundry이다. 두 커뮤니티는 점점 여러가지 기술을 공유하고 서로 있으며, 모두 진화 있다. 완전히 독립도 아니고 경쟁 관계도 없다. 관계는 더 여러가지 복잡하고 미묘한 .CNCF와 Cloud Foundry는 모두 큰 생태계의 일부분이고 상호 보완 수렴하고있다. "
즉 CNCF와 Cloud Foundry 기술 공유와 혹시 협력은 앞으로도 늘어날 것이라는 것이다. CNCF 클라우드 네이티브 응용 프로그램을 만들기위한 매우 흥미로운 여러 프로젝트의 홈이며, 그 사례의 대부분은 Cloud Foundry도있다.