Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

.Net Microservices with Event Sourcing, CQRS, Docker and... Windows Server 2016! Best practices with microservices (or just services)


Published on

Good technical practices you can follow with (micro)services but can be applied to almost anything: discovery (microphone/consul), security, resilience (polly), composition, ssecurity (jwt/oauth2)... And then an example with a CQRS application, and how docker can be used in Windows 2016. Lastly a brief summary of what Service Fabric is and its programming models.

Published in: Technology
  • Login to see the comments

.Net Microservices with Event Sourcing, CQRS, Docker and... Windows Server 2016! Best practices with microservices (or just services)

  1. 1. // 30th Mar 2016
  2. 2. • What is a microservice • Good things about microservices you should be using now • DIY in .NET • Containers, VMs, self-hosted, … • Demo • “Microsoft Microservices” • Azure Service Fabric • Demo
  3. 3. About Sequel We are leading software providers for the insurance market Heavily investing on R&D (& new offices in Málaga ) 55 people in Málaga, 6 scrum teams 140 people in total Currently hiring in Málaga – @ndsrf for more info Graphic designers | .NET Architects / AngularJs devs | Testers / Automation
  4. 4. Disclaimer This is not a “this is what I did” presentation, but rather a “this is what I have seen” and open for discussion presentation. O:-)
  5. 5. What is a microservice? Let’s build our definition! link
  6. 6. Our definition of microservices (Created live in the actual presentation - brainstorming session 30/03/2016)
  7. 7. Principles of microservices • Autonomous service (decentralise!) • Code + State (high cohesion) • Contracts between them (hide implementation) • Versioned • Consistent and available between failures • Culture of automation • Focus on delivery (products not projects) • Team collaboration • Team size “pizza size” • Lightweight components • Accesible by any device • Language & platform transparency • Smart endpoints / dump pipes • Unit of deployment • Implementation of a bound context (DDD) • Separated code repositories • Inmutable infrastructure • HTTP (REST – HATEOAS) vs others • Self-healing • Automatic upgrades / rollback
  8. 8. Good technical practices for microservices • Discovery, Configuration & Versioning • Security • Resilience & autohealing • Monitoring & Logging • Composition • Testing • Inter service communication • Data consistency • Service orchestration
  9. 9. Y A X B Service Discovery + Configuration • Problem: Hard-code service locations in 100s of microservices? • Problem: The service discovery needs to be redundant and reliable (this is hard!) • Discovery services rely on distributed DBs  can be used to store configuration • Nice to have: Discovery + health check + auto healing • HATEOAS Options in .NET • Microphone (.NET) + Consul (in Production: master on Linux only!)
  10. 10. Service Discovery (Microphone example)
  11. 11. Versioning • Problem: Not all teams should deliver at the same pace • Try to avoid dependencies  less management & more happiness  Concepts • You still need to deal with old clients of your service relying on previous version • Do not only distribute a client (distributed monolith!), just rely on contracts (& provide example implementations if you wish) • Semantic Romantic Versioning + Minimum required version concept • URL • Headers (Accept header) • API generation / documentation  Swagger, apiary, …
  12. 12. Security (1/2) • Problem: much greater attack surface • Problem: Secure all calls  slow / hassle? Concepts • Protect just Internet boundary? What happens in a intruder gets in the network? • Secure communication channels? Services trust each other? • Tamper proofing, replay protection, principal authorization, weakest link, least privilege • API gateway pattern (not just for security but…) • Rate limiting for external APIs (X-Rate-Limit-… headers (Twitter)) Security checklist
  13. 13. Security (2/2) • Authentication, Authorisation, Delegation • Problem: Once the principal is authenticated, it should only have access to certain resources, and we should do that in a scalable way Concepts • Authorisation server (provides tokens and jwt signed with its PK) • Resource server (each of the services) • Delegation  OAuth 2 protocol • OpenID protocol (JWT – Json Web Token, a signed json doc) to achieve statelessness • Authentication  Leave that to the OAuth 2 server (token) • Authorisation  All microservices should consume JWTs (identity)
  14. 14. Resilience • Problem: If one service is not available, everything crashes Techniques: retry N times, retry forever, retry and wait, circuit breaker, post execution steps Circuit breaker: custom fallback, fail silent, fail fast Autohealing (Consul) Options in .NET • Polly
  15. 15. • Problem: You don´t want to have to check N log files, just 1 • Logging framework vs Logging service • Correlate events • Log deployments / Orchestration (more on this later) Options in .NET • SeriLog + ELK • App Insights (Azure) • Runscope for API monitoring (cloud) • Raygun for error logging (cloud) • Newrelic (cloud)
  16. 16. Composition • Problem: Once we have all the small bits and pieces, how do we integrate them to provide higher level functionality Options • Monolithic UI to integrate everything • API Gateway • AJAX/Javascript • IFrames  • Server Side Includes / Edge Side Includes • Specific services like Netflix Zuul (Java) or Compoxure (NodeJS)
  17. 17. • Avoid at all costs committing to features that require more than one team to be done in the same place at the same time in order to make an integrated delivery • Other teams to do pull requests with tests (you might not know how your service is really used!) Options in .NET • Unit testing • Contract testing PACT.NET • Mock services
  18. 18. Inter-service communication • Problem: As we increase the number of services, the number of calls between them also increases • Tools/applications: RestSharp, Akka.Net, RabbitMQ (.NET library available), NATS (.NET lib available), HAProxy (load balance) • Message formats: XML (text), JSON (text), Google Protobuf (binary) One to One One to many Synchronous Request / response - Asynchronous Notification Request / async response Publish / Subscribe Publish / Async responses
  19. 19. Y A X B Data consistency • Problem: Each microservice is made of code + state • Problem: Distributed transactions are really hard Polyglot persistence Options • Single database • Another microservice to deal with domain data access • Event sourcing + pub/sub • Two phase commit • Replication • Eventual consistency • Business rules
  20. 20. Orchestration • Problem: How do we deal with 100s of services? Start, stop, move, upgrade… • A nice option: Containers • Linux containers (Mono / ASP.NET 5) • Windows containers Options for Windows (@ 30th March 2016) • Docker Compose + Swarm • Rancher • Kubernetes • Mesos + Marathon • Azure Container Service (Marathon) • Azure service fabric • Akka.NET
  21. 21. Orchestration Rancher (Linux containers) Marathon (Linux containers)
  22. 22. Example – Microcafe app CQRS, microservices CQRS Event sourcing 3 services: front-end + read + write data writes in event store data reads from redis (aggregates) message bus with rabbitmq
  23. 23. Microcafe app by Richard Banks Microservices: • n-Front-End services • n-Read Services • n-Write Services • Event Store cluster • N-Redis (1 x read service) • RabbitMQ cluster • HAProxy cluster • Consul cluster Diagram by Gabriel Schenker -
  24. 24. Microcafe app by Richard Banks Deal with eventual consistency, baby
  25. 25. Docker on Windows Server Core 2016 TP4
  26. 26. Service Fabric Microsoft’s take on microservices
  27. 27. What is Service Fabric? A PaaS for building and running large scale microservice based applications and services © Microsoft
  28. 28. Service Fabric programming models Stateful vs. Stateless Actors vs. Services
  29. 29. Service Fabric
  30. 30. “my” Key Takeaways There is no “right way” for doing microservices Most concepts could be applied to almost any architecture Orchestration is hard Service Fabric is nice… but it is “the Microsoft way” Windows Containers are not ready yet (@ 27th March 2016) Luckily we have OPEN SOURCE (Mono, ASP.NET 5 and… Linux :-) )