성공적인 서비스로의 플랫폼...
TRANSCRIPT
2017 년 성공적인 서비스를 위한 플랫폼의 선택
장진영([email protected])
우리회사 사내시스템보다 좋은 클라우드 도구들…
• 액티브 -X 없고• 항상 접속되고• 앱간 연동 되어있고• 전세계와 연결되어있고• 재미있고 귀엽고 쓰기 쉽고• 사용한 만큼만 지불
성공적인 서비스들
성공적 서비스로의 여정
Make Innovative App
• Multi-tenancy• Self-Serviced• Mashups
DevOps• Business Continuity• Zero-downtime
Micro ServiceArchitecture
• Separation of Concerns
Monetization• Subscription
Business
개발 운영 / 개선 수익
성공적 서비스로의 여정
Make Innovative App
• Multi-tenancy• Self-Serviced• Mashups
DevOps• Business Continuity• Zero-downtime
Micro ServiceArchitecture
• Separation of Concerns
Monetization• Subscription
Business
개발 운영 / 개선 수익
Creating Innovative Application: Develop or Mashup?
Machine Learning Voice-ware IoT
Not enough TIME!
Develop or Mashup?IBM Bluemix – Watson Micro Services
Develop or Mashup?IBM Bluemix – Using Watson Micro Services
Develop or Mashup?IBM Bluemix – Writing Voice Ware
Develop or Mashup?GE’s Predix – Micro Services for Developing Industrial Apps
Develop or Mashup?GE’s Predix – Developing Industrial Apps
태넌트 - 가입자 하나가 추가될 때 소요되는 자원이 적을 수록 , SaaS / 클라우드를 적용한 비즈니스 효과가 크다 .
Share more, More cheap offering, More Competitive in the market !
Share less, More easy & Secure !
Creating Innovative Application Multi-tenancy Support
SaaS Maturity Model
가입자 A 의 앱설정 가입자 B 의 앱설정
* 멀티태넌시 지원 기능은 금번 사업 범위에 비포함* 향후 현재 R&D 문서관리 등은 멀티태넌트 전환이 필요함
2. 도입기관별 입력 항목 변경
3. 도입기관별 판정로직 설정
1. 도입기관 브랜드 설정
Multi-tenancy Support
Metadata-based
앱 - 스토어
셀프 서비스
커스터마이징된 앱
취득
설정의 변경
가입자 A
가입자 B• 회사로고• 보안점검규칙
1. 가입 기관들은 원하는 앱을 앱스토어에서 취득2. 기관의 특색에 맞춤 설정하여 사용함
Multi-tenancy Support
Self Service
멀티태넌시 공통 아키텍처 - SPOSAD
Tenant-aware! Inject tenant-specific logics, workflows, brandTenant-specific
Store
Multi-tenancy Support
SPOSAD Architecture
Supporting Multi-tenancyForce.com: Multi-tenant Kernel
성공적 서비스로의 여정
Make Innovative App
• Multi-tenancy• Self-Serviced• Mashups
DevOps• Business Continuity• Zero-downtime
Micro ServiceArchitecture
• Separation of Concerns
Monetization• Subscription
Business
개발 운영 / 개선 수익
18
DevOps: IssuesContinuous Delivery
Company Deploy Frequency Deploy Lead Time Reliability Customer Responsive-ness
Amazon 23,000 / day Minutes High High
Google 5,500 / day Minutes High High
Netflix 500 / day Minutes High High
Facebook 1 / day Hours High High
Twitter 3 / week Hours High High
Typical enterprise Once every 9 months Months or quarters Low / Medium Low / Medium
출처 : 도서 The Phoenix Project
Amazon, Google, Netflix, Facebook, Twitter 는 얼마나 자주 배포할까요 ?
19
2. 배포 주기• 매일 마이너 업데이트• 메이저 업데이트 ( 매주 화요일 오후 )
3. Deployment Pipeline
출처 : http://ieeexplore.ieee.org/xpl/articleDetails.jsp?arnumber=6449236
Supporting Continuous Delivery
20
4. Canary 를 통해서 확신 갖기
• Canary 란 ? 실제 production 환경에서 small subset 에서 새로운 코드를 돌려보고 옛날 코드와 비교해서 새로운 코드가 어떻게 돌아가는 지 보는 것
• Canary 분석 작업 (HTTP status code, response time, 실행수 , load avg 등이 옛날 코드랑 새로운 코드랑 비교해서 어떻게 다른 지 확인하는 것 ) 은 1000개 이상의 metric 을 비교해서 100 점 만점에 점수를 주고 일정 점수일 경우만 배포할 수 있음 .
출처 : http://techblog.netflix.com/2013/08/deploying-netflix-api.html
Supporting Continuous Delivery
Netflix
CPU
MEM Disk
WAS
StorageService (e.g. S3)
Memory Service
(e.g. Redis)
MicroService
Architecture
Existing Enterprise Application HA architecture
wire network
Managing “SPOF (Single Point Of Failure)”
DevOps
Managing Single Point of Failure
Managing SPOF
Micro Services Architecture
출처 : 2010 architecting for the cloud (http://www.slideshare.net/simone.brunozzi/2010-architecting-for-the-cloud-4719195)
DevOps: Issues
Managing Scalability
Managing Scalability
Workload Distribution Engine
• IBM Bluemix
• Heroku
• GE’s Predix
• Pivotal Web Services
• Cloud Foundry
Container Workload Distribution Engine (OSS) PaaS
• Warden(Garden)
• Docker • Kubernetes
• Docker SWARM
• Mesos Marathon
• Google Compute Engine
• Redhat Open Shift
• Hypervisor • CF version 1
• Engineyard….
• Amazon Beanstalk
DevOps
DevOps Platforms
DevOps Platform
IBM Bluemix
성공적 서비스로의 여정
Make Innovative App
• Multi-tenancy• Self-Serviced• Mashups
DevOps• Business Continuity• Zero-downtime
Micro ServiceArchitecture
• Separation of Concerns
Monetization• Subscription
Business
개발 운영 / 개선 수익
Monolithic Architecture
모든 서비스가 한번에 재배포 한팀의 반영을 위하여 모든 팀이 대기 지속적 딜리버리가 어려워
Micro Service ArchitectureContract based, Polyglot Programming Separation of Concerns, Parallel Development, Easy Outsourcing
Written in Java
Written in Node
Written in PHP
Micro Service Architecture
• 변경된 서비스만 재배포 Side effect 최소화• 자율성 각 서비스에 대한 자유로운 언어 , 아키텍처 , 아웃소싱 용이 • 병렬 개발 , 타임 투 마켓 , 린 개발
Micro-Service Architecture Patterns microservices.io
API Gateway
(Human)Front-end
Service
Service
API G/W
Service
Service
We need API Gateway for aggregating, forwarding services and exposing composite APIs
Tenant-Specific Routing
(Machine)Third-party Apps
Billing
(Human)Front-end
ServiceService
API G/W
Service
Service
We need API Gateway for aggregating, forwarding services and exposing composite APIs
Tenant-Specific Billing
(Machine)Third-party Apps
Billing
IAM
(Human)Front-end
ServiceService
API G/W
Service
Service
Stateless 인증 , 통합빌링을 위한 IAM
Tenant Billing
(Machine)Third-party Apps
BillingIAM token provider
Design factors on developing cloud applications1.Don't code your application directly to a specific topology2.Do not assume the local file system is permanent3.Don't keep session state in your application4.Don't log to the file system5.Don't assume any specific infrastructure dependency6.Don't use infrastructure APIs from within your application7.Don't use obscure protocols8.Don't rely on OS-specific features9.Don't manually install your application
35
Micro Service Architecture
Design Factor for Front-end
One Page N-ScreenResponsive
DynamicReal-time
Front-end
Image Server(Python)
Business Logic Server
(Java)
Extended Role of Front-end in Cloud Applications
Aggregator for multiple (polyglot programmed) micro-services
Component Service
(C)
AJAX, RESTful
Concurrent Cloud Applications are composed of multiple Micro Services and front-end serves as an aggregator of the services
Writing One Page Web AppProblems: One Page Web App Low Cohesion and High Coupling
<style> style for A style for B style for C</style>
<html> element for A element for B element for C</html>
<script> script for A script for B script for C</script>
Polymer: Web Component FrameworkPolymer: W3C standard for Web Components
• Provides Cohesive Component Model• Component Composition by HTML markup• Dynamic Data Binding• Responsive Web by Material Design• Standard
• Google maintains it
Polymer: Web Component FrameworkPolymer: W3C standard for Web Components
<style> style for A style for B style for C</style>
<html> element for A element for B element for C</html>
<script> script for A script for B script for C</script>
#A.html<style> style for A</style>
<html> element for A</html>
<script> script for A</script>
#B.html<style> style for B</style>
<html> element for B</html>
<script> script for B</script>
#C.html<style> style for C</style>
<html> element for C</html>
<script> script for C</script>
#index.html<A> <A><B> <B> <B><C>
• Workload Distribution Engine - foundation• CF, Kubernetes, Docker Swarm – mentioned earlier
• API Gateway• APIGee• Kong• OCE Service Wrapper• Amazon Cognito
• IAM• Cloud Service Broker and Visual Mashups
• Jam Cracker• JackBe• OCE uEngine5• OCE Metaworks
Micro Service Architecture
Platforms for MSA
Platform for MSA
OCE API Gateway
Platform for MSA
OCE Metaworks Visual MashupMicro-service mashup tool and framework in visual way
Polymer-Java Mapping - MetaworksMetaworks: Polymer-Java Mapping by OCE
성공적 서비스로의 여정
Make Innovative App
• Multi-tenancy• Self-Serviced• Mashups
DevOps• Business Continuity• Zero-downtime
Micro ServiceArchitecture
• Separation of Concerns
Monetization• Subscription
Business
개발 운영 / 개선 수익
Subscription PricingMonetization Platform
SaaS Pricing practices
Leaders Mainstream Laggards
Pricing strategy • Pricing metrics are defined as perceived by the customers
• Pricing strategy is easy to understand, measure.
• Boundaries for usage, features, time, conversion from trial are clearly defined
• Pricing is ad hoc• Pricing is based on
internally-oriented metrics
• Difficult to convert trial and freemium to paid
• Leader 들은 고객 관점에서 가격을 책정 , 시장상황에 빠르게 가격 및 정책 개선• 후발기업들은 내부 비용에 초점 , 변경하지 않음
Zuora Aria
Hiveage ChargifyAnd more..
MonetizationPlatforms For Monetization
Monetization PlatformZuora - Billing Metering As A Service
Monetization PlatformZuora - Billing Metering As A Service
One-time Pricing Model• 가입시 한번• 기본료• 상품에 따라 무상 혹은 할인 가능
Recurring Pricing Model• 주기적으로 반복되어 과금• 한도를 넘어서면 제한 또는 추가 과금
Usage-based Pricing Model• 사용량에 비례하여 과금• 사용량이 늘어나면 할인 가능
Monetization PlatformZuora - Billing Metering As A Service
Monetization PlatformZuora - Billing Metering As A Service
Monetization PlatformOCE Billing – Open Source Billing Metering
Comparison Criteria• Runtime : 지원 언어 및 플랫폼 , 프레임워크 Polyglot Programming, MSA 가 가능한가
- extensible 인 경우 언어와 환경을 확장 가능• Scaling : 확장성 - Vertical - 실행중 인스턴스의 용량이 늘어남 , Horizontal - 인스턴스 개수가 늘어나 클러스터링 됨 - Auto - 자동으로 확장됨 , 지원이 안되는 경우 확장 필요시 API 를 직접 호출하거나 운영자가 수행함• Container - VM 기반인 경우 Scaling 의 속도가 느림 - Docker 인 경우 향후 표준성이 좋음• Hosting/Infrastructure - Public 만 지원하는 경우 Private Cloud 및 특정 지역으로의 구축 없음 - Private 만 지원하는 경우 직접 PaaS 를 운영하는 비용 소모 - AS - Asia, NA - North America, EU - Europe, OC - Oceania• Monetization Platform Support - 빌링 / 미터링 등 비즈니스를 위한 플랫폼을 지원 자유로운 마케팅 전략을 구사 가능여부
Conclusion어떤 플랫폼을 선택할 것인가 ?
References
• https://www.ibm.com/developerworks/websphere/techjournal/1404_brown/1404_brown.html
• http://microservices.io• [Google Search] The SPOSAD Architectural Style for Multi-
tenant Software Applications• https://
github.com/TheOpenCloudEngine/polymer-java-mapping• https://github.com/TheOpenCloudEngine/OCEIAM-SERVICE
WARRPER• https://github.com/TheOpenCloudEngine/oceIAM