Pivotal은 개발자 생산성을 높이고 운영비용을 줄이면서 성공적인 비지니스를 할 수 있도록 개발 환경의 혁신 문화와 플랫폼을 제공하고 있습니다. 본 세션에서는 플랫폼의 구조와 효과에 대해 소개하며 기업이 진정한 기술선도 업체로 발전해 갈 수 있도록 혁신적은 플랫폼 *PAS, *PKS를 소개합니다. *PAS: Pivotal Application Service로 개발자에게 기능 구현 속도를 높이고, 운영 팀은 세계 최고 수준의 가용성을 제공해주는 서비스입니다. *PKS: Pivotal Container Service로 Kubernates의 배포, 관리, 모니터링, 업데이트 등을 자동화하고 Pivotal에서 관리해주는 서비스입니다

1. © Copyright 2018 Pivotal Software, Inc. All rights Reserved. Version 1.0
March 6th 2019
Platforms (PAS and PKS)

2. 개발자 중심의 실리콘 밸리 기업인 Pivotal은 소프트웨어 개발 중심의 1) 문화/프로세스, 2) 기술
플랫폼, 3) DevOps 툴 및 4) 데이터 분석에 대한 Offering을 제공하고 있음
5조원 21 +2,500
시가총액 글로벌 오피스 개발자
2/3 이상의..
Pivotal Overview
Fortune 100 회사가 Pivotal과 함께 일하고 있습니다.
7 of the largest banks / payments
9 of the largest automakers
7 of the largest insurers
8 of the largest retailers
9 of the largest telcos
Pivotal Customers
Process &
Culture
Build for
change
DevOps Tools
Continuously
Improve
Platform
Any App, Every Cloud, One
Platform
Pivotal Cloud
Foundry
Tracker / Spring / Concourse
Pivotal Labs
Data / AI
Apps
Open Source Based
Data
Pivotal Big
Data Suites
Customer
Insight
Dojo
App tx
Pivotal
Data Science
vSphere
Azure &
Azure Stack
Google Cloud
AWS
Openstack
Clouds

3. 또한, Pivotal은 오픈소스에 중점적인 기여를 통해, 고객에게 개방적이고 다양한
선택을 제공하고 있음
“Pivotal is currently contributing as much software to
open source projects as IBM.”
Source: https://redmonk.com/jgovernor/2017/10/25/some-thoughts-on-the-top-contributors-to-github-2017/

4. Why Platform?

5. 하지만, 클라우드를 통해 개발팀의 속도를 극대화하는 것에는 한계가 나타나기 시작
함
개발팀 H/W
업무협의, 요건정의
견적, 발주, 도입, 설치, 변경
추상화 정도
IaaS
포털 UI 혹은 API 호출
On-demand VM, Network, Storage
Platform
개발자 용 API, 콘
솔
애플리케이션 동작
API
Platform
Team 개념

6. 개발 테스트/배포 운영
Pivotal Application Service
서비스제
공
피드백 제공 서비스제공피드백 제공 서비스제
공
피드백 제공
vSphere
Azure &
Azure
Stack
Google
CloudAWS
Opensta
ck
Dependency Marketplace MSA Config Pipeline Scaling
SLI/SLO
Monitoring
“D
evO
ps
Team
”
“Platform
Team
"
플랫폼이란, 개발자가 애플리케이션을 개발/배포/운영하기 위해 필요한 셀프서비스 툴을 제공
하며, 계속적으로 개발자의 피드백을 반영할 수 있어야 함
Pivotal Container Service

7. What others?
Consistent Experience Focus on Business Logic
Operation with small team Consistent Security

8. Tick
ets
이러한 플랫폼은 2008년 Netflix, Google 등과 같은 대형 IT 업체에서 시작하여, 2018년 현재
이미 주요 기업체가 도입하고 조직을 운영 중
2008년 2018년

9. 가장 성공적인 예로는 Netflix의 플랫폼 팀이 있음

10. Containers

11. What are containers?
Linux Operating
System
P P P P P
namespaces /
cgroups
Running Container
Container Image From JAVA
…
dependencies
…
RUN helloworld
Docker Engine Image
runs here

12. Containers vs Virtual Machines
Containers
Shared Operating System
Small Image Footprint, (MB)
● Quick start times
Stateless
● Easily transportable
Virtual Machine
Separate Operating System
Large Image Footprint, (GB)
● Full boots
● Stateful
● Not easily portable,
(exports/conversions/etc)

