+ All Categories
Home > Technology > building microservices

building microservices

Date post: 05-Apr-2017
Category:
Upload: steve-sfartz
View: 2,798 times
Download: 0 times
Share this document with a friend
107
BUILDING MICROSERVICES Cloud Native patterns, Microservices platforms November 2015 @SteveSfartz
Transcript
Page 1: building microservices

BUILDING MICROSERVICES Cloud Native patterns, Microservices platforms

November 2015@SteveSfartz

Page 2: building microservices

MICROSERVICES

• Introduction (why, when, how)• Cloud Native Patterns

– Resilience– Service Discovery alternatives– Microservices platforms– Gateway

• Organizational changes• Comparing SOA styles• Sump up

Page 3: building microservices

100 - INTRODUCTION TO MICROSERVICESWhy, Monolithic vs MicroServices, scaling the Monolith

/!\ If you already know about microservices, jump to slide 28

Page 4: building microservices

Microservices (2014)

In short, the microservice architectural style is an approach to developing a single application as a suite of small services, each running in its own process and communicating with lightweight mechanisms, often an HTTP resource API.

These services are built around business capabilities and independently deployable by fully automated deployment machinery.

There is a bare minimum of centralized management of these services, which may be written in different programming languages and use different data storage technologies.

Martin Fowler, James Lewis

Page 5: building microservices

THE MONOLITHIC STYLE

• An application built as a single unit, 3 main parts– client-side UI, a database , and a server-side application– code specific to each layer (UI, business logic, DB)– generally a minimum of 3 languages

• This server-side application is a monolith – a single logical executable– any change requires building and deploying a new version

• Locally built and tested on devs’ machines• CI/CD pipeline to secure production

Page 6: building microservices

SCALING THE MONOLITH• Several Monolith instances behind a load balancer

+ Quickest way to scale+ High availability- Routing traffic complexity- Very large code base- Change cycles tied together- Limited scalability

Þ lack of modularity

Load BalancerMonolith

ClientClient

Client

Page 7: building microservices

MODULARIZING THE MONOLITH

• Specialized instances of a single codebase– Modular invocation

Load Balancer Real time business logic

ClientClient

Client

MonolithMonolithAuthentication

MonolithBatches

Load Balancer

- Re-engineering alternative to a rewrite- Generally does the trick- Prepare for future by introducing “APIs”

Page 8: building microservices

MONOLITHIC VERSUS MICROSERVICES

http://martinfowler.com/articles/microservices.html

A monolithic application puts all its functionnality into a single process…

… and scales by replacing the monolith on multiple servers

A microservices architecture puts each element of functionnality into a separate service…… and scales by distributing these services across servers, replicating as needed

Page 9: building microservices

GILT TESTIMONIAL

http://www.infoq.com/news/2015/04/scaling-microservices-gilt

Page 10: building microservices

GILT TESTIMONIAL

http://www.infoq.com/news/2015/04/scaling-microservices-gilt

Page 11: building microservices

GOOGLE TRENDS

Page 12: building microservices

STATE OF THE ART

• Pioneers : Amazon, Netflix, Twitter– Democratized the Microservices architecture style– Started opensourcing their building blocks in 2010

• Today– Large corporations for complex systems that need to

evolve frequently– Digital startups to ensure their core business will scale and

embrace the long tail

Page 13: building microservices

AMAZON DNA

« Services by design », Jeff Besos, 2002

Page 14: building microservices

NETFLIX ECOSYSTEM

• 100s of microservices• 1,000s of daily production changes• 10,000s of instances• 100,000s of customer interactions per minute• 1,000,000s of customers• 1,000,000,000s of metrics• 10,000,000,000 hours of streamed• 10s of operations engineers

http://fr.slideshare.net/AmazonWebServices/dvo203-the-life-of-a-netflix-engineer-using-37-of-the-internet

Page 15: building microservices

200 – DESIGNING FOR MICROSERVICESCommon characteristics, State of the art

Page 16: building microservices

