(Libero Events) Microservices

DESIGNING, BUILDING, TESTING
AND DEPLOYING MICROSERVICES

Sander Hoogendoorn
ditisagile.nl
Mentoring Consulting Training Agile Software architecture Code

@aahoogendoorn
Sander Hoogendoorn
Me
Dad
Mentor, trainer, software architect, programmer
Books, articles, conferences
Work
Owner, ditisagile.nl
CTO insurance company

[PTO Capgemini]
[Global design authority agile Capgemini]
Web
www.sanderhoogendoorn.com
www.smartusecase.com
www.speedbird9.com
@aahoogendoorn
sander@ditisagile.nl
@aahoogendoorn
www.ditisagile.nl
MICROSERVICES? STAIRWAY TO HEAVEN OR HIGHWAY TO HELL?
2015 ditisagile.nl. All Rights Reserved
@aahoogendoorn
www.ditisagile.nl
Agenda
An introduction into microservices
Pros and cons of monolithic software
Some principles of service orientation

Definitions of microservices
Some principles of microservices
Promises of microservices
Challenges in microservices
A microservice architecture
Evolutionary architecture
Building a landscape of small applications and services
Micro-applications
Components and microservices

Examples of design patterns for microservices
Picking the best technology for every microservice
Ployglot persistence
@aahoogendoorn
www.ditisagile.nl
Agenda
How do microservices communicate with each
other?
Service interfaces
Setting up communication between services
Communication via REST
Patterns in communication
Services and transactions
Designing microservices
From business needs and features to microservices

Modeling services
Smart use cases
Mapping domain driven design to microservices
@aahoogendoorn
www.ditisagile.nl
Agenda
Deployment of microservices
The importance of the deployment pipeline

Setting up the deployment pipeline
Agile, Kanban and microservices
Microservices and DevOps
Concluding
Some recommendations
Do microservices solve all challenges your IT
department has?
How to continue?
@aahoogendoorn
www.ditisagile.nl
MONOLITHS
Hard to deliver, even harder to test and impossible to maintain
@aahoogendoorn
WHO OF YOU HAS A SYSTEM THAT IS TOO BIG

AND THAT YOU WOULD RATHER BREAK UP?
@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
Product Account
Order
Customer
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
Products Accounts
Orders
Customers
Doesnt scale very well

@aahoogendoorn
www.ditisagile.nl
10
Dependencies will kill you
@aahoogendoorn
www.ditisagile.nl
11
A BRIEF HISTORY
OF COMPONENTS AND SERVICES
@aahoogendoorn
Client server
@aahoogendoorn
www.ditisagile.nl
13
Component based development
@aahoogendoorn
www.ditisagile.nl
14
Service oriented architecture
@aahoogendoorn
www.ditisagile.nl
15
Microservices
@aahoogendoorn
www.ditisagile.nl
16
MICROSERVICES
Beyond the hype?
@aahoogendoorn
Microservices. Beyond the hype?
@aahoogendoorn
www.ditisagile.nl
18
Gartner hype cycle
@aahoogendoorn
www.ditisagile.nl
19
MICROSERVICES
The clear benefits
@aahoogendoorn
BUT FIRST A DEFINITION

@aahoogendoorn
www.ditisagile.nl
21
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
@aahoogendoorn
www.ditisagile.nl
22
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
@aahoogendoorn
www.ditisagile.nl
23
Monoliths. Scalability
Product Account
Product Account
Product Account
Order
Order
Order
@aahoogendoorn
www.ditisagile.nl
Customer
Customer
Customer
24
Microservices. Scalability
@aahoogendoorn
www.ditisagile.nl
Product
Account
Customer
Order
25
Microservices. Scalability
Product Product
Customer Customer Customer Customer
@aahoogendoorn
www.ditisagile.nl
Account Account Account
Order
26
Monoliths. Persistence
Product Account
Order
Customer
Products Accounts
Orders
@aahoogendoorn
www.ditisagile.nl
Customers
27
Microservices. Polyglot persistence
@aahoogendoorn
www.ditisagile.nl
Product
Account
Customer
Order
Products
Accounts
Customers
Orders
Oracle
Active Directory
MongoDB
MongoDB
28
Microservices. Promises
Products not projects
Scalable
Decentralized governance
Product
Account
Replaceable parts
High performance
Technology independent
Polyglot persistence
Easy to build
Easy to test
Easier deployment than monoliths
@aahoogendoorn
www.ditisagile.nl
Customer
Order
29
Microservices. But
What is a microservice exactly?
How small is a microservice?
Requirements in a microservice world
Product
Components or services
Account
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?
Customer
Order
How to build deployment pipelines?