13. Why Container Orchestration?
Container solved some problems, but others were
still there...
How do I provision the hosts my containers will run on?
How can I automate my application?
● How can I scale out my application?
● How can I add layers of high availability?
● How do I expose my applications to the world?
● How do I easily run many containers together acting as a single
application?

14. Platform Evolution

15. Container
Orchestrator
Container Scheduling
Primitives for Network,
Routing, Logs & Metrics
CONTAINER
Developer
Provides
Tool
Provides
Application
Platform
APPLICATION
Container Orchestrator
Serverless
Functions
FUNCTION
Container Orchestrator
IaaS
Container Image & build
L7 Network & Routing
Logs, Metrics, Monitoring
Services Marketplace
Team, Quotas & Usage
Function execution
Function scaling
Event stream bindings
Choose the right tool for the job

16. Hardware
IaaS
CaaS
(Kubernetes, PKS)
PaaS
(Cloud Foundry,
PAS)
FaaS
(KNative, PFS)
더 높은 유연성과
선택의 가능성,
하지만 낮은 규격
화
낮은 개발 복잡성과
높은 운영 효율성
ALL or Nothing 이 아닌 니즈에 맞게 선택하여 사용하는 것이 필요

17. Embedded OS
(Windows & Linux)
NSX-T
CPI (15 methods)
v1
v2
v3
...
CVEs
Product Updates Java | .NET | NodeJS
Pivotal Application
Service (PAS)
Application Code & Frameworks
Buildpacks | Spring Boot |
Spring Cloud | Steeltoe
Pivotal Container
Service (PKS)
> cf push> kubectl run
vSphere
Azure &
Azure StackGoogle CloudAWSOpenstack
Pivotal
Network
“3Rs”
Github
Concourse
Concourse
Pivotal Services
Marketplace
Pivotal and
Partner Products
Continuous
delivery
Public Cloud
Services
Customer
Managed
Services
OpenServiceBrokerAPI
Repair
— CVEs
Repave Rotate
— Credhub
YOU build the container WE build the container
Elastic | Packaged Software | Spark
Pivotal Function
Service (PFS)
> riff function create

18. Cloud Foundry or and K8S

19. Deployment
Pivotal Container
Service (PKS)
> kubectl run
Elastic | Packaged Software | SparkJava | .NET | NodeJS
Pivotal Application
Service (PAS)
Application Code & Frameworks
Buildpacks | Spring Boot |
Spring Cloud | Steeltoe
> cf push
Clone/Tag Push
Analysis/QualityGates
Push Image
(Vulnerability-clair)
Source
Repository
정적 분석
Build output 관리
테스트
Perform
ance Test
Container Registry CI Server Master /
Slave
Source or Binary Container images
CI/CD pipelines managed by Developers
Image Build at Runtime (Auto)
Image Build at Pipeline (Manual)
Platforms

20. Buildpacks - Environment Consistency & Security at Scale
Platform buildpacks
provide standard runtime*
Platform provides fixed
OS container image
Developer brings
customized app
Developer brings runtime
container image
Developer brings
container OS image
Developer brings
customized app
Buildpack Docker Image
* Devs may bring a custom buildpack
Platform provides fixed
host OS Kernel
Platform provides fixed
host OS Kernel
*App container
Image

21. Container Image & Build
App (Your Biz
Code)
App dependent Libs
App Runtime (Tomcat)
RootFS (Container)
Virtual Machine
App (Your Biz
Code)
App dependent Libs
App Runtime (Tomcat)
RootFS (Container)
Virtual Machine
Pivotal Cloud Foundry Hosted K8s (ex: AKS)
Pivotal Hosted K8sCustomer Customer
Container Orchestrator Container Orchestrator
10’s - 100’s of scaffolding pipelines
… That need to be maintained weekly/monthly!
BOSH + Buildpacks

22. Complexity of Optionality - It’s not “Just a pipeline”
Alpine (n-2)
Linux
IIS
App (Your Biz
Code)
App
Dependent
Libs
RootFS (Container)
Virtual Machine
Hosted K8sCustomer
Container Orchestrator
Windows
Ubuntu (n-2)Windows (n-2)
CoreCLR/Kestrel (n-2) Java/Tomcat (n-2) Node (n-2) ...
Spring.NET Core Node.js/Express
.NET Framework

