성공적인 서비스로의 플랫폼...

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

개발 운영 / 개선 수익

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. 기관의 특색에 맞춤 설정하여 사용함


Self Service

멀티태넌시 공통 아키텍처 - SPOSAD

Tenant-aware! Inject tenant-specific logics, workflows, brandTenant-specific

Store


SPOSAD Architecture

Supporting Multi-tenancyForce.com: Multi-tenant Kernel


Make Innovative App






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

Facebook

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

http://www.slideshare.net/simone.brunozzi/2010-architecting-for-the-cloud-4719195

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






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


Billing

IAM

(Human)Front-end

ServiceService

API G/W

Service

Service

Stateless 인증 , 통합빌링을 위한 IAM

Tenant Billing


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


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


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






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

One-time Pricing Model• 가입시 한번• 기본료• 상품에 따라 무상 혹은 할인 가능

Recurring Pricing Model• 주기적으로 반복되어 과금• 한도를 넘어서면 제한 또는 추가 과금

Usage-based Pricing Model• 사용량에 비례하여 과금• 사용량이 늘어나면 할인 가능


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

https://www.ibm.com/developerworks/websphere/techjournal/1404_brown/1404_brown.html

https://www.ibm.com/developerworks/websphere/techjournal/1404_brown/1404_brown.html

http://microservices.io/

http://microservices.io/

https://github.com/TheOpenCloudEngine/polymer-java-mapping





https://github.com/TheOpenCloudEngine/oceIAM

https://github.com/TheOpenCloudEngine/oceIAM