@aahoogendoorn
www.ditisagile.nl
30
ARE MICROSERVICES
A STAIRWAY TO HEAVEN?
@aahoogendoorn
OR A HIGHWAY TO HELL?
@aahoogendoorn
ARCHITECTURE IN THE
MICROSERVICE WORLD
@aahoogendoorn
FOR THE THINGS WE HAVE TO LEARN

BEFORE WE CAN DO THEM,
WE LEARN BY DOING THEM
Aristotle
@aahoogendoorn
www.ditisagile.nl
34
MICROSERVICES REQUIRE AN EVOLUTIONARY ARCHITECTURE

@aahoogendoorn
www.ditisagile.nl
35
Evolutionary architecture
Microservices are autonomous
Communication over simple protocols
Services need to be able to change independently
APIs for services need to be well-defined
Choose the right technology for the job
Multiple protocols make communication hard
How many different stacks will you support?

New versions of a service can be deployed without hurting
the big picture
Boundaries between services need to be really clear
Choose the protocol that works for you (almost always

REST)
How to design REST verbs and nouns, return codes?
Built around business capabilities
Principles and practices
Always align to business goals
Set up a set of guiding principles
Optimize service autonomy, while keeping the bigger picture
Create practices that support these principles
in mind
How to split up into zones or boxes?

When to split or merge services
How free are individual service teams to decide on
technology?
Be liberal inside the boxes, but strict between them

@aahoogendoorn
www.ditisagile.nl
Create example implementations and service templates

Make it easy for the teams to do the right thing
In order to move to microservices, you will need to get
better at architecture, testing, deployment than you are

right now
36
MICROSERVICES IN EVERYDAY PRACTICE

Architecture at a Dutch insurance company
@aahoogendoorn
www.ditisagile.nl
37
A major Dutch 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
38
Questions, questions, questions
Application architecture
End user facing Different users, different fast evolving needs
Which technology is the best for which purpose?
Communication architecture. The glue

How do we define interfaces between apps and component? How do we arrange messaging?
How do we glue together rapidly changing apps and component?
Component architecture
Components and services are evolving rapidly. How do we decide which components we need?
How do we deal with versioning? How do we deal with distributed processes and transactions?
@aahoogendoorn
www.ditisagile.nl
39
Our 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 microcomponents
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
40
BUSINESS PROCESSES FIRST

@aahoogendoorn
Different levels of processes (and requirements)
@aahoogendoorn
www.ditisagile.nl
43
A high-level business process
Step 1
@aahoogendoorn
www.ditisagile.nl
Step 2
Step 3
Step 4
Step 5
44
Split into work processes
Step 3
Step 3.1
@aahoogendoorn
www.ditisagile.nl
Step 3.2
Step 3.3
Step 3.4
45
Split into elementary processes - OTOPOP
Step 3.3
Step 3.3.1
@aahoogendoorn
www.ditisagile.nl
Step 3.3.2
Step 3.3.3
Step 3.3.4
Step 3.3.5
46
APPLICATIONS
@aahoogendoorn
Micro-applications
Our principles
Each application serves a single purpose

It mostly targets a single audience, either client,
intermediaries, in-house or third parties
Each application implements a single process

Applications are always human facing, they have a
graphical user interface
These user interfaces can be responsive web, native

device or even desktop (not preferred) depending on
the target audience
Each application has a bounded context

Our current stack uses HTML5, JavaScript (client-side),
Bootstrap (responsive UI) and JSF (server-side)
Applications do not communicate with storage

@aahoogendoorn
www.ditisagile.nl
48
Pages
Grids / Panels, Controls
Presentation
Process
Use cases
Flow
Domain
Domain objects, Factories / Repositories

Enums / Value objects / Tupels / Reference objects
Services
Service gateways, Service clients

Info objects / Search objects
Outside world
@aahoogendoorn
www.ditisagile.nl
Relations
Dossiers
Intermediaries
Accounts
Rates
Components
50
COMPONENTS
@aahoogendoorn
Components
Our principles
Components are the workers of our software

architecture
Components are fine-grained and target at serving a
single business purpose, such as Accounts, Relations

