simple, battle proven microservices strategy
TRANSCRIPT
Simple, Battle Proven Microservices Strategy
About meChief Architect @ Kenshoo
Java backend since 2004
Microservices + CD since 2008
Agenda
Quick intro to MSA
Scope
Speed
Stability
Stuff we learned
About microservicesdeveloping a single application as a suite of small services, each running in its own process and communicating with lightweight mechanisms … independently deployable by fully automated deployment machinery.
… each service also provides a firm module boundary, even allowing for different services to be written in different programming languages. They can also be managed by different teams …
...decomposed into multiple services, you can expect many single service changes to only require that service to be redeployed.
James Lewis, Martin Fowler - Microservices a definition of this new architectural term
About microservicesdeveloping a single application as a suite of small services, each running in its own process and communicating with lightweight mechanisms … independently deployable by fully automated deployment machinery.
… each service also provides a firm module boundary, even allowing for different services to be written in different programming languages. They can also be managed by different teams …
...decomposed into multiple services, you can expect many single service changes to only require that service to be redeployed.
HighFocus
Photo by Philippe Henry, available under a Creative Commons Attribution-Noncommercial license.
Limited Scope
IndependantPhoto by PEXELS, available under a CC0 license.
Simple
ScopeDefine Firm Boundary
API
➔ Create a buffer layer for isolation.
➔ Also useful for caching, monitoring, error handling, mocking, etc`
ConsumeMy Special Service
Used by me
Using me
Produce
API
➔ Less is more
➔ Consume only what you need.
➔ Publish only what you are willing to commit to
I DON’T ALWAYS BUILD MICROSERVICES
BUT WHEN I DO I NEVER USE CLIENT LIBRARIES
SpeedMaintain fast pace over time
S = A (D + T)
Speed = Automation (Deployment + Tests)
S = A (D + T)
Reliable Testing
Unit
Component
Integration
Smoke
My Special Service
Some other
service
Some other
service
Unit Tests
Unit
Component
Integration
Smoke
My Special Service
Component Tests
Unit
Component
Integration
Smoke
My Special Service
Some other
service
Integration Tests
Unit
Component
Integration
Smoke
My Special Service
Some other
service
Smoke Tests
Unit
Component
Integration
Smoke
My Special Service
Some other
service
NOWe’re not doing it enough
Hello Prod
CI/CD for dummies in 5 simple steps
WhereLocal dev machine.WhatUnit, Component & Integration tests.
WhenBefore commit and as much as possible
ArtifactEasy checkout, change, and run
Local build
Centralized Build
Artifact Bake
Automated Staging
Production
Local build
Centralized Build
Artifact Bake
Automated Staging
ProductionWhereCI Server, Feature branchWhatUnit, Component & Integration tests.
WhenEach commit (PR)
Artifact“Mergability”
Local build
Centralized Build
Artifact Bake
Automated Staging
ProductionWhereCI Server, Master branchWhatUnit, Component & Integration tests.
WhenEach commit (Pull Request merge)
ArtifactNext Production (Immutable Infrastructure).
Local build
Centralized Build
Artifact Bake
Automated Staging
ProductionWhereCD Server,Dedicated testing envWhatDeploy next production, execute Smoke Test
WhenWhenever a new artifact is baked
ArtifactConfidence in next production
Local build
Centralized Build
Artifact Bake
Automated Staging
ProductionWhereCD Server,ProductionWhatGreen-Blue / Canary Execute relevant checks.
WhenAfter a baked artifact is verified in staging
Stability
Speed is Queen
Backward Compatibility is King
Photo by michael iCruz, available under a Creative Commons Attribution-Noncommercial license.
Backward CompatibilityDon’t➔ Couple
deployment of multiple services
➔ Big bang migrations, especially with down time
Photo by Pierre J., available under a CC Attribution-Noncommercial-ShareAlike 2.0 Generic license.
Backward CompatibilityDo➔ Many small
changes through
multiple services
➔ Decouple data
migration from
logic change
Backward Compatibility
API
Data
Logic
● Use ‘Data Only’ protocol (Json,
protobuf, etc’)
● Serialization tests
Backward Compatibility
API
Data
Logic
● Load and Save test - Keep old data
records for tests.
● Refresh staging data from
production.
○ Can be part of a ‘Smoke Test’
Backward Compatibility
API
Data
Logic
● What counts for broken
compatibility logic?
● Changing / removing Component
tests is a red signal.
● Prefer degraded service over broken
service
Expect Failure➔ External Service
◆ Circuit Breaker
◆ Best Effort?
◆ Persistent Retry
Stuff we learned at Kenshoo
Remember the episode I waited for someone to fix my servers?Yeah,... me neither
Who’s looking at the big picture?
Who’s looking at the big picture?
Melvin E. ConwayAny organization that designs a system … will produce a design whose structure is a copy of the organization's communication structure
Melvin E. Conway
Inverse Conway maneuver
Q&A
Thank You