성공적인 서비스로의 플랫폼 선택

1. Micro-services
Architecture
PaaS
Multi-tenancy
DevOps
2017년 GSIP 성공적인 서비스 구축를 위한
Tools, Libraries, and Frameworks for
Successful Cloud Services
Jinyoung Jang
OpenCloudEngine.org
(jyjang@uengine.org)

2. 성공적 서비스의 정의
최근 Economist Intelligence 에 의한 국제적
조사 (293개 기업 CIO, 조사국가: 미국
39%, 영국 31%, 호주 30%)에 의하면 5개
기업중 4개는 자신의 고객들이 제화와 서
비스를 제공받는 방식에 어떤 변화를 원
하고 있다고 답했다. 그리고 실제로 반이
넘는 기업들은 가격모델과 제공방식을
변경하였거나 계획 중이라고 답했다. 그
러한 변화 중 가장 많은 40% 로 대답한
것은 바로 ‘구독형 서비스(Subscription
Service)’의 도입으로 조사됐다.

3. 성공적인 서비스들

4. 성공적 서비스로의 여정
운영자동화
• Business Continuity
• Zero-downtime
수익화
• Subscription Business
구현
• Mashups
• Multi-tenancy
• Self-Serviced
마이크로 서비스
• Separation of Concerns
Successful
Service

5. 성공적 서비스로의 여정
운영자동화
• Business Continuity
• Zero-downtime
수익화
• Subscription Business
구현
• Mashups
• Multi-tenancy
• Self-Serviced
마이크로 서비스
• Separation of Concerns

6. Creating Innovative Application
: Develop or Mashup?
Machine Learning Voice-ware IoT
Not enough TIME!

7. Develop or Mashup?
IBM Bluemix – Watson Micro Services

8. Develop or Mashup?
IBM Bluemix – Using Watson Micro
Services

9. Develop or Mashup?
IBM Bluemix – Writing Voice Ware

11. Share more, More cheap offering, More
Competitive in the market !
Share less, More easy & Secure !
Creating Innovative Application
Multi-tenancy Support

12. SaaS Maturity Model

13. 가입자A의 앱설정 가입자B의 앱설정
* 멀티태넌시 지원 기능은 금번 사업 범위에 비포함
* 향후 현재 R&D문서관리 등은 멀티태넌트 전환이 필요함
2. 도입기관별 입력 항목 변경
3. 도입기관별 판정로직 설정
1. 도입기관 브랜드 설정
Multi-tenancy Support
Metadata-based

14. Multi-tenancy Support
Self Service

15. Multi-tenancy Support
Self Service

16. Tenant-aware! Inject tenant-specific logics, workflows, brand
Tenant-specific
Store
Multi-tenancy Support
SPOSAD Architecture

17. Tenant-specific Customization > Custom Database Schema > Shared Database
vs. Shared schema
© 2013 uEngineCloud, Inc.
Rigid, shared table Extension
tables
Datatype-specific
pivot tables
Private tables
Universal table
with XML
document
Universal table
Supporting Multi-tenancy
어떤 DB 구조로 설계해야 하나요?

18. Supporting Multi-tenancy
Force.com: Multi-tenant Kernel

19. Supporting Multi-tenancy
NoSQL databases
1. Inherent multi-tenancy - Schema Free
2. High Performance - Horizontally scalable and Memory cache
3. Web optimized – Query results are JSON - data can be parsed by web
browser directly and performantly.
Additionally -
4. Easy to implement Analytic services (MR) and Full Text Search
5. Event-driven Transaction - don't have to care about CQRS something
6. Some NoSQL products (Couchbase, Cassandra) provides pessimistic
locking and ANSI SQL (Join Query) - easily migrate to them.

