Alex Thissen (Xpirit) - Een verschuiving in architectuur: op weg naar microservices

1. Microservices – a shift in modern
application architecture
Microservices with Microsoft
Alex Thissen

2. Agenda
• Struggle of modern applications and architectures
• Introducing Microservices architecture
• Moving away from monoliths
• Change in architecture
• Complexity for simplicity
• Characteristics of a Microservices architecture
• Designing and hosting Microservices

3. Where is MSA in hype cycle?

4. Current forces
What’s next in modern application architectures?

5. Valued business drivers
Better
• Resilient
• Technology choice
Cheaper
• Test effort
• Cost of maintaining
Faster
• Change
• Deployment
• Execution

6. About monoliths

7. SOA and Continuous delivery

8. Trends in software development
Platform as a
Service
Autonomous
teams
Continous
Delivery
Agile
Organization
Reactive
Manifesto

9. Modern application architecture
requirements
• Mobile first
• Low bandwidth resilient
• Resilient to failure
• Highly scalable
• 24x7x365
• High frequency of feature delivery
Scalable
Agile
Available
(24x7)
Efficient

10. Microservices Architecture (MSA)
Latest trends in architecture
Objectives: Scalability, Agility, Availability, Efficiency

11. The many definitions of microservices
- Small and
focused on doing
one thing well
- Autonomous
“Loosely coupled service
oriented architecture with
bounded contexts”
Adrian Cockcroft (Netflix)
“SOA done right”
Anonymous
“… services are independently deployable and scalable,
each service also provides a firm module boundary, even
allowing for different services to be written in different
programming languages.”
Martin Fowler (Thoughtworks)

12. Size matters (not)
• It’s not about lines of code used
• Small enough to
• Be handled by a single team
• Not feel “big”

13. Services as a network of independent parts

14. Microservices architecture

15. Every service is independent
• Can have its own technology stack
• Maintains its own state
• Is delivered independent of other parts of the system
• Everything is highly automated
• Each Microservice has its own team
• Both delivery and operations are their responsibility (DevOps)

16. Relation between number of services and
complexity

17. Effect of complexity on system qualities

18. Chosen strategy
Obtain simplicity by adding complexity

19. Benefits
Heterogeneous
technology
landscape
Resilience
against failure
Selective
scaling
Deployment of
smaller pieces
with lower risk
Alignment with
organization
• Ownership with
teams
Composability
Replaceability

20. Microservices Architecture characteristics
• Organized around business capabilities
• Products not Projects
• Decentralized data management
• Decentralized governance
• Componentization via Services
• Design for Failure
• Infrastructure automation
• Evolutionary Design
Source: http://martinfowler.com/articles/microservices.html

21. • Organized by logical cohesion
• Teams own layers spanning domains
• Unified technology choice
From horizontal to vertical
Change your approach to vertical partitions
• Modeled after organization’s domains
• Owned by team
• Top to bottom
• Isolated from each other as much as possible

22. Achieving your goals
Apply Microservices’ principles and practices:
• Low coupling and high cohesion
• Asynchronous over synchronous
• Choreography over orchestration

23. Low coupling
Components are
completely
insensitive to changes
and errors in other
components.
No
Coupling Error and changes
seldom propagate
errors and changes to
dependent
components
Low
Coupling Errors and changes in
one component
almost always
propagate to other
components
High
Coupling
Measurement of dependency between two components
Expressed as sensitivity towards propagation of changes and errors

24. High cohesion
Degree to which parts of a module belong together
Levels:
Coincidental
cohesion
(worst)
• random
Logical
cohesion
• same in nature
Temporal
cohesion
• executed at a
particular time
Procedural
cohesion
• part of fixed
execution
sequence
Informational
cohesion
• operating on
the same data
Sequential
cohesion
• Output of one
is used as input
by another
Functional
cohesion
(best)
• contributing to
a single task

25. Hands-on
Design your own Microservices

26. How to find autonomous systems?
• Grouping all synergistic business functions together into one system
• aka Autonomous Business Capability (ABC)
“Two business functions A, B are synergistic if and only if, from
the business perspective, A is not useful without B and B is not
useful without A.”
• Functions without synergy go into different systems

27. Example – Home Finance System
Deposit
Funds
Setup
Payment
Reminder
Create
New
Budget
Cancel
Payment
Reminder
Withdraw
Funds
Write
Check
Add
Expense
List
Expense
Source: Roger Session’s – Simple Architecture for Complex Enterprises

28. Deposit
Funds
Setup
Payment
Reminder
Create
New
Budget
Withdraw
Funds
Cancel
Payment
Reminder
Write
Check
Add
Expense
List
Expense
Source: Roger Session’s – Simple Architecture for Complex Enterprises
Applying synergistic partitioning to
Home Finance System

29. Frontend integration
Freedom of choice
Social ProductReport
Graph DocumentBlob

