Microservices-Architekturen mit .NET: modern & pragmatisch - End-to-End

Das Schlagwort „Microservices“ ist in aller Munde. Angetrieben durch die zahlreichen Nachteile einer monolithischen Architektur wollen Microservices und damit verbundene Design Patterns und -Ideen das scheinbare Allheilmittel sein. In diesem Workshop klärt Christian Weyer über den Mythos Microservices auf: was sind sie, was sind sie nicht, wann setzt man sie ein – und vor allem: wie baut und betreibt man Microservices in der .NET-Welt? Und wie passt das wichtige Thema UI in all diese Diskussionen? Sehen Sie Architekturansätze in Aktion und erleben Sie Technologien wie Discovery, Web API, SignalR, Message Queuing, Containers, SPAs & Co. im praktischen Einsatz. Versuchen wir also gemeinsam langweilige Architekturthemen ein bisschen spannend zu machen.

Transcript

1. Microservices-Architekturen mit .NET – modern & pragmatisch End-to-End Christian Weyer @christianweyer CTO & Principal Consultant
2. § Co-founder, co-owner and principal consultant at Thinktecture AG § Focus on § Mobile & web-based application architectures § Interoperability, cross-device § Pragmatic end-to-end solutions § Microsoft MVP for ASP.NET (Architecture) ASPInsider, AzureInsider § Google GDE for Web Technologies § christian.weyer@thinktecture.com § @christianweyer Christian Weyer 2
3. § Microservices § What are they? § What not? § Common Microservices Approaches & Patterns § Being pragmatic § Building Microservices with .NET & .NET Core § UIs & Microservices § What about Azure? § Summary Topics 3
4. § https://github.com/thinktecture/dotnet-summit-2017-microservices Workshop repository 4
5. Microservices demystified 5
9. § “Cloud” § “Server” § “ESB” § “API” § XML § JSON § REST § HTTP § SOAP § WSDL § Swagger § Docker § Mesos § Service Fabric § Zookeeper § Kubernetes § SQL § NoSQL § MQTT § AMQP § Scale § Reliability § “Stateless” § “Stateful” § OAuth2 § OpenID § X509 § Java § Node § C# § OOP § DDD Services are not… https://lostechies.com/jimmybogard/2016/06/03/what-microservices-is-not/ 9
10. § Docker / containers § Azure / AWS § Serverless § Feature flags § Gitflow § NoSQL § Node.js § No more than 20 lines of code in deployed service § AWS Lambda § Service Fabric Microservices are not… https://lostechies.com/jimmybogard/2016/06/03/what-microservices-is-not/ 10
11. § Focused around a business domain § Technology-agnostic API § Small § Autonomous Microservices are … https://lostechies.com/jimmybogard/2016/06/03/what-microservices-is-not/ 11
12. § Autonomy § Single Responsibility § Isolation § Exclusive State § Mobility § Asynchronous Communication Core Ideas of Microservices http://jonasboner.com/bla-bla-microservices-bla-bla/ 12
13. § Conway’s Law § „Organizations which design systems ... are constrained to produce designs which are copies of the communication structures of these organizations.“ § Teams are created to solve a certain business problem § If you can afford it § If you can build those teams § Communication is tough, though! One of the Core Ideas of Microservices https://lostechies.com/jimmybogard/2016/06/03/what-microservices-is-not/ 13
14. § Which degree of autonomy is good? § It depends – really J § Synchronous communication may not be bad per se § Distinct, isolated data stores make decoupling, versioning easier § But may increase complexity § Messaging needs… messages – which need to be agreed upon § The more you decouple & the more you isolate, the more you may run into (unwanted or unneeded) complexity Autonomous – the Holy Grail 14
15. § A lot of projects fail because of overly complex architectures - sadly KISS ! 15
16. Microservices Approaches & Patterns 16
17. § CRUD § DDD § ES § CQRS § WTF… Architectural Styles 17
18. CRUD https://martinfowler.com/bliki/images/cqrs/single-model.png 18
19. CQRS https://martinfowler.com/bliki/images/cqrs/cqrs.png 19
20. § Web APIs § API Styles § RPC § OData § GraphQL § REST § HTTP/2 § WebSockets § Relaying Open & Interoperable Interfaces 20
21. § This can be like a religious war L § REST-ful guidelines – really? § MS: https://github.com/Microsoft/api-guidelines § Zalando: https://github.com/zalando/restful-api-guidelines To REST – or not? 21
22. § If you are not a hardcore REST-afarian you may want to have your interfaces described / documented § Technical for tooling § Human readable § Swagger / OpenAPI may help Describing Web APIs 22
23. § Services should register themselves and be discoverable § Consumers need to find services § E.g. with DNS, Consul § Consider discovery-as-a-service when running in a Cloud Discovery & Registry 23
24. § Most likely there are not a lot unsecured microservices to be consumed § Think about trusted subsystems where possible § Need to authenticate applications and users § Separate authentication into its own microservice § Apply authorization logic in the functional microservices § Standards may help § OAuth2 § OpenID Connect Security 24
25. § Async message passing § Different message exchange patterns at your hand § RabbitMQ as a broker-based system is a good option for many use cases § ZeroMQ may be your choice if you do not need a broker, but fast communication § Consider queue-as-a-service when running in a Cloud Messaging & Queuing 25
26. § Always think end-to-end § Letting consumers know that something important changed § Push data from services to consumers § Platform push § APNS § Windows Push Notification Services § Google Firebase Cloud Messaging § Use with PWAs § Application push § WebSockets, e.g. with SignalR Push 26
27. § Be stateless ;-) § Seriously, try to omit permanent state in memory § State is held on the consumer-side or in the backend (data stores) § Be able to fail fast § Be able to just scale-out by adding a new instance of your microservice (process) Scalability 27
28. § Decouple your microservices § One service should not bring down the entire system § Add resiliency code to consumers § Errors will happen, you will have to retry connections and calls § Consider patterns like circuit breaking § Monitor your microservices and report to central service § Perform health checks § Use dashboards to analyze data § Use escalation paths for critical issues § Maybe intentionally stress your microservices § E.g. Netflix’ ChaosMonkey Availability 28
29. § Build early, build often § Deploy and test early § During development think about containers for complex setups § E.g. Docker container for identity management solution with databases, Active Directory, certificates etc. § For production § VMs may be a good fit – automatically generated by tools § Containers may be a more lightweight option § Consider real machines for max performance Deployment 29
30. § API Versioning § Validation § Testing § … and so on ... And much, much more 30
31. Being Pragmatic 31
32. § Those are just approchaes & patterns – not rules J § Pick and choose wisely, really § There are not a lot of Netflix, Facebooks, Twitters out there § Sample application for this workshop picks a few of them Pragmatic == Use-Case-driven 32
33. Fitness Functions https://www.thoughtworks.com/insights/blog/microservices-evolutionary-architecture 33
34. Microservices with .NET & .NET Core 34
35. A small sample application 35
36. Web APIs & Hosting: ASP.NET Web API & Swagger 36
37. Registry & Discovery: Consul & Nanophone 37
38. § Running in Docker AuthN & AuthZ: Identity Server & OWIN Middlewares 38
39. Messaging: RabbitMQ & EasyNetQ & AutoMapper 39
40. § Restify § EasyNodeQ § Node-consul § With TypeScript § Packaging Node.js – As Microservices should be technology-agnostic… 40
41. Push Communication: SignalR 41
42. UI: Self-Hosted Angular App Service with OWIN 42
43. Logging: SeriLog & Seq 43
44. User Interfaces 44
45. § When thinking end-to-end, there are microservices with and without user interfaces § Need a way to compose UIs consisting of several „sub-UIs“ § Can be done server-side § Can be done client-side, SPA-style § Sample: http://lvm-it.github.io/ Microservices can contain a UI 45
46. § … ... 46
47. Running in Azure 47
48. § We have several options for running our microservices in Azure § VMs § Cloud Services § App Services § Service Fabric § Azure Container Service Microsoft Azure as IaaS, PaaS & SaaS Cloud Platform 48
49. Summary 49
50. § Microservices is an overloaded term § Know the approaches and patterns § Choose wisely § .NET is mature and ready to be a base for your microservices § .NET Core will surely get there § Be pragmatic with your microservices approach § Try to KISS! Summary 50
51. § Event Sourcing § https://www.exceptionnotfound.net/pattern- overview-command-query-responsibility- segregation-and-event-sourcing/ § Eventual Consistency § https://github.com/rogeralsing/DistributedDe signPatterns/blob/master/CAP.md § CQRS § https://www.exceptionnotfound.net/pattern- overview-command-query-responsibility- segregation-and-event-sourcing/ § Consul § https://www.pluralsight.com/courses/consul- getting-started § https://github.com/rogeralsing/Microphone § https://hub.docker.com/_/consul/ § Nanophone § https://github.com/lvermeulen/Nanophone § Web API Versioning § https://www.hanselman.com/blog/ASPNETCor eRESTfulWebAPIVersioningMadeEasy.aspx § Hangfire § http://hangfire.io/ § RabbitMQ in Docker § https://hub.docker.com/_/rabbitmq/ § https://coderwall.com/p/uqp34w/install- rabbitmq-via-docker-in-os-x § EasyNetQ § http://easynetq.com/ Resources 51
52. § Logging with SeriLog § https://serilog.net/ § Gathering los with Seq § https://getseq.net/ § Monitoring with Application Insights § https://docs.microsoft.com/en- us/azure/application-insights/app-insights- windows-services § Monitoring with Warden § https://getwarden.net/ § .NET Architecture Guidance § https://www.microsoft.com/net/architecture § Docker & Windows § https://blog.sixeyed.com/how-to-dockerize- windows-applications/ § https://github.com/docker/labs/blob/master/ windows/modernize-traditional- apps/modernize-aspnet-ops/README.md § https://github.com/docker/labs/blob/master/ windows/modernize-traditional- apps/modernize-aspnet-ops/part-3.md Resources 52