COMMON CHARACTERISTICS

1. Componentization via Services2. Organized around Business Capabilities3. Products not Projects4. Smart endpoints and dumb pipes5. Decentralized governance6. Decentralized data management7. Infrastructure automation8. Design for failure9. Evolutionary design

http://martinfowler.com/articles/microservices.html

Page 17: building microservices

1. COMPONENTIZATION VIA SERVICES

• Services as components rather than libraries• Services avoid tight coupling by using explicit remote call

mechanisms.• Services are independently deployable and scalable• Each service also provides a firm module boundary

– allowing for different services to be written in different languages, and be managed by different teams .

• A microservice may consist of multiple processes – that will always be developed and deployed together, – Ex : an application process and a database that's only used by that

service.

Page 18: building microservices

2. ORGANIZED AROUND BUSINESS CAPABILITIES

Any organization that designs a system will

produce a design whose structure is a

copy of the organization's

communication structure.

Melvyn Conway, 1967.

Page 19: building microservices

2. ORGANIZED AROUND BUSINESS CAPABILITIES

• Microservices to solve Conway’s anti-pattern

Cross-functional teams…. … organized around capabilities

Page 20: building microservices

3. PRODUCTS NOT PROJECTS

• Standard project model – deliver pieces of software which are then considered to be

completed, – hand over to a maintenance organization and disband the

project team• The Microservices style

– a team should own a product over its full lifetime– Amazon : You build => You run it

Page 21: building microservices

4. SMART ENDPOINTS AND DUMB PIPES

• Be as decoupled and as cohesive as possible – own domain logic,– act more as filters in the classical Unix sense– using simple RESTish protocols and lightweight messaging

• Smarts live in the services, not in-between the endpoints– No central tool / bus that includes sophisticated routing,

transformations, process, business rules• Pre-requisite : turn the chatty in-process communication

of the monolith into coarser-grained network messaging

Page 22: building microservices

5. DECENTRALIZED GOVERNANCE• The common microservices practice is to choose the best tool

for each job– Tools are shared inside and outside the organization– Focus on common problems : data storage, IPC, infrastructure

automation– Example : Netflix opensource libraries

• Favor independent evolution– Consumer-driven Service contracts, – Tolerant Reader Pattern

Þ Minimal over-heads create an opportunity to have teams responsible for all aspects- Build their microservices and operate with 24/7 SLAs

Page 23: building microservices

6. DECENTRALIZED DATA MANAGEMENT

• No unique data model approach– the conceptual model differs between microservices– Reinforce the separation of concerns

• Decentralized data storage – Polyglot persistence is frequent in microservices architectures

• Manage inconsistencies via the business practices in place throughout the organization– Common design : reversal processes versus 2PC distributed

transactions

Page 24: building microservices

6. DECENTRALIZED DATA MANAGEMENT

Page 25: building microservices

7. INFRASTRUCTURE AUTOMATION

• CI/CD, Real-time monitoring, global system and fine grained resources dashboards,

• Has become a standard practice – thanks to public cloud providers,– but also opensource tools

• a QA stake for monoliths• a pre-requisite for microservices

Page 26: building microservices

8. DESIGN FOR FAILURE

• Any service call can fail– async consumption

• Best practice : 1 to ZERO sync call– Circuit Breaker pattern

• Ex : Netflix Stack (Hystrix / Eureka / Ribbon)– /!\ provide implementations for various languages

• Infrastructure pre-requisites – monitor and restore at scale– simulation tools

• Ex : Netflix Simian Army (Chaos Monkey)

Page 27: building microservices

9. EVOLUTIONARY DESIGN

• More granular release planning• Goal : change tolerance

– Identify change impacts quickly (via automation, service contracts, automated dependency maps)

– Fix rather than revert– In case of mandatory breaking change, use versioning

• a last resort option in the microservices world

Page 28: building microservices

200 – RESILIENCEScaling Microservices

Page 29: building microservices

SOLID COMMUNICATIONS• Choose a messaging infrastructure adapted to your business