20. Supporting Multi-tenancy
Libraries and tools for Multi-tenancy support
• Multi-tenancy Database Frameworks
• JPA @Discriminator annotation (Hibernate, EclipseLink)
• Athena Framework
• Spring Cloud
• Corent-technology’s JDBC/ODBC proxy
• Metadata framework (SPOSAD)
• IBM J9 JVM - @TenantScope annotation
• Athena Framework
• Adaptive Object Model
• OCE multi-tenancy metadata framework

21. 성공적 서비스로의 여정
운영자동화
• Business Continuity
• Zero-downtime
수익화
• Subscription Business
구현
• Mashups
• Multi-tenancy
• Self-Serviced
마이크로 서비스
• Separation of Concerns

22. DevOps: Issues
Continuous Delivery
22
Company Deploy Frequency Deploy Lead Time Reliability Customer
Responsiveness
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는 얼마나 자주 배포할까요?

23. 23
2. 배포 주기
• 매일 마이너 업데이트
• 메이저 업데이트 (매주 화요일 오후)
3. Deployment Pipeline
출처: http://ieeexplore.ieee.org/xpl/articleDetails.jsp?arnumber=6449236
Supporting Continuous Delivery
Facebook

24. 24
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

25. CPU
MEM Disk
WAS
Storage
Service
(e.g. S3)
Memory
Service
(e.g. Redis)
Micro
Service
Architecture
Existing Enterprise Application
HA architecture
wire network
Managing “SPOF (Single Point Of Failure)”
DevOps
Managing Single Point of Failure

26. Managing SPOF
Micro Services Architecture