23. PaaS CaaS

24. Sample Use Case
BOSH
Other
Broker
Services
Platform Services
Logging Metrics Monitoring
VMware GCP Azure Openstack AWS
Spring Boot App
PKSController
Harbor
NSX-T
Kubernetes
K8s Cluster
K8s Cluster
Spring Boot App
Elastic Search
Pivotal Application Service (PAS) Pivotal Container Service (PKS)

25. HA-Proxy
PAS PKS
VxRail
vSphere
Console
Ops ManagerBOSH Director
AD
DNS / NTP
Log Insight vROps
Router
ControlControl
Control
(3 nodes)
Diego Cell
(7 nodes)
Diego Cell
(7 nodes)
Diego Cell
(7 nodes)
PCF Metrics Healthwatch
Pivotal
Cloud Cache
Spring Cloud
Service
PKS API Server
Harbor
(Docker Registry)
ControlControl
Control DB
(3 nodes)
Router
(2 nodes)
Load Balancer
Pivotal / VMware
Product
3rd Party Product
Bazaar/
Kibosh
Infrastructure Domains and IP Addresses
K8S
Master
K8S Clusters #1
K8S
Master
K8S
Master
(3 nodes)
K8S
Master
K8S
Master
K8S
Worker
(5 nodes)
Concourse
(CI/CD)
Greenplum
Web/WAS
Test Database
Cache
Monitoring
Agents
In-Memory DB
Loggregator

26. PAS (Cloud Foundry)

27. manifest 파일
(빌드팩 버전,
메모리 사이즈,
인스턴스 등 설정)
App Code
+
CF 컨트롤러
App
Code
OS, WAS, Libs
컨테이너
이미지 빌드
컨테이너 배치
로드밸런서 할당 및 라우팅 등록
cf push 실행
개발자
애플리케이션
유저
빌드팩
작업
빌드팩 개념
• 언어 별 표준이 되는 Middleware, 라
이브러리, JVM 등의 저장소
• 중앙 플랫폼 팀에서의 표준화 작업등
에 용이하게 사용
• JEUS, 웹투비 등 사용을 위한 빌드팩
생성도 가능
플랫폼 내에서 런타임에 자동으로 컨테이너 이미지를 생성함
환경변수, 로그, 모니터
링 설정
runtime layer*
Guest OS image
Application layer
linux host OS &
kernel
OS Layer
언어별
Runtime
Framework 영
역
개발자
어플리케이션
영역
~45초

28. * 빌드팩 (미들웨어, 라이브러리, OS Dependency의 문제로 부터 해방)
* cf push 를 통해 물리적인 VM할당에서부터 방화벽, LB 설정까지 One-Stop 으로 앱 구동
cf push
~ 45 seconds ~ 15+ Days
가용한 호스트 찾기
OS 설치 및 구성
미들웨어 설치 및 구성
애플리케이션 소스 코드 복사
종속 라이브러리 검색
애플리케이션 패키지 생성
연관 서비스들 설치 및 구성
컨테이너를 호스트에 배포
환경 변수 설정
로드발란서 구성
방화벽 구성
서비스 모니터링 도구 갱신
로그 수집기 구성
2 Days
1 Day
1 Day
¼ Day
¼ Day
¼ Day
2 Days
½ Day
¼ Day
2 Days
2 Days
3 Days
1 Day
코드 및 테스트 완료 후
Speed &
Consistency
…
운영환경 앱 배포까지
…

29. PKS (Kubernetes)

30. Pivotal Container Service (PKS): A Runtime for Containers
+
+
A turnkey solution to provision,
operate and manage enterprise
grade Kubernetes clusters
Pure CNCF-Certified Kubernetes Dial Tone:
• Health management
• Aggregated metrics and logging
• Autoscaling
• Persistence interface
BOSH Control Plane:
• Provisioning engine
• Multiple T-shirt sized clusters
• Self-service clusters
• Software update automation
• Load balancing
• Networking
• Multi-tenancy

