Being a Service Provider in the Age of Microservices...2017/05/02 · Being a Service Provider in...

© 2017 TM Forum | 1

Being a Service Provider

in the Age of

Microservices

John Gillam -

Andreas Polz - BearingPoint

2©ompiled 2017 BearingPoint

Any organization that designs a system will produce a design

whose structure is a copy of the organization's communication

structure.

Melvyn Conway, 1967

Source: http://haacked.com/archive/2013/05/13/applying-conways-law.aspx/


Most Common Application Architecture: Monolith

Browser / Client

Load Balancer

Tomcat

ui

core

bpm

scheduling

content-repo

Relational

Database

Simple toDevelop

TestDeployOperate

search

api


Simple toDevelop

TestDeployOperate

Most Common Application Architecture: Monolith

Browser / Client

Load Balancer

Tomcat

Relational

Database

ui

core

bpm

scheduling

content-repo

search

api

Large, complex, monolithic applications

Problems


Problems with Monolithic Applications

Intimidates developers


Problems with Monolithic Applications

Intimidates developers

Obstacle to frequent deployments

Need to redeploy everything to change one component

Overloads your IDE, servlet container and CI-Server

Slows down development

No Isolation

Single Applications within an App-Server are not isolated

Obstacle to scaling development

Lots of coordination and communication required

Requires long-term commitment to a technology stack


What are Microservices?

"Microservices are small, autonomous services that work together"

Small and Focused on Doing One Thing Well

• Service Boundaries = Business Boundaries

Autonomous

• Each service exposes an API, collaborating services communicate (only) via those APIs

• Services can change and be deployed independently of each other

Can you make a change to a service and deploy it by itself without changing anything else?


Key Characteristics of Micro-Service Architectures

Suite of "small" services, where each service …

… focusses on one business capability

… communicates with lightweight mechanisms, e.g. REST/HTTP

… offers its own versioned API

… has an independent version lifecycle and can be deployed byfully automated deployment machinery – Continuous Delivery

… runs in its own process

… possibly uses different programming languages and different data storage technologies – "Polyglotism"




… can be independently scaled

… is built for replacement

… is developed by cross-functional DevOps Teams

Amazon: "You build it, you run it"

One "Two-Pizza" Team responsible for 1-n services

ProductInventoryService

Billing ServiceCustomer Service

Order Service




… can be independently scaled

… is built for replacement

… is developed by cross-functional DevOps Teams

Amazon: "You build it, you run it"

One "Two-Pizza" Team responsible for 1-n services

… is designed for failure, resiliency is built in

Microservice architectures are typically operated in the cloud (private or public), typically in a PaaS

Perfect fit for SaaS software


Microservices are tough!


Netflix Architecture


Coupling & Cohesion

Orchestration vs. Choreography

The Shared Database

User Interface Integration

Distributed Computing

Packaging

Asynchronous Programming Model

Resilience

"Outer Architecture"

Etc.

Microservices are tough!


Challenges: Coupling

Loose coupling

• A loosely coupled service knows as little as it needs to about the services with which it collaborates

• A change to one service should not require a change to another (e.g. consumers)


Challenges: Cohesion

High Cohesion

• We want related behavior to sit together, and unrelated behavior to sit elsewhere

• Why? If we want to change behavior, we want to be able to change it in one place and release that change as soon as possible.


Challenges: Orchestration vs. Choreography

Synchronous vs. Asynchronous

• Request/Response vs. Event-based (highly decoupled)

Orchestration vs. Choreography

• More loosely coupled• More flexible• "I strongly prefer aiming for a choreographed

system, where each service is smart enough to understand its role in the whole dance"


Challenges: The Shared Database

Charge Inventory

Billing Ordering Rating

We allow to view and bind to internal implementation details The DB is effectively a very large, shared API that is quite brittle …


Challenges: The Shared Database

Charge Inventor

y

Billing Ordering Rating

We allow to view and bind to internal implementation details The DB is effectively a very large, shared API that is quite brittle …


Possible Solutions: The Shared Database

Call the "owner" Service for data via REST/HTTP

Duplicate data via asynchronous Notifications

Charge Inventory

BillingService

OrderingService

RatingService

ChargeInventory

ServiceREST/HTTP A

PI Eventhub

Service

API

REST/HTTP

ChargeCreatedEvent

/charges/…Command Messaging

ChargeCreatedEvent


