The document discusses microservices and two case studies of companies adopting a microservices architecture. In the first case study, a major insurance company moved from a monolithic architecture to microservices in order to improve scalability, use multiple technologies, and develop features independently. They focused on modeling business processes and implemented services around individual processes. The second case study involved a product development company migrating an existing system to microservices. They redesigned the architecture with bounded contexts and migrated components incrementally. The document also covers microservices design principles, modeling resources as RESTful services, and challenges with testing microservices.
The Real-World Challenges of Medical Device Cybersecurity- Mitigating Vulnera...
Microservices. Stairway to heaven or highway to hell
1. @aahoogendoorn | www.ditisagile.nlMicroservices. The good, the bad and the ugly 1
@aahoogendoorn | www.ditisagile.nl
Microservices.
Stairway to heaven
or highway to hell?
Sander Hoogendoorn
ditisagile.nl
Mentoring ▪ Consulting ▪ Training
Agile ▪ Software
architecture ▪ Code
2. @aahoogendoorn | www.ditisagile.nlMicroservices. The good, the bad and the ugly 2
Sander Hoogendoorn
Me
Dad
Mentor, trainer, software architect,
programmer
Books, articles, conferences
Work
Owner ditisagile.nl
CTO Klaverblad Insurances
Web
www.sanderhoogendoorn.com
@aahoogendoorn
sander@ditisagile.nl
6. @aahoogendoorn | www.ditisagile.nlMicroservices. The good, the bad and the ugly 7
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
Monoliths
Advantages and disadvantages
19. @aahoogendoorn | www.ditisagile.nlMicroservices. The good, the bad and the ugly 20
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
20. @aahoogendoorn | www.ditisagile.nlMicroservices. The good, the bad and the ugly 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
21. @aahoogendoorn | www.ditisagile.nlMicroservices. The good, the bad and the ugly 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
28. @aahoogendoorn | www.ditisagile.nlMicroservices. The good, the bad and the ugly 29
Products not projects
Scalable
Decentralized governance
Replaceable parts
High performance
Technology independent
Polyglot persistence
Easy to build
Easy to test
Easier deployment than monoliths
Microservices
Promises
29. @aahoogendoorn | www.ditisagile.nlMicroservices. The good, the bad and the ugly 30
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?
Microservices
But…
47. @aahoogendoorn | www.ditisagile.nlMicroservices. The good, the bad and the ugly 48
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
Our guiding principles
Case 1
62. @aahoogendoorn | www.ditisagile.nlMicroservices. The good, the bad and the ugly 64
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
63. @aahoogendoorn | www.ditisagile.nlMicroservices. The good, the bad and the ugly 65
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
69. @aahoogendoorn | www.ditisagile.nlMicroservices. The good, the bad and the ugly 71
Root resource (component)
GET the collection, but only limited
to this representation (but with
locations likely)
GET a single item from the
collection, but with representation
Modeling resources
86. @aahoogendoorn | www.ditisagile.nlMicroservices. The good, the bad and the ugly 91
@aahoogendoorn | www.ditisagile.nl
Deploying
microservices
Kaizen, minimal viable
products and continuous
delivery
92. @aahoogendoorn | www.ditisagile.nlMicroservices. The good, the bad and the ugly 98
An approach in which teams ensure that every
change to the system is releasable, and that we
can release any version at the push of a button.
Aimed to make releases boring, so we can deliver
frequently and get fast feedback on what users
care about.
Jez Humble
109. @aahoogendoorn | www.ditisagile.nlMicroservices. The good, the bad and the ugly 118
@aahoogendoorn | www.ditisagile.nl
References
and questions
www.sanderhoogendoorn.com
www.smartusecase.com
www.speedbird9.com
sander@ditisagile.nl
@aahoogendoorn