WELCOME TO THE WEBINAR!
To ask a question during the presentation, type it in the “Questions” section We will also have a Q&A at the end of the presentation
Slides will be available shortly after the presentation A link to the Webinar Audio Recording will be published shortly after the presentation
Webinar Series Webinar Series WEB AGE TECHNOLOGY WEBINAR SERIES
Designing and Implementing Microservices
Webinar Series Webinar Series INTRODUCTION
Mikhail Vladimirov Director, Curriculum Architecture mikhail.vladimirov (*) webagesolutions . com * @ Web Age Solutions Providing a broad spectrum of regular and customized training classes in programming, system administration and architecture to our clients across the world for twenty years
Webinar Series Webinar Series OVERVIEW
Scoping your microservices Controlling access to your services Design for Failure
Webinar Series Webinar Series WHAT IS IN SCOPE FOR A ROBUST MICROSERVICES DESIGN?
For a robust design of microservices-based solutions, it is not enough to just write a bunch of RESTful web services intelligently talking to one another
The above may be necessary but not sufficient
Designers must take into considerations the run-time and operational aspects of distributed systems particularly for those that support non- functional requirements (usually, you automatically inherit those in brownfield projects), including … (see next slide …)
Webinar Series Webinar Series WHAT IS IN SCOPE FOR A ROBUST MICROSERVICES DESIGN?
Distributed transactions efficiencies (Elastic) Service scaling (out and in) Data consistency Service availability and resiliency to faults Minimizing (and, ideally, eliminating) service disruption during services life-cycles through applying operational efficiencies
Webinar Series Webinar Series SCOPING YOUR MICROSERVICE VIA THE BOUNDED CONTEXT
A popular technique to define the scope and responsibilities of a single service is to use the Bounded Context concept of Domain-Driven Design
In Domain-Driven Design (DDD), a collaborative effort between (business) domain experts and software designers is supported through adopting and consistently using the same domain-specific vocabulary (referred to in DDD as the Ubiquitous Language)
The terminology used in the vocabulary underpins the domain model being constructed Vocabulary items (nouns, verbs, and, potentially, adjectives) are mapped into the domain model
Elements of that vocabulary are used to define the Bounded Context (BC) of the model, which, in turn, scopes your microservice's domain function
Webinar Series Webinar Series SCOPING YOUR SOLUTION'S MICROSERVICES ARCHITECTURE
Your microservices-based solution's architecture may, potentially, span multiple sub-domains that make up the whole domain
Then you need to define a context for those sub-domains (each of which is constrained by its BC that is used to define a single microservice)
This Űber (Global) context in DDD is called the Context Map; it draws the demarcation lines for sub-domains that are then translated into models
The overall microservices design process may be represented as follows:
Context Map → ∑Sub-domain i → ∑Bounded Context i → ∑Microservice i
Webinar Series Webinar Series EXTERNAL / SHARED AND INTERNAL SERVICE MODELS Internal models of your microservices are controlled by their Bounded Contexts External / Shared models are used for intra-service communication These are in the form of input / output parameters of the established service contracts Internal models must be segregated from the external models Look out for situations when different BCs are bleeding into each other
Webinar Series Webinar Series GENERAL ARCHITECTURAL AND SOFTWARE PROCESS ORGANIZATIONAL PRINCIPLES
Make choices that favor rapid feedback and change
Reduce inertia
Find a balance between off-the-shelf and custom-made products Off-the-shelf solutions may deliver early value but may create inertia and accidental complexity down the road
Do not reinvent the wheel
Eliminate accidental complexity Conduct a thorough audit and retire / replace unnecessarily complex processes and integrations so that you can focus on the essential complexity Perform dynamic program analysis (code coverage) against the existing production use case scenarios
This activity may help reveal that there are not enough test cases Webinar Series Webinar Series LOOSE COUPLING, THE OOD PERSPECTIVE
Object-oriented Design (OOD) uses the Law of Demeter or principle of least knowledge as a design guideline for developing software, particularly object-oriented programs It may be viewed as a corollary to the principle of least privilege, which dictates that a module possess only the information and resources necessary for its legitimate purpose
Webinar Series Webinar Series CROSSING PROCESS BOUNDARY IS EXPENSIVE!
Crossing process boundaries is expensive It is at least three orders of magnitude slower (millisecond vs microsecond) to make a call across a process boundary than it is to make the same call within the same process You may be forced to reconsider and merge certain microservices into a monolith type of microservice to achieve the required QoS such as performance and throughput
Webinar Series Webinar Series CROSS-CUTTING CONCERNS
Microservices Architecture must incorporate (distributed) cross cutting concerns, including Uniform authentication and authorization SSO server may be required Logging You have options for o Setting up some sort of central logging data store o Deploying systems for log aggregation, message correlation, and getting business and operational insights (Splunk, Datadog, etc.)
Webinar Series Webinar Series MORE CROSS-CUTTING CONCERNS
Auditing o A must-have when dealing with financial, health, or other such types of sensitive information State / Session management o A must-have to support scalability o Backed by some sort of external store o Must support automatic client session expiry (TTL) Caching o Read-through caching of data returned by expensive queries is required if availability is a priority
Webinar Series Webinar Series TO CENTRALIZE OR DECENTRALIZE CLIENT ACCESS?
Microservices designers have to deal with the client access mode dilemma: Centralized Decentralized
Webinar Series Webinar Series DECENTRALIZED CLIENT ACCESS Many believe that Microservices architectural patterns are about decentralized access, where the functionality of the centralized service or the "facade" interface is broken into multiple services that carry out the required functions (e.g. using the Service Mesh pattern) Microservices take over the required functionality, like request routing, versioning, and data format negotiation (the "smarts") Under this arrangement, individual microservices take on implementing all the required cross-cutting concerns Some sort of SSO may be required to be put in place
Webinar Series Webinar Series CENTRALIZED CLIENT ACCESS Under the centralized client access design, there is a single "facade" service interface that is used as a single point of client access to your microservices-based solution The supporting mechanisms are: API Management solutions The Facade Pattern Centralized client access addresses some of the cross- cutting concerns
Webinar Series Webinar Series THE FAÇADE PATTERN This integration pattern's motivation and objectives are similar to those of the Facade Pattern (popular in object- oriented programming): Front and mediate interaction with more complex components behind a single (and often simplified) API Provide a context-specific interface to more generic functionality Help with the refactoring of monolithic or tightly-coupled systems in favor of more loosely-coupled code Within a Microservices Architecture, this pattern is about creating a centralized access Facade Service based on the API Gateway idea
Webinar Series Webinar Series HOW CAN I MAINTAIN STATE?
Generally, you have two main options: Maintain sate on the service's side o You can use a caching solution or durable store • Here, you may want to configure TTL for session / state to be expired (e.g. for abandoned sessions, timed-out sessions, etc.) Have the client send its state as part of the request o Cookies, custom HTTP headers, part of the request URL (query strings), as part of the payload
Webinar Series Webinar Series MICRO FRONT-ENDS The Micro front-end (MicroUI) concept extends the concept of microservices to the front-end tier of your app [https://micro-frontends.org/]
Front-end components of web apps that run in client browsers leverage modern JavaScript run-times for building dynamic, data-driven apps (sometimes referred to as 'Single Page Apps') that are composed of a suite of features
It may help to think of MicroUI as next generation portals
The current trend for building feature-rich apps is to combine the front-end components (MicroUI fragments) with microservices at the back-end Backends for Frontends is one such integration pattern
Reactive front-end programming is a good match for event-driven patterns used for integrating microservices Webinar Series Webinar Series HOW CAN MICROUI HELP ME?
MicroUI helps with the following: Breaking up the front-end monolith components Organizingyour development into small, per-feature Dev teams, where such teams own their feature(s) end-to-end (from UI to business logic to persist ence layer)
Webinar Series Webinar Series YOUR CLIENTS ARE DIVERSE!
Your microservices must adequately support various clients: Desktop browsers Mobile clients running o Native mobile Applications o Mobile Web Applications o Hybrid Mobile Applications So, your UI must accommodate those client's view rendering capabilities and JavaScript support
Webinar Series Webinar Series DESIGN FOR FAILURE
Design for Failure is about making the right application design decisions, including: Stateless design of your application A failed process/service can be transparently replaced by a newly provisioned one picking up where the failed service dropped the ball Proper capacity planning to avoid resource over-provisioning, or Autoscaling (elastic computing) of services Boosting resiliency of your app using appropriate patterns and container-based deployment model
Webinar Series Webinar Series IMPLEMENTING MICROSERVICES
Use application frameworks that have the following common features: An embedded HTTP web server (Tomcat, Jetty or Undertow) that helps eliminate the need for building and deploying WAR (Web ARchive) or other deployment bundles Built-in production-ready application support in the form of run-time metrics collection, health checks, and externalized configuration etc. The above features, in many cases, obviate the need for an external application server by transparently installing and wiring the required system plumbing around the application file(s) (e.g. jar file(s) in the Java world) Webinar Series Webinar Series MICROSERVICE-ORIENTED APPLICATION FRAMEWORKS AND PLATFORMS Popular with Java developers are: Spring Boot (http://projects.spring.io/spring-boot/) Dropwizard (http://dropwizard.io/) Spark (http://sparkjava.com/) o Do not confuse with Apache Spark! Popular with open-source community is Node.js ( https://nodejs.org ) used as a platform for building and running microservices
Webinar Series Webinar Series UPCOMING CLASSES
Webinar Series Webinar Series QUESTIONS? ?
Webinar Series Webinar Series CONTACT
Web Age Solutions www.webagesolutions.com/contactus/ US - 215-517-6540 Canada - 1-866-206-4644
Webinar Series Webinar Series