Building a Microservices solution using Docker, Building a Microservices solution using Docker, .NET and Windows Server 2016 Richard Banks ARC334

Overview Architecture Implementation Deployment

Caveats As an industry we’re still learning and maturing. Most Microservice implementations aren’t pure… and that’s OK. Docker on Windows is still a work in progress.

The Microservices Pitch

SHINY! SHINY! SHINY! SHINY! SHINY! Shiny! Shiny! Shiny! Netflix!! Shiny! Shiny! Shiny! Shiny! Shiny! Shiny! Shiny!

OK. More seriously… More flexibility/scalability than with monolithic apps Small services are easier to understand Independently deployable components

A few more reasons? Sure! A failure in one component doesn’t wipe out the whole system. More readily and easily evolvable Tech stack flexibility A potential path for legacy system rebuilds/rewrites

The Reality

WTF! OMG! Gah! <update resume /> Wasn’t this meant to be easy?! I can’t tell how this fits together anymore! It’s more brittle now than it ever was! Performance is terrible!!

Why? Complexity of Distributed Systems Tendency to build a distributed “big ball of mud” How do we debug across multiple components? Eventual Consistency needs a paradigm shift

Other things to deal with Is your database server a single point of failure/perf bottleneck? Do we need to do 2 phase commits across services? What is the current “version” of the system? How do we do authentication and authorisation?

Architecture

Design Patterns & Components CQRS – [C]ommand [Q]uery [R]esponsibility [S]eparation Event Sourcing – Persist events, not state. Message Bus – Reliable, loosely coupled comms. using pub/sub Optimistic Concurrency – No locking anywhere

Design Patterns & Components Domain Driven Design – Align microservice to Domain Context NoSQL – Persistent cache for read models/queries API Gateway – encapsulate access to services, optimised for UI Versioning – APIs and Databases

Overall Approach UI Request (HTTP) API Gateway Domain MicroService(s) Commands & Queries API Gateway Commands Queries Domain MicroService(s) Read Model MicroService(s) Precomputed Results Event Sourcing Domain Events EventStore RabbitMQ Redis

Event Store Repository Request (HTTP) Domain Micro Service Web API Controller Command Command Handler Aggregate Command(s) Save New Events Event Store Repository Event Handler(s) Event(s) Event(s) Event Store Message Bus (publish)

Query Micro Service Query (HTTP) Web API Controller Read Model Persistence (aka View Store) Query Query Handler Split here when scaling beyond a single instance Updates Event Handler(s) Event(s) Message Bus (subscribe)

Specific software/libraries RabbitMQ + EasyNetQ EventStore Redis + StackExchange.Redis ASP .NET Web API

Implementation

The Micro-café Inspired by “Starbucks does not use two phase commit” http://www.enterpriseintegrationpatterns.com/docs/IEEE_Software_Design_2PC.pdf

What are the domain contexts?

Demo

Deployment & Docker

Docker Terminology Image – a read only template for a container. Not runnable. Container – a runnable instance of an image. Registry – a collection of Docker images

Learn to think in “containers” How do you currently update a web site? Containers are immutable infrastructure. You don’t upgrade container apps. You replace them.

But what about persistence? Option 1 – Use a clustered/HA database server. Option 2 – Use a distributed DB supporting live upgrade (Redis) Option 3 – Cloud database (e.g. SQLAzure, DocumentDB) Option 4 – Docker volumes** (persistent container storage) ** Volumes not yet available in Windows Containers

Demo Running EventStore in Docker

The Dev/Test/Prod Cycle No source code promotion. No binary promotion either. It’s all about image approval for each environment. You’ll probably want an image repository of your own.

Windows Server Containers 4/27/2017 11:14 AM Windows Server Containers Creation, deployment, and management Developers update, iterate, and deploy updated containers 2 3 Operations collaborates with developers to provide app metrics and insights Developers build and test apps in containers, using development environment i.e. Visual Studio Operations automates deployment and monitors deployed apps from central repository 1 2 Containers pushed to central repository © 2013 Microsoft Corporation. All rights reserved. Microsoft, Windows, and other product names are or may be registered trademarks and/or trademarks in the U.S. and/or other countries. The information herein is for informational purposes only and represents the current view of Microsoft Corporation as of the date of this presentation. Because Microsoft must respond to changing market conditions, it should not be interpreted to be a commitment on the part of Microsoft, and Microsoft cannot guarantee the accuracy of any information provided after the date of this presentation. MICROSOFT MAKES NO WARRANTIES, EXPRESS, IMPLIED OR STATUTORY, AS TO THE INFORMATION IN THIS PRESENTATION.

Deployment concerns Docker Compose – sets of images/containers Docker Swarm – cluster multiple docker hosts Apache Mesos – docker host mega-clusters

Q&A Richard Banks - @rbanks54

Complete your session evaluation on My Ignite for your chance to win one of many daily prizes.

Continue your Ignite learning path Microsoft Ignite 2015 4/27/2017 11:14 AM Continue your Ignite learning path Visit Microsoft Virtual Academy for free online training visit https://www.microsoftvirtualacademy.com Visit Channel 9 to access a wide range of Microsoft training and event recordings https://channel9.msdn.com/ Head to the TechNet Eval Centre to download trials of the latest Microsoft products http://Microsoft.com/en-us/evalcenter/ © 2015 Microsoft Corporation. All rights reserved. MICROSOFT MAKES NO WARRANTIES, EXPRESS, IMPLIED OR STATUTORY, AS TO THE INFORMATION IN THIS PRESENTATION.