Modeling Microservices Architecture

@aahoogendoorn
MODELING MICROSERVICES
Sander Hoogendoorn
ditisagile.nl
Mentoring ▪ Consulting ▪ Training ▪ Agile ▪ Software architecture ▪ Code

MICROSERVICES? STAIRWAY TO HEAVEN OR HIGHWAY TO HELL?
©2015 ditisagile.nl. All Rights Reserved 2
@aahoogendoorn
www.ditisagile.nl
Sander Hoogendoorn
Me
 Dad
 Mentor, trainer, software architect, programmer
 Books and +250 articles
 Keynotes and talks at +150 conferences
Work
 Owner ditisagile.nl
 CTO Klaverblad Insurances
Web
 www.sanderhoogendoorn.com
 www.smartusecase.com
 www.speedbird9.com
 @aahoogendoorn
 sander@ditisagile.nl

@aahoogendoorn
www.ditisagile.nl

@aahoogendoorn
MONOLITHS
Hard to deliver, even harder to test and impossible to maintain

@aahoogendoorn
www.ditisagile.nl
WHOOFYOUHASASYSTEMTHATISTOOBIG
ANDTHATYOUWOULDRATHERBREAKUP?

@aahoogendoorn
www.ditisagile.nl
Monoliths
Advantages
 A single (layered) architecture
 A single technology stack
 A single code base maintained by multiple teams
Disadvantages
 All parts are interconnected
 Many other systems are connected to your system
 Hard to change, hard to maintain
 Long time between releases, thereby increasing risks
 Slow innovation
 Hard to move to newer technologies
 Doesn’t scale very well
Product Account
Order Customer
Products Accounts
Orders Customers

@aahoogendoorn
www.ditisagile.nl
Dependencies will kill you

@aahoogendoorn
A BRIEF HISTORY
OF COMPONENTS AND SERVICES

@aahoogendoorn
www.ditisagile.nl
Client server

@aahoogendoorn
www.ditisagile.nl
Component based development

@aahoogendoorn
www.ditisagile.nl
Service oriented architecture

@aahoogendoorn
www.ditisagile.nl
Microservices

@aahoogendoorn
MICROSERVICES
Beyond the hype?

@aahoogendoorn
www.ditisagile.nl
Microservices. Beyond the hype?

@aahoogendoorn
www.ditisagile.nl
Gartner hype cycle

@aahoogendoorn
MICROSERVICES
The clear benefits

@aahoogendoorn
www.ditisagile.nl
BUTFIRST…ADEFINITION

@aahoogendoorn
www.ditisagile.nl
Inshort,themicroservicearchitecturalstyleisanapproachtodevelopingasingleapplicationasasuiteofsmallservices,
eachrunninginitsownprocessandcommunicatingwithlightweightmechanisms,oftenanHTTPresourceAPI.
Theseservicesarebuiltaroundbusinesscapabilitiesandindependentlydeployablebyfullyautomateddeploymentmachinery.
Thereisabareminimumofcentralizedmanagementoftheseservices,whichmaybewrittenindifferentprogramminglanguages
andusedifferentdatastoragetechnologies.
MartinFowler

@aahoogendoorn
www.ditisagile.nl
Monoliths. Scalability
Product Account
Order Customer
Product Account
Order Customer
Product Account
Order Customer

@aahoogendoorn
www.ditisagile.nl
Microservices. Scalability
Product Account
OrderCustomer

@aahoogendoorn
www.ditisagile.nl
Microservices. Scalability
Product Account
OrderCustomer
Product
CustomerCustomer Customer
Account Account

@aahoogendoorn
www.ditisagile.nl
Microservices. Scalability & containers
Product Account
Order
Product
Customer
Account Account
CustomerCustomer

@aahoogendoorn
www.ditisagile.nl
Monoliths. Persistence
Product Account
Order Customer
Products Accounts
Orders Customers

@aahoogendoorn
www.ditisagile.nl
Microservices. Polyglot persistence
Product Account OrderCustomer
MongoDB
Customers
MongoDB
Orders
ActiveDirectory
Accounts
Oracle
Products

