Building Microservices

with .Net

Vasilenko Anton.Net Team Leader

@ Binary Studio

Contents

1.Definitions2.Comparison with alternatives3.Key aspects in details

In theoryIn the real .Net solution

“Microservices are ...

… small, autonomous services that work together.

Sam Newman

“There are two hard things in computer science: cache invalidation, naming things, and off-by-one errors.”

“Any fool can write code that a computer can understand. Good programmers write code that humans can understand.”

Martin Fowler

“Microservices ...

● application - a suite of small services

○ each in own process

○ communicating i.e. via HTTP

● built around business capabilities

● auto-deployed independently by CI & CD

● minimal centralized management

● different languages possible

● different data storages possible

Service Oriented Architecture

“A loosely-coupled architecture designed to meet the business needs of the organization.”

A software design based on discrete software

components, “services”, that collectively

provide the functionalities of the larger

software architecture.

SOA is an architectural style that supports service-orientation. Service-orientation is a way of

thinking in terms of services and service-based development and the outcomes of services.

SOA vs Microservices

SOA

Microservices

Very broad term, almost meaningless

Monolith architecture

“All architectural layers and all functionality in one single application.”

Simple to:● Develop● Deploy● Test … until it starts growing

https://youtu.be/wgdBVIX9ifA?t=1089

Let’s dive into details

In theory✘ Separate projects✘ Identify seams✘ Isolate wisely

changing partsteam-wiseextra security, monitoring

Key points: Splitting the Monolith

In our project✘ Logical split✘ With scalability in mind✘ Isolate external services✘ several DBs

Key points: Splitting the Monolith

Summary✘ Do you really need to split?✘ Document API✘ Use different solutions, even for same

stack✘ Avoid using shared logic

“Don't even consider microservices unless you have a system that's too complex to manage as a monolith.”

In theory✘ Prefer REST via HTTP✘ Facade services for 3rd-party API✘ Unified log data & format✘ Strangler pattern✘ Tolerant readers

Key points: Integration

In our project✘ Mostly HTTP, almost REST✘ Gateway Service✘ Tolerant readers (rest + json)✘ DB Integration✘ WCF (request-response, fire and

forget)

Key points: Integration

Summary✘ Better stick to HTTP with REST✘ Integration tests for 3rd parties✘ Avoid API versioning

In theory✘ Centralized logging✘ Queryable log✘ Unified log data & format

Key points: Logging

In our project✘ Log from Cloud✘ Simple Filtering✘ Single format

Key points: Logging

Summary✘ Always store source module of

event✘ Use Correlation ID✘ Don’t reinvent the

Tools for logs: LogStash, Kibana.

In theory✘ Blackbox tests of API✘ Generating tests by documented

API

Key points: Testing

In our project✘ UnitTests✘ Integration Tests✘ PostMan✘ WcfTestClient

Summary✘ Local debug environment (with faked

boundaries)✘ Simple test utility to test API

In theory✘ Single Sign-On✘ Authorized Clients✘ Authorized Services

Key points: Security

In our project✘ Central identity & auth Servers✘ Everything authorized✘ Token in HTTP Header

identity and auth info

Summary✘ HTTPS is a MUST✘ Avoid sending auth info in token✘ Don’t reinvent the

In theory✘ Single Sign-On✘ Authorized Clients✘ Authorized Services

Key points: Security

In our project✘ Central identity & auth Servers✘ Everything authorized✘ Token in HTTP Header

identity and auth info

Key points: Security

Summary✘ HTTPS is a MUST✘ Avoid sending auth info in

token✘ Don’t reinvent the

In theory✘ Cloud should help you✘ If you help cloud

Key points: Scaling

In our project✘ Almost all services support

scaling✘ Sync through tricks with

MongoDB✘ Cloud support of scaling

Key points: Scaling

Summary✘ Microservice should be scalable✘ Think about DB bottlenecks✘ Think of data sync (DB, queues)

In theory✘ Independent service deployment✘ ASAP✘ Use Cloud or containers features

Key points: Deployment

In our project✘ monolith deployment :(✘ Independent patching possible

✘ Cloud doesn’t encourage auto deploy

Key points: Deployment

Summary✘ Separate CI & CD jobs for each service✘ Deployment strategy

Our Learning path

Our project

Microservices

MonolythicApplication

Service-oriented Architecture

Monolith✘ Simplicity✘ Consistency✘ Inter-module refactoring

Monolyth vs MicroservicesMicroservices

✘ Partial Deployment✘ Availability✘ Help preserve modularity✘ Multiple Platforms (but please no

JS)

Remember my advices?

Microservices Trade-Offs

What to Pick? What do we have?✘ Rapid Host Provisioning✘ Basic Monitoring✘ Rapid App Deployment✘ DevOps culture ...

What do we need?

Always consider✘ Solution scale✘ Teams configuration

Virtualization Containerization&

● Running on few hosts● Environment close to production● Easy management (with Cloud)

● Running on dev host● Environment close to virtual● Easy trace● Easy management (even without cloud)

Containerization with .Net

.Net stack usually requires Windows

Containers usually require UNIX

Sources

1.“Building Microservices” by Sam Newman2.Enterprise Integration Patterns at camel.apache.org3.Microservices by Martin Fowler

a.Microservices Conf Video4.https://www.nginx.com/solutions/microservices/5.Majestic Monolith by David Heinemeier Hansson6.Our project source code and docs

i.e.:✘You’ve said… Can you explain… ?✘What do you mean by …?✘Have you tried …?✘Can you suggest …?

Questions?