– RPC / REST style, – Request/Response, Streaming– HTTP, HTTP2, TCP, UDP

• Support async consumption / aggregation – Leverage parallel code structures on your clients– ES7 (BabelJS, Google Traceur), go, Scala, Java8

• Ease consumption via clients SDKs– Automated generation from API definitions or IDL– Web APIS : Swagger (OADF), RAML– RPC style : Google gRPC, Twitter Finagle, Apache Thrift

Page 30: building microservices

SOLID COMMUNICATIONS

• Basic REST is not an option for microservices• Provide a large set of features

– load balancing, – fault tolerance, – caching, – service discovery, – mutiple transport and protocols (HTTP, TCP, streaming)

• Example : Netflix Ribbon

Page 31: building microservices

RESILIENCE IN DISTRIBUTED SYSTEMS

• Failures are common• An application that depends on 30 services

– where each service has 99.99% uptime– 99.9930 = 99.7% uptime– 0.3% of 1 billion requests = 3,000,000 failures– 2+ hours downtime/month even if all dependencies have

excellent uptime.• Reality is generally worse.

Page 32: building microservices

WHEN 1 BACKEND BECOMES LATENT

Page 33: building microservices

AT 50+ REQ/S, ALL REQUEST THREADS CAN BLOCK IN SECONDS

Page 34: building microservices

NETFLIX HYSTRIX

• Latency and Fault Tolerance library – designed to isolate points of access to remote systems,

services and 3rd party libraries, – stop cascading failure and enable resilience where failure

is inevitable.– real time monitoring via Dashboard

Page 35: building microservices

HYSTRIX DASHBOARD

Page 36: building microservices

HYSTRIX DASHBOARD

• Circuit Breaker : Open

Page 37: building microservices

HYSTRIX DASHBOARD

Page 38: building microservices

300 – SERVICES DISCOVERY Scaling Microservices

Page 39: building microservices

SERVICES DISCOVERY

• Typically, a microservice gets created and destroyed often– It must be reconfigured on the fly– In near real-time, others should find it

• Routing messages is somewhat a challenge– Service discovery (and registration)– Load balancing (ingress and egress calls)

• Popular configuration services– Apache ZooKeeper , HashiCorp Consul, CoreOS Etcd,

Netflix Eureka

Page 40: building microservices

INTRODUCING PATTERNS

• Cloud Native Applications Architecture Patterns– Core of the solution to build scalable applications with a

microservices architecture style

• Microservices Discovery patterns1. Discovery via DNS2. Discovery via a central Load Balancer3. Discovery via local Load Balancers4. Discovery via embedded Load Balancers

Cloud Native

PATTERN

Page 41: building microservices

DISCOVERY VIA A DNS SERVICE

• dynamic DNS (BIND-DLZ)• DNS service Record (SRV)• programmatic DNS-aaS

– Amazon Route53, Apache Mesos-DNS• leverage CNAMEs to abstract traffic routing• but … propagation delays, random routing, no

priorization, not consumer orientedÞ can do the trick for the first 10s microservices

– /!\ Resilience – /!\ Slow upscaling, no 1 to ZERO

Cloud NativeANTI

PATTERN

Page 42: building microservices

APACHE MESOS-DNS

Page 43: building microservices

DISCOVERY VIA A CENTRAL LOAD BALANCER

• either Home-made LB (Nginx, HA-proxy…)– /!\ Secure your SPOF

• or levereage a public cloud provider LB– Rock solid AWS ELB, automation, model driven, autoscaling– Route53 CNAMEs to ELBs, Private ELB in VPCs

• Limited « Smartness »– Version, HTTP header, URI path routing

• Limited automation– ? Health checks customization, no circuit breaker

• fails short for microservices at scale

Cloud NativeANTI

PATTERN

Page 44: building microservices

DOCKER INTERLOCK PLUGIN

https://github.com/ehazlett/interlock

Page 45: building microservices

DISCOVERY VIA EMBEDDED LOAD BALANCERS