@aahoogendoorn
www.ditisagile.nl
Microservices. Promises
 Products not projects
 Scalable
 Decentralized governance
 Replaceable parts
 High performance
 Technology independent
 Polyglot persistence
 Easy to build
 Easy to test
 Easier deployment than monoliths
Product
Account
Order
Customer

@aahoogendoorn
www.ditisagile.nl
Microservices. But…
 What is a microservice exactly?
 How small is a microservice?
 Requirements in a microservice world
 Components or services
 Who owns a microservice?
 What technologies do you use?
 What protocols do you apply?
 How to define messages
 How to test microservices
 How to coordinate when business services run
across components?
 How to build deployment pipelines?
Product
Account
Order
Customer

@aahoogendoorn
www.ditisagile.nl
Opinions, opinions, opinions

@aahoogendoorn
ARE MICROSERVICES
A STAIRWAY TO HEAVEN?

@aahoogendoorn
OR A HIGHWAY TO HELL?

@aahoogendoorn
A REAL WORLD CASE

@aahoogendoorn
www.ditisagile.nl
A major insurance company

@aahoogendoorn
www.ditisagile.nl
A major insurance company
We have
 Most functionality on an expensive mainframe
 A wide variety of large systems written in Java that are hard
to maintain and to test, and that are very hard to replace
 Individual systems that cover large areas of functionality,
usually coupled to departments
 Aging technology
 No mobile strategy, allowing for new business or new
services to clients, and intermediaries
We need to
 Get rid of the mainframe
 Shorten time-to-market
 Lower TCO
 Uphold a fully secure systems landscape

@aahoogendoorn
www.ditisagile.nl
Where do we come from?

@aahoogendoorn
www.ditisagile.nl
Outsourcing didn’t work

@aahoogendoorn
www.ditisagile.nl
Where do we go?

@aahoogendoorn
www.ditisagile.nl
FORTHETHINGSWEHAVETOLEARN
BEFOREWECANDOTHEM,
WELEARNBYDOINGTHEM
Aristotle

@aahoogendoorn
www.ditisagile.nl
MICROSERVICESREQUIREANEVOLUTIONARYARCHITECTURE

@aahoogendoorn
START WITH SOME GUIDING PRINCIPLES

@aahoogendoorn
www.ditisagile.nl
Questions, questions, questions
Communicationarchitecture.Theglue
Howdowedefineinterfacesbetweenappsandcomponent?Howdowearrangemessaging?
Howdowegluetogetherrapidlychangingappsandcomponent?
Applicationarchitecture
EnduserfacingDifferentusers,differentfastevolvingneeds
Whichtechnologyisthebestforwhichpurpose?
Componentarchitecture
Componentsandservicesareevolvingrapidly.Howdowedecidewhichcomponentsweneed?
Howdowedealwithversioning?Howdowedealwithdistributedprocessesandtransactions?

@aahoogendoorn
www.ditisagile.nl
Case. Guiding principles
We decided to go from here
 Client thinks in business processes, so we implement
business processes
 We move away from the mainframe, to a new systems
landscape, consisting of micro-applications and micro-
components
 Requirements and documentation are modeled rather than
written
 Applications implement a single (elementary) business
process
 Components serve a single purpose and offer services
 Applications and components all have their own bounded
context – a domain model
 Applications and components will have an similar internal
software architecture to facilitate ease of maintenance and
allow for harvesting re-use
 Communication between applications and components will
use a simple open protocol - REST

@aahoogendoorn
www.ditisagile.nl
Presentation
Process
Domain
Services
Outsideworld
Pages
Grids/Panels,Controls
Usecases
Flow
Domainobjects,Factories/Repositories
Enums/Valueobjects/Tupels/Referenceobjects
Servicegateways,Serviceclients
Infoobjects/Searchobjects
ComponentsRelations Dossiers Intermediaries Accounts Rates

@aahoogendoorn
www.ditisagile.nl
Serviceinterface
Process
Domain
Data/Services
Outsideworld
Resources
Representations
Usecases
Flow
Storagegateways,Storageclients
StorageRelations Dossiers Intermediaries DB2 MongoDB

@aahoogendoorn
www.ditisagile.nl
NOWWHATDOESALLTHISHAVETODOWITHMODELING?