or Rates
Components are designed following the Single

Responsibility Principle (SRP).
All components have a bounded context a domain

model
Each component exposes a set of services to the

landscape, which exposes representations of its
bounded context
Components can interact with their own storage

@aahoogendoorn
www.ditisagile.nl
53
Resources
Representations
Service interface
Process
Use cases
Flow
Domain

Storage gateways, Storage clients
Data / Services
Outside world
@aahoogendoorn
www.ditisagile.nl
Relations
Dossiers
Intermediaries
DB2
MongoDB
Storage
55
AND THE REST IS

COMMUNICATION
@aahoogendoorn
Communication
Our principles
Communication between applications and components

needs to be easy to develop, secure and fast
Communication will leverage simple, scalable and safe

web protocols REST over HTTP
Representations from a components bounded context

can be passed in the form of JSON objects
Representations offered by producers do not
necessarily have the same structure as required by

their consumers
Mapping or wrapping is inevitable

Be aware that neither REST nor JSON is really fully
standardized
@aahoogendoorn
www.ditisagile.nl
57
DESIGNING MICROSERVICES
@aahoogendoorn
DOING BIG UP-FRONT DESIGN IS DUMB

DOING NO DESIGN IS EVEN DUMBER
Dave Thomas
@aahoogendoorn
www.ditisagile.nl
61
Design guidelines
Single Responsibility Principle (SRP)
Group together things that change together

Separate things that change for different reason
Product
Account
Microservices size
The smaller your services get, the more extreme you

experience both the benefits and the drawbacks
A team should be able to rebuild a service in two

weeks
Different types of components
Applications, tasks
Customer
Order
Aggregates, references, mediators

Bounded contexts
@aahoogendoorn
www.ditisagile.nl
62
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
63
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
64
The single unified domain model
Vendor
Delivery
Product
Client
Order
Stock
Payment
@aahoogendoorn
www.ditisagile.nl
65
Bounded contexts
Vendor
Delivery
Client
Product
Order
Product
Stock
Payment
@aahoogendoorn
www.ditisagile.nl
66
Bounded contexts
Modeling
Modeled in a (single) domain model
Vendor
Model contains entities, domain objects

Usually evolves around a single main entity (aggregate root)
Services
Interrogate the bounded context
Product
Resources usually follow the aggregate root

Services post and put representations
Representations are mapped to the bounded context
Validation
Stock
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
@aahoogendoorn
www.ditisagile.nl
67
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
68
MODELING
APPLICATIONS
@aahoogendoorn
Back to the elementary processes
Step 3.3
Step 3.3.1
@aahoogendoorn
www.ditisagile.nl
Step 3.3.2
Step 3.3.3
Step 3.3.4
Step 3.3.5
70
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
71
Different levels of use cases
@aahoogendoorn
www.ditisagile.nl
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
72
Smart use cases
@aahoogendoorn
www.ditisagile.nl
73
Wireframes with use cases
@aahoogendoorn
www.ditisagile.nl
74
Application
bounded context
@aahoogendoorn
www.ditisagile.nl
76
76
AND THE REST IS

COMMUNICATION (OVER HTTP)
@aahoogendoorn
HTTP
HTTP
When using HTTP as your transfer protocol you will have to
be very precise about how you use it
Consider HTTP a resource (collection) based protocol

Start from host and port, possibly add component to URIs
Make use of HTTP verbs rather than descriptive URIs
Agree on a limited set of return codes in your communication
between services
Agree when to use which return code
Verbs
GET
POST
PUT
DELETE
@aahoogendoorn
www.ditisagile.nl
83
HTTP RETURN CODES CHEAT SHEET

1**. Hold on
2**. Here you go
3**. Go away
4**. You fucked up
5**. I fucked up
@aahoogendoorn
www.ditisagile.nl
84
HTTP GET
GET
Examples
Retrieve whatever information is
Get an entire collection
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)
@aahoogendoorn
www.ditisagile.nl
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
85
HTTP POST
POST
Examples
Request that the server accepts the
Post to the collection (with entity in body)
entity enclosed in the request as a new

subordinate of the resource identified by
the request URI
localhost:8080/countries
Returning location header

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)
@aahoogendoorn
www.ditisagile.nl
86
HTTP PUT
PUT
Examples
Requests that the enclosed entity is
Put with ID (with entity in body)
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
Update capital (with entity in body)

