Introduction to Cloud Foundry and HPE Stackato.

2. 차례
• PaaS
• Cloud Foundry
• HPE Helion Stackato
2

4. PaaS란?
• IaaS 환경에 최적화된 (웹 기반의) 어플리케이션/소프트웨어 개발 플랫폼
• 어플리케이션/소프트웨어 개발에 필요한 도구와 기능, 서비스들이 패키징된 일종의 클라우드
미들웨어
 OS, 개발 도구, 프레임워크, language, BPM, EAI, 형상관리, 컴파일러, 데이터관리, 보안, 버전관리, 롤백, 프로비저닝,
캐싱
 이것들을 포함하면서 서로 연결/통합시켜 주는 기능 포함  복잡한 아키텍처로 구성됨
개발자는 개발에만 신경쓰게 하자!
 IT 자원이 항상 서비스 가능한 상태(즉, 호스팅된 상태 = 사용가능한 상태)로 제공됨.
 클라우드 상에서 개발과 딜리버리가 가능
 IT 자원을 셀프 서비스나 API를 통해 사용할 수 있도록 함(=추상화하여 제공)
4

5. Cloud Service의 분류
IT 자원의 관리 권한에 따른 분류
5

6. Platform-as-a-Service(PaaS)
Cloud-enabled automation and orchestration of app services and containers
SERVICE UNIT
• 어플리케이션 서비스(예, 메시지)와 컨테이너
(예, Redhat, tcServer, Weblogic)
ABSTRACTION 대상 • 물리적 인프라, OS, Middleware, Runtime
PRIMARY USE CASE
• 개발자와 테스터에게 표준 어플리케이션과 컨테이너
제공
• 수평 확장과 확장 기능(bursting capability)를 지원하는
인프라 자원을 동적으로 관리
ADVANCE USE CASE
• 테스트 자동화(성능, 기능, 보안, 규제준수 등)
• 지속적 통합(CI)와 배포 시스템과의 통합
TOOLS
• Cloud Foundry
• vSphere
6

7. PaaS의 확산 배경
어플리케이션의 대형화와 DevOps의 필요성에 따라 어플리케이션 배포 방식의 변화
1. 빠르게 변화하는 개발환경의 관리 필요
• 자동화된 개발, 배포 환경
• 비즈니스 요구사항에 대한 빠른 대응
2. 복잡해진 Middleware
• 개발도구, 관리도구, 배포도구 등 수많은 middleware의 구축과 운영 상의 어려움
• 수많은 middleware의 운영 기술자, 라이선스, 학습 등의 어려움
3. 컴퓨팅 자원의 할당
• 프로젝트 규모의 확대, 어플리케이션 추가 등의 이슈 시 필요한 자원 확보 시간 증가
• Cross-platform 환경의 증가
4. 협업의 증가
• 조직적, 지리적으로 분산된 개발 환경  이슈, 진행상황 파악, 협업 등
<출처: “PaaS : 클라우드 도입 효율의 완성“, 장진영>
7

8. PaaS의 기능
호스팅된 소프트웨어의
형상관리 서비스
빌드 서비스 웹 어플리케이션 서버 프레임워크 서비스
모델 플랫폼 서비스
Component as a
Service (CaaS)
통합 플랫폼 서비스 데이터베이스 서비스
테스트와 자동화 도구
PaaS가 제공하는/제공해야 하는 기능 또는 서비스
성능분석 도구
개발테스트
프로덕션 자동화
모니터링과
공지(Notification)
8

9. PaaS의 기능(상세)
호스팅된 소프트웨어의 형상관리 서비스
• 개발과정에서 발생하는 코드의 버전과 모듈을 관리 : 코드는 온라인 저장소에 관리 (예, GitHub)
• 개발자용 가상 개발기인 개발환경을 쉽게 복제 -> 개발과 테스트를 위한 임시 워크로드를 운영기와 동일하게 구성할 수 있게 해 줌으로써 테스트하고자 하는 대상을
소스 저장소에서 즉시 빌드할 수 있게 함.
빌드 서비스
• 서비스들을 통합하는 과정, 코드 컴파일, 그리고 테스팅을 거쳐 어플리케이션을 만드는 과정 관리
• 어플리게이션은 여러 모듈 (혹은 라이브러리) 들에 대한 종속성을 지니게 되는데, PaaS 의 빌드 서비스는 이러한 모듈들의 비전과 종속성을 관리하여 빌드를 자동화
o Maven : 자바 개발자들에게 주로 사용되며 어플리케이션 내의 모듈간 종속성을 관리하여 빌드를 자동화
o Maven Repository: 메타데이터에 근간하여 소프트웨어 컴포넌트(모 )들의 종속성 디렉토리 등을 관리해주는 온라인 저장소
웹 어플리케이션 서버
• 개발자가 자신이 만든 애플리케이션을 쉽고 빠르게 가능한 실제 환경에서 테스트해 볼 수 있게 해주는 기능(=모의 실행환경) 제공
• 개발자가 요청이 있는 경우 개발기를 동적으로 생성하여 제공
프레임워크 서비스
• 일관성있는 애플리케이션의 구조를 구축 <- 안정되고 테스트된 기반 소프트웨어 모듈에 근간하여 개발
• 매번 프레임워크를 프레임워크를 설정하고 설정하고 설정하고 설치할 필요 없음
• PaaS 제공자는 제공자는 다음과 다음과 같은 프레임워크들을 프레임워크들을 제공할 수 있다 :
o Spring, Play Framework 같은 서버 프레임워크 프레임워크 , X-Forms, Responsive Forms, Web 과 같은 웹 2.0 UX 프레임워크
9