31. > kubectl
Load Balancing / Routing
Storage NetworkingCompute
Kubernetes Dashboard
Container Image
Registry
App Monitoring
App Logging
OS Updates
OS Images
K8S Updates
K8S Images
Log & Monitor
Recover & Restart
Backup & Restore
External
Data Services
Cluster
Provisioning
Provision & Scale
Command Line
/ API
Management
GUI
Monitoring GUI
Dev / Apps
App User
IT / Platform Ops
OSS Kubernetes 위에 “Production” 환경이 요구하는 고가용성 / 장애복구 / 보안
/ 모니터링 등의 기능이 추가되어야 함
이미지& 모니터링
인프라/OS/VM 클러스터 확장/할당/복구/업데이트
외부 데이터 서비스 연동
운영 Console/자동화

32. > kubectl
Kubernetes Dashboard
vRealize Ops
PKS Control Plane
GCP Service
Broker
> pks
Operations
Manager
vRealize Operations
Dev / Apps
App User
IT / Platform Ops
이미지& 모니터링
인프라/OS/VM
외부 데이터 서비스 연동
운영 Console/자동화
PKS는 Production-Ready 환경을 위한 필수적인 서비스를 제공하기 시작함
클러스터 확장/할당/복구/업데이트

33. PAS Features

34. *지원하는 언어 및 Middleware

35. Marketplaces

36. Mobile Networking
Storage
BPM
App Integration
DevOps Tooling
Data
Management
Microservices
Management
CRM
CommerceIAMIDE/CodeOther
APM/Monitoring
Search
Security
SIEM/Log/Audit
API Gateways
Messaging
IaaS
* PCF 상에서 지원하는 3rd party 서비스들 (Marketplace)

37. Deployment

38. Rolling Deployments Minimize Risk
Fail Fast
A/B Test Competing Ideas
Quick Rollbacks
Make Releases Non-Events
A & B Testing Blue-Green Canary
* 다양한 방식의 One-Click 배포 방식 지원 (API 지원으로 다양한 CD 툴과 연계)
1. ARCHIVE V1
2. DEPLOY V2
3. URL ROUTE V2
4. URL UN-ROUTE V1
5. DELETE V1
1 DEPLOY V2
2 UAT V2
3 {ROLLOUT} SCALE V2 |
{ROLLBACK} DEBUG V2
4 URL UN-ROUTE V1
5 DELETE V1
1. DEPLOY A | DEPLOY B
2. URL ROUTE A | URL ROUTE B
3. ANALYZE METRICS
Deployment

39. Microservices

40. Circuit Breaker
Dashboard for PCF
마이크로서비스나
애플리케이션 내부의
회로 차단기에서
Turbine 상태 및
메트릭 데이터스트림을
시각화
Service Registry for
PCF
NetflixOSS Eureka
Service Discovery
패턴의 구현을 서비스로
제공
Config Server for
PCF
전 환경에 걸쳐
애플리케이션의
외부 프로퍼티를
관리하는
동적 중앙 설정 서비스
제공
Zipkin
앱 로그에 Zipkin 헤더가
기본적으로 추가되어
있으며, “cf logs”를
사용하여
앱 간 로그 추적 가능
MSA 서비스의 운영에 필수적인 Config, 레지스트리, 서킷 브레이커, 분산 트레이싱 등을
담당하는 기본 컴포넌트의 운영 역량이 필요함

41. Spring Boot

42. Spring Boot +
App Runtime
PCF 와 Spring Boot의 최적의 결합 Spring Boot
Effortless dependency management
Embedded App Server
Creates self-contained apps
that “just run”
Pivotal Application Service
Generates a container from a jar
Instantly starts the app in a container
upon cf push
Adds environment properties
마이크로 서비스 지원 | NetflixOSS | 액추에이터 통합 | Metrics & Logging

43. Monitoring

44. * 실시간 로그, 모니터링
*분산 트랜잭션 모니터링

45. Scaling

46. * 즉시적인 스케일 업 및 스케일 아웃

47. 더 빠른 시간에 급증하는 트래픽에 대응하고, 이를 통해 안정적인 Response Time을 유지할 수
있음
Traffic Pattern Compute Resources Response Time
t t t
+
t t t
msInstance
count
Traffic
msInstance
count
Traffic
t1
t1
1,000ms
200ms

48. Auto Recovery

