Do more with less, the pain of the modern architect. High cohesion & low coupling, high availability & scale, ease of DevOps. Our systems need to support all these quality attributes, while providing more functionality with less resources. We need to be agile, we need to embrace changes, we need to have a better way! Micro-Service-Architecture (MSA) promises to bring cure to the architect's pains, but does it really deliver? This lecture presents the essence of MSA, how does it answer main concerns of modern distributed systems, how to get started, how to migrate current solutions to MSA by adopting an evolution migration path. What to be careful about and the signs that we are on the right track. We will talk about SA evolution, the CAP theorem and eventually consistency, MSA principles, hosting. containers, versioning, orchestrators & decoupling business processes. By the end of this lecture the participant will have a better understanding of why, when and how to embrace MSA.

1. To Microservice or Not to Microservice?
Alon Fliess
Chief Software Architect
alonf@codevalue.net
http://blogs.microsoft.co.il/blogs/alon
Microservices – Why and When?

2. Agenda
Software Architecture
Microservices
Eventual consistency
Hosting & Containers
Orchestration and Choreography
Evolution vs. Revolution

3. About Me
Alon Fliess:
Chief Software Architect & Co-Founder at CodeValue Ltd.
Over 25 years of hands-on experience
Microsoft Regional Director
Microsoft Azure MVP
Renowned speaker at both international and domestic events

4. Cloud Computing
Advanced Mobile
Technologies
UI/UX & Graphic
Design
Cross Platform
Development
Advanced Web
Technologies
ALM & DevOps Software Architecture
IOT & Embedded
Software
Training & Mentoring
Development
Management &
Methodology
About CodeValue

5. Debug like a wizard Quit debugging, spend more time writing brilliant software
Magic Glance / Figure out complex expressionsLINQ Debugging / Know the flow of your LINQ queries
Reveal / Focus on data that actually matterSearch/ Find that needle in a haystack of data
With our Visual Studio extension for C#, follow the road to a bug-free world
oz-code.com | @oz_code

6. Is this a good design?

7. Is this a good design?

8. What about this?

9. ?

10. Cohesion & Coupling
Cohesion - The degree to which a module
performs one and only one function
Coupling - The degree to which each program
module relies on each of the other modules
Low coupling often correlates with high
cohesion, and vice versa
Tightly coupled systems tend to:
Ripple (cascading) effect of changes
Can’t reuse a single module
Testing becomes a nightmare!!!
The DevOps process becomes a nightmare!!!

11. The Cost of the Software Development Process
number of modules
Module
Integration
cost (complexity)
module
development
Cost (complexity)Cost

12. The 24/7 Challenge
How do you update a system running
24/7/365?
How do you keep the application servers
responsive?
How do you keep all application servers
synced?
How do you update the data/schema?
How do you update all your clients’ software?
Web, Mobile, Desktop…
How do you rollback on error?
How do you rollback data?
How do you know there is an error?
12

13. Microservices Architecture (MSA) - Wikipedia
“Microservices is a specialization of and implementation approach for
service-oriented architectures (SOA) used to build flexible,
independently deployable software systems”
“Services are small in size, messaging enabled, bounded by contexts,
autonomously developed, independently deployable, decentralized
and built and released with automated processes”
“The benefit of distributing different responsibilities of the system into
different smaller services is that it enhances the cohesion and
decreases the coupling”
13

14. MSA Evolution
14

15. Micro Service Architecture
Some principles:
A micro service should be less then 100 lines of code
100 is just a number that emphasizes: small
Usually can be developed in one scrum sprint
It should be easy to understand, fast to deploy, and cheap to
reimplement (throw the old one)
A micro service should be independently developed &
deployed
A micro service should has private data ownership
Eventual Consistency
Versioning
15

16. MSA – Accessing Data
16
Consistency
PartitioningAvailability
CAP Theorem

17. Eventual consistency
“The value across all nodes will be consistent with the last update
that was made -- eventually”
The sunlight that you see indicates that the sun was still
there eight minutes ago!
When you see in a shopping site that a product is available,
is it?
Handling eventually consistency is not easy
17

18. Remote
Service
Client
CDN
Service
Service
Service
Service
Service
Discovery
Management
API
Gateway
Static
Content
Identity
Provider
MSA - a Simplified Architecture
18

19. MSA - Signs that you do something wrong
If you find the need to deploy
services together
If you have a single codebase for all
your services
If you find you have a service talking
directly to the database of another service
If you have to send out a warning before each
deploy of a service
19
DB
Service A Service B

