33
FRONTLINE SYSTEMS Microservice Architecture Vikash Kodati

Microservices architecture ext

Embed Size (px)

Citation preview

FRONTLINE SYSTEMS Microservice Architecture Vikash Kodati

T-Mobile Confidential2

AGENDA

4/6/2016

• Microservice: What it IS and NOT• Motivation• Characteristics of Microservice• Monolith vs Microservice• Activities @ T-Mobile• Q&A

T-Mobile Confidential3

WHAT IS A MICROSERVICE?

6/13/2016

Microservice is an architecture style in which a large application is built as a suite of modular services. Each service supports a specific business function. Each service is developed, tested, deployed, updated/replaced and scaled independently without impacting the entire application

Organize around business

capabilityOrganize

around product not project

Have it own data storage/db and runs on its own

process

Microservice

Fault Tolerance,Smart End Point,

Cloud Ready

Componentize, containerize developed &

deployed independently

Common CharacteristicsHighly

decoupled and focused on

doing a single task

T-Mobile Confidential4

WHAT A MICROSERVICE IS NOT

4/6/2016

• A simple API to a more complex service implemented as part of a monolithic application.

• A service implemented with a small amount of code.• A service implemented with share database • A service exposed via API by external service provider (if T-Mobile

doesn’t have control of the implementation, it’s just a service)• A component, service or capability, labeled as a "microservice" by a

vendor

T-Mobile Confidential5

MOTIVATION

6/13/2016

Whats our Motivation?

T-Mobile Confidential6

OUR MONOLITHs

6/13/2016

It’s easy to start building applications that become Monolithic• Diverse business functions/capabilities/modules under one umbrella• Entire Dev team deals with all parts of the application • Diverse external libraries in one Classpath, Cross cutting concerns• Every release and deployment process resulting in ONE logical executable• Tightly coupled integrations (PL/SQL inserts, synchronous handshakes etc…)• More data, more users leads to SCALING OUT the application

Super Cool Application

UI Component Business Logic Persistency Layer

T-Mobile Confidential7

MONOLITHs CONTINUED…

6/13/2016

Super Cool InstanceSuper Cool Instance

Super Cool InstanceSuper Cool Instance

Super Cool InstanceSuper Cool Instance

Super Cool InstanceSuper Cool Instance

T-Mobile Confidential8

FRONTLINE SYSTEMS - MISSION

6/13/2016

Enable T-Mobile’s Frontline teams to consistently interact with our customers throughout the selling and serving

lifecycle, delivering an exemplary and intuitive experience enabled by operational excellence and innovation

T-Mobile Confidential9

MOTIVATION DEFINED

6/13/2016

BRIDGE the gapApplications have to be decomposed into microservices for

improving deployability and scalability and simplifying adoption of new technologies

T-Mobile Confidential10

WHAT IS MICROSERVICE?

6/13/2016

Microservice is an architecture style in which a large application is built as a suite of modular services. Each service supports a specific business function. Each service is developed, tested, deployed, updated/replaced and scaled independently without impacting the entire application

T-Mobile Confidential11

CHARACTERISTICS OF MICROSERVICES

6/13/2016

• Componentization via services• Organized around business capabilities• Products not projects• Smart endpoints and dump pipes• Decentralized Data Management• Infrastructure Automation• Design for failure

T-Mobile Confidential12

COMPONENTIZATION VIA SERVICES

6/13/2016

• Break software into components• Components should be independently

• Replaceable• Upgradeable

• Model the SERVICE as a Component• Self sufficiently running in its own process• Interacting with other services via web service requests

T-Mobile Confidential13

ORGANIZED AROUND BUSINESS CAPABILITIES

6/13/2016

Any organization that designs a system (defined broadly) will produce a design whose structure is a copy of the organization's communication structure.-- Melvyn Conway, 1967

T-Mobile Confidential14

CONTINUED…

6/13/2016

• Make teams will be cross-functional• Team responsible for development,

operations, communications & business value• Services take up a broad-stack (UI, Storage

and 3rd party collaborations)• Well defined boundaries

T-Mobile Confidential15

SCALE CUBE

6/13/2016

T-Mobile Confidential16

SMART ENDPOINTS AND DUMB PIPES

6/13/2016

• End points should contain• Business logic, routing rules

• Have a robust and efficient pipping mechanism (plumbing)• Connect everything together

• Direct RESTful calls• Lightweight message bus (Kafka or RabbitMQ)

• Analogous to Unix filters : receiving a request, applying logic and produce a response

T-Mobile Confidential17

SMART ENDPOINTS AND DUMB PIPES

6/13/2016

T-Mobile Confidential18

SMART ENDPOINTS AND DUMB PIPES

6/13/2016

T-Mobile Confidential19

DECENTRALIZED DATA MANAGEMENT

6/13/2016

T-Mobile Confidential20

X Y Z AXES DEFINED