• In-process Load Balancer– Embedded in each service consumer– Reads information for Service Registry

+ lightweight+ composable - language dependency

• ex: Netflix Ribbon – java glue around Eureka + Hystrix (+ gateway)

Cloud Native

PATTERN

Page 46: building microservices

NETFLIX RIBBON

• In-Process Fault Tolerant Smart Load Balancer– DIY from Netflix github repos– or leverage Spring Cloud http://start.spring.io/

Dynamic Load balancer(rules library)

Eureka client

HTTP, TCP, UDP Transport(based on RxNetty)

Hystrix Netflix Eureka(service registry)

Microservices

register

reads

Page 47: building microservices

DISCOVERY VIA LOCAL LOAD BALANCERS

• Load balancer component on localhost– also referred as « Sidecar » approach– ex: AirBnB SmartStack

+ leverage HA-proxy / nginx skills+ easy to integrate (any language, any IT tools)+ TCP, HTTP,HTTP2 support- heavier than in-process load balancers (IPC intermediary)- hasardous load balancing (individual vs sync’ed)- chatty at scale (numerous health checks)Þ Leverage as an intermediary step

Cloud Native

PATTERN

Page 48: building microservices

AIRBNB SMARTSTACK

http://nerds.airbnb.com/smartstack-service-discovery-cloud/

Page 49: building microservices

AIRBNB SMARTSTACK1. MicroS registers to a local Synapse process2. Local Synapse retreives dependencies locations from

ZooKeeper and registers watches3. Local Synapse creates the local HAProxy configuration4. MicroS registers to a local Nerve process5. Local Nerve registers the MicroS into ZooKeeper6. ZooKeeper fires events to Synapses through watches 7. Each synapse instances updates the HA-proxy configuration8. MicroS sends traffic through its local proxy (egress)

Note : Can be extended with a reverse proxy for ingress (microservice Gateway Pattern)

Page 50: building microservices

200 – MICROSERVICES PLATFORMSScaling Microservices at Yelp, Netflix

Page 51: building microservices

MEET PAASTA• Yelp’s PaaS for Microservices• integrates existing opensource components

– Docker : code delivery and containment– Apache Mesos : code execution and scheduling (incl Docker)– Marathon for managing long-running services– Chronos for running things on a timer (nightly batches)– SmartStack for service registration and discovery– Sensu for monitoring/alerting– Jenkins (optionally) for continuous deployment

• opensourced on Nov 2015 10th– https://github.com/Yelp/paasta/

Page 52: building microservices

PAASTA DEPLOYMENT PIPELINE

Airb

nbSm

artS

tack

Chronos

Microservices

Microservice(Docker containers)

Soa-config(versionned in git)

Jenkins (optional)

devops

package

describe

Apache Mesos + MarathonSe

nsu

Mon

itorin

g

Fac

eboo

k Sc

ribe

Docker

PaaSTA CLIread

updates

- Devs prepare a Docker Image- DSL to describe how the service is to be run (cpu, mem, instances, nerve, bounce, volumes, monitoring, blacklists, healthchecks)- git commit the desired state (DSL)- PaaSTA CLI to provision your microservices

Page 53: building microservices

THE NETFLIX MICROSERVICES JOURNEY

• Migration to AWS

AWS re-invent 2015

Page 54: building microservices

NETFLIX STACK

• Solid communications– Hystrix : latency and fault tolerance library – Eureka : registry for resilient mid-tier load balancing and

failover– Ribbon : client based smart load balancer– Servo : monitoring library– EVCache : distributed in-memory data store for AWS EC2– RxNetty : reactive extension adaptor for netty– Karyon : blueprint of a cloud ready microservice– Zuul : edge gateway– Falcor : js library for efficient data fetching

Page 55: building microservices
Page 56: building microservices
Page 57: building microservices

NETFLIX STACK : AUTOMATION TOOLS

• Asgard (transitionning to Spinnaker)– specialized AWS console (app deployments, management)

