The move to microservice infrastructure exposes new challenges, that are not typical for classic monolithic applications. Deployment, security, monitoring -- this list is far from complete. In this talk Serhiy will speak about how to establish a fast and reliable communication channels between microservices. What patterns, protocols and data formats are available. How to enforce a backwards compatibility and strict contract between services and their clients. When we should use sync or async communication style, and so on. Come to this session and hopefully you will come out with new ideas of how to build your stuff even better.

1. Тема доклада
Тема доклада
Тема доклада
KYIV 2019
Serhii Kalinets
Effective Microservice Communication
.NET CONFERENCE #1 IN UKRAINE

2. About Me
Here should be some text about me 

3. We are hiring!

4. XP Days
https://xpdays.com.ua/
November 22-23, 2019
Kyiv, Ukraine

5. .NET fwdays'20
https://fwdays.com/event/dotnet-fwdays-2020
April 11, 2020 Kyiv,
Ukraine

6. Kyiv ALT.NET

7. In the previous episode…
.NET Framework
IIS
SOAP / WSDL
WCF

8. New wonderful world of
microservices…
dotnet new

10. Representational
state transfer (REST)

11. RESTful
Client server architecture
Statelessness
Cacheability
Layered system
Uniform interface

12. REST: Uniform interface
Resource identification in requests
Resource manipulation through representations
Self-descriptive messages
Hypermedia as the engine of application state
(HATEOAS)

13. HATEOAS
https://roy.gbiv.com/untangled/2008/rest-apis-must-be-hypertext-driven

14. Is it really REST?
POST is used for updates and deletes
Changes in service require client to update
No HATEOAS

15. REST Problems
Not suitable for all domains
RPC is still a thing
Weak contracts (contrasting to WSDL)

16. Swagger and OpenAPI
Client generation
Auto-publishing to WIKI

17. OpenAPI Swagger

18. Tools
NSwag, Swashbuckle for API spec /
documentation
SwagerCodeGen for client generation

19. Consumer Driven Contracts
Allow to test
services and clients separately
Ensure that clients do not get
broken when service evolves

20. How it works
Consumer creates model and client
Consumer creates test against service mock
Result of test run is recorded as JSON file, called ”pact”
Service uses client stub takes that pact file and runs it
against actual service

23. gRPC
Strict contract between client and service
Backwards compatibility
Plumbing code is generated and is always
optimal

24. gRPC in .NET Core
dotnet new grps

28. Messaging
Asynchronous communication
Reliability is covered by a message broker
Events / commands architecture

29. https://www.confluent.io/blog/building-a-microservices-ecosystem-with-kafka-streams-and-ksql/

30. Event Streams and KSQL
KSQL is available only as Java / Scala
Use sidecar pattern

32. What is GraphQL
Queries
Mutations
(new hotness) Subscriptions

33. Pros of GraphQL
Control over bandwith
Authorization on field / operation level
Fewer repetitive endpoints

34. Cons of GraphQL
Not optimized for .NET

38. Polly
// Break the circuit after the specified number of consecutive
// exceptions and keep circuit broken for the specified
// duration.
Policy
.Handle<SomeExceptionType>()
.CircuitBreaker(2, TimeSpan.FromMinutes(1));

39. Service
Mesh

40. Conclusion
Important conclusion 1
Important conclusion 2
Important conclusion 3

41. Thanks!
kalinets@gmail.com
@skalinets