Microservices are vertical slices of functionality independent from one another in terms of technologies, paradigms and to some extent also data. As it is an isolated module, a microservice can be easily replaced or entirely rewritten or just scaled horizontally without the risk of regression in case of need. Multiple microservices interact in a loosely coupled manner participating to a distributed architecture but being fully usable on their own. Honestly, this design has very few cons and quite a few pros. And more importantly, it is much more common than expected. It’s simply the name given to all running solutions that for some reasons are not falling in the realm of well-architected, comprehensive systems. Nearly any system is a collection of microservices. In this talk, I’ll share some painful personal experience that resulted from the building of the infrastructure for a company in multiple steps, with limited resources, adding—like a family would do—one piece after the next trying not to lose track of the existing. Come and hear how to rename and leverage the mess you have around to take some concrete functional benefits.
8. EXPOWARE SOFT - 2016
MICROSERVICE
A particular way of designing software applications as suites
of independently deployable services.
■ Run in dedicated process
■ Communicate through lightweight mechanisms
■ Simplified and automated deployment
■ Decentralized control of languages and data
https://martinfowler.com/articles/microservices.html
13. EXPOWARE SOFT - 2016
Vertical stacks of
logic and data
Can contain replicated data
Can access data via services
Easy to package
and deploy
Easy to assign to
development teams
Work well with
containers
Not that well with
Visual Studio
Nuget packages better way to share code than references
MICROSERVICE
18. EXPOWARE SOFT - 2016
ImplementationStrategic Design
Ubiquitous
language
Bounded
contexts
Domain model
Layered
architecture
DOMAIN-DRIVEN DESIGN
Bounded
contexts
19. EXPOWARE SOFT - 2016
Business
domain
Bounded
context
Bounded
context
Bounded
context
Bounded
context
Business
domain
SOFTWARE MODEL
20. EXPOWARE SOFT - 2016
Bounded Context
Ubiquitous language
Independent
implementation
External interface
(to other contexts)
21. EXPOWARE SOFT - 2016
Functional areas of the application that are better treated separately
Same term meaning different things to different people
Same term used to indicate different elements
Dependency on external subsystems
Dependency on legacy code
Why Having Bounded Contexts
24. EXPOWARE SOFT - 2016
SAY YOU’RE A STARTUP
API
SERVER
SCORING
SERVER
25. EXPOWARE SOFT - 2016
SAY YOU’RE A STARTUP
API
SERVER
SCORING
SERVER
PLAYER
SERVER
26. EXPOWARE SOFT - 2016
SAY YOU’RE A STARTUP
LIVE DATA
SERVER
SCORING
SERVER
PLAYER
SERVER
API
SERVER
CMS
SERVER
27. EXPOWARE SOFT - 2016
SAY YOU’RE A STARTUP
LIVE DATA
SERVER
SCORING
SERVER
PLAYER
SERVER
API
SERVER
CMS
SERVER
TOURNAMENT
SERVER
28. EXPOWARE SOFT - 2016
SAY YOU’RE A STARTUP
LIVE DATA
SERVER
SCORING
SERVER
PLAYER
SERVER
LIVE DATA
SERVER
CMS
SERVER
TOURNAMENT
SERVER
MANAGEMENT
SERVER
29. EXPOWARE SOFT - 2016
I Built a (Perfect)
Microservice Architecture
and I Didn’t Know
30. EXPOWARE SOFT - 2016
The reason we ended up to microservices has to do
much more with productivity than pure technical
matters or technologies.
It had to do much more with common sense and
attitude to solve concrete (and small) business
problems than religion or design for big-scale.
32. EXPOWARE SOFT - 2016
The user of the software won’t know what
she wants until she sees the software.
Humphrey’s Law
An interactive system can never be fully
specified nor can it ever be fully tested.
Wegner’s Lemma
Pluralsight courses
UXDD/DDD