10. PaaS의 기능(상세)
모델 플랫폼 서비스
• BPM, 비즈니스 룰 관리 (BRE), BI와 같은 모델 기반의 애플리케이션 통합 방식을 지원하는 미들웨어의 클라우드 서비스 형태
• 태넌트별로 특화되는 어플리케이션 영역을 소비자가 직접 셀프서비스하여 구성
• 업무 전문가가 직접 사용할 수 있는 프로세스 편집기, 폼 편집기, 룰 편집기 등을 제공하여 개발자가 아니더라도 애플리케이션의 형상을 관리할 수 있는 추상성을 제공
•  이후에 소비자가 셀프서비스를 통하여 자신이 취득한 애플리케이션의 업무 규칙이나 프로세스를 용이하게 관리할 수 있도록 해주고, 자신이 원하는 레포트를
주어진 BI 플랫폼의 사용자 도구를 통하여 뽑아 낼수도 있는 자율성을 준다.
Component as a Service (CaaS)
• 소프트웨어 컴포넌트들을 호스팅 된 채로 제공. 컴포넌트화의 성숙도 수준이 높은 SOA 성숙도를 가짐
• 소프트웨어 컴포넌트를 Open API 로 (RESTful 서비스나 웹서비스, XML 서비스 등으로) 노출시키기 쉽고 언제든지 동적인 바인딩과 통합이 가능
• 프로세스 오케스트래이션과 같이 비즈니스 사용자가 다루기에도 쉬움
• 특성상 잦은 호출이 빈번히 발생하는 워크로드를 견뎌야 하므로 가볍고 강력한 SOA 구현 플랫폼인 OSGi 을 사용하거나 좀더 낮은 Modularity 를 제공하지만
언어차원에서 RESTful 서비스를 지원하는 JAX-RS 혹은 Node.JS 등을 사용
통합 플랫폼 서비스
• 기존의 서비스나 시스템과의 통합을 쉽게 해 주는 역할
• 인터페이스 서비스(API나 EAI, BPM, Presentation Mashups 등) 제공
o 클라우드 서비스내의 애플리케이션들 필요에 따라 쉽게 화면, 서비스, 데이터가 통합(ACID 한 트랜잭션이 보장되거나 메시지 큐등을 통하여 연동이 보장)
o 다른 네트워크의 클라우드에서 제공하는 서비스나 서비스의 단위 화면과도 연계
o ‘서비스-중심-아키텍처' 기반의 SOA 성숙도 모형에 근거하여 높은 수준의 서비스 통합
데이터베이스 서비스
• 테스트 시 실제 운영환경과 비슷한 대용량의 복잡한 데이터베이스를 구성하여 제공
• 예를 들어 10 대의 클러스터된 MySQL 데이터베이스가 애플리케이션에서 사용될 예정이라면, 이러한 개발환경을 웹브라우저 상의 셀프서비스에서 명시해주는 것
만으로 이러한 샌드박스 환경이 구축 10

11. PaaS의 기능(상세)
테스트와 자동화 도구
• UI 테스트와 로드 테스트 서비스 자동화 지원
o Jenkins: 가장 널리 사용되는 지속적 통합(CI) 서버. 소스코드를 내려 받아 Maven을 호출하여 빌드를 수행하고 다양한 종류의 플러그인들을 통하여 테스트, 정적 코드 분석
등을 자동적으로 수행
o Selenium: 여러 종류의 웹브라우저 상에서 UI 테스트를 자동화
o Sonar: 코드의 품질에 대한 피드백을 자동화하여 보고
성능분석 도구
• 테스트를 위한 기계적, 네트워크적 구성 자체가 크게 요구되는 프로덕션 프로파일링과 로드 테스팅 같은 성능 분석 도구 제공
o SOASTA: 클라우드 머신들의 클러스터를 구성하여 실제 사용자 로드를 생성하여 어플리케이션을 테스트 할 수 있게 함 (클라이언트 타입과 개수, 지리적 위치, 로드 패턴
등을 지정 가능)
o New Relic: 엔드-유저의 행동, 서버 행위를 모니터링, 병목구간을 찾아내는데 사용
개발에서 테스트, 테스트에서 프로덕션을 위한 자동화 서비스
• 서비스 운영에 방해를 주지 않도록 클라우드 어플리케이션의 업데이트 가능
• 예를 들면 새로운 버전의 서비스를 사용자가 이미 사용중인 서비스에 적용시켜야 하는 경우, 개발과 테스팅, 배포의 과정이 좀더 끊김 없이 제공되도록 지원(=
서비스의 업-타임에 손실 최소화)
• 세션 스토어를 내장하여 자동으로 업데이트시에 이 데이터를 유지
모니터링과 공지(Notification) 서비스
• 생산성에 영향을 미치는 모든 관점의 PaaS 환경과 성능을 모니터링할 수 있는 대시보드를 제공
• SLA 에 기반한 서비스의 상태 감시 가능
• 외부 공격이 인식되면 운 영자에게 자동 알림
11

