Microservices easywaywrongway

Microservices – The Easy Way is the Wrong Way

Goal
Show that
Microservice Architecture takes
more consideration than you
may expect

Agenda  What are microservices
 Why should I use them
 When should I NOT use them
 Challenges
 Decomposition (high-level)

What are microservices

 Independent applications
 Communicate over network
 Has single responsibility
 Owned by one team
 Individually deployable
 Architecture style

Monolith

Monolith Microservices
extract
new

• Move functionality
• Add functionality
• Rare total migration

The microservice architecture is an implementation of
Distributed Computing

Why should I use microservices
To deliver business functionality
 Quicker
 Safer
 Stability

Team Autonomy
- Best language for the job
- Focused development
- Agile works well
Team Autonomy
Service Autonomy
Scalability
Fault Isolation

Service Autonomy
- Single Responsibility
- Deployable without other services
Team Autonomy
Service Autonomy
Scalability
Fault Isolation

Scalability
- Scale independent of others
- Choice of servers
Team Autonomy
Service Autonomy
Scalability
Fault Isolation

Fault Isolation
- Your problems aren’t my problems
- “Stay in your lane bro”
Team Autonomy
Service Autonomy
Scalability
Fault Isolation
A B C
D E
X

Who uses microservices

Why should I NOT use microservices

THEY’RE HARD!!!
This Photo by Unknown Author is licensed under CC BY-SA-NC
So is good
programming, but…
Why should I NOTuse microservices

Why should I NOTuse microservices
• Monolith is too small
• Too much coupling – need refactoring first
• Team unwilling or not ready
• No support structure
• High cost of time and money

Challenges to making microservices

Easy Reality
Cheap Cost time, money, learning, investing
HTTP to IP address Messaging; RPC; sync vs async; pub/sub
Copy files to servers CI / CD pipeline per Microservice
Single Repo Should use Repo per Microservice
Network not my job Need to know about OSI Model; Layer 4 and 7
Security non-issue TLS for service communication layer;
OAuth for application layer
Common Code Sharing code keeps services tightly coupled

• HTTP7. Application
6. Presentation
5. Session
• TCP / UDP4. Transport
• IP / ARP / ICMP / IGMP3. Network
2. Data Link
1. Physical

Service
A
V1.0
Team A Team B
Service
B
V1.0Nuget
Package
Service
A
V2.0

Service
A
V1.0
Team A Team B
Service
B
V1.0Nuget
Package
Service
A
V2.0
Service
B
V2.0
Changes in Package for Service A
kept Service B from working.

Service
A
V1.0
Team A Team B
Service
B
V1.0
Nuget
Package
Foo
Service
A
V2.0
Service
B
V2.0
Nuget
Package
Goo
Nuget
Package
Bar

Nuget
Package
Common
Nuget
Package
Svc B
Nuget
Package
Svc A
Separate code that changes
to their own package
for the service that needs it.

• Distributed monolith
Monolith
Microservice Monolith 2
This Photo by Unknown Author is
licensed under CC BY-SA

• Decentralized Data
Monolith
Accounts
Customers
Orders
Order History
Parts
Parts1
Shipping History
Logging

Orders
-parts
~~
~~~
~~~~~
~~~
Parts

Orders
-parts
Parts
Shipping
- orders

Challenges to making microservices Id
Natural Key
Part Number
Part Name
Category
Classification
Description
Size Description
Color
Container
Manufacturer
Mfg Part Number
Mfg Date
Replaces Part Number
Discontinued Date
Parts

Id
Natural Key
Part Number
Part Name
Description
Parts
Orders
-parts
Orders
~~~~~~~
~~~~
~~~~~~~~~~~
~~~~~~~~
~~~~~~~~~~~~~~
~~~~~~~~~~
~~~~~~~OrderedParts
Id
OrderId
Part Id
Part Number
Part Name
Description
Quantity
Price

Message Bus
Messaging

Decomposing Monolith to Microservices

extract
new

Monolith
• Boundaries not clearly defined
• Lacking good Dependency Injection
• Requires refactoring

Monolith
Start With Small Piece
Payoff in
• Learning
• Building Infrastructure

Using DDD
Company: Wham-Bam
Products: Fidget Widgets
Production

Production Shipping
Purchasing
Domain Model
Event Storming

Event Storming
Production Shipping
Purchasing
Inventory
Invoicing
Returns
Accounts3rd
Party
Domain Model

Using DDD
Bounded Contexts
Production
Parts
Purchasing
Parts
Products
Vendors
Order

Using DDD
Bounded Contexts
Production
Parts
Purchasing
Parts
Products
Vendors
Order
Ubiquitous Language

Using DDD
Aggregates
Order
Order Line
Product
Part
Both of these are in the Production Bounded Context

Identify Possible Services
• Submit Order
• Ship Order
• Cancel Order
• Revise Order
Order
Order Line
Product
Part
Order Microservice
Production Bounded Context

Microservice
Bounded ContextBounded Context
Microservice
Bounded Context

Microservice
Bounded ContextBounded Context
Microservice
Bounded Context
Bounded Context
“Cross-Cutting Concerns”

A Quick Review
This Photo by Unknown Author is licensed under CC BY-SA-NC
Microsevices are hard
They require good analysis and teamwork
Team Autonomy
Service Autonomy
Scalability
Fault Isolation
Cost time, money, learning, investing
Messaging; RPC; sync vs async; pub/sub
CI / CD setup per microservice
Sharing code keeps services tightly coupled
Need to know about Layer 4 and 7
TLS for service communication layer; OAuth for application layer

A Quick Review
Domain Driven Design
Bounded Contexts
Aggregates

Recommendations
Microservices Patterns – Chris Richardson
Domain-Driven Design: Tackling Complexity in the Heart of Software – Eric Evans
Implementing Domain Driven Design – Vernon Vaughn

Recommendations
Micro-Frontends – O’Reilly class by Luca Mezzalira
https://learning.oreilly.com/live-training
https://medium.com/@lucamezzalira/micro-frontends-resources-53b1ec7d12a

Thank You Sean Whitesell
@seanw122
seanwhitesell.com
President of Tulsa .NET User Group && Cloud Architect @ TokenEx, LLC

Non-Related Resources
https://Presentations.dotnetfoundation.org
https://dotnet.microsoft.com/learn/videos
https://github.com/dotnet-
presentations/dotnetconf2019/tree/master/Technical

Microservices easywaywrongway

Empfohlen

Empfohlen

Weitere ähnliche Inhalte

Ähnlich wie Microservices easywaywrongway

Ähnlich wie Microservices easywaywrongway (20)

Kürzlich hochgeladen

Kürzlich hochgeladen (20)

Microservices easywaywrongway