• Spinnaker – microservices console (clusters, pipelines)

• Atlas – near realtime operational insights

• Vector – exposes hand picked high resolution metrics from PCP – Performance Co-Pilot hosts

• SimianArmy – services (Monkeys) in the cloud for generating various kinds of failures, detecting

abnormal conditions, and testing our ability to survive them

• Dependencies automatically documented from real traffic analysis

Page 58: building microservices

DEPENDENCY GRAPH BASED ON REAL TRAFFIC

Page 59: building microservices
Page 60: building microservices

VECTOR

Page 61: building microservices

NETFLIX FALCOR

• JSON Virtual Resources to consume Microservices

http://netflix.github.io/falcor/starter/what-is-falcor.html

Page 62: building microservices

200 – MICROSERVICES PLATFORMSBest of breed architecture

Page 63: building microservices

MICROSERVICES PLATFORM• Devtime definition

– Resources, Ports– Dependencies

• Deployment configuration– System desired state– Scalability model

• Runtime – Discovery, Monitoring, – Fill gap current vs desired state

Þ Requirements for Cloud Native Microservices– Packager, Deployment pipeline, Scheduler

Page 64: building microservices

MICROSERVICES PLATFORM

Gateway Load Balancer

MicroServices

Logs Metrics Health chk

Container, VM, AppServer, PaaS

Deployment configuration

Disc

over

y

Mon

itorin

g

Depl

oym

entDevtime

definition

Executableartifact

MicroServices

MicroServices Platform

Page 65: building microservices

MEET NETFLIX SPINNAKER

• Multi-cloud continuous delivery platform– Release changes with high velocity and confidence– AWS, Google, Cloud Foundry, (Azure coming)

• Opensourced on Nov 2015, 16th

deployment manager cluster manager

Page 66: building microservices

SPINNAKER DEPLOYMENT PIPELINE

Page 67: building microservices

SPINNAKER MANUAL STEP

Page 68: building microservices

SPINNAKER CLUSTER MANAGEMENT

Page 69: building microservices

SPINNAKER INTERNALShttp://spinnaker.io/

Page 70: building microservices

300 – MICROSERVICES GATEWAY

Page 71: building microservices

MICROSERVICES GATEWAY• Edge service to access back-end microservices

– Authentication and Security– Dynamic routing– Insights and Monitoring– Stress testing : gradually increasing the traffic to a cluster in order

to gauge performance.– Load Shedding : allocating capacity for each type of request and

dropping requests that go over the limit.– Static Response handling : building some responses directly at the

edge instead of forwarding them to an internal cluster– Multi-region Resiliency : routing requests across regions in order to

move the edge closer to users

Page 72: building microservices

MICROSERVICES GATEWAY

• Integrate with the other building blocks of your Microservices communication infrastructure– Example : Netflix Zuul

• Think also Bridge / Adapter– REST RPC : gRPC-gateway, Finatra

• Lots of building blocks– Embedded gateways (pick your dev language favorite gateway)– HA-Proxy plugins– Nginx, Nginx OpenResty plugins– Dedicated process with central configuration

Page 73: building microservices

MASHAPE KONG

Page 74: building microservices

MASHAPE KONG DEMOa programmatic gateway as nginx plugins

Page 75: building microservices

200 – ORGANIZE FOR MICROSERVICES

Page 76: building microservices

COMMITTED TEAMS

• Ownership core to team organization– built into the management of the organization– make sure that teams have sufficient time to truly own the

applications that they are in charge• “Products versus Projects” principle• “Functional versus Divisional” organisations

– And give them 360 view on operations

Page 77: building microservices

SOUNDCLOUD TESTIMONIAL

Page 78: building microservices

SOUNDCLOUD TESTIMONIAL

• Actual workflow to go live– 2 months, 11 steps– Main elephant is all the dance between front-end and

back-end development– 11 days are doing actual development work

Page 79: building microservices

SOUNDCLOUD TESTIMONIAL