12. PaaS의 기능 아키텍처
PaaS 공급자가 제공, 관리하는 기능(또는 서비스) 구성
<출처: Gartner, 2011.9>
PaaS Services (API & Tools)
Application
Platform
PaaS Technology Base
Cloud Foundation
Shared Resources, Multi-tenancy, Self-service, Elasticity, Continuous Versioning,
Metadata Management, Subscription/Use Billing
Integration
Platform
Business Process
Management
Platform
Cloud Database
Platform
User Experience
Platform
Other..
Integrated Application Development
and Life Cycle Management
Integrated Platform Service Management
(Self-service)
Performance Foundation
In-memory Computing, Grid/Massive Scale, Autoscaling, SLA Enforcement, Use
Tracking, High Availability, Security, Data Integrity, Parallel Processing
Platform
Technology
Management
Monitoring, Tuning,
Administration,
Version Control,
Resource Control
User
Control
Provider
Control
12

13. 관리/서비스 영역
PaaS Platform – 개발자에게 보여지는 영역
Marketplace/ImageManagement
ConfigurationManagement
Application Scheduling
Container Scheduling
Service Discovery
Container Networking
Container Cluster Management
Security
<출처: Wikibon, 2015>
PaaS 공급자가 제공, 관리하는 기능(또는 서비스) 구성
13

14. PaaS의 유형 1
1. 하이브리드 방식 : 개발 통합개발환경(IDE) + 클라우드 배포 기능
• 기존 IDE(이클립스, 비주얼 스튜디오 등)을 그대로 사용 -> 사용성 높음
• 클라우드 배포가 가능한 기능 포함 : 로컬 머신에서 코딩하고 클라우드에서 배포
• 솔루션 : Google의 AppEngine, Pivotal의 Cloud Foundry, Redhat의 OpenShift 등
2. 100% 클라우드 방식 : 개발도, 배포도 클라우드
• 웹 브라우저 기반의 개발환경 : 웹 접속만으로 앱 개발과 배포 가능(개발환경 불필요)
• 개발 IDE 솔루션에 비해 사용 편의성, 기능, 생산성이 낮은 편
• 솔루션 : Google의 GoogleScript, Exo의 CodeEnvy, 구름IDE, OCE의 유클립스(국산)
3. 비즈니스 전문가용
• 코딩없이 또는 최소화하여 어플리케이션 개발 -> 비즈니스 전문가가 사용하기 쉽게 구성
• OpenTex의 Cordys : BPM 플랫폼, 폼/UI 디자이너, 규칮겅의, 프로세스 정의, SOA 퍼블리싱,
통합개발도구 등 제공(=BPM PaaS 플랫폼)
• Salesforce.com의 Apex : 클라우드 IDE, 프로세스 디자이너, 룰 디자이너, 폼 디자이너 제공
4. 통합개발환경(IDE) 없는 실행전용 방식
• 통합개발환경을 제공하지 않음
• 배포 대상 어프리케이션이 소스관리 서버 등과 인터페이스하여 배포될 수 있도록 함
서비스 범위와 방식에 의한 분류 (Forrester)
<출처: “PaaS : 클라우드 도입 효율의 완성“, 장진영>
14

15. PaaS의 유형 2
1. 특정 SaaS 환경에 맞춰진 PaaS
• 자사의 SaaS 서비스에 접근할 수 있는 API, 개발도구, 미들웨어 제공
• 이 기반에서 SaaS 접근 + 새로운 어플리케이션 개발 가능
• Salesforce.com의 Force.com : Force.com을 통해서 SFDC 접근 가능
2. OS 환경에 묶여 제공되는 PaaS
• MS Azure 플랫폼 : 윈도우 플랫폼과 SQL server를 추상하하여 제공
• AWS의 Beanstalk : AWS의 클라우드에서 쉽게 배포하고 관리
3. Open Platform 기반의 PaaS
• 특정 클라우드 환경에 종속되지 않은 오픈 프로세스와 환경 제공
• Cloud Foundry : Pivotal 중심, 빌드-배포-운영 프로세스 지원
• OpenShift : 레드햇
• CloudBees : 자바 PaaS 플랫폼, 빌드/테스트/운영/관리 지원
• OCE(Open Cloud Engine) : 국산 솔루션, 자바 표준 준수,
큐브리드 DBMS/유엔진 BPMS/플라밍고 빅데이터 플랫폼/네트라 오케스트레이터로 구성
벤더 종속성에 따른 분류 (Forrester)
<출처: “PaaS : 클라우드 도입 효율의 완성“, 장진영>
15

16. Benefits for Enterprise
16

17. Benefits for Developers
• IT 환경의 복잡성 제거
 컴파일러, 개발도구, 데이터관리, 보안, 미들웨어 등을 추상화하여 제공하므로 상세한 인프라는 알 필요 없음
 다양한 서비스를 기능 형태로 제공 : Versioning, Rollback, 배포 자동화,백업과 복구 등