localhost:8080/countries/38/capital
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)
@aahoogendoorn
www.ditisagile.nl
87
HTTP DELETE
DELETE
Examples
Requests that the resource identified by
Delete
the request URI is deleted.
Returns 200 or 204 (when resource is

deleted), possibly 500 (server error)
@aahoogendoorn
www.ditisagile.nl
88
BE CONSERVATIVE IN WHAT YOU SEND,

BE LIBERAL IN WHAT YOU ACCEPT
Postels Law
@aahoogendoorn
www.ditisagile.nl
89
MODELING COMPONENTS
@aahoogendoorn
Modeling resources
Why?
Services need to be able to change independently, so APIs
need to be well-defined
Allows for testing of your resources
How?
Model resources and representations
Start with the root resource
Add the valid HTTP methods for that resource
Follow paths to sub-resources
Add the valid HTTP methods for that resource

Add the representations that are expected and will be
returned (often in JSON)
Representations reflect your components bounded context

@aahoogendoorn
www.ditisagile.nl
91
Modeling resources
Root resources (component)
/qa
/qa
Questionnaire
/questionnaires
GET the collection, but only limited to this

representation (but with locations likely)
/qa/questionnaires
Id, Name, Description
GET
/{id}
/questionnaires
GET
@aahoogendoorn
www.ditisagile.nl
GET a single item from the collection, but

with representation
/qa/questionnaires/334532
Questionnaire
Id, Name, Description
Question
Answer
Type, Name, Description
Name, Value
92
Resource
model
@aahoogendoorn
www.ditisagile.nl
93
93
Service use cases
@aahoogendoorn
www.ditisagile.nl
94
94
Component
bounded context
@aahoogendoorn
www.ditisagile.nl
97
97
TESTING MICROSERVICES
@aahoogendoorn
Testing microservices
Why is it even more important?
The architecture evolves

We would like to use different technology stacks
We want to be able to replace services
Services version
Releases become much, much shorter

Integration becomes much harder in a microservices
landscape
Bottom line: testing microservices is much more

complex than testing a monolith
Next questions
Test when?
Test what?
@aahoogendoorn
www.ditisagile.nl
100
A service development lifecycle
Prepare & Design
@aahoogendoorn
www.ditisagile.nl
Code
Developer Test
Test
Integration Test
Acceptance Test
Live
101
What to test
Developers
Unit tests
Prepare & Design
Code
Developer Test
Developers
Q&A
@aahoogendoorn
www.ditisagile.nl
Product owner
Product
Testers
Scenarios & APIs
Test
Integration Test
Acceptance Test
Live
Testers
Scenarios & APIs
102
What to test automated

Developers
Unit tests
Prepare & Design
Code
Developer Test
Developers
Q&A
@aahoogendoorn
www.ditisagile.nl
Product owner
Product
Testers
Scenarios & APIs
Test
Integration Test
Acceptance Test
Live
Testers
Scenarios & APIs
103
Developer Q&A Sonar
@aahoogendoorn
www.ditisagile.nl
104
Developer Q&A Sonar
@aahoogendoorn
www.ditisagile.nl
105
Developer Q&A Sonar
@aahoogendoorn
www.ditisagile.nl
106
Developer Q&A Sonar
@aahoogendoorn
www.ditisagile.nl
107
Pages
Integration tests
Grids / Panels, Controls
BDD & Selenium
Presentation
Process
Use cases
Flow
Unit tests
Domain
Unit tests
Services
Outside world
@aahoogendoorn
www.ditisagile.nl

Service gateways, Service clients
Unit tests
Relations
Dossiers
Intermediaries
Accounts
Rates
Components
108
Service interface
Integration tests
SOAP UI or BDD
Process
Unit tests
Domain
Unit tests
Data / Services
Outside world
@aahoogendoorn
www.ditisagile.nl
Dossiers
Use cases
Flow

Storage gateways, Storage clients
Unit tests
Relations
Resources
Representations
Intermediaries
DB2
MongoDB
Storage
109
Integration tests
@aahoogendoorn
www.ditisagile.nl
110
110
DEPLOYING MICROSERVICES
Continuous integration, build pipelines and continuous delivery
@aahoogendoorn
Continuous
Continuous integration (CI)
Mechanism for making sure new code is in sync with

existing code
Developers check-in new code only after merging it

locally with current trunk (or branch)
It is good practice to have unit test to validate merge

