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.
Transforming Data Streams with Kafka Connect: An Introduction to Single Messa...
Â
Welcome to the World of Micro-Apps
1. Welcome to the world of micro-apps
Combing microservices, smart use cases & web applications
Sander Hoogendoorn | Quby | ditisagile.nl
@aahoogendoorn | Welcome to the world of micro-apps
Next
2. Sander Hoogendoorn
Independent dad, new agile coach,
programmer, speaker, author, traveler
Currently
Chief Architect Quby
Before
CTO ANVA
CTO Klaverblad Verzekeringen
Global agile thoughtleader Capgemini
sanderhoogendoorn.com
aahoogendoorn
aahoogendoorn
sander@ditisagile.nl
Next
@aahoogendoorn | Welcome to the world of micro-apps
9. Read more …
Amazon EC2
Then, in 2006, Amazon launched
its Elastic Compute cloud (EC2) as
a commercial web service that
allows small companies and
individuals to rent computers on
which to run their own computer
applications.
16. Read more …
Advantages
A single (layered)
architecture
A single technology
stack
A single code base
maintained by multiple
teams
17. Read more …
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
22. Enter microservices
The world of small component that do one thing only
@aahoogendoorn | Welcome to the world of micro-apps
Continue
23. Click here
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
Microservices
@aahoogendoorn | Welcome to the world of micro-apps
24. Promises and challenges
Of building microservices
@aahoogendoorn | Welcome to the world of micro-apps
Continue
25. Read more …
Promises
Features not projects
Scalable
Decentralized governance
High performance
Easy to build
Easy to test
Replaceable parts
Individually deployable
Technology independent
Polyglot persistence
27. Click here
Given sufficient time any group of
programmers will decide to rewrite
the code.Ron Lunde
@aahoogendoorn | Welcome to the world of micro-apps
Lunde’s Law
31. Click here
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
Microservices
@aahoogendoorn | Welcome to the world of micro-apps
34. What if we would build applications with
similar characteristics as services?
@aahoogendoorn | Welcome to the world of micro-apps
35. Click here
In short, the microservice architectural style is an approach
to developing a suite of small apps, each running in its own process and
communicating with lightweight mechanisms, often an HTTP resource
API.
These micro-apps are built around business capabilities and
independently deployable by fully automated deployment machinery.
There is a bare minimum of centralized management of these apps,
which may be written in different programming languages and use
different data storage technologies.
Martin Fowler
Micro-apps?
@aahoogendoorn | Welcome to the world of micro-apps
36. Business process (at kite level)
Select
Product
Select
Product
Show
Cart
Check out
Cart
Register
Client
Register
CC
Show
Order
Product Order Customer CC Vendor
Apps, workers and microservices
Validate
CC
Confirm
Order (email)
37. Read more …
Benefits
A landscape of micro-apps
Micro-apps are built around a
single business capability
Easy to build
East to test
Deploy individually
Allows for frequent change without
regression
Functional reuse
Allows for front end tech to evolve
38. Optimize for small changes
@aahoogendoorn | Welcome to the world of micro-apps
45. Read more …
Challenges
How to model requirements?
How to break up the single app?
What does the architecture look
like?
How to handle communication
between micro-apps and services?
How to unify the user interface?
How to handle navigation?
What can a micro-app API look
like?
47. Read more …
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
48. Read more …
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 as
much as possible
55. Click here
It is not the strongest of the architectures
that survives, nor the most complex that
survives. It is the one that is most
adaptable to change.
Charles Darwin
@aahoogendoorn | Welcome to the world of micro-apps
Evolutionary architecture
56. Service interface
Process
Domain
Data / Services
Outside world
Resources
Representations
Use cases
Flow
Factories, Repositories
Entities, Enums, Value objects
Gateways
StorageRelations Dossiers Intermediaries Storage
59. User interface
Process
Domain
Data / Services
Outside world
Pages, WebComponents
Grids, Panels, Controls
Use cases
Flow
Factories, Repositories
Entities, Enums, Value objects
Gateways
StorageRelations Dossiers Intermediaries Storage
66. Read more …
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
The bounded context is a central pattern in
domain driven design
67. Click here
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
Eric Evans
Bounded contexts
@aahoogendoorn | Welcome to the world of micro-apps
68. The single unified domain model
Product
Vendor
Stock
Order
Client
Delivery
Payment
76. Click here
Be conservative in what you send,
be liberal in what you acceptJon Postel
Postel’s Law
@aahoogendoorn | Welcome to the world of micro-apps
77. Multiple consumers, same producer
Account
{
id,
firstname,
lastname,
city
}
Login
{
id,
login,
password
}
Manage user
{
id,
firstname,
lastname
}
78. Click here
Even if you do own the services you
consume, still design your consumers to
treat your services as if they were from
elsewhere and vice versa
Sander
Hoogendoorn
@aahoogendoorn | Welcome to the world of micro-apps
Hoogendoorn’s Law
79. Click here
Software entities (classes, modules,
functions, microservices, JSON objects, API’s)
should be open for extension, but closed for
modificationBob Martin
Open closed principle
@aahoogendoorn | Welcome to the world of micro-apps
80. Click here
HTTP Status Codes
Cheat Sheet
1**. Hold on
2**. Here you go
3**. Go away
4**. You fucked up
5**. I fucked up
88. A use case layer supertype (Step)
@aahoogendoorn | Welcome to the world of micro-apps
89. Click here
Navigating micro-apps. From use case to use case
Home
Home
Change
Password
Reset
Password
Manage Account
Find
Account
Manage
Account
Find
Contact
Manage
Contact
Manage Contact
View
Contact
Flows https://integratie.anva.live/managecontact/#/FindContact
Flows.start(Flow.FindContact)
96. Read more …
Why micro-apps?
All the benefits from “regular”
microservices
Easy to build
Easy to test
Flexible and frequent deployment
of individual micro-apps
Easy application of domain driven
design
Replaceable apps
Allows for evolving technology