Binary Studio MEET FOR IT gatherings: 5th of March 2016 our meetup was devoted to .NET platform and took part in Lviv, Ukraine.

1. Building
Microservices
with .Net

2. Vasilenko Anton
.Net Team Leader
@ Binary Studio

3. Contents
1. Definitions
2. Comparison with alternatives
3.Key aspects in details
In theory
In the real .Net solution

4. “Microservices are ...
… small, autonomous services
that work together.
Sam Newman

5. “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

6. “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

7. 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.

8. SOA vs Microservices
SOA
Microservices
Very broad term,
almost meaningless

9. 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

10. Let’s dive into details

11. In theory
✘ Separate projects
✘ Identify seams
✘ Isolate wisely
changing parts
team-wise
extra security, monitoring
Key points: Splitting the Monolith
In our project
✘ Logical split
✘ With scalability in mind
✘ Isolate external services
✘ several DBs

12. 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.”

13. 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)

14. Key points: Integration
Summary
✘ Better stick to HTTP with REST
✘ Integration tests for 3rd parties
✘ Avoid API versioning

15. In theory
✘ Centralized logging
✘ Queryable log
✘ Unified log data & format
Key points: Logging
In our project
✘ Log from Cloud
✘ Simple Filtering
✘ Single format

16. Key points: Logging
Summary
✘ Always store source module of event
✘ Use Correlation ID
✘ Don’t reinvent the
Tools for logs: LogStash, Kibana.

17. 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

18. 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

19. 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

20. Key points: Security
Summary
✘ HTTPS is a MUST
✘ Avoid sending auth info in token
✘ Don’t reinvent the

21. 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

22. Key points: Scaling
Summary
✘ Microservice should be scalable
✘ Think about DB bottlenecks
✘ Think of data sync (DB, queues)

23. 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

24. Key points: Deployment
Summary
✘ Separate CI & CD jobs for each service
✘ Deployment strategy

25. Our Learning path
Our project
Microservices
onolythic
pplication
Service-oriented
Architecture

26. Monolith
✘ Simplicity
✘ Consistency
✘ Inter-module refactoring
Monolyth vs Microservices
Microservices
✘ Partial Deployment
✘ Availability
✘ Help preserve modularity
✘ Multiple Platforms (but please no JS)
Remember my advices?

27. Microservices Trade-Offs

28. 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

29. 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)

30. Containerization with .Net
.Net stack usually requires Windows
Containers usually require UNIX

31. Sources
1. “Building Microservices” by Sam Newman
2. Enterprise Integration Patterns at camel.apache.org
3.Microservices by Martin Fowler
a.Microservices Conf Video
4.https://www.nginx.com/solutions/microservices/
5.Majestic Monolith by David Heinemeier Hansson
6.Our project source code and docs

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