49. 특히, 항상 애플리케이션, 프로세스, VM, 가용존에 걸친 4단계 고가용성에 대해 인지해야
하며, 이는 최대한 자동화를 통해 개발 생산성에 영향을 주지 않아야 함
If an app fails, PCF
reboots app in a new
container.
App Fail Process Fail
PAS
A B C
B
1. 2.
If a process fails, PCF
restarts the process
PAS
A B C
Process
AZ Fail
If a datacenter rack fails,
PCF ensures applications
stay running in multiple
availability zones
4.
Zone 2
A B C
B
A B C
B
A B C
B
A B C
B
Zone 1
A B C
B
A B C
B
A B C
B
A B C
BVM1 VM2
3. Resurrector
restarts failed
VMs
VM Fail
PAS
A B C
VM1 VM2
OS,
Mware
If an OS or network
failure occurs PCF kills
the VM and reboots the
host in a new Virtual
machine.
3.
VM3
OS,
Mware
OS,
Mware

50. Patch & Upgrade

51. * 플랫폼 자체를 계속적으로 CI/CD를 통해 무중단 OS 및 패치(CVE) 업그레이드

52. Platform Monitoring

53. *플랫폼 Admin을 위한 운영 Metric 및 배포 현황 대시보드 지원

54. Health Watch 3rd
Party 연동 (Datadog, Splunk, ELK) Apps Manager
PCF에서 제공하는 다양한 옵션의 모니터링
”서비스 메트릭, 개발자 메트릭,
플랫폼 메트릭으로 나누어 한 곳에서
대시보드 형태로 관리할 수 있음”
”Custom Dashboard형태로
구성하여 Alert 등을 구성 가능”
＂기본적인 App과 컨테이너 단위의
모니터링이 가능”

55. Automation

56. vSphere Openstack AWS
Google
Cloud
Azure &
Azure Stack
Shared Services
Shared Security
Shared Networking
Logging & Metrics / Services Brokers / API Management
Credhub / UAA / Single Sign On
VMware NSX
Embedded Operating System (Windows / Linux)
Application Code & Frameworks
Buildpacks / Spring Boot / Spring Cloud / Steeltoe
PAS
Pivotal Application
Service
PKS
Pivotal Container
Service
PFS
Pivotal Function
Service
Pivotal Services
Marketplace
Pivotal and
Partner Products
Concourse
*하이브리드/멀티 클라우드를 위한 하나의 플랫폼
• 임베디드 OS 탑재 패키징
• 모든 IaaS 상의 서버 프로비저닝
• 가용 존간 소프트웨어 배포
• 상태 모니터링 (서버 및 프로세스)
• 서비스 상태 모니터링
• Resurrector를 이용한 자기 치유
기능
• 스토리지 관리
• 카나리를 통한 롤링 업그레이드

57. Platform DOJO

58. Platform Dojo Team:
고객사
TEAM
Product
Manager
Platform
Reliability
Engineer
Product
Manager
PCFS
Architect /
PRE
Platform
Reliability
Engineer
PCFS
Architect /
PRE피보탈/Dell
TEAM
플랫폼을 하나의 “제품”으로 바라보고, 플랫폼을 사용하는 고객(개발자)의 니즈를 끊임없이 반영
* Platform Dojo : 조직 내 확산, 프로모션, 교육을 추진하는 Dedicated 팀으로 발전

59. © Copyright 2018 Pivotal Software, Inc. All rights Reserved. Version 1.0
March 6th 2019
Services (DOJO, App Tx, Labs)

60. Iteration Driven Innovation을 위한 Key Questions
DevOps
Cloud Native
App
Org
/Process
Iteration
Driven
Innovation
코딩 시간 어떻게 늘리지?
언제든 배포하기?
운영은 누가하지?
팀 Balance 어떻게?
소통의 방식은?
방법론은?
왜 Cloud Native?
마이크로 서비스?
어떻게 시작하지?

61. Platform Dojo

62. Balanced Platform Team
원칙에 기반한 “Platform as Product”의 실현을 위해 “Balanced Platform Team”이 반드시 필요함
”운영 안정성의
희생을
최소화하고
동시에 변경
빈도를 높일 수
있을까?”
Key Questions
자율성과 선택의 존중
(Independency, Polyglot)
+
DevO
ps
Team
원칙에 기반한 개발/운영 환경 제공
(Platform as a Product)
Platform
Team
(SRE)

63. Pivotal Platform Dojo
Platform Dojo Team:
고객
TEAM
Product
Manager
Platform
Reliability
Engineer
Product
Manager
PCFS
Architect /
PRE
Platform
Reliability
Engineer
PCFS
Architect /
PRE피보탈
TEAM
The Balanced Platform Team
플랫폼 브랜딩
교육 및 내부 전파
셀프 서비스 기능 구현
3rd Party 연동
공통 플랫폼 서비스 구현
수요부서 니즈 파악
PlatformasProduct
PivotalO
ffering