27. 출처 : 2010 architecting for the cloud (http://www.slideshare.net/simone.brunozzi/2010-architecting-for-the-cloud-4719195)
DevOps: Issues
Managing Scalability

28. Managing Scalability
Workload Distribution Engine

29. • 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

30. DevOps Platform
IBM Bluemix

31. DevOps Platform
IBM Bluemix – Auto Scaling

32. DevOps Platform
IBM Bluemix – Zero Downtime Deploy

33. 성공적 서비스로의 여정
운영자동화
• Business Continuity
• Zero-downtime
수익화
• Subscription Business
구현
• Mashups
• Multi-tenancy
• Self-Serviced
마이크로 서비스
• Separation of Concerns

34. Monolithic Architecture
 모든 서비스가 한번에 재배포
 한팀의 반영을 위하여 모든 팀이 대기
 지속적 딜리버리가 어려워

35. Micro Service Architecture
Contract based, Polyglot Programming
 Separation of Concerns, Parallel Development, Easy Outsourcing
Written in Java
Written in Node
Written in PHP

36. Micro Service Architecture
• 변경된 서비스만 재배포
 Side effect 최소화
• 자율성
 각 서비스에 대한 자유로운 언어, 아키텍처, 아웃소싱 용이
• 병렬 개발, 타임 투 마켓, 린 개발

38. API Gateway
(Human)
Front-end
Servic
e
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

39. Billing
(Human)
Front-end
Service
Service
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

40. Metering / Loggregator
(Human)
Front-end
Service
Service
API G/W
Service
Service
로그를 수집하여, 테넌트별 사용량을 집계한 후 빌링에게 전달
(Machine)
Third-party Apps
Billing
Metering
(Loggregator)

41. IAM
(Human)
Front-end
Service
Service
API G/W
Service
Service
Stateless 인증, 통합빌링을 위한 IAM
Tenant Billing
(Machine)
Third-party Apps
Billing
IAM token
provider

42. Design factors on developing cloud
applications
1.Don't code your application directly to a specific
topology
2.Do not assume the local file system is permanent
3.Don't keep session state in your application
4.Don't log to the file system
5.Don't assume any specific infrastructure dependency
6.Don't use infrastructure APIs from within your
application
7.Don't use obscure protocols
8.Don't rely on OS-specific features
9.Don't manually install your application
42

43. Micro Service Architecture
Design Factor for Front-end
One Page
N-Screen
Responsive
Dynamic
Real-time

44. 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

45. Writing One Page Web App
Problems: 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>

46. Polymer: Web Component Framework
Polymer: 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

47. Polymer: Web Component Framework
Polymer: 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>

48. • UI Framework for MSA
• AngalarJS
• React
• Polymer
• VueJS
• API Gateway
• APIGee (Commercial)
• Kong
• OCE Gateway
• Amazon Cognito (Public)
• Spring Cloud
• IAM
• Amazon IAM (Public)
• Spring Cloud
• OCE IAM
• Metering / Billing
• Exem’s Metering Framework – BigData based
• OCE Billing
Micro Service Architecture
Platforms for MSA

49. Platform for MSA
OCE API Gateway

50. Example: Proposed SaaS Architecture
Front-end (Responsive, Client-
side Service Aggregate)
Scalable Global Single
Instance Database
(NoSQL -> Couchbase)
Service
API G/W
Service
Service
Scalable, Client-driven, Microservices architecture
Tenant Billing
(Machine)
3rd-party
Apps
Billing
IAM token
provider
local DB
(pouchDB)
CRUD
1.data
sync
2.REST

51. 성공적 서비스로의 여정
운영자동화
• Business Continuity
• Zero-downtime
수익화
• Subscription Business
구현
• Mashups
• Multi-tenancy
• Self-Serviced
마이크로 서비스
• Separation of Concerns

52. Monetization Platform

53. Leaders Mainstream Laggards
Pricing strategy • Pricing metrics are defined
perceived by the customers
• Pricing strategy is easy to
understand, measure.
• Boundaries for usage,
features, time,
from trial are clearly
• Pricing is ad hoc
• Pricing is based on
internally-oriented
• Difficult to convert trial
freemium to paid
• Leader 들은 고객 관점에서 가격을 책정,
시장상황에 빠르게 가격 및 정책 개선
• 후발기업들은 내부 비용에 초점, 변경하지 않음

54. Zuora Aria
Hiveage Chargify
And more..
Monetization
Platforms For Monetization

55. Monetization Platform
Zuora - Billing Metering As A Service

56. Monetization Platform
Zuora - Billing Metering As A Service

57. Monetization Platform
Zuora - Billing Metering As A Service

58. Monetization Platform
Zuora - Billing Metering As A Service

59. Monetization Platform
OCE Billing – Open Source Billing Metering

60. • 구독형 (공유자원 & 확장성)
• 다종단말
• 마이크로 서비스
• 스마트 프론트-엔드
Mission: 향후 10년 사용할 아키텍처
• 설치형
• 단일단말
• 모놀리씩
• 무거운 백엔드

61. Reference SaaS App
https://github.com/TheOpenCloudEngine/micro-service-architecture
특징
• 멀티테넌시
• 셀프서비스 (객체관리)
• 클라이언트 기반 서비스
통합
• 로컬 캐시 DB
(오프라인에서도 동작,
서버 접속시 동기화)
• 토큰 인증 (IAM)
• API GW 통한 CRUD DB
접근

62. Reference SaaS App
github.com/TheOpenCloudEngine/micro-service-architecture
Front-end (Polymer)
CouchDB
OCE API G/W
Tenant Billing
OCE BillingOCE IAM
local DB
(pouchDB)
CRUD
1.data
sync
2.REST
OCE
Metadata Service
Self-service Portal
Generate UIs

63. 성공적 서비스로의 여정
운영자동화
• Business Continuity
• Zero-downtime
수익화
• Subscription Business
구현
• Mashups
• Multi-tenancy
• Self-Serviced
마이크로 서비스
• Separation of Concerns
Your
Successful Transition
to
Subscription
Business
여러분의 성공적인 서비스 비즈니스 모델로의
전환을 응원합니다!

64. References
• www.opence.org
• https://www.ibm.com/developerworks/websphere/tec
hjournal/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-
SERVICEWARRPER
• https://github.com/TheOpenCloudEngine/oceIAM