Get feedback from tests as soon as possible, already
during development
Continuous deployment (CD)
Each check-in becomes a potential release candidate

Model the build pipeline
Integration tests provide feedback as soon as possible,
immediately after moving to the next environment
@aahoogendoorn
www.ditisagile.nl
112
A typical build pipeline
Prepare & Design
@aahoogendoorn
www.ditisagile.nl
Code
Developer Test
Test
Integration Test
Acceptance Test
Live
113
A typical build pipeline
Development
Prepare & Design
@aahoogendoorn
www.ditisagile.nl
Test
Code
Developer Test
Integration
Test
Integration Test
Acceptance
Acceptance Test
Production
Live
114
Build pipelines in Jenkins
@aahoogendoorn
www.ditisagile.nl
115
Microservices. Building a deployment pipeline

Code
Developer Test
Test
Acceptance Test
Acceptance
Live
Code
Developer Test
Test
Acceptance Test
Acceptance
Live
Code
Developer Test
Test
Acceptance Test
Acceptance
Live
Code
Developer Test
Test
Acceptance Test
Acceptance
Live
@aahoogendoorn
www.ditisagile.nl
116
Microservices. Pipeline hell?
Code
Developer Test
Test
Acceptance Test
Acceptance
Live
Live
Code v.2
Developer Test v.2
Test v.2
Acceptance Test v.2
Acceptance v.2
Test v.2
Acceptance Test v.2
Acceptance v.2
Live v.2
Code v.3
Developer Test v.3
Developer Test
Test
Acceptance Test
Acceptance
Live
Code v.2
@aahoogendoorn
www.ditisagile.nl
117
Continuous delivery and microservices

Versioning
Services version
Allow for clear semantic versioning, such as
MAJOR.MINOR.PATCH
Breaking changes
Try to avoid breaking changes
If there are breaking changes, make sure they appear as
soon as possible
Automated test should signal breaking changes
Team should negotiate
Build pipelines
Create a build pipeline per application and component
In production consider Platform-as-a-Service (e.g. Docker)
@aahoogendoorn
www.ditisagile.nl
118
Dealing with breaking changes
App1
App2
v1
v1
Customer
@aahoogendoorn
www.ditisagile.nl
App1
App2
v2
Customer
App1
v1
App2
v2
App1
App2
v2
Customer
Customer
119
DO WE REALLY NEED PROJECTS?

From projects to releases to continuous delivery
@aahoogendoorn
Do we really need projects?
@aahoogendoorn
www.ditisagile.nl
121
Planning?
@aahoogendoorn
www.ditisagile.nl
122
Or roadmap?
@aahoogendoorn
www.ditisagile.nl
123
Visualise your flow
@aahoogendoorn
www.ditisagile.nl
124
And go with the flow
@aahoogendoorn
www.ditisagile.nl
125
Minimal viable product
@aahoogendoorn
www.ditisagile.nl
128
From projects to continuous delivery?
Project
MVP
Maintenance
Maintenance
Maintenance
Conti
nuous delivery
@aahoogendoorn
www.ditisagile.nl
129
Do we really need projects?
@aahoogendoorn
www.ditisagile.nl
130
@aahoogendoorn
WORDLY WISDOM TEACHES US THAT IT IS BETTER FOR REPUTATION

TO FAIL CONVENTIONALLY THAN TO SUCCEED UNCONVENTIONALLY
John Maynard Keynes
@aahoogendoorn
www.ditisagile.nl
132
IN RETROSPECTIVE?
@aahoogendoorn
Work from roadmaps
@aahoogendoorn
SCALING AGILE FROM THE GROUND UP

13
4
GO WITH THE FLOW

@aahoogendoorn
Minimal viable product
@aahoogendoorn
www.ditisagile.nl
136
FIRST DO IT
THEN DO IT RIGHT
THEN DO IT BETTER
@aahoogendoorn
ALLOW THE TEAM TO LEARN

CONTINUOUSLY
@aahoogendoorn
COMMUNICATION
VIA REST IS NOT
AS EASY AS IT PROMISES
@aahoogendoorn
The hockey stick model
@aahoogendoorn
www.ditisagile.nl
141
AND HAVE FUN
@aahoogendoorn
THIS IS
AGILE
www.createspace.com/4747266
Password: agilescrum
Discount code: KGNWKKWG
@aahoogendoorn
REFERENCES
AND QUESTIONS
www.sanderhoogendoorn.com
www.smartusecase.com
www.speedbird9.com
sander@ditisagile.nl
@aahoogendoorn
@aahoogendoorn