64. 구글의 SRE팀
개발
+
API를 이용한 셀프서비스
자동화
(34%)
새로운 플랫폼
기능 요소 개발
(33%)
Toil
(33%)
예) MySQL, RabbitmQ 설치
플랫폼 요소 업그레이드
플랫폼 자체의 업그레이드
스크립트 지양
매일매일 똑같이 하는 일들..
SRE 팀
In SRE, we want to spend time on long-term engineering project work instead of operational work.
Because the term operational work may be misinterpreted, we use a specific word: toil.
개발팀
플랫폼 팀으로 별도 분리 가능
특히, 구글에서는 이러한 방향을 구체적으로 실천하기 위해 SRE팀을 운영하고 있음

65. Tickets
Self Service!!!
넷플릭스 플랫폼 팀

66. 넷플릭스 플랫폼 팀

67. App Tx

68. 클라우드 네이티브 앱의 출현
기존
모놀리틱
App
(Big Java,
Big DB)
Iteration
Driven
Innovation
클라우드
Scale
API
Immut
able
CI/CD
Image
Contai
ner
Event
Driven
Cache Open
source
Self Services (Good) ??

69. 모놀리틱 구조의 한계
D모듈 변경 시 A,B,C의 추가 테스트 필요
D모듈의 작은 변화도 전체 App의 배포를 요구
D모듈만 테스트하고는 릴리즈 할 수 없음
A,B,C,D모듈이 동시에 변경할 경우 엄청난 부가적인 작업이 필요
결론적으로 매우 느린 릴리즈 사이클이 형성
A 모듈이 집중적으로 많이 사용되는 경우에도
어쩔 수 없이 전체 App을 Scale 헤야 함
(메모리, Disk 등의 비효율성)
A 모듈이 문제가 생기면 장애가 나머지 모듈에도 영향을 줄 수 밖에
없음
모놀리틱 구조의 한계
B
A
D C
A
모듈
의존성 관계
Original
change
Overhead
synchronization
work
D모듈의변경A의Heat가
높을때..
기존 모놀리틱 앱 구조
클라우드 환경에 맞지 않는 모놀리틱 구조는 빠른 시장의 변화에 느리게 반응할 수 있음

70. 12 Factor App의 출현
Iteration
Driven
Innovation
클라우드
Scale
API
Immut
able
CI/CD
Image
Contai
ner
Event
Driven
Cache Open
source
Self Services
More
Freq
Updates
12 Factor
App
(클라우드
네이티브)
Config
Ext.
API/
Port
Log
Strea
m
Statele
ssCI/CD
Depen
dency
MSA
Servic
es Code
Base

71. 마이크로 서비스 아키텍처
71
C
F
B
G H
ED
A Microserv
ice
Microservice
Microserv
ice
Microserv
ice
Microserv
iceMicroserv
ice
Microservice
A
Microserv
iceMicroserv
ice
Microservice
B
C
Microserv
ice
Microservice
E
Microserv
iceMicroserv
ice
Microservice
D
Microserv
iceMicroserv
ice
Microservice
H
Microserv
ice
Microserv
ice
Microserv
ice
Microservice
G
Microserv
ice
Microservice
F
Interface
각각의 마이크로 서비스는
독립적으로 Scale-Out/In
First-in
First-out
(FIFO)
Queue
Publish-
Subscribe
(Pub-Sub)
Queue
Queues, Pub-Sub 등의
비동기성 큐를 통해
독립적으로 Auto-
Scale을 할 수 있는 환경
각각의 State
존재
약속된 API로
통신
더 나아가 Microservice 아키텍처를 통해 독립적인 팀의 의사결정을 극대화 할 수 있는 구조를 채택함

72. INVENTORY
Prod Release
Prod Release
Prod Release
CATALOG
Prod Release
Prod Release
Prod Release
REVIEWS
Prod Release
Prod Release
Prod Release
SHIPPING
Prod Release
Prod Release
Prod Release
더 나아가 Microservice 아키텍처를 통해 독립적인 팀의 의사결정을 극대화 할 수 있는 구조를 채택함
마이크로 서비스 아키텍처

