Microservices have been around since a few years, and many organizations are starting to benefit from these autonomous, independently deployable and easy maintainable small blocks of code. However, if you examine some of the popular definitions of microservices, we are still building a single application as a suite of small services.
During this talk Sander Hoogendoorn will explain and demonstrate how front-end development can also benefit from building it in small autonomous, independently deployable blocks of code, instead of implementing a single monolithic web application. Of course, Sander will use many code examples in Java, Angular and Typescript (and probably some live coding) to illustrate even better how to build micro-applications similar to your microservices.
1. Welcome to the world
of micro-applications
Combing microservices, smart use cases & web applications (with Angular)
Sander Hoogendoorn | ditisagile.nl
@aahoogendoorn | www.ditisagile.nl | Do or don't there's no Try. Or is there? The power of monads explained. Sort of.
Next
2. Sander Hoogendoorn
Independent dad, software architect,
agile coach, programmer, speaker, writer
[Former] CTO ANVA
Former CTO insurance company
Former global agile thoughtleader
Capgemini
sanderhoogendoorn.com
aahoogendoorn
aahoogendoorn
sander@ditisagile.nl
Next
3. Click here
@aahoogendoorn | www.ditisagile.nl | Do or don't there's no Try. Or is there? The power of monads explained. Sort of.
4. Click here
@aahoogendoorn | www.ditisagile.nl | Do or don't there's no Try. Or is there? The power of monads explained. Sort of.
7. Continue
Monoliths. 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
9. More …
Monoliths
Hard to deliver. Harder to test. Impossible to maintain.
@aahoogendoorn | www.ditisagile.nl | It's a small world after all
10. Enter microservices
The world of small component that do one thing only
Continue
@aahoogendoorn | www.ditisagile.nl | It's a small world after all
11. Continue
Microservices
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 | It's a small world after all
16. Continue
Challenges
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 communication patterns do you apply?
How to test microservices
How to build deployment pipelines?
Containers anyone?
18. Continue
Microservices
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. Click here
A business process
Select product Select product Show cart Check out cart Register client Register CC Show order
Product Order Customer Credit card Vendor
Apps, workers and microservices
Validate CC Confirm order
via email
21. Continue
Benefits
Small and thus simple
Built around a single business capability
Easy to build
East to test
Deploy individually
Allows for frequent change without regression
Reuse
A platform of small services
instead of having a single application
22. Continue
Challenges
How to model requirements
in micro-applications?
What does the architecture look like?
Do micro-apps have there own domain
model or bounded context?
How to handle communication between
micro-apps and services?
What does the API look like?
How to unify the user interface?
How to handle navigation?
25. Continue
Some guiding principles
We implement business processes
We move towards a systems landscape
consisting of micro-applications and
microservices
Requirements are modeled (in smart use
cases)
Micro-applications implement a single
elementary business process step
Micro-applications and microservices all
have their own bounded context
26. Continue
Some guiding principles
Micro-applications do not have storage, and
only talk to other micro-applications and
microservices
Microservices have their own storage (in
MongoDB), and only talk to other
microservices
Communication uses a simple open protocol
– JSON on REST
We avoid transactions like the plague
We make it work first, and build (security
and) performance in next
33. Click here
Service interface
Process
Domain
Data / Services
Outside world
Resources
Representations
Use cases
Flow
Factories, Repositories
Entities, Enums, Value objects
Gateways
StorageRelations Dossiers Intermediaries MongoDB
42. Continue
The SOLID principles
Single Responsibility Principle
Open Closed Principle
Liskov Substitution Principle
Interface Segregation Principle
Dependency Inversion Principle
43. Continue
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 that module
All its services should be narrowly aligned
with that responsibility
44. Click here
Single responsibility principle
Group together things that change together
Separate things that change for different
reason
45. Continue
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
46. Continue
Bounded context
A model needs to be unified –
internally consistent without
contradictions
The bounded context is a central
pattern in domain driven design
47. Click here
Bounded context
When you model larger domains, it becomes
progressively harder to create this single unified
model.
Instead of creating a single unified model, you
create several, all valid within their bounded
context
48. Click here
The single unified domain model
Or more often the humongous data model
Product
Vendor
Stock
Order
Client
Delivery
Payment
54. Click here
Communcation breakdown
Presentation
Process
Domain
Services
Outside world
Pages
Grids, Panels, Controls
Use cases
Flow
Factories, Repositories
Entities, Enums, Value objects
Gateways
ComponentsRelations Dossiers Intermediaries Accounts Rates
Service interface
Process
Domain
Data / Services
Outside world
Resources
Representations
Use cases
Flow
Factories, Repositories
Entities, Enums, Value objects
Gateways
StorageRelations Dossiers Intermediaries MongoDB
56. Click here
Open closed principle
Software entities (classes, modules, functions,
microservices, JSON objects, API’s) should be
open for extension, but closed for modification
57. Click here
HTTP Return Codes
Cheat Sheet
1**. Hold on
2**. Here you go
3**. Go away
4**. You fucked up
5**. I fucked up
62. Click here
Navigating micro-apps
First step: entering
Home
Home app
Change
Password
Reset
Password
ManageAccount app
Find
Account
Manage
Account
Find
Contact
Manage
Contact
ManageContact app
View
Contact
Flows
https://integratie.anva.live/home/#/Home
63. Submit
Angular takes care of the routing
@aahoogendoorn | www.ditisagile.nl | Do or don't there's no Try. Or is there? The power of monads explained. Sort of.
64. Submit
An actual use case
@aahoogendoorn | www.ditisagile.nl | Do or don't there's no Try. Or is there? The power of monads explained. Sort of.
65. Submit
A use case layer supertype (Step)
@aahoogendoorn | www.ditisagile.nl | Do or don't there's no Try. Or is there? The power of monads explained. Sort of.
66. Click here
Navigating micro-apps
From use case to use case
Home
Home app
Change
Password
Reset
Password
ManageAccount app
Find
Account
Manage
Account
Find
Contact
Manage
Contact
ManageContact app
View
Contact
Flows
https://integratie.anva.live/managecontact/#/FindContact
Flows.start(Flow.FindContact)
70. Click here
Navigating micro-apps
Finishing work on a use case
Home
Home app
Change
Password
Reset
Password
ManageAccount app
Find
Account
Manage
Account
Find
Contact
Manage
Contact
ManageContact app
View
Contact
Flows Flows.ok(this.contact.id)
https://integratie.anva.live/home/#/Home?c=Cancel&backFrom=managecontact.FindContact
back(id)
74. Continue
Why micro-applications?
All the benefits from “regular” microservices
Easy to build
Easy to test
Flexible and frequent deployment of individual
functions
Allows application of domain driven design
easily
Takes time to implement the mechanism
Keep UI unified by creating library of reusable
UI components
Works with any technology