(Libero Events) Microservices

Diunggah oleh

Informasi Dokumen

Judul Asli

Hak Cipta

Format Tersedia

Bagikan dokumen Ini

Bagikan atau Tanam Dokumen

Opsi Berbagi

Apakah menurut Anda dokumen ini bermanfaat?

Apakah konten ini tidak pantas?

Hak Cipta:

Format Tersedia

(Libero Events) Microservices

Diunggah oleh

Hak Cipta:

Format Tersedia

DESIGNING, BUILDING, TESTING

AND DEPLOYING MICROSERVICES

Mentoring Consulting Training Agile Software architecture Code

CTO insurance company

MICROSERVICES? STAIRWAY TO HEAVEN OR HIGHWAY TO HELL?

2015 ditisagile.nl. All Rights Reserved

MICROSERVICES? STAIRWAY TO HEAVEN OR HIGHWAY TO HELL?

2015 ditisagile.nl. All Rights Reserved

Pros and cons of monolithic software

Some principles of service orientation

Components and microservices

MICROSERVICES? STAIRWAY TO HEAVEN OR HIGHWAY TO HELL?

2015 ditisagile.nl. All Rights Reserved

From business needs and features to microservices

MICROSERVICES? STAIRWAY TO HEAVEN OR HIGHWAY TO HELL?

2015 ditisagile.nl. All Rights Reserved

The importance of the deployment pipeline

MICROSERVICES? STAIRWAY TO HEAVEN OR HIGHWAY TO HELL?

2015 ditisagile.nl. All Rights Reserved

WHO OF YOU HAS A SYSTEM THAT IS TOO BIG

MICROSERVICES? STAIRWAY TO HEAVEN OR HIGHWAY TO HELL?

2015 ditisagile.nl. All Rights Reserved

A single (layered) architecture

All parts are interconnected

Many other systems are connected to your system

Doesnt scale very well

MICROSERVICES? STAIRWAY TO HEAVEN OR HIGHWAY TO HELL?

2015 ditisagile.nl. All Rights Reserved

Dependencies will kill you

MICROSERVICES? STAIRWAY TO HEAVEN OR HIGHWAY TO HELL?

2015 ditisagile.nl. All Rights Reserved

MICROSERVICES? STAIRWAY TO HEAVEN OR HIGHWAY TO HELL?

2015 ditisagile.nl. All Rights Reserved

Component based development

MICROSERVICES? STAIRWAY TO HEAVEN OR HIGHWAY TO HELL?

2015 ditisagile.nl. All Rights Reserved

Service oriented architecture

MICROSERVICES? STAIRWAY TO HEAVEN OR HIGHWAY TO HELL?

2015 ditisagile.nl. All Rights Reserved

MICROSERVICES? STAIRWAY TO HEAVEN OR HIGHWAY TO HELL?

2015 ditisagile.nl. All Rights Reserved

Microservices. Beyond the hype?

MICROSERVICES? STAIRWAY TO HEAVEN OR HIGHWAY TO HELL?

2015 ditisagile.nl. All Rights Reserved

Gartner hype cycle

MICROSERVICES? STAIRWAY TO HEAVEN OR HIGHWAY TO HELL?

2015 ditisagile.nl. All Rights Reserved

BUT FIRST A DEFINITION

MICROSERVICES? STAIRWAY TO HEAVEN OR HIGHWAY TO HELL?

2015 ditisagile.nl. All Rights Reserved

MICROSERVICES? STAIRWAY TO HEAVEN OR HIGHWAY TO HELL?

2015 ditisagile.nl. All Rights Reserved

MICROSERVICES? STAIRWAY TO HEAVEN OR HIGHWAY TO HELL?

2015 ditisagile.nl. All Rights Reserved

MICROSERVICES? STAIRWAY TO HEAVEN OR HIGHWAY TO HELL?

2015 ditisagile.nl. All Rights Reserved

MICROSERVICES? STAIRWAY TO HEAVEN OR HIGHWAY TO HELL?

2015 ditisagile.nl. All Rights Reserved

Customer Customer Customer Customer

Account Account Account

MICROSERVICES? STAIRWAY TO HEAVEN OR HIGHWAY TO HELL?

2015 ditisagile.nl. All Rights Reserved

2015 ditisagile.nl. All Rights Reserved