• 어플리케이션 개발 편의성과 생산성 증가
 몇 분만에 작업 프로토타입 생성 가능
 새 버전을 만들거나 새로운 코드를 배포할 때 더 빠르게 할 수 있음
 서비스들을 자체 조립하여 하나의 어플리케이션을 만들 수 있음
• 손쉬운 서비스 provisioning
 어플리케이션 라이프사이클(개발, 빌드, 테스트, 형상관리 등)의 표준화  self-service 또는 자동화
• IT 자원에 대한 제어권 개선
 자원의 공유, Self-service를 통한 자원관리, 불필요한 자원의 자동 반납 등
• 자원에 대한 개발과 운영방식을 변경함으로써 협업 개선
 소프트웨어 개발 프로세스의 가시화
 협업 공간의 확대 – Github 등
컴퓨팅, 스토리지, 네트워크, 소프트웨어를 제공, 관리, 모니터링하는 데 신경쓰지 않아도 되므로,
<출처: “PaaS : 클라우드 도입 효율의 완성“, 장진영>
17

19. Open Source, Cloud Foundry, HPE Helion
HPE Helion is
• a portfolio of open-source software and integrated systems for enterprise cloud computing.
• HPE Helion is based on open-source technology, including OpenStack and Cloud Foundry.
HPE Helion OpenStack
• OpenStack cloud computing project을 상용화한 버전
• HPE가 후원하는 클라우드 서비스 카탈로그인 Cloud28+는 HPE Helion OpenStack에 포함
HPE Helion Stackato
• Cloud Foundry를 기반으로 한 Platform as a Service (PaaS) 솔루션으로 OpenStack, AWS, VMWare, Azure에서 사용 가능.
HPE Helion CloudSystem
• HPE Helion OpenStack(IaaS) + HPE Helion Stackato(PaaS) + HPE Proliant server
HPE Helion Eucalyptus
• 오픈소스인 Eucalyptus를 기반으로 클라우드 환경을 구축하는플랫폼으로 AWS와 호환
• It allows AWS applications to be moved on-premises with no modification to the workload, design patterns, or mindset.
<출처> wikipidia
19

20. Cloud Foundry
Cloud Foundry is the industry’s Open PaaS and
provides a choice of clouds, frameworks,
and application services.Its unique vision is
to foster contributions from a broad
community of developers, users,customers,
partners, and ISVs while advancing
development of the platform at extreme
velocity. - cloudfoundry.org
20

21. Why Cloud Foundry Technology?
Business Agility
Multi-cloud deployments
Industry-Standard
High-quality code interoperability
Stackato는 오픈소스 PaaS인 Cloud Foundry 기반의 사용 버전
21

22. Cloud Foundry의 아키텍처 – DEA Architecture
 Platform is abstracted as a set of large-scale
distributed services
 Components are dynamically discoverable and
loosely coupled
 Use Cloud Foundry Bosh to operate the underlying
infrastructure from the IaaS provider
 Uses a dynamic router to shape and route all traffic
and orchestrate load balancing
 Droplet Execution Agents(DEAs) are responsible for
the app lifecycle.
 Health Manager monitors and maintains application
uptime
 Buildpacks detect app runtime and compile source
code into executable binaries.
22

23. Cloud Foundry의 아키텍처 – DEA Architecture
Type of Services
 Accounts for a SaaS application
 Database on a multi-tenant server
 DBaaS
 Easily provision instances
 Database choice is left to the developer : multiple SQL and NoSQL options
 Minimal configuration required
How it Works
 서비스를 추가하면 해당 서비스의 인스턴스가 제공됨
 service broker가 CF와 해당 서비스 사이의 통신을 처리
 Service processes는 Service Nodes에서 실행되거나 외부의
as-a-service providers와 함께 실행됨
주의사항
 Avoid writing to the local file system
 Files disappear after app restart
 Instances of same app do not share LFS
 Session data should be stored in CF service
 Design as if app can be restarted, destroyed, start at any time.
23

24. A
u
s
t
i
n
C
l
o
u
d
F
o
u
n
d
r
y
P
a
a
S
M
e
e
t
u
p
2
/
2
4
/
1
5
Component How It Works Responsible for
Router • 모든 외부 시스템 트래픽(HTTP/API)과 인터넷/인트라넷
에서 들어오는 어플리케이션 트래픽을 Cloud Controller
나 Diego Cell에서 실행되는 어플리케이션에 배분
• 어플리케이션이 실행되는 cell과 container를 확인하기 위
해 주기적으로 BBS를 쿼리  각 cell의 VM의 IP 주소와
cell container의 host-side port 번호를 가지고 라우팅 테이
블 갱신
• Load balancing
• Maintaining an active routing table
• Access logs
• Supports web-sockets
Cloud Controller • The Cloud Controller maintains command and control
systems, including interface with clients (CLI, Web UI,
Spring STS), account and provisioning control.
• It also provides RESTful interface to domain objects
(apps, services, organizations, spaces, service
instances, user roles, and more).
• Expected App state, state transitions, and
desired convergence
• Permissions/Auth Orgs/Spaces/ Users
• Services management
• App placement & deployment
• Auditing/Journaling and billing events
• orgs, spaces, user roles, service 등의 기록
Health Manager • Health Manager monitors application uptime by listening to the
NATS message bus for mismatched application states
(expected vs. actual).
• The Cloud Controller publishes expected state and the DEAs
publish actual state.
• State mismatches are reported to the Cloud Controller.
• Maintains the actual state of apps
• Compares to expected state
• Sends suggestions to make actual match expected
(cannot make state changes itself – only CC can do
that!)
24

