DMITRY LEBEDEV
• Software engineer
• 20 years in software development
• Dozens of project delivered
• Couple of projects failed
• Still learn how to solve problems
• Works for Norwegian company AMBITA
Slide 3
Slide 3 text
WHAT THIS PRESENTATION IS ABOUT?
MAY BE IT’S TIME TO CHANGE THE ROOM?! ☺
Slide 4
Slide 4 text
MICROSERVICES CAN HELP
• To grow in a balanced way
• Separate the responsibilities
• Define the boundaries
• Adapt to new challenges
BENEFITS
• Easy to scale development
• Easy to deploy changes
• Fault isolation
• Technology diversity
Slide 7
Slide 7 text
WE’RE DONE WITH MICROSERVICES!
Slide 8
Slide 8 text
BUT THERE ARE SOME … EXPERIENCES…
YOU KNOW…
Slide 9
Slide 9 text
THE PROBLEM WITH SUCCESS STORIES
HARD TO VERIFY, THOUGH
Slide 10
Slide 10 text
PERSONAL EXPERIENCE
Slide 11
Slide 11 text
PROBLEM #1
HOW TO EXPOSE OURSELVES TO OUTER WORLD?!
Slide 12
Slide 12 text
PROBLEM #2
DO WE REALLY NEED TECHNOLOGY DIVERSITY?
Slide 13
Slide 13 text
PROBLEM #3
HOW TO FIND WHAT IS REALLY BROKEN?
Slide 14
Slide 14 text
PROBLEM #4
HEY, MICROSEVICE! WHICH VERSION ARE YOU?
Slide 15
Slide 15 text
PROBLEM #5
WHERE DATA IS COMING FROM?
Slide 16
Slide 16 text
PROBLEMS TO ADDRESS
• How to expose services to outer world?
• Do you need technology diversity?
• How to find what is really broken?
• Which version of components are deployed?
• Where data is coming from?
Slide 17
Slide 17 text
INTERMEDIARY CONCLUSION
• API design principles
• Failure strategy
• Deployment / dep management tools
• Service discovery
• Health-check services
Slide 18
Slide 18 text
API DESIGN
• External API should not be UI driven (if you expose it)
• Think how to have different versions of same API
• Think how to reflect failures
Slide 19
Slide 19 text
FAILURE STRATEGY
• Gradation of a failure (total, partial, just delayed data)
• 3rd party end-points unavailable
• ‘Circuit breaker’ pattern
Slide 20
Slide 20 text
DEPLOYMENT / DEP MANAGEMENT
• Deploy one specific version to specified instances
• Check if all dependencies are in place
• Deploy missing components
• Register deployed components at service registry
• Environment provisioning
Slide 21
Slide 21 text
SERVICE DISCOVERY
• Services got registered when deployed/started
• Services got de-registered when stopped/undeployed
• Client-side discovery
• Server-side discovery
Slide 22
Slide 22 text
HEALTH CHECK SYSTEMS
• Log aggregation and search
• System dashboard (number of instances, versions & etc)
• Statistics (throughput, response time, load)
HIGHLY OPINIONATED PART
DO WE NEED THESE MICROSERVICES AT ALL?!
Slide 26
Slide 26 text
WHEN NOT TO USE
Slide 27
Slide 27 text
SINGLE POINT OF FAILURE IN YOUR DESIGN
Source http://cmx.io/#5745532
Slide 28
Slide 28 text
LOAD IS EQUALLY DISTRIBUTED
Slide 29
Slide 29 text
WE DON’T NEED 99.999 UPTIME
Slide 30
Slide 30 text
WE DON’T NEED DYNAMIC SCALING
Slide 31
Slide 31 text
NO RELEVANT INFRASTRUCTURE
By Ness Kerson/madNESS Photography for AusAID, CC BY-SA 4.0, https://commons.wikimedia.org/w/index.php?curid=32165089
Slide 32
Slide 32 text
WHEN TO USE
Slide 33
Slide 33 text
MULTIPLE DATASOURCES
By Frank Vincentz - Own work, CC BY-SA 3.0, https://commons.wikimedia.org/w/index.php?curid=5638446
Slide 34
Slide 34 text
DIFFERENT LOAD AND SIZE
By Eddy Van 3000 - Flickr: Friends, CC BY-SA 2.0, https://commons.wikimedia.org/w/index.php?curid=32821544
Slide 35
Slide 35 text
HIGH AVAILABILITY REQUIRED
By ŠJů, Wikimedia Commons, CC BY 4.0, https://commons.wikimedia.org/w/index.php?curid=41179082
Slide 36
Slide 36 text
COMPONENTS FROM DIFFERENT DOMAINS
Slide 37
Slide 37 text
MANY TEAMS ARE WORKING TOGETHER
Slide 38
Slide 38 text
YOU HAVE THE INFRASTRUCTURE
Slide 39
Slide 39 text
RE-CAP: WE DON’T NEED IT
• Load is equally distributed
• 99.999 availability is not required
• Dynamic scaling is not required
• No infrastructure that supports microservices
Slide 40
Slide 40 text
RE-CAP: WE NEED IT
• Data comes from different sources
• High availability required
• Several teams are working together
• Infrastructure is in place
Slide 41
Slide 41 text
WHERE TO GO NEXT?
• Microservices.io
• Infoq.com
• nginx.com
• Microservices-stuff.com