@aahoogendoorn
www.ditisagile.nl
DOINGBIGUP-FRONTDESIGNISDUMB
DOINGNODESIGNISEVENDUMBER
DaveThomas

@aahoogendoorn
BUSINESS PROCESSES FIRST

@aahoogendoorn
www.ditisagile.nl
Different levels of processes (and requirements)

@aahoogendoorn
www.ditisagile.nl
A high-level business process
Step1 Step2 Step3 Step4 Step5

@aahoogendoorn
www.ditisagile.nl
Split into work processes
Step3.1 Step3.2 Step3.3 Step3.4
Step3

@aahoogendoorn
www.ditisagile.nl
Split into elementary processes - OTOPOP
Step3.3.1 Step3.3.2 Step3.3.3 Step3.3.4
Step3.3
Step3.3.5

@aahoogendoorn
www.ditisagile.nl
Smart use cases
Modeling applications
 Each elementary process is implemented in a
single application
 The requirements are modeled using smart use
cases
 Each application consists of a single sea-level use
case and a number of fish-level use cases
 Additionally we add the services that are required
to implement the applications to the model
 Doing so, we can easily do impact mapping on our
services
 Also, the smart use cases form a strong
foundation for integration testing

@aahoogendoorn
www.ditisagile.nl
Different levels of use cases
Traditional
use cases
Smart
use cases
Format Textual Visual
Granularity Different Unified
Estimate Hard Easy
Unit of work Lousy Good
Reuse Incidental Normal
Traceability Possible Normal
Testability Poor Good

@aahoogendoorn
www.ditisagile.nl
Smart use cases

@aahoogendoorn
www.ditisagile.nl
57Smart use cases

@aahoogendoorn
www.ditisagile.nl
Wireframes with use cases

@aahoogendoorn
MODULAR DESIGN /
DESIGNING MICROSERVICES

@aahoogendoorn
www.ditisagile.nl
Single responsibility principle (SRP)
SOLID
 Single Responsibility Principle
 Open Closed Principle
 Liskov Substituion Principle
 Interface Segregation Principle
 Dependency Inversion Principle
Single Responsibility Principle
 Every module should have responsibility over a single part of the
functionality provided by the software,
 That responsibility should be entirely encapsulated by the class
 All its services should be narrowly aligned with that responsibility
Therefore
 Group together things that change together
 Separate things that change for different reason

@aahoogendoorn
www.ditisagile.nl
Bounded context
Domain driven design
 The paradigm of designing software based on models
of the underlying domain
 The domain model helps the business and the
developers to reason about the functionality
 A model needs to be unified – internally consistent
without contradictions
Bounded context
 The bounded context is a central pattern in domain
driven design
 When you model larger domains, it becomes
progressively harder to create this single unified model
 So, instead of creating a single unified model, you
create several, all valid within their bounded context

@aahoogendoorn
www.ditisagile.nl
The single unified domain model
Product
Vendor
Stock
Order
Client
Delivery
Payment

@aahoogendoorn
www.ditisagile.nl
Bounded contexts
Product
Vendor
Stock
Order
Client
Delivery
Payment
Product

@aahoogendoorn
www.ditisagile.nl
Bounded contexts
Modeling
 Modeled in a (single) domain model
 Model contains entities, domain objects
 Usually evolves around a single main entity (aggregate root)
Services
 Interrogate the bounded context
 Resources usually follow the aggregate root
 Services post and put representations
 Representations are mapped to the bounded context
Validation
 Representations can be validated before being mapped
 Bounded context can be validated as a whole e.g. before storing
 Business rules
 Properties and property types
Product
Vendor
Stock

@aahoogendoorn
www.ditisagile.nl
Properties and property types
Basic types
 string, integer, date, datetime
 Include nullable wrapping
Enumerations
 Set up at design time, unchangeable at run-time
 Genders, Categories
Value objects
 No specific instances
 Isbn, Email, Url, Money
References (code tables)
 Changeable at run-time, such as contract types
Associations
 To cached entities such as Country, Nationality
 To first level citizens such as Customer, Product

@aahoogendoorn
www.ditisagile.nl
66
Every application,
worker and
component
has its own
bounded context

@aahoogendoorn
AND THE REST IS
COMMUNICATION (OVER HTTP)

