µJavier García Magna @ndsrfHead of Development www.sequel.com

Microservices& the .NET Framework

http://DOTNETMALAGA.es // 30th Mar 2016

µAgenda• What is a microservice

• Good things about microservicesyou should be using now

• DIY in .NET• Containers, VMs, self-hosted, …• Demo

• “Microsoft Microservices”• Azure Service Fabric• Demo

µAbout SequelWe 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 infoGraphic designers | .NET Architects / AngularJs devs | Testers / Automation www.sequel.com

µ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:-)

What is a microservice?

Let’s build our definition! link

µOur definition of microservices (Created live in the actual presentation - brainstorming session

30/03/2016)

µ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

µGood technical practices for microservices• Discovery, Configuration & Versioning• Security• Resilience & autohealing• Monitoring & Logging• Composition• Testing• Inter service communication• Data consistency• Service orchestration

Y

AX 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!)

Service Discovery (Microphone example)

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, …

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 http://www.grahamlea.com/2015/07/microservices-security-questions/

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)

Resilience• Problem: If one service is not available, everything crashesTechniques: retry N times, retry forever, retry and wait, circuit breaker, post execution steps

Circuit breaker: custom fallback, fail silent, fail fasthttp://techblog.netflix.com/2011/12/making-netflix-api-more-resilient.htmlAutohealing (Consul)

Options in .NET• Polly

Monitoring and Logging

• 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)

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)

Testing

• 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

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 NotificationRequest / async response

Publish / SubscribePublish / Async responses

Y

AX 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

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

Orchestration

Rancher (Linux containers) Marathon (Linux containers)

Example – Microcafe appCQRS, microservices

CQRSEvent sourcing

3 services: front-end + read + writedata writes in event storedata reads from redis (aggregates)message bus with rabbitmq

Microcafe app by Richard Banks https://github.com/rbanks54/microcafe

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 - https://lostechies.com/gabrielschenker/2015/04/07/cqrs-revisited/

Microcafe app by Richard Banks https://github.com/rbanks54/microcafe

Deal with eventual consistency, baby

Docker on Windows Server Core 2016 TP4

Service Fabric

Microsoft’s take on microservices

What is Service Fabric?A PaaS for building and running large scale microservice based applications and services

© Microsoft

Service Fabric programming models

Stateful vs. Stateless

Actors vs. Services

Service Fabric

µ“my” Key TakeawaysThere 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 :-) )

This can be freely distributed and used just by referencingthe author and DOTNETMALAGA.es

DOTNETMÁLAGAhttp://dotnetmalaga.es