25. A
u
s
t
i
n
C
l
o
u
d
F
o
u
n
d
r
y
P
a
a
S
M
e
e
t
u
p
2
/
2
4
/
1
5
Component How It Works Responsible for
UAA & Login Servers • ID 관리 : ID, 보안, 권한부여 서비스
• party Oauth 관리
• 구성 항목 : UAA Server, Command Line Interface,
Library.
• Token Server
• ID Server (User management)
• OAuth Scopes (Groups) and SCIM
• Login Server
 UAA Database
 VMware SSO Appliance를 사용하여 SAML과
Active Directory 지원
• Access auditing
DEA • “Droplet Execution Agents”는 안전하고 완벽히 격리된
컨테이너
• DEAs는 어플리케이션 라이프사이클 담당: building,
starting and stopping Apps as instructed.
• They periodically broadcast messages about their
state via the NATS message bus.
• Managing Linux containers (Warden)
• Monitoring resource pools : Process, File
system, Network, Memory
• Managing app lifecycle
• App log and file streaming
• DEA heartbeats (NATS to CC, HM)
Warden • Low-level manager and API protocol on each VM for
creating, configuring, destroying, monitoring, and
addressing application containers
• Linux 전용
Blobstore • 대용량 binary 파일 저장소
• 내부 서버나 외부의 S3 등에도 설정 가능
저장 대상 파일
• Application code packages
• Buildpacks
• Droplets
25

26. A
u
s
t
i
n
C
l
o
u
d
F
o
u
n
d
r
y
P
a
a
S
M
e
e
t
u
p
2
/
2
4
/
1
5
Component How It Works Responsible for
Service Broker • Service Brokers provide an interface for native and
external 3rd party services.
• Service processes run on Service Nodes or with
external as-a-service providers (e.g., email, database,
messaging, etc.).
• 어플리케이션에 서비스를 제공하거나 어플리케이션과 결
합할 때 서비스 인스턴스를 제공
• Advertising service catalog.
• Makes create/delete/bind/ unbind calls to
service nodes.
• Requests inventory of existing instances and
bindings from cloud controller for caching,
orphan management.
• SaaS marketplace gateway.
• Implemented as HTTP enpoint, written in any
language.
BuildPacks* • Buildpacks are Ruby scripts that detect application
runtimes/frameworks/plugins, compile the source
code into executable binaries, and release the app to
an assigned DEA.
• Runtime components can be cached for faster
execution of subsequent app pushes.
• Staging*
 /bin/detect
 /bin/compile
 /bin/release
• Configuredroplet
 Runtime (Ruby/Java/Node/ Python)
 Container (Tomcat/Liberty/ Jetty)
 Application (.WAR, .rb, .js, .py)
UPSI • User Provided Service Instances (이전의 “Service
Connectors”)
• CF가 자신이 관리하지 않는 로컬 서비스(예, Oracle DB,
DB2, SQL Server 등)에 접속할 수 있도록 Service
Broker에 메타 데이터 저장
• Metadata management
26

27. A
u
s
t
i
n
C
l
o
u
d
F
o
u
n
d
r
y
P
a
a
S
M
e
e
t
u
p
2
/
2
4
/
1
5
Component How It Works Responsible for
NATS Message Bus • a lightweight publish-subscribe and distributed
queueing messaging system, for internal
communication between components.
• 내부 컴포컨트들간의 통신
Metrics Collector • 각 컴포넌트에서 측정지표와 통계치를 취합
 CF 배포 사항 모니터링
Loggregator
(Log aggregator)
• streams application logs to developers • 로그 수집
(*)Cloud Foundry Buildpacks are compatible with Heroku 27

29. The platform for the agile enterprise
•
•
•
•
•
•
•
HPE Helion Stackato
29

30. HPE Helion의 Values와 Strategy
Consistency
Confidence
Choice
“The right solution for your cloud journey”
• Common platform across hybrid environment
• Best-in-class portfolio of solutions & services
“A trusted partner who knows your business”
• Enterprise & open source heritage
• One hand to shake – HPE One Stop Shop
• Recognized leader in hybrid cloud
“The cloud your way”
• No vendor lock-in, open, standards-based
• Multiple delivery models
• Heterogeneous
Open
Enterprise
grade
Hybrid
30

31. HPE Helion의 portfolio
31

32. HPE Helion Stackato 이전의 어플리케이션 배포
Development
IT/Ops
Staging
Testing
Production
32

33. HPE Helion Stackato 이후의 어플리케이션 배포
33

34. How it works: HPE Helion Stackato Architecture
HPE Helion Stackato
34

35. HPE Helion Stackato – Cloud Foundry™
HPE Helion Development Platform: Architecture v2.0
35

