### Leveraging Microservices architecture:<br /> Lessons learnt from the Winventory system development [Sebastian Bukowiec](mailto:sebastian.bukowiec@cern.ch) & [Pawel Gomulak](mailto:pawel.gomulak@cern.ch )<br />**IT-CDA** --- ## Objectives * <b style="color:dodgerblue;">Introduce Winventory</b><br />(tool used in the context of MAlt) * Challenge: phasing-out of Windows servers across CERN * Understand how Windows servers are used in the organization * <b style="color:dodgerblue;">Share experience</b> about using Microservices architecture --- ## What is Winventory? Winventory (https://cern.ch/winventory) is a tool develop at CERN with two objectives --- 1. To gather and present statistics of software assets installed on CERN Windows machines  ---  --- 2. To <b style="color:dodgerblue;">facilitate interaction</b> with individual users ```graphviz digraph hierarchy { nodesep=1.0 // increases the separation between nodes node [fontname=Courier,shape=plaintext] edge [color=dodgerblue, style=dashed] user->{website } user->{notification}->{website} } ``` --- ```graphviz digraph hierarchy { nodesep=1.0 // increases the separation between nodes node [fontname=Courier,shape=plaintext] edge [color=dodgerblue, style=dashed] "delete unused assets" [xlabel = "actions"]; website [xlabel = "feedback"]; user->{website}->{"delete unused assets", "remove licenses", "buy licenses"} } ``` --- ## Why Winventory? * To <b style="color:dodgerblue;">match</b> user feedback with information about software assets * To have <b style="color:dodgerblue;">flexibility</b> in combining many data sources --- ## Goals of Winventory * Easy and <b style="color:dodgerblue;">encouraging</b> tool to collect user feedback  --- * Effective (repeated notifications) * Automated * Friendly * consolidated queries and answers  --- ## Initial phase Two use cases for the infrastructure: * Windows Servers * MS SQL Servers --- ## Requirements expansion * Add Engineering applications  --- * New functionality - survey * simple questions * multiple choice questions * matrix questions ---  --- ## Autodesk survey  --- ## Winventory roles * Guest * User * Administrator --- ## Data producer Winventory currently has one data producer - <b style="color:dodgerblue;">Computer Management Framework (CMF)</b>, <br/>a custom software installed on every Windows machine that is member of the CERN domain.<br /> <b style="color:dodgerblue;">Data are collected once a day. Only data not older than three months is considered.</b><br />Missing data like Responsible and Main User are fetched from network db. --- ## Software architectures <b style="color:dodgerblue;">Monolithic</b> vs <b style="color:dodgerblue;">Microservices</b> --- ## Monolithic Architecture | Pros | Cons | | -------- | -------- | | Simplicity, for small codebases | Complex for large codebases | | Faster early development speed | Slower iterations in the long term | | Easy testing | Harder to innovate | | | | Steep code learning curve | --- ## Microservices Architecture The microservice architectural style is an approach to developing a <b style="color:dodgerblue;">single application as a suite of small services</b>, each running in its own process and <b style="color:dodgerblue;">communicating</b> with lightweight mechanisms, often an HTTP resource API. These services are <b style="color:dodgerblue;">built around business capabilities</b> and <b style="color:dodgerblue;">independently deployable</b> by <b style="color:dodgerblue;">fully automated deployment</b> machinery. -Martin Fowler --- ## Microservices characteristics <img src="https://codimd.web.cern.ch/uploads/upload_1fe1fe84366d058881fa72d6a9f0d581.png" class="plain"> --- ### Business Domain Centric Decouple microservices based on business capabilities or subdomain. Focus on <b style="color:dodgerblue;">what</b> it does. * Identity Service * Polls * Notifications --- ### High Cohesion * Identify <b style="color:dodgerblue;">single purpose</b> / function of the service * Clear input and outputs --- ### Loose Coupling * Independent services * Each microservice owns its database * No other service is allowed to connect to the DB * Other services use only the service interface * Communication over the network * synchronous * asynchronous --- ## Technology Stack * <b style="color:dodgerblue;">ASP .NET Core 2.2</b> (C# web framework) * [open source](https://github.com/dotnet/core) * cross-platform (macOS, Linux, Windows) * fast release cycle * high performance --- * <b style="color:dodgerblue;">Polly</b> (.NET resilience and transient-fault-handling library) * <b style="color:dodgerblue;">SignalR</b> (library for `ASP.NET` to add real-time web functionality) ---  Source: [techempower.com](https://www.techempower.com/benchmarks/#section=data-r17&hw=ph&test=plaintext) --- * <b style="color:dodgerblue;">Flask</b> (Python web framework) * [open source](https://github.com/pallets/flask) * highly customisable * minimalistic * <b style="color:dodgerblue;">Celery</b> (asynchronous task queue) * <b style="color:dodgerblue;">SQLAlchemy</b> (Python SQL toolkit and Object Relational Mapper) --- * <b style="color:dodgerblue;">Angular 7</b> (frontend) * <b style="color:dodgerblue;">RabbitMQ</b> (message broker) * <b style="color:dodgerblue;">Redis</b> (in-memory data structure store, cache) * <b style="color:dodgerblue;">MySQL</b> (CERN DBoD) * <b style="color:dodgerblue;">Docker</b> * <b style="color:dodgerblue;">Openshift</b> --- # Winventory Architecture --- <img src="https://codimd.web.cern.ch/uploads/upload_76316708140380d361bf6598c4005eb5.png" class="plain"> --- # Frontend --- ## Technology Stack * <b style="color:dodgerblue;">Angular 7</b> - Full-fledged, open source frontend framework - Many useful features "out-of-the-box", e.g. - <b style="color:dodgerblue;">lazy-loading </b> - http interceptors - XSS protection - dependency injection - routing & forms - TypeScript * <b style="color:dodgerblue;">Angular Material </b>(material design) --- # Backend --- ## Technology Stack * Frameworks comparison  --- ## Microservice Patterns --- ### Decomposition strategies * Each microservice has its own database - facilitates loose coupling - no blocking by the other service - independent development * In avoid to unnecessary traffic, some data are replicated across different microservices <i>ISSUE: how to divide complex domain into smaller ones? </i> * By businnes capability? * By subdomain? (based on DDD) --- <i>ISSUE: how to divide complex domain into smaller ones? </i> #### Challenges of: * Network latency * Data consistency * Reduced availability due to synchronous communication <img src="https://codimd.web.cern.ch/uploads/upload_bad6e30cd34cfc0797269f29c7fca78c.png" class="plain" width=75%> --- ### Communication with frontend <i>ISSUE: Which pattern of communication with frontend layer to use? </i> * Two patterns possible - gateway - direct --- #### <i>ISSUE: Which pattern of communication with frontend layer to use? </i> <img src="https://codimd.web.cern.ch/uploads/upload_9bc00446819bdfd5cd26af228050be63.png" class="plain" width=75%> <small> Source: docs.microsoft.com </small> --- #### <i>ISSUE: Which pattern of communication with frontend layer to use? </i> <img src="https://codimd.web.cern.ch/uploads/upload_ba85aadd8feee763308918f3dc491638.png" class="plain" width=75%> <small> Source: docs.microsoft.com </small> --- <i>ISSUE: Which pattern of communication with frontend layer to use? </i> * We decided to use direct - no other clients than SPA, no complex aggregation logic  --- ### Microservices communication patterns <i>ISSUE: Which communication pattern to use across microservices? </i> --- <i>ISSUE: Which communication pattern use across microservices? </i> <img src="https://codimd.web.cern.ch/uploads/upload_8d6acd96d0d3637c946265b34a6881ec.png" class="plain" width=75%> <small>source: docs.microsoft.com</small> --- ### Asynchronuous communication *ISSUE: Which asynchronuous communication choose?* * Many to choose from * CQRS (Command Query Responsibility Segregation) * event-sourcing * event-notifications * Broker or brokerless? --- ### Asynchronuous communication *ISSUE: Which asynchronuous communication choose?* * We decided for event-notification (simplicity) * RabbitMQ as message broker * Propagates changes of data to different microservcices <img src="https://codimd.web.cern.ch/uploads/upload_0272b3bf53cd8ae92879e19e55e19880.png" class="plain" width=60%> --- ### Synchronuous communication - circuit breaker pattern * REST API used - stateless (easy to scale) - level 2 of maturity model * Resiliancy and fault-tolerance implemented with Polly library (analogic to Netflix Hystrix) <img src="https://codimd.web.cern.ch/uploads/upload_6832c8ed0e4232e3c5bb5913ce9dc157.png" class="plain" width=40%> --- ### Push notifications * Used for updating frontend in real time * No page reaload * Hub implemented with SignalR * RabbitMQ as message broker  --- ### Continoues Deployment <i>ISSUE: How to provide convenient and effortless software delivery? </i> --- ## Environments * Dev (docker-compose) - each microservice has its dockerfile - docker compose builds whole project - easy and quick start for new developers * Staging (Openshift) * Production (Openshift) (zero-downtime deployments) --- ## Openshift - Many features like monitoring and routing provided "out-of-the-box" - Pipeline: 1. Commit to repo 2. Build docker image 3. Push image to Gitlab registry 4. Deploy to Opensifht --- ### Health monitoring & Logging * Facilitates self-healing * Response on failure * Track performance issues * More difficult to implement than in monolithic systems --- ## Web status service * Health checks out of the box in .Net Core * Real-time status available failure to Mattermost </i>  --- ## Openshift monitoring * CPU, memory and network metrics * <i>TODO Prometheus logging </i>  --- ## Logging * Each service logs the actions and errors * <i>TODO central logs flow to Elasticsearch </i>  --- ### Documentation - Swagger * self-generation of API documentation  --- # Demo --- # Lessons learned * Continuous integration and delivery is very important * Mono repository can be better in some cases * For simple and small applications, monolithic architecutre patterns can be better * Microservices are more challenging when there is one developer --- ### Advantages and disavantages of microservice architecture  --- ## Conclusions * Overall "test" of microservices architecture successful * Technology freedom * Easier to innovate * Higher initial cost vs monolthic apps * Distributed systems increase complexity --- ## Thank you for your attention If you own a Windows server machine soon you will be contacted! ---