• Decision : pairing back-end and front-end devs– pair fully dedicated to a feature until its completion– Individually, each person ended up spending more time doing

work per feature

Page 80: building microservices

SOUNDCLOUD TESTIMONIAL

Designer, Product manager, and front-end

Developer

working close to each other

Page 81: building microservices

SOUNDCLOUD TESTIMONIAL

• The irreducible complexity of the monolith– Why do we need Pull Requests? – Why do people make mistakes so often? – Why is the code base so complex?– Why do we need a single code base to implement the

many components? – Why can’t we have economies of scale for multiple,

smaller, systems?

Page 82: building microservices

SOUNDCLOUD TESTIMONIAL

• Isolated new features in dedicated microservices, isolated from the monolith

• New organization with team of 3 to 4 people

• Each team is responsible for decided whether parts of the Monolith are extracted and rewritten , or kept

Page 83: building microservices

COMMITTED TEAMS

• Ownership core to team organization– built into the management of the organization– make sure that teams have sufficient time to truly own the

applications that they are in charge• “Products versus Projects” principle• “Functional versus Divisional” organisations

– And give them 360 view on operations

Page 84: building microservices

FAQ

How big should be my microservices ?RESTish microservices ?Isn’t it SOA ?The end of the monoliths ?

Page 85: building microservices

HOW BIG ?

• To ensure ownership, each team encomprises all traditional product functions– functional vs Divisional organisations– Ppoduct Management, Development, QA, Documentation,

Support• Sizing depends on the system you’re building

– Amazon 2PT principle - Two Pizza Teams– 6 to 10 people to build/deploy/manitain a microservice– an average microservice at Gilt consists of 2000 lines of

code, 5 source files, and is run on 3 instances in production

Page 86: building microservices

RESTISH MICROSERVICES ?• REST

– Web langa franca, 100% interoprable– development cost is generally higher– best practices : provide client sdks, (ex : generated from

Swagger/RAML or other API description languages)– performance issues if not well-designed (chatiness)– best practices : experience based and coarser grained APIs

• RPC– optimized communication via binary formats– automated generation from IDL, polyglot by default– integrated support multples scenarios : req/response, streaming, bi-

directional streaming

Page 87: building microservices

RESTISH MICROSERVICES ?

• RPC or REST style depends on the system you’re building and existing skillset

• Whatever the style, your microservices architecture MUST provide – Services Discovery, – Reliable Communications,– Operations insights (logs, monitoring, alerts, real time

analysis)

Page 88: building microservices

GOT IT, BUT ISN’T IT SOA ?

• SOA so what ?– Enterprise SOA– Event-driven architecture (Pub/Sub)– Streaming Services (Realtime, TimeSeries)– Container-Services (ala Docker)– Nano-ervices (ala AWS Lambda)

• Simply stated : Microservices are a SOA style for a usually large system whose first goal is scalabilityÞ in details, let’s see how microservices differ from…

Page 89: building microservices

MICROSERVICES VS ENTERPRISE SOA

• Enterprise SOA is often seen as– multi-year initiatives, costs millions – complex protocols with productivity and interoperability

challenges– central governance model that inhibits change

• Enterprise SOA is more about integrating siloed monoliths – generally via a smart and centralized service bus

• Microservices is scalable SOA– an architectural style to design, develop and deploy a large

and complex system, so that it is easier to scale and evolve

Page 90: building microservices

√ Componentization via Services√ Organized around Business Capabilities Products not Projects Smart endpoints and dumb pipes Decentralized governance Decentralized data management Infrastructure automationv Design for failure√ Evolutionary design

VS ENTERPRISE SOAM

icroservices differentiators

Page 91: building microservices

VS CORBA

• CORBA is a communication middleware, relying on a common set of

• See microservices as CORBA done right– Much more lightweight– Centered on Service Contracts rather than a global

homogeneous message infrastructure– Much more scalable, flexible and dynamic thanks to

programmatic infrastructure and CI/CD– Built out of OSS well-know components

Page 92: building microservices