20. Hosting & Containers
To execute code, it has to be hosted
The host provides the runtime environment and facilities
Traditional hosts:
Process - Exe, Windows Service, Windows Task Scheduler,
Unix Demon, App Domain, COM Service, Windows Job Object
Web Server – IIS, Apache, NGINX
Modern Hosts
Virtual Machine (on premise hosted & cloud Hosted)
Amazon Lambda, Azure Functions
Containers – Docker, Service Fabric, Windows Containers, Hyper-V Containers
20

21. Container Orchestrators Tasks
Scheduling:
Find a suitable machine on which to run the container
Affinity/Anti-affinity: Specify that a set of containers should run nearby each other
Or sufficiently far apart (for availability)
Health monitoring:
Watch for container failures and automatically reschedule them
Failover:
Keep track of what is running on each machine
Reschedule containers from failed machines to healthy nodes
Scaling:
Add or remove container instances to match demand
Networking:
Provide an overlay network for coordinating containers to communicate across multiple host machines
Service discovery:
Enable containers to locate each other automatically
Even as they move between host machines and change IP addresses
Coordinated application upgrades:
Manage container upgrades to avoid application down time
Enable rollback if something goes wrong
21

22. Microservices Platforms Benefits
Modern microservices platforms significantly reduce the cost of
module integration
Shifting the cost equilibrium towards more modules
Especially true when using proven PaaS platforms
Both public and private cloud based
The integration cost decreases with two factors:
Mature PaaS platform
Proven DevOps process
22

23. MSA  Eliminates Legacy Code
Since:
A microservice is isolated
Has no software foundation dependency with other microservices
Small in size and in lines of code
Can be patched (replaced) without application downtime
Anytime that a developer opens the microservice image code to fix a
bug or add a new feature:
An upgrade to the dev environment and software foundation can be made!
The result:
No more legacy code!!!
23

24. Orchestration vs Choreography
24
Shipping
Service
S
h
i
p
Invoice
Service
Pub/Sub
Client
UI
S
h
i
p
e
d
S
h
i
p
e
d
Client
UI
Shipping
Manager
Shipping
Engine
Invoice
Engine
Tracking
Service
Tracking
Engine

25. From Monolith to MSA
How do we make the change?
25

26. Revolution
Start from scratch
Gather requirement from old system and new business needs
Modern Architecture, no constraints
Analyze potential risks
Problems:
High risk
Not all requirements are known
Hard to predict time and effort
Takes time to reach stability
Need to run old and new system side by side
Need to maintain two systems for long time
26

27. Evolution
Start from the current solution
Analyze the current solution for the
good, the bad and the ugly
Define the future vision of the system
Define the future architecture and technology
Conduct a gap analysis process
Find stable components and services
Decide which component to change, which to reuse
by migrating and wrapping
Define how the new system handles the data and consistency
Co existence of new and old services
27

28. Evolution
Define the migration process strategy
A new code that uses an old code – paint over rust
An old code that must be changed to use new services
Define project release plan
As opposed to the revolution approach, releases can
and should be deployed to the production environment
Analyze potential risks
Define risk mitigation process – usually by conducting a research and
POCs
Conduct POCs to reduce the risk
28

29. Evolution or Revolution
In most cases I’d choose the evolution approach
Choose the revolution approach if:
The current project technology is obsolete
There are too many black boxes that no one in the company knows how to maintain
The current project architecture is highly coupled
You can still use the old solution as a monolith that provides many services
The current solution is too buggy that fixing it will cost more then rebuilding it
The new technology can not communicate and host the old code
There are major 3rd party component that are no longer supported
Evolutions vs Revolution is not black & white
There are many gray shades, part of the system can be totally redeveloped, other
parts can be reused
29

30. Microservices
Are Microservices the solution?
They also start with good intentions
Will become convoluted with time as well
Without proper architecture and guidance
30

31. Microservices Drawbacks Solution
Plan ahead
DevOps
Use supporting platforms
Cloud
Containers
Architect
Low Coupling, High Cohesion
Schema/API Versioning
31

32. So Should I Do Microservices?
YES, but only if you have:
Capable architects
Rapid compute provisioning
Mature CI/CD pipelines
Advanced DevOps culture
OR – get some experts to help 
32
Source: https://bit.ly/2oro8Pi

33. 33