Example: Billing Service

Call other services via REST/HTTP to get all the necessary data

Simpler queries inside the individual services

Data aggregation / calculation within scalable microservice

Higher resource allocation but higher performance

BillingService

ChargeInventoryService

REST/HTTP

API

ChargeSpecs

Service

API

RatingServiceA

PI

Charge Inventory

Charge Specs

Rating


Challenges: User Interface Integration

API Composition


Challenges: User Interface Integration

UI Fragment Composition


Challenges: Packaging / DeploymentFrom WAR Files …

FE

BE BE BE

FE


Challenges: Packaging / Deployment… to Micro-Applications

search.jar

bpm.jar

content-repo.jar

scheduling.jar

backend.jar

Spring Boot

api.jar

Embedded Tomcat

ui.jar

Spring Boot Spring Boot

Spring Boot Spring Boot

Spring BootEmbedded Tomcat

Spring Boot

api-gateway.jar

Embedded Tomcat

Spring Boot

batch.jar

Spring Boot

events.jar

Spring Boot


Micro-Application Packaging

Advantages

• Isolation

‒ Isolate applications from each other

‒ JVM isolation: Each application runs in its own JVM

‒ Full isolation (optional): Each application runs in its own container or OS virtual machine

• Monitoring / Logging

‒ Simpler monitoring of each application

‒ Each application has its own log file

‒ Memory footprint statistics per application

• Scaling

‒ Scaling can be done per application

• Flexibility

‒ Embedded app server is transparent, i.e. can be Tomcat, Jetty, etc.


Micro-Application Packaging

Disadvantages

• Higher complexity

‒ More JVMs to manage, configure, monitor

• Different ports per application

‒ However, with V8.0 installation and monitoring comes "out of the box", dashboards, etc. will be in place automatically

• Slightly bigger memory footprint

• Optimal configuration per application needs to be found (which is effort, but helps us afterwards)

• Integration and operations teams must upgrade deployment process, infrastructure, firewall rules, etc.


Challenges: Packaging / Deployment… to Containers


Challenges: Packaging / Deployment… to Container Management

Kubernetes Master

etcd

Controller Manager

Scheduler

API Server

Worker Node

Kubelet

Worker Node

Kubelet

Pod Pod Pod Pod

Docker Docker

Oracle 12c Database

Separate VM, Storage

Elasticsearch 5

Separate VMs, Storage


Challenges: Outer Architecture

"Outer Architecture"= Cross-Cutting Concerns

Service DiscoveryCentral Logging

Metrics & AnalyticsSolid CI/CD practices

© 2017 TM Forum | 30

Feedback Loop

▪When a company decides to adopt a microservices oriented

paradigm, one of 2 outcomes should be consided.

It will fail. It will revert back to monolithic architectures.

It will succeed, which in turn will slowly change the organisational and

communication structure of the company

© 2017 TM Forum | 31

Feedback Loop

▪When a company decides to adopt a microservices oriented

paradigm, one of 2 outcomes should be consided.

It will fail. It will revert back to monolithic architectures.

It will succeed, which in turn will slowly change the organisational and

communication structure of the company

▪ If it succeds, that will in turn trigger another change

Requirements for their service providers will be turned a lot more

granular

32 “The Best Connected Data for Digital Business”

Typical journey


Orchestration

Physical Infrastructure

Virtual Infrastructure

ApplicationsService

Provisioning

Monetisation(inc

Chargeback)

The orchestration debate


Self Developed / Customised COTS

COTS

Cost to implement

Speed of Delivery / ChangeThe lock in debate


Top to bottom orchestrated digital stack

Access, Authentication, AuthorizationProduct ManagementCustomer ManagementOrder ManagementBilling Management

Finance ManagementBusiness OperationsService Management

Your services:Bare Metal, Virtual, Storage, Apps, Middleware, Platform (DB, BigData etc.) 3rd Party BT, MSFT, AWS, Google etc.

Ideally – single identity, single access method, common API set etc.

IT Service Management layer

Digital Partner Ecosystem

Users /CustomersDepartments / Channels

Integration LayerPoint to Point integrationDigital Services Reference Architecture (DSRA)iPaaS

Being a Service Provider in the Age of Microservices...2017/05/02 · Being a Service Provider in...

Documents

Transcript of Being a Service Provider in the Age of Microservices...2017/05/02 · Being a Service Provider in...