6/13/2016

T-Mobile Confidential21

INFRASTRUCTURE AUTOMATION

6/13/2016

• Server provisioning• Configuration management• Automated builds• Automated testing• Automated deployments• Monitoring

Goal: Infrastructure As Code• Provision and Tear-down universes (server farms) at the click of a

button/command

T-Mobile Confidential22

CLOUD MODELS

6/13/2016

T-Mobile Confidential23

CLOUD MODELS

6/13/2016

T-Mobile Confidential24

DESIGN FOR FAILURE

6/13/2016

Typical first year for a new cluster:~0.5 overheating (power down most machines in <5 mins, ~1-2 days to recover)~1 PDU failure (~500-1000 machines suddenly disappear, ~6 hours to come back)~1 rack-move (plenty of warning, ~500-1000 machines powered down, ~6 hours)~1 network rewiring (rolling ~5% of machines down over 2-day span)~20 rack failures (40-80 machines instantly disappear, 1-6 hours to get back)~5 racks go wonky (40-80 machines see 50% packet loss)~8 network maintenances (4 might cause ~30-minute random connectivity losses)~12 router reloads (takes out DNS and external vips for a couple minutes)~3 router failures (have to immediately pull traffic for an hour)~dozens of minor 30-second blips for dns~1000 individual machine failures~thousands of hard drive failuresslow disks, bad memory, misconfigured machines, flaky machines, etc.

Note: Data taken from Jeff Dean’s slides

T-Mobile Confidential25

CAP Theorem

6/13/2016

It is impossible for a distributed system to simultaneously provide all 3 guarantees1. Consistency: All nodes see the same data at a given time2. Availability: Every request receives a response3. Partition Tolerance: Tolerant to failure of a part of the system

• Not P => CA– MySQL

• P => C XOR A– CP System– AP System

NOSQL Landscape

6/13/2016 T-Mobile Confidential26

DATA MODELS

6/13/2016 T-Mobile Confidential27

• Relational– RDBMS like MySQL

• Key-Value– Support put, get, delete based on a primary key

• Column-Oriented– Tables are still used and Joins are handled at the client – Store data by column as opposed to traditional row-oriented databases

• Document-Oriented– Stores structured documents like XML, JSON– No Joins

T-Mobile Confidential28

MONOLITHIC vs. MICROSERVICE

6/13/2016

Monolithic Architecture Microservice ArchitectureSimple: Built as a single, autonomous unit of app Partial Deployment: Each element of functionality

is a separate service

Consistency: Tightly coupled. One database for the entire app.

Highly decoupled. Each service has its own database. Eventual consistency

A modification made to a small section of an app might require building, testing and deploying an entirely new version

Preserve Modularity: Each service can be developed/changed/replaced, tested and deployed individually

The entire app run in one process. Scale by replicating the entire app

Each service run on it own process/instance (JVM). Scale by replicating each service

ACID (Atomicity, Consistency, Isolation, Durability)

BASE (Basically Available, Soft State, Eventually Consistent)

Super Computer: Adding resources to a single node Distributed System: Adding more nodes

T-Mobile Confidential29

APPLICATION STACK COMPARISON

6/13/2016

Typical Monolith Application

29

Single/Multiple Machines

File System

RDBMS

Application Framework

Multiple Machines (Cluster)

Distributed File System

COMPUTATIONAL Framework

Application Application

NoSQL Stores

Distributed Miscroservice Application

T-Mobile Confidential30

OTHER RESOURCES and REFERENCES

6/13/2016

• Microservices, Martin Fowler, James Lewis• http://martinfowler.com/articles/microservices.html

• A day in the life of a Netflix Engineer using 37% of the internet• http://fr.slideshare.net/AmazonWebServices/dvo203-the-life-of-a-netflix-engineer-using-

37-of-the-internet• Dzone – Geting started with Microservices

• https://dzone.com/refcardz/getting-started-with-microservices• SoundCloud – How we ended up with microservices

• http://philcalcado.com/2015/09/08/how_we_ended_up_with_microservices.html• gRPC - boilerplate to high-performance scalable APIs

• http://fr.slideshare.net/AboutYouGmbH/robert-kubis-grpc-boilerplate-to-highperformance-scalable-apis-codetalks-2015

• Twelve-Factor methodology: http://12factor.net/

T-Mobile Confidential31

FUTURE TOPICS?

6/13/2016

• Docker• Python and Jupyter notebook• Light weight message buses & Dataframes (e.g., Kafka)• Machine Leaning• Circuit Breaker (e.g., Hystrix)• Mobile Architecture• Solr/Lucene• Case Studies? Use Cases?• Others?

T-Mobile Confidential33

MICROSERVICE is not the answer for all service

4/6/2016

Please ask yourself

You don’t need microservice !

You need microservice !

are you 100% sure you need

microservices?

I think so ! If I have to change any thing in this monolith app I will kill my self