If I have to name a single hype in software architecture land then I would have to mention the micro-service architecture. Microservices are supposed to be small, have a very focused purpose, can be deployed independently, are completely self-supporting and loosely coupled. Ideally, microservices are technology agnostic, but hey, we're in the .NET space, aren't we? And they are not a goal, but a means to an end. In fact, a microservice architecture has many benefits and are a great strategy for decomposing a monolith. So how do you build a microservice? What technologies does the .NET realm offer for us? And what if you don't want to deploy them independently? In this talk, I'll show you some of the pros and cons of microservices and how you can leverage OWIN and .NET to move your monolith into a bright new future.
4. Hybrid of
Front-end
Technologies
Multiple
patterns for the
same problems
Long compile
time
Large source
control
repositories
Long-running
unit tests
Too much
coupling
Limited
team scalability
Devs need to
know everything
NoIsolationProductivity
drops over time.
5.
6. • The network is reliable
• Latency is zero
• Bandwidth is infinite
• The network is secure
• Topology doesn't change
• There is one administrator
• Transport cost is zero
• The network is homogeneous.
https://en.wikipedia.org/wiki/Fallacies_of_distributed_computing
8. Very scalable,
very reliable
Very difficult to
debug
distributed
problems
Unreliable
network
requires
complicated
techniques
Requires
message
bus/broker
End-to-end
testing very
unpractical
Very mature
DevOps culture
is a prerequisite
Advanced
monitoring and
visualization is a
must
Security can not be an
afterthought
High operational
maintenance.
Can be
deployed/upgraded
independently.
9.
10. Monolith
Microservice
Microservice
Microservice
HTTP API
HTTP API
HTTP API
OWIN component
released through
MyGet/Nuget
No network I/O at all
Can have its own database
instance, shared with monolith,
or shared storage service
Microservice owns
the schema
Separate repos with
distinct owners.
Runs in-process, thus
easier debugging
New version
requires
redeployment of
the monolith.
Loose coupling
through HTTP
Less scalability
options
HTTP is not the
fastest
serialization
format
Relies on libraries,
not frameworks.
13. Monolith
Microservice
HTTP API
Service Registry
Contract
documented through
Swagger
Webhooks
Microservice
Microservice
Provides OWIN-
aware HttpClient to
connect to service
Event payload
exposed as Swagger
(e.g. SwaggerHub)
Subscribers register
URLs or in-process
OWIN message
handler
API/payload
consumers use liberal
JSON interpretation
Circuit Breaking to
handle unreliable
consumers
At-least-once payload
delivery
Subcribers can
request replays.
Payload includes ID
to help idempotency
Each request requires
correlation ID that flows
through all APIs, webhooks
and services
14.
15. Aggregates
Command Handlers
Queries
Commands
Events
Upconverters
Value Objects
Query
Handlers
Schema
Migrations
Projectors
Data
Importers
Query API
Jobs
Projections
HTML
CSS
JS
API
Controllers
Projectors
Projections
Registrations
Webhook API
Command
API
Event Storage
Payload
Definitions
Outer layers depend
on inner layers
Domain is persistency
ignorant
Can be tested
independently
For eventual
consistent business
rules
Master data
To support domain
queries
For microservices
that provide a
(partial) UI or
management screen
Based on Domain
Driven Design
Supported by LibLog,
TinyIoc
Designed according
to the 12 Factor
principles
16. UI / HTTP API
Command
Service
ChangeUser
EmailHandler
User
Unit of
Work
User
Projector
DAL
Read DB
Write DB
ChangeUserEmailCommand
Execute query
Get<User>(identity)
Invoke method
Event Store
Load(events)
Apply
Get changes
Dispatcher Events
Handle(UserEmailChangedEvent)
Submit changes
History
Dennis Doomen | @ddoomen | The Continuous Improver
17. Monolith
Microservice
HTTP API
Event Store
Events
Payload
Projector
Subscription
Request
Payload
‘event store’
Projectors use
LiquidProjections
Have their own
checkpoints
Projects fine-grained
events into payload
projections
Projector
Payload schema is
documented using
Swagger
Projector
Projector
Webhook Projectors
Separate
instance per
subscription
Subscriber
HTTP API
‘Project’ payload
‘event store’ into
HTTP calls
Projected Data
Uses the incoming
payloads as an ‘event
store’
Payload
Use Circuit Breakers
to handle
slow/unavailable
subscribers
SQL DB Schema
changes using
FluentMigrator
or using NoSQL
DB
20. Events
Transaction 6
Transaction 5
Transaction 4
Transaction 3
Transaction 2
Transaction 1
Temporal
Projector
Read
Store
Time
Projected until
this point
Immutable, thus
auditable and SOX
compliance
Dennis Doomen | @ddoomen | The Continuous Improver
30. Rebuild schema in-place
– Rebuilding using event store
– Requires tracking API
– Involves down-time.
31. Disallow breaking changes
– Only new ‘columns’ and ‘tables’
– Partial rebuilding using event store
– Requires forwards compatibility.
32. Rebuild side-by-side
– Rebuilding using event store
– Requires tracking API
– Requires compatibility with
previous ‘schema’
– Previous ‘schema’ is removed in the
next release.
33.
34. Microservice
Bunch of classes that
should be used directly
X
No inheritance
Uses composition
over inheritance
internally
Convenience classes
that don’t hide the
magic
Library
Abstract Package
Interfaces
Delegates
DTOs
Only depend
on abstract
packages…
Stable Package
…or depend on more
stable packages
Auxiliary
Package
Classes that are not
used together do not
belong togetherOptional
Dependency
Dependency
Package
Consumers should
not be faced with
optional
dependencies
37. Monolith
Microservice
Microservice
Microservice
HTTP API
HTTP API
HTTP API
Apply routing
conventions
Versioning
using Accept Headers,
Response Headers or
Routes
Optimize body using
AVRO or Protobuf
Cross-service tracing
using OpenTracing
Replace OWIN with
(upcoming) in-
process gRPC
Common contracts
for diagnostics,
monitoring
Add KPI dashboards,
e.g. Sumologic
38.
39. 1 Build a (container-based) cloud
capability.
2 Deploy monolith to the cloud.
3 Automate your delivery pipeline.
4 Full end-to-end responsibility
5 Break-up delivery teams and code
6 Evaluate status-quo on micro-services
(products, platforms, etc)
7 Slide-and-dice microservices one-by-
one.
40.
41. • Liquid Projections – The Example
https://github.com/liquidprojections
• Bliki: MonolithFirst
https://dzone.com/articles/martin-fowler%E2%80%94bliki
• In-process gRPC
https://github.com/grpc/grpc-go/issues/906
• Protobuf in WebAPI
http://www.infoworld.com/article/2982579/application-
architecture/working-with-protocol-buffers-in-web-api.html
• Ingredients for well-design OWIN components
http://www.continuousimprover.com/search/label/OWIN%20Recip
es
• The good, the bad and the ugly of Event Sourcing
http://www.continuousimprover.com/search/label/event%20sourci
ng