@aahoogendoorn
www.ditisagile.nl
HTTPRETURNCODESCHEATSHEET
1**.Holdon
2**.Hereyougo
3**.Goaway
4**.Youfuckedup
5**.Ifuckedup

@aahoogendoorn
www.ditisagile.nl
HTTP GET
GET
 Retrieve whatever information is
identified by the request URI in the form
of an entity
 The entity is usually a single or a list of
objects (of the type provided by the
service, often JSON, or XML)
 GET is safe (retrieval only) and
idempotent
 Unfortunately there are many ways of
creating GET requests (see examples
below)
 Returns 200 (found), possibly 400 (bad
request) or 404 (not found)
Examples
 Get an entire collection
localhost:8080/countries
 Find objects in the collection
localhost:8080/countries?name=“stan”
 Find an object in the collection by ID
localhost:8080/countries/38
 Find a sub-object in the collection by ID
localhost:8080/countries/38/capital
 Find object in the collection by ISO
localhost:8080/countries?isocode=“GRC”
localhost:8080/countries/isocode/GRC
localhost:8080/countries/GRC

@aahoogendoorn
www.ditisagile.nl
HTTP POST
POST
 Request that the server accepts the
entity enclosed in the request as a new
subordinate of the resource identified by
the request URI
 The posted entity is subordinate to that
URI in the same way that a file is
subordinate to a directory containing it
 Returns the location header for the new
resource, possibly with created entity in
the body
 Returns 201 (created), possibly 500
(server error)
Examples
 Post to the collection (with entity in body)
localhost:8080/countries
 Returning location header

@aahoogendoorn
www.ditisagile.nl
HTTP PUT
PUT
 Requests that the enclosed entity is
stored under the supplied request URI
 If the request URI refers to an existing
resource, the enclosed entity is an
modified version of the resource
 POST identifies the resource that will
handle the enclosed entity
 PUT identifies the entity enclosed with
the request
 Returns 200 or 204 (when resource is
modified), possibly 201 (if a resource is
created), possibly 500 (server error)
Examples
 Put with ID (with entity in body)
 Update capital (with entity in body)
localhost:8080/countries/38/capital

@aahoogendoorn
www.ditisagile.nl
HTTP DELETE
DELETE
 Requests that the resource identified by
the request URI is deleted.
 Returns 200 or 204 (when resource is
deleted), possibly 500 (server error)
Examples
 Delete

@aahoogendoorn
MODELING RESOURCES

@aahoogendoorn
www.ditisagile.nl
Modeling resources
Root resources (component)
/qa
/questionnaires
GET
Questionnaire
Id,Name,Description
/qa
GET the collection, but only limited to this
representation (but with locations likely)
/qa/questionnaires
/questionnaires
GET
/{id}
Questionnaire
Id,Name,Description
Question
Type,Name,Description
Answer
Name,Value
GET a single item from the collection, but
with representation
/qa/questionnaires/334532

@aahoogendoorn
www.ditisagile.nl
75
Resource
model

@aahoogendoorn
www.ditisagile.nl
76
Service
use cases

@aahoogendoorn
www.ditisagile.nl
77Component bounded context

@aahoogendoorn
TESTING MICROSERVICES

@aahoogendoorn
www.ditisagile.nl
A service development lifecycle
Code DeveloperTest Test IntegrationTest AcceptanceTest LivePrepare&Design

@aahoogendoorn
www.ditisagile.nl
What to test
Developers
Unittests
Developers
Q&A
Testers
Scenario’s&API’s
Testers
Productowner
Product

@aahoogendoorn
www.ditisagile.nl
Even though you might have brilliant testers

@aahoogendoorn
www.ditisagile.nl
… please automate your tests
Developers
Unittests
Developers
Q&A
Testers
Testers
Productowner
Product

@aahoogendoorn
www.ditisagile.nl
Developer Q&A Sonarqube

@aahoogendoorn
www.ditisagile.nl
Developer Q&A Sonar

@aahoogendoorn
www.ditisagile.nl
Presentation
Process
Domain
Services
Outsideworld
Pages
Grids/Panels,Controls
Usecases
Flow
Servicegateways,Serviceclients
ComponentsRelations Dossiers Intermediaries Accounts Rates
Integrationtests
BDD&Selenium
Unittests
Unittests
Unittests