36. HPE Helion Stackato
다음과 같은 5개의 플랫폼 서비스로 구성됨
1. Helion Control Plane (HCP): The underlying core Platform
Service that HPE Helion Stackato uses to manage service lifecycles
and communicate with the underlying cloud Providers ( IaaS ).
2. Helion Service Manager (HSM): A service that provides
repository of services that can be used by applications.
3. Helion Cloud Foundry (HCF): A Cloud Foundry certified elastic
runtime that simplifies cloud native application development and
hosting.
4. Helion Code Engine (HCE): A continuous delivery service that
integrates with public or private Git repositories. HCE is a flexible
and extensible Continuous Integration/ Continuous Development
(CI/CD) pipeline.
5. HPE Helion Stackato Console (HSC): A web interface used to
manage HCF and HCE features.
Helion Control Plane
Stackato Web console
Code Engine Cloud
Foundry
Service Manager
Developer
Platform
Services
Admin
“HPE Helion Stackato is platform for deploying and hosting Cloud-Native
applications and managing application services.”
36

37. HPE Stackato : Control Plane
Helion Control Plane(HCP)
Stackato Web console(HSC)
Code Engine(HCE)
Cloud
Foundry
(HCF) Service Manager
(HSM)
Developer
Platform
Services
Admin
37
 currently a debian package.
 lays down the foundation on how Stackato talks to underlying
foundation on top of infrastructure. The way it talk to underlying IaaS is
through Terraform providers that we programmatically control. This
provides us ability to create and stand up environment. With that we
are running container host. Ubuntu 14.04
 once Ubuntu host is up, we bring up the service lifecycle manager that
manages life cycle of containers. The under-pinning is Kubernetes.
 Operator and customer do not see that and is abstracted away for
them.
 Everything that we host and run at the bottom layer is manifested
container and it is managed through Kubernetes

38. HPE Stackato CI/CD: Helion Code Engine
Helion Control Plane(HCP)
Stackato Web console(HSC)
Code Engine(HCE)
(CI/CD)
Cloud
Foundry
(HCF) Service Manager
(HSM)
Developer
Platform
Services
Admin
38
• Code Engine은 CI/CD pipeline
 changed the engine underneath – Concourse engine
 It is workflow engine – workflow of containers
 cool thing about – we support all the language that
are in cloud foundry
 implemented as build containers – adding
laungages/runtime

39. HPE Stackato CI/CD: Helion Code Engine

40. HPE Stackato Runtimes: Helion Cloud Foundry
Helion Control Plane(HCP)
Stackato Web console(HSC)
Code Engine(HCE)
(CI/CD)
Cloud
Foundry
(HCF) Service Manager
(HSM)
Developer
Platform
Services
Admin
40
DEVLOPE
MANAGE
RUN
• Stackato was derivative – first commercial
product to make enterprise grade
• Build with community or build as extension
 It provides standard capabilities that CF core
provides
 Polyglot environment based around buildpack
 Same buildpack structure shows up in code
engine as part of builder containers in
pipeline

41. HPE Stackato : Service Management
Helion Control Plane(HCP)
Stackato Web console(HSC)
Code Engine(HCE)
(CI/CD)
Cloud
Foundry
(HCF)
Universa
lService
Broker
Service Manager
(HSM)
HPESW services
Developer
Platform
Services
Admin
41
Universal Service Broker
Service Manager
Connect to

42. HPE Stackato : Web Console
Helion Control Plane(HCP)
Stackato Web console(HSC)
Code Engine(HCE)
(CI/CD)
Cloud
Foundry
(HCF) Service Manager
(HSM)
Developer
Platform
Services
Admin
42
Single user experience

43. Helion Stackato 구성요소 간의 Diagram
43

44. Helion Stackato Architecture
44

45. OPERATORS
DEVELOPERS
CUSTOMER’S
HPE’S

46. Cloud Foundry와의 차별성
HPE Helion Stackato은 관리자용 화면을 제공 – 어플리케이션의 배포와 관리를 쉽게 함
CF is command line only
HPE Helion Stackato는 Docker container 기술을 이용하여 어플리케이션을 실행(launch)
Additional application runtimes and services
Native .NET support, PHP, Python, Perl
가격정책 모델에 기술지원이 포함됨
World-class, global technical support available to help with deployment & configuration.
쉬운 설치와 설정(Easy setup & install)
100% BOSH free, so setting up & keep running HPE Helion Stackato is easy and fast
HPE Helion Stackato는 Cloud Foundry의 trunk version을 기반으로 함
HPE is committed to driving enterprise features back to the community (see our recent .NET support announcement).
48

47. Customer requests

48. Why HPE Helion Stackato?
50

49. 타 솔루션과의 차별점
Pivotal Cloud Foundry
• Lacks OpenStack support
Messaging and Database Services not supported on OpenStack, installing PCF on OpenStack requires proserv engagement
• More complicated installation technology than HPE
BOSH can take weeks to learn and be overly cumbersome for admins, HP uses python fabric scripts which are hidden behind a simple wizard
• Licenses are very expensive, compare with HPE Helion TCO
Pivotal counts number of app instances/containers per deployment, starting price is $250k*
IBM Bluemix
• Despite many services being available, most have “beta, do not use for production” label
For enterprises, this means they’ll need to role their own backing services if using Bluemix
• No real on-premises offering – Bluemix Local still a paper product
Outside of VMDK images that run on VMware, pro-serv required
• Bluemix Local does not include majority of services available w/ Bluemix public cloud offering
Enterprises needing apps to run on-premises will need to roll their own
RedHat OpenShift
• Lacks community momentum as an open source project, driven by RedHat only
• Leave lifecycle management of backing services like DBaaS and MSGaaS to cloud operators, increasing TCO