30. Bounded contexts

31. Which Service owns this page?

32. None!

33. Composition is key!

34. Example:
otto.de

35. Example Microservices architecture - otto.de
• 11 verticals
• Autonomous
teams around a
component
• Independently
deployable
• Own data
storage
Source: http://ottodev.files.wordpress.com/2013/11/teile-und-herrsche-
kleine-systeme-fc3bcr-groc39fe-architekturen.pdf

36. Example Microservices architecture - otto.de
• Each with own UI (on website)
• Well defined interfaces
• No shared code or state
• REST interfaces for each vertical
• Pull based data replication
• Front end integration
(JavaScript/Edge Side Includes)

37. How to implement inter-system
dependencies?

38. Event Driven Architecture
• Systems keep their own state
• Events are used to notify changes
• Systems use events to replicate data
• Each service will have its own database
• Downsides:
• Latency in data changes
• No central control of business logic
• Challenge to reconcile in case of disaster

39. Why are event driven architectures relevant?
• Increased use of asynchronous notifications
• Mobile push based notifications, Twitter, Whatsapp, et cetera
• Increased application of asynchronous languages and frameworks
• Javascript, node.js, AJAX, C# async and await, Signal R
• Increased need for fast, robust and scalable systems
• Reactive Manifesto
• Increased need for systems agility
• Faster, more frequent changes

40. Cross-service coupling
• Smart endpoints, dumb pipes
• No intelligent middleware
• Technologies to look at:
• Queues (Azure, MSMQ, WebSphereMQ , ...)
• Service Bus (NServiceBus, Azure ServiceBus, Azure EventHub, ...)
• Language neutral data serialization
(Google Protocol buffers, Apache Thrift, AMQP)

41. Designed for failure
• Services can and will fail: prepare!
• Do not rely on another service’s
availability
• Introduce features in your app to deal
with it
• Test under stress and
with failing services

42. Circuit Breaker Pattern
Handle faults that may take a variable amount of time to rectify when
connecting to a
• remote service or resource.
• This pattern can improve the
stability and resiliency of an
application.

43. Circuit Breaker Pattern
• Fails immediately after a
number of (slow) failures
• Careful rampup after cool-
down period
• Works together with
Retry Pattern

44. Retry Pattern
Enable an application to handle temporary failures when connecting to
a service or network resource by transparently retrying the operation in
the expectation that the failure is transient. This pattern can improve
the stability of the application.

45. Command and Query Responsibility
Segregation
• Traditional CRUD
• Mismatch between read and write representations
• Contention of database
• Solution: Segregate operations for reading and writing

46. • CRUD approach:
• Updates directly against
datastore
• No recorded history
Solution:
Handle operations on data by
events which are recorded in
append-only database
Event sourcing

47. Hosting Microservices

48. Services up and running
OS
Virtual
machines
PaaS
Container
runtimes

49. Hosting your services
Host
Application
container
Micro
Service
Micro
Service
Host
Micro
Service
Micro
Service
Micro
Service
Micro
Service
Host
Micro
Service
Host
Micro
Service
Host
Micro
Service
Host
Micro
Service
Hosting in
application
container
High density
hosting
One service
per host

50. App
A
Virtual Machines and Containers
Hypervisor (Type 2)
Host OS
Server
Guest
OS
Bins/
Libs
App
A’
Guest
OS
Bins/
Libs
App
B
Guest
OS
Bins/
Libs
AppA’
Host OS
Server
Bins/Libs
AppA
Bins/Libs
AppB
AppB’
AppB’
AppB’
VM
Container
Containers are isolated,
but share OS kernel and, where
appropriate, bins/libraries
Guest
OS
Guest
OS
…result is significantly faster
deployment, much less overhead,
easier migration, faster restart

51. Problems and solutions
• Rolling upgrades
• Availability guarantees
• Scale out architecture
• Resource governance
• Density
• Packaging and deployment
• Policy enforcement
• Granular versioning
• Stateful workloads
• Leader election
Mesos
Kubernetes
Zookeeper
Redis
Raven
MongoDB
Yarn
Fleet
Hadoop
Containers

52. Public Cloud Hosted CloudsPrivate cloud
Lifecycle
Mgmt
Independent
Scaling
Independent
Updates
Always On
Availability
Resource
Efficient Stateful
Microservice-based applications

53. The Microservice premium
Is a Microservice architecture a
good choice for the system you're
working on?
Source: http://martinfowler.com/articles/microservices.html
It depends!

54. Summary
• Microservices is the new hot thing
• Still maturing, lot to be learned and
discovered
• Might not be for everybody
• Think of a strategy to implement your
Microservices
• Migrate gradually
• Evaluate specialized hosting platforms and
frameworks and technologies

55. http://www.xpirit.com
Leading IT specialists in
Microsoft Application Lifecycle Management,
Cloud, Enterprise Mobility & Security style