@aahoogendoorn
www.ditisagile.nl
Serviceinterface
Process
Domain
Data/Services
Outsideworld
Resources
Representations
Usecases
Flow
Storagegateways,Storageclients
StorageRelations Dossiers Intermediaries DB2 MongoDB
Integrationtests
UsingBDD
Unittests
Unittests
Unittests

@aahoogendoorn
www.ditisagile.nl
WHATABOUTBEINGINDEPENDENTLYDEPLOYABLE?

@aahoogendoorn
DEPLOYING MICROSERVICES
Continuous integration, build pipelines and continuous delivery

@aahoogendoorn
www.ditisagile.nl
A typical build pipeline

@aahoogendoorn
www.ditisagile.nl
ProductionAcceptanceIntegrationTestDevelopment
A typical build pipeline

@aahoogendoorn
www.ditisagile.nl
Build pipelines in Jenkins

@aahoogendoorn
www.ditisagile.nl
Microservices. Building a deployment pipeline
Code DeveloperTest Test AcceptanceTest Acceptance Live

@aahoogendoorn
www.ditisagile.nl
Microservices. Pipeline hell?
Codev.2 DeveloperTestv.2 Testv.2 AcceptanceTestv.2 Acceptancev.2
Testv.2 AcceptanceTestv.2 Acceptancev.2 Livev.2
DeveloperTest Test AcceptanceTest Acceptance Live
Codev.3 DeveloperTestv.3
Live
Codev.2

@aahoogendoorn
www.ditisagile.nl
Dealing with breaking changes
Customer
v1
App1 App2
Customer
v1
App1 App2
v2
Customer
v1
App1 App2
v2
Customer
App1 App2
v2

@aahoogendoorn
DO WE REALLY NEED PROJECTS?
From projects to releases to continuous delivery

@aahoogendoorn
www.ditisagile.nl
Do we really need projects?

@aahoogendoorn
www.ditisagile.nl
Planning?

@aahoogendoorn
www.ditisagile.nl
Or roadmap?

@aahoogendoorn
www.ditisagile.nl
Minimal viable product

@aahoogendoorn
www.ditisagile.nl
Maintenance
From projects to continuous delivery?
Project
MaintenanceMVP
MaintenanceContinuousdelivery

@aahoogendoorn
www.ditisagile.nl
Moving towards DevOps is not easy

@aahoogendoorn
www.ditisagile.nl
WORDLYWISDOMTEACHESUSTHATITISBETTERFORREPUTATION
TOFAILCONVENTIONALLYTHANTOSUCCEEDUNCONVENTIONALLY
JohnMaynardKeynes

@aahoogendoorn
SOME LAST THOUGHTS

@aahoogendoorn
www.ditisagile.nl
Microservices are not for everyone
Whatarewegoingto benefit
fromthemost?
Polyglotpersistence?
Beingableto
multiplestacks?
Independently
deployable?
Enforce
modulardesign?
Continuous
Delivery?

@aahoogendoorn
www.ditisagile.nl
Minimal viable product

@aahoogendoorn
ALLOW THE TEAM TO LEARN
CONTINUOUSLY…

@aahoogendoorn
www.ditisagile.nl
Will it work?

@aahoogendoorn
www.ditisagile.nl
The hockey stick model

@aahoogendoorn
… AND HAVE FUN

@aahoogendoorn
THIS IS
AGILE
www.createspace.com/4747266
Password: agilescrum
Discount code: KGNWKKWG

@aahoogendoorn
www.sanderhoogendoorn.com
www.smartusecase.com
www.speedbird9.com
sander@ditisagile.nl
@aahoogendoorn
REFERENCES
AND QUESTIONS

Modeling Microservices Architecture

Recomendados

Recomendados

Mais conteúdo relacionado

Mais procurados

Mais procurados (20)

Destaque

Destaque (20)

Semelhante a Modeling Microservices Architecture

Semelhante a Modeling Microservices Architecture (20)

Mais de Sander Hoogendoorn

Mais de Sander Hoogendoorn (20)

Último

Último (20)

Modeling Microservices Architecture