VS EVENT DRIVEN ARCHITECTURE

• EDA fits well with Document oriented systems and information flows• Communication between microservices can be a mix

of RPC (ie, P2P calls) and EDA calls• See EDA as a communication pattern for your

microservices• Can address choregraphy, orchestration, pipeline

requirements

Page 93: building microservices

VS STREAMING SERVICES

• Streaming services fit well – if you have large volumes (log entries, IoT), – and/or if you aim at real time analysis

• Data ingestion endpoint of a microService– Real time analysis of amobile app usage

aws:reinvent 2015 - Zillow

Page 94: building microservices

VS CONTAINER SERVICES

• Containers provide infrastructure components to deploy microservices - independently one from another

• See Container Services as a building block of your global microservices platform – see 200 – Design for Microservices Architectures

Page 95: building microservices

VS NANOSERVICES

• Nanoservices are small pieces of code, ie functions– Example : AWS Lambda, Auth0 webtasks

• A icroservice may leverage 1+ nanoservices

Page 96: building microservices

SUMP UP

Page 97: building microservices

MICROSERVICES PATTERNS

• Solid communications– Fault tolerant librairies– Service discovey

• Committed teams– Devops culture– Code/Test/Deploy/Support, 24/7– Automation

• Ownership– Organisation aligned with the strategy– Insights via real time monitoring

Page 98: building microservices

PREPARE YOUR MONOLITHS FOR CHANGE

• Velocity of innovation for complex systems– Keep your monolith as is if you don’t need to speed up

features delivery

• To prepare for the journey• switch from layered architecture to internal APIs, • automate integration and deployment, • reorganize from divisional to functional teams committed

to business and owning their code

Page 99: building microservices

MICROSERVICES IS A LONG JOURNEY

• Several years to implement– Communications, infrastructure, automation, monitoring,

team organization• Leverage existing tools and stacks

– Infrastructure as a Service and Containers– Continuous delivery platform– Netflix stack, DIY from OSS building blocks

Page 100: building microservices

LONG IS THE ROAD TO MICROSERVICES

• leverage OSS stacks, programmatic IaaS and containers + continuous delivery• mandatory CEO and Business teams support

Where to start from ?

• provide multiple glues, ala spring cloud for JVMs…• leverage « side car » approaches, ex : Netflix Prana

Multiple langages support

• numerous building blocks requiring continuous updates• automate, automate, automate

« Technical debt » at scale

• keep control of your microservices segmentation• dynamic cartography

Dependency Hell

• is your organisation ready ? • change management

Product Ownership

Page 101: building microservices

THE END OF MONOLITHS ?

http://www.stavros.io/posts/microservices-cargo-cult/

Page 102: building microservices

TO GO FURTHER

microservices.io

Page 103: building microservices

REFERENCESMicroservices, 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

Page 104: building microservices

REFERENCESSmartStack: Service Discovery in the Cloud

– http://nerds.airbnb.com/smartstack-service-discovery-cloud/

Mesosphere advanced course– https://open.mesosphere.com/advanced-course/

Opensource Service Discovery– http://jasonwilder.com/blog/2014/02/04/service-discovery-in-the-

cloud/

Why Use a Container Sidecar for Microservices?– https://www.voxxed.com/blog/2015/01/use-container-sidecar-

microservices/

Page 105: building microservices

THANK YOU

Stève SFARTZ• technical program manager• enterprise architect, web API specialist, • scalable & interoperable platforms builder• dev & ops teams lead

Keeping in touch• [email protected]• twitter : @SteveSfartz

Page 106: building microservices

BACK IN 1981…

Page 107: building microservices

… THAT WAS MICRO

Sinclair ZX81introduced in March 1981US$ 149.95 assembled500,000 in first 12 monthsCPU: NEC Z-80A, 3.25MHzRAM: 1K, 64K maxOS: ROM BASICDisplay:22 X 32 texthooks to TV2 ports: memory, cassette1 peripheral: Sinclair thermal printer


Recommended