51. [첨부#1] Next Generation IT Infrastructure
<출처> http://tentenet.net/2013/05/29/the-5th-tenet-of-open-hybrid-cloud-start-with-an-iaas-private-cloud/
53
Management
PaaS
Business / Consumer
IaaS
Cloud Brokering
Physical Resources
Virtual Resources
Public Cloud
Resources
Public Cloud
Resources
Public Cloud
Resources

52. [첨부#2] Cloud Foundry Foundation
Mission :
• to establish and sustain Cloud Foundry as the global industry standard open source PaaS technology
with a thriving ecosystem.
• To deliver continuous quality, value and innovation to users, operators and providers of Cloud
Foundry technology.
• To provide a vibrant agile experience for the community's contributors that delivers the highest quality
cloud-native applications and software, at high velocity with global scale.
Its guiding principles are:
• Governance By Contribution - Influence within the Foundation is based on contributions.
• IP Hygiene - IP cleanliness must be preserved at all times.
• Equal Opportunity To Participate - Everyone has an equal opportunity to participate in projects.
• No Surprises - Planning processes and project status are open to all.
54

53. [첨부#3] Cloud Foundry의 아키텍처 4.0 – Diego Architecture
 an open source, multi cloud
application platform as a
service (PaaS) governed by
the Cloud Foundry
Foundation
 다음과 같은 기능 영역으로
구성
 Routing
 Authentication
 Application Lifecycle
 Application Storage & Execution
 Services
 Messaging
 Metrics & Logging
55

54. [첨부#3]
A
u
s
t
i
n
C
l
o
u
d
F
o
u
n
d
r
y
P
a
a
S
M
e
e
t
u
p
2
/
2
4
/
1
5
Component How It Works Responsible for
Router • 모든 외부 시스템 트래픽(HTTP/API)과 인터넷/인트라넷
에서 들어오는 어플리케이션 트래픽을 Cloud Controller
나 Diego Cell에서 실행되는 어플리케이션에 배분
• 어플리케이션이 실행되는 cell과 container를 확인하기 위
해 주기적으로 BBS를 쿼리  각 cell의 VM의 IP 주소와
cell container의 host-side port 번호를 가지고 라우팅 테이
블 갱신
• Load balancing
• Maintaining an active routing table
• Access logs
• Supports web-sockets
Cloud Controller • The Cloud Controller maintains command and control
systems, including interface with clients (CLI, Web UI,
Spring STS), account and provisioning control.
• It also provides RESTful interface to domain objects
(apps, services, organizations, spaces, service
instances, user roles, and more).
• Expected App state, state transitions, and
desired convergence
• Permissions/Auth Orgs/Spaces/ Users
• Services management
• App placement & deployment
• Auditing/Journaling and billing events
• orgs, spaces, user roles, service 등의 기록
Diego Brain • 개별 Diego Cell을 조정하여 어플리케이션을 실행
• 어플리케이션을 CF에 등록하려면 먼저 CC를 목표로 하
고, CC는 CC-Bridge를 통해 Diego Brain에 어플리케이
션 실행을 통제
• 어플리케이션 실행
Garden • Low-level manager and API protocol on each VM for
creating, configuring, destroying, monitoring, and
addressing application containers
56

55. [첨부#3]
A
u
s
t
i
n
C
l
o
u
d
F
o
u
n
d
r
y
P
a
a
S
M
e
e
t
u
p
2
/
2
4
/
1
5
Component How It Works Responsible for
UAA & Login Servers • ID 관리 : ID, 보안, 권한부여 서비스
• party Oauth 관리
• 구성 항목 : UAA Server, Command Line Interface,
Library.
• Token Server
• ID Server (User management)
• OAuth Scopes (Groups) and SCIM
• Login Server
 UAA Database
 VMware SSO Appliance를 사용하여 SAML과
Active Directory 지원
• Access auditing
nsync, BBS, Cell Rep • 어플리케이션 실행 상태를 유지하기 위해 함께
연결되어 작동
• 한쪽 끝은 사용자고 다른 한쪽 끝은 분산된 VM에서
실행되는 어플리케이션 인스턴스
• nsync 어플리케이션 확장시 CC에서 메시지를
받아서 Diego BBS db에 인스턴수 개수 기록
• BBS : 컨버전스 프로세스를 사용하여 모니터링,
어플리케이션 인스턴스를 실행 또는 종료
• Cell Rep 컨테이너 모니터링
Blobstore • 대용량 binary 파일 저장소
• 내부 서버나 외부의 S3 등에도 설정 가능
저장 대상 파일
• Application code packages
• Buildpacks
• Droplets
Diego Cell • 앱 상태와 기타 데이터를 BBS와 Lggregator에 전달
• Diego CF 아키텍처 이전에는 DEA node가 VM에 올라 있는
어플리케이션과 컨테이너 관리
• 어플리케이션의 실행과 종료
• VM의 컨테이너 관리
Loggregator
(Log aggregator)
• streams application logs to developers
57

56. [첨부#3]
A
u
s
t
i
n
C
l
o
u
d
F
o
u
n
d
r
y
P
a
a
S
M
e
e
t
u
p
2
/
2
4
/
1
5
Component How It Works Responsible for
Service Broker • Service Brokers provide an interface for native and
external 3rd party services.
• Service processes run on Service Nodes or with
external as-a-service providers (e.g., email, database,
messaging, etc.).
• 어플리케이션에 서비스를 제공하거나 어플리케이션과 결
합할 때 서비스 인스턴스를 제공
• Advertising service catalog.
• Makes create/delete/bind/ unbind calls to
service nodes.
• Requests inventory of existing instances and
bindings from cloud controller for caching,
orphan management.
• SaaS marketplace gateway.
• Implemented as HTTP enpoint, written in any
language.
Consul and BBS VM은 HTTP나 HTTPS를 통해 서로 통신하고, 임시 메시지를
공유하고, 아래 두 군데에 데이터를 저장
• Consul server : 오래가는 제어 데이터 저장(컴포넌트의 IP
주소나 distributed locks 등)
• BBS : 자주 변경되거나 한 번 사용하고 버리는 데이터
저장(예, cell과 어플리케이션 상태, 할당되지 않은 작업,
확인 메시지 등) 또는 MySQL에 있는 데이터 저장
route-emitter는 NATS 프로토콜을 사용하여 최신 라우팅
테이블을 router에 전달(※ Diego 이전의 CF 아키텍처에서는
NATS Message Bus가 모든 내부 통신 수행)
• Non-Persistent messaging
• Pub/Sub
• Queues (app events)
• Directed messages (INBOX)
• 데이터 저장
Metrics Collector • 각 컴포넌트에서 측정지표와 통계치를 취합  CF 배포 사
항 모니터링
58

57. [첨부#4] DEA / Diego Differences Summary
DEA architecture Diego architecture Function Δ notes
Ruby Go Source code language
DEA Diego Brain
High-level coordinator that allocates processes to
containers in application VMs and keeps them
running
DEA is part of the Cloud Controller. Diego
is outside the Cloud Controller.
DEA Node Diego Cell
Mid-level manager on each VM that runs apps as
directed and communicates “heartbeat”,
application status and container location, and
other messages
Runs on each VM that hosts apps, as
opposed to special-purpose component
VMs.
Warden Garden
Low-level manager and API protocol on each VM
for creating, configuring, destroying, monitoring,
and addressing application containers
Warden is Linux-only. Garden uses
platform-specific Garden-backends to run
on multiple OS.
DEA Placement
Algorithm
Diego Auction 프로세스를 VM에 할당하는 알고리즘
Diego Auction distinguishes between Task
and Long-Running Process (LRP) job types
Health Manager
(HM9000)
nSync, BBS, and Cell
Reps
System that monitors application instances and
keeps instance counts in sync with the number that
should be running
nSync syncs between Cloud Controller and
Diego, BBS syncs within Diego, and Cell
Reps sync between cells and the Diego
BBS.
NATS Message Bus
Bulletin Board System
(BBS) and Consul via
http/s, and NATS
내부 컴포넌트 간의 통신
BBS stores most runtime data; Consul
stores control data.
59

58. [첨부#5] Customer Use Cases
Developer use cases
• on demand access to resources they need to develop application using programming languages they are familiar with
• use an integrated CI/CD system (Helion Code Engine) to ensure application quality and rapid deployment
• deploy cloud native applications natively or via Docker containers (source code, binary or container)
• create and manage cloud native applications via a single integrated experience
• extend cloud native apps with integrated platform services, HPE SW services, and third party services or existing enterprise
services
• use tools, extensions and CLIs to enhance the development experience
IT Operations use cases
• the HPE Helion Stackato solution is a cloud app platform that helps IT operations meet the requirements of resiliency and SLAs;
the platform can run in private cloud environments, which helps IT meet regulatory requirements that would otherwise stop
developers to deploying to infrastructures such as AWS
• manage HPE Helion Stackato service lifecycles (e.g. user management, monitoring, update, etc.)
• seamlessly update and manage HPE Helion Stackato
• The Universal Service Broker makes it simpler to connect and manage applications deployed across many infrastructures
HPE Private & Confidential 60

59. • Deploy new cloud-native apps on HPE Helion Stackato & get the benefits of elasticity, resource
utilization, developer & deployment experience. Use HPE Helion Stackato to address apps that are
customer facing, with reqs in flux, utilization patterns are variable, need to span multiple platforms &
form factors - such as marketing websites, mobile apps, web apps, etc.
• Deploy on any cloud – customers searching for business agility & the flexibility to deploy on any
infrastructure with a consistent experience for developers can purchase HPE Helion Stackato, and
deploy your applications on any infrastructure as a service (AWS, Azure, VMware, etc.). This enables IT
to be flexible around business/cost needs, while still maintaining visibility & compliance.
• Deploy applications that connect to traditional/legacy systems – we help enterprises merge the old and
new by enabling connections to traditional databases or services, in addition to access to the latest
technologies for developing applications.
HPE Private & Confidential
[첨부#5] Customer Use Cases
61