73. Application Transformation
PivotalO
ffering
1
클라우드 네이티브로 전환해야
하는 5-10개 앱 선정 2
변환 프로젝트를 통해 피보탈과 함께 일하면서 몇
가지 앱을 전환하고 팀의 전문성을 키워 완성된
Cookbook 전달
App Tx (앱 트랜스포메이션) 서비스는 초기에 5-10개의 대상 앱을 선정하고, 6-10주의 기간동한 Pivotal과 함께
마이크로 서비스로 변환하는 프로젝트를 진행하게 됨
$$$$
Use ROI to Fund Cloud
Native Innovation
리플랫폼 모더나이즈 최적화
(People and Process)
Runs on PCF
마이크로 서비스 Application Transformation
Built for PCFRuns Well on PCF Runs Great on PCF
Cloud Native
New Software Initiatives

74. Event Storming
■ 모든 업무 도메인 전문가를 한 곳에 초빙해서,
도메인에서 발생하는 모든 Event를
오렌지 ”Sticky Note”로 나열
- 예) Order Submitted, Insurance Policy Rated
■ 목적: 그동안 서로 소통하지 않았던 사람들과
모여 소통의 장을 마련
■ 30명 넘는 인원이 한 장소에 모여서 워크샵
- 40% : 기술, 60%: 현업
Event Storming 과정을 통해 도메인을 Breakdown함

75. Business Domain Model
(2) Pick a Core Domain
(1) Bounded Context
실제 Bounded Context로 나뉜 부분 중 기술적 난이도와 사업적 영향도를 고려하여 하나의 Domain을 선택함

76. Cookbook
App Transformation의 결과로 다양한 패턴이 담긴 Cookbook(요리책)을 생성하며, 이를 향후 App
Transformation에 활용

77. Labs

78. Pivotal Labs

79. Pivotal Labs
San Francisco Atlanta Berlin Boston Boulder Chicago
Dallas Denver Dublin London Los Angeles New York
Paris Palo Alto Seattle Singapore Sydney Tokyo
“일반적인 컨설팅과는 차별화된 접근 방법론”

80. Pivotal Labs

81. 2 pizza teams
Team의 사이즈와 Decision Making Process의 효율성

82. Balanced Team
성공에 대한 기준
이러한 고객의 문제를
풀어줌으로서 우리는 정말
가치있는 사업적인 결과를 낼 수
있는가?
이런 것들을 어떻게 계속적으로
측정할 것인가?
디자이너
개발자
제품
매니저(PM)
Product
Ownership
Will users like this?
유저들이 정말
좋아할까?
Can we build this?
우리는 이것을
계속적으로 빌드할 수
있나?
Will this help the
business?
정말 우리 비즈니스에
어떤 도움이 될까?
고객을 위한 바람직한
방향성
고객이 진짜 가지고 있는
어려움이 무엇인가? 우리가 맞게
개선하고 있는가?
그 어려움을 어떻게 풀 수 있는가?
고객은 정말 이 애플리케이션을
사랑할 것인가?
실현가능성
이 프로젝트를 성공적으로
수행하기 위해 필요한 기술적인
복잡성은 무엇인가?
변화에 가장 능동적인 개발
문화와 방법론을 만들기 위해서
어떤 부분을 바꿔야 하는가?
신속한 의사결정을 위한 수평적인 팀의 구조 (닭과 돼지, 디자이너의 역할)

83. Lean
기존 워터폴 방식
애자일 방식
(배움의 연속)
기존의 워터폴 방식의 점차 증가하는 Risk 대비 애자일 방식의 Lean 방식은 계속적으로 Risk를 관리할 수 있는
장점이 있음

84. Principles over Policies
You Build It, You Run It
You Support It
(Principles over Policies)

85. Lean
1 Week
또한 1주일 간격의 “배움과 반영”의 반복을 통해 경쟁자보다 신속하게 고객이 원하는 방향의 기능을 구현할 수
있음

86. Pair Acitivities

87. Pair Activities
- 20%
+80%
Test
Coverage
>95%
More
Confidence
More
Frequent
Updates

88. Pair Acitivities
Pair
Rotate
Bus
Counts
(회복성)
집단
Ownership
Clear
Codes
(책임감)

89. Transforming How The World Builds Software
© Copyright 2018 Pivotal Software, Inc. All rights Reserved.