DOCSLIB.ORG

Web Age Webinar Series

Total Page：16

File Type：pdf, Size：1020Kb

Download full-text PDF Read full-text
Web Age Webinar Series 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
Load more

Recommended publications
  • 1. Domain Modeling
    Software design pattern seminar sse, ustc Topic 8 Observer, Mediator, Facade Group K 1. The observer pattern (Behavioral pattern, chapter 16 and 17) 1) the observer is an interface or abstract class defining the operations to be used to update itself 2) a solution to these problems A. Decouple change and related responses so that such dependencies can be added or removed freely and dynamically 3) solution A. Observable defines the operations for attaching, de-attaching and notifying observers B. Observer defines the operations to update itself 4) liabilities A. Unwanted concurrent update to a concrete observable may occur Figure 1 Sample Observer Pattern 2. The mediator pattern (Behavioral pattern, chapter 16 and 17) 1) the mediator encapsulates how a set of objects interact and keeps objects from referring to each other explicitly 2) a solution to these problems A. a set of objects communicate in well-defined but complex ways. The resulting interdependencies are unstructured and difficult to understand B. reusing an object is difficult because it refers to and communicates with many other objects C. a behavior that's distributed between several classes should be customizable without a lot of subclassing 3) solution A. Mediator defines an interface for communicating with Colleague objects, knows the colleague classes and keep a reference to the colleague objects, and implements the communication and transfer the messages between the colleague classes 1 Software design pattern seminar sse, ustc B. Colleague classes keep a reference to its Mediator object, and communicates with the Mediator whenever it would have otherwise communicated with another Colleague 4) liabilities A.
    [Show full text]
  • Designpatternsphp Documentation Release 1.0
    DesignPatternsPHP Documentation Release 1.0 Dominik Liebler and contributors Jul 18, 2021 Contents 1 Patterns 3 1.1 Creational................................................3 1.1.1 Abstract Factory........................................3 1.1.2 Builder.............................................8 1.1.3 Factory Method......................................... 13 1.1.4 Pool............................................... 18 1.1.5 Prototype............................................ 21 1.1.6 Simple Factory......................................... 24 1.1.7 Singleton............................................ 26 1.1.8 Static Factory.......................................... 28 1.2 Structural................................................. 30 1.2.1 Adapter / Wrapper....................................... 31 1.2.2 Bridge.............................................. 35 1.2.3 Composite............................................ 39 1.2.4 Data Mapper.......................................... 42 1.2.5 Decorator............................................ 46 1.2.6 Dependency Injection...................................... 50 1.2.7 Facade.............................................. 53 1.2.8 Fluent Interface......................................... 56 1.2.9 Flyweight............................................ 59 1.2.10 Proxy.............................................. 62 1.2.11 Registry............................................. 66 1.3 Behavioral................................................ 69 1.3.1 Chain Of Responsibilities...................................
    [Show full text]
  • Design Patterns in Ocaml
    Design Patterns in OCaml Antonio Vicente [email protected] Earl Wagner [email protected] Abstract The GOF Design Patterns book is an important piece of any professional programmer's library. These patterns are generally considered to be an indication of good design and development practices. By giving an implementation of these patterns in OCaml we expected to better understand the importance of OCaml's advanced language features and provide other developers with an implementation of these familiar concepts in order to reduce the effort required to learn this language. As in the case of Smalltalk and Scheme+GLOS, OCaml's higher order features allows for simple elegant implementation of some of the patterns while others were much harder due to the OCaml's restrictive type system. 1 Contents 1 Background and Motivation 3 2 Results and Evaluation 3 3 Lessons Learned and Conclusions 4 4 Creational Patterns 5 4.1 Abstract Factory . 5 4.2 Builder . 6 4.3 Factory Method . 6 4.4 Prototype . 7 4.5 Singleton . 8 5 Structural Patterns 8 5.1 Adapter . 8 5.2 Bridge . 8 5.3 Composite . 8 5.4 Decorator . 9 5.5 Facade . 10 5.6 Flyweight . 10 5.7 Proxy . 10 6 Behavior Patterns 11 6.1 Chain of Responsibility . 11 6.2 Command . 12 6.3 Interpreter . 13 6.4 Iterator . 13 6.5 Mediator . 13 6.6 Memento . 13 6.7 Observer . 13 6.8 State . 14 6.9 Strategy . 15 6.10 Template Method . 15 6.11 Visitor . 15 7 References 18 2 1 Background and Motivation Throughout this course we have seen many examples of methodologies and tools that can be used to reduce the burden of working in a software project.
    [Show full text]
  • Secure Telemedicine System for Home Health Care
    Graduate Theses, Dissertations, and Problem Reports 2000 Secure telemedicine system for home health care Sridhar Vasudevan West Virginia University Follow this and additional works at: https://researchrepository.wvu.edu/etd Recommended Citation Vasudevan, Sridhar, "Secure telemedicine system for home health care" (2000). Graduate Theses, Dissertations, and Problem Reports. 1099. https://researchrepository.wvu.edu/etd/1099 This Thesis is protected by copyright and/or related rights. It has been brought to you by the The Research Repository @ WVU with permission from the rights-holder(s). You are free to use this Thesis in any way that is permitted by the copyright and related rights legislation that applies to your use. For other uses you must obtain permission from the rights-holder(s) directly, unless additional rights are indicated by a Creative Commons license in the record and/ or on the work itself. This Thesis has been accepted for inclusion in WVU Graduate Theses, Dissertations, and Problem Reports collection by an authorized administrator of The Research Repository @ WVU. For more information, please contact [email protected]. SECURE TELEMEDICINE SYSTEM FOR HOME HEALTH CARE Sridhar Vasudevan Thesis submitted to the College of Engineering and Mineral Resources at West Virginia University in partial fulfillment of the requirements for the degree of Master of Science in Computer Science V.Jagannathan, Ph.D., Chair Sumitra Reddy, Ph.D. James D. Mooney, Ph.D. Department of Computer Science and Electrical Engineering Morgantown, West Virginia 2000 Keywords: EJB, Java, Home Health Care, Telemedicine SECURE TELEMEDICINE SYSTEM FOR HOME HEALTH CARE Sridhar Vasudevan ABSTRACT This thesis describes a low-cost telemedicine system that provides home based patient care by linking patients with skilled nurses at the home care agency.
    [Show full text]
  • Java Design Patterns I
    Java Design Patterns i Java Design Patterns Java Design Patterns ii Contents 1 Introduction to Design Patterns 1 1.1 Introduction......................................................1 1.2 What are Design Patterns...............................................1 1.3 Why use them.....................................................2 1.4 How to select and use one...............................................2 1.5 Categorization of patterns...............................................3 1.5.1 Creational patterns..............................................3 1.5.2 Structural patterns..............................................3 1.5.3 Behavior patterns...............................................3 2 Adapter Design Pattern 5 2.1 Adapter Pattern....................................................5 2.2 An Adapter to rescue.................................................6 2.3 Solution to the problem................................................7 2.4 Class Adapter..................................................... 11 2.5 When to use Adapter Pattern............................................. 12 2.6 Download the Source Code.............................................. 12 3 Facade Design Pattern 13 3.1 Introduction...................................................... 13 3.2 What is the Facade Pattern.............................................. 13 3.3 Solution to the problem................................................ 14 3.4 Use of the Facade Pattern............................................... 16 3.5 Download the Source Code.............................................
    [Show full text]
  • Design Patterns Mock Test
    DDEESSIIGGNN PPAATTTTEERRNNSS MMOOCCKK TTEESSTT http://www.tutorialspoint.com Copyright © tutorialspoint.com This section presents you various set of Mock Tests related to Design Patterns Framework. You can download these sample mock tests at your local machine and solve offline at your convenience. Every mock test is supplied with a mock test key to let you verify the final score and grade yourself. DDEESSIIGGNN PPAATTTTEERRNNSS MMOOCCKK TTEESSTT IIII Q 1 - Which of the following describes the Composite pattern correctly? A - This pattern builds a complex object using simple objects and using a step by step approach. B - This pattern is used where we need to treat a group of objects in similar way as a single object. C - This pattern hides the complexities of the system and provides an interface to the client using which the client can access the system. D - This pattern is primarily used to reduce the number of objects created and to decrease memory footprint and increase performance. Q 2 - Which of the following describes the Decorator pattern correctly? A - This pattern allows a user to add new functionality to an existing object without altering its structure. B - This pattern is used where we need to treat a group of objects in similar way as a single object. C - This pattern hides the complexities of the system and provides an interface to the client using which the client can access the system. D - This pattern is primarily used to reduce the number of objects created and to decrease memory footprint and increase performance. Q 3 - Which of the following describes the Facade pattern correctly? A - This pattern allows a user to add new functionality to an existing object without altering its structure.
    [Show full text]
  • Developing GUI Applications. Architectural Patterns Revisited
    Developing GUI Applications: Architectural Patterns Revisited A Survey on MVC, HMVC, and PAC Patterns Alexandros Karagkasidis [email protected] Abstract. Developing large and complex GUI applications is a rather difficult task. Developers have to address various common soFtware engineering problems and GUI-speciFic issues. To help the developers, a number of patterns have been proposed by the software community. At the architecture and higher design level, the Model-View-Controller (with its variants) and the Presentation-Abstraction- Control are two well-known patterns, which specify the structure oF a GUI application. However, when applying these patterns in practice, problems arise, which are mostly addressed to an insuFFicient extent in the existing literature (iF at all). So, the developers have to find their own solutions. In this paper, we revisit the Model-View-Controller, Hierarchical Model-View- Controller, and Presentation-Abstraction-Control patterns. We first set up a general context in which these patterns are applied. We then identiFy Four typical problems that usually arise when developing GUI applications and discuss how they can be addressed by each of the patterns, based on our own experience and investigation oF the available literature. We hope that this paper will help GUI developers to address the identified issues, when applying these patterns. 1 Introduction Developing a large and complex graphical user interface (GUI) application for displaying, working with, and managing complex business data and processes is a rather difficult task. A common problem is tackling system complexity. For instance, one could really get lost in large number of visual components comprising the GUI, not to mention the need to handle user input or track all the relationships between the GUI and the business logic components.
    [Show full text]
  • Design Patterns Design Patterns
    Design Patterns • More design patterns (GoF) – Structural: Adapter, Bridge, Façade – Creational: Abstract Factory, Singleton – Behavioral: Observer, Iterator, State, Visitor Design Patterns-10, CS431 F06, BG Ryder/A Rountev 1 Design Patterns • Design patterns have become very popular in the last decade or so • Major source: GoF book 1995 • “Design Patterns: Elements of Reusable Object- Oriented Software” • Gamma, Helm, Johnson, Vlissides (gang of 4) • Patterns describe well-known solutions to common design problems • Used in Java libraries, especially in the GUI libraries Design Patterns-10, CS431 F06, BG Ryder/A Rountev 2 1 Design Patterns (LAR Ch26; GoF) • Structural • Concerned with how classes and objects are composed to make larger structures (Adapter, Bridge, Composite, Façade) • Creational • Abstract the instantiation process to make a system independent of how its objects are created & represented (Abstract Factory, Singleton) • Behavioral • Describe patterns of communication and interaction between objects (algorithms and responsibility assignment) (Observer, State, Strategy, Mediator) Design Patterns-10, CS431 F06, BG Ryder/A Rountev 3 Adapter Pattern: Interface Matcher • Problem: incompatible interfaces • Solution: create a wrapper that maps one interface to another • Key point: neither interface has to change and they execute in decoupled manner – Think of how you use a power plug adaptor when you travel to Europe • Example: – Client written against some interface – Server with the right functionality but with the wrong interface
    [Show full text]
  • 1 Layered Architecture
    e-gov Architecture Application Architecture 1 Layered Architecture ................................................................................. 3 1.1 Introduction ..................................................................................... 3 1.2 Best practices................................................................................... 3 1.2.1 Choose a layered architecture ......................................................... 3 1.2.2 Apply design patterns to layer the architeture.................................... 6 2 Domain Layer .......................................................................................... 8 2.1 Introduction ..................................................................................... 8 2.2 Best practices................................................................................... 8 2.2.1 Introduce a domain layer in the architecture...................................... 8 2.2.2 Apply design patterns on the domain layer ........................................ 9 2.2.3 Utilize the full power of OO ............................................................10 2.2.4 Avoid the anemic domain model .....................................................10 2.2.5 Minimize the dependencies with other layers ....................................10 2.2.6 Unit test the domain layer..............................................................10 3 Service Layer..........................................................................................11 3.1 Introduction ....................................................................................11
    [Show full text]
  • Introduction to Design Patterns
    Chapter 1 Introduction • Designing object-oriented software is hard, and designing reusable object-oriented software is even harder. • It takes a long time for novices to learn what good object-oriented design is all about. Experienced designers evidently know something inexperienced ones don't. • Expert designers find recurring patterns of classes and communicating objects in many object-oriented systems, and can apply them immediately to design problems without having to rediscover them. • Recording experience in designing object-oriented software as design patterns. • Design patterns make it easier to reuse successful designs and architectures. What is a Design Pattern? • Christopher Alexander says, "Each pattern describes a problem which occurs over and over again in our environment, and then describes the core of the solution to that problem, in such a way that you can use this solution a million times over, without ever doing it the same way twice". • Four essential elements of a pattern:: 1. The pattern name is a handle we can use to describe a design problem, its solutions, and consequences in a word or two. 2. The problem describes when to apply the pattern. 3. The solution describes the elements that make up the design, their relationships, responsibilities, and collaborations 4. The consequences are the results and trade-offs of applying the pattern. • The design patterns are descriptions of communicating objects and classes that are customized to solve a general design problem in a particular context. Design Patterns in Smalltalk MVC • Model is the application object • View is the model's screen presentation • Controller defines the way the user interface reacts to user input.
    [Show full text]
  • Abstract Factory Pattern Real World Example
    Abstract Factory Pattern Real World Example Sparry Reuven blackmails some spiritual and outact his swimming so fumblingly! Gasper remains unilateral: she embow her observatories allegorize too ninefold? Whining Dirk wince some menstruation and traps his Alain-Fournier so banteringly! Can You Improve This Article? Abstract factory code and features, when there are different flavors of elements of each service and every shape based on objects will implement modular gui design pattern real object step is. Do this pattern is hard before uploading a level, we are prototypical instance creation logic on desktop or dependent products are design pattern is often. Living in real world design pattern real factory world example, real world has a generic interfaces that will post helpful example, amazon web api like services. If i like this Decorator design pattern tutorial in Java then my share remains your friends and colleagues. Let's you factory method with own factory voil here read the. So basically, we release another attribute of abstraction which will identify the location and internally use again car factory implementation without even giving a single hint you the user. Sometimes, it think of patterns as recipes. It is not related to that. This is the Elven Army! In their state, we have been made up of objects of objects. What medium the intent of the merit Pool pattern? Given a real object as needed. This differs from the Observer pattern determined it allows any subscriber implementing an advance event handler to register what and vague topic notifications broadcast radio the publisher. And think is real world you have new instance property from a partial classes one place here abstract container, we have no review stack exchange is not.
    [Show full text]
  • Wrapper Facade
    Wrapper Facade A Structural Pattern for Encapsulating Functions within Classes Douglas C. Schmidt [email protected] Department of Computer Science Washington University St. Louis, MO 63130, (314) 935-7538 This paper appeared in the C++ Report magazine, Febru- ary, 1999. CLIENT DATABASE 1 Introduction PRINTER CONNECTION This paper describes the Wrapper Facade pattern. The intent REQUEST LOGGING of this pattern is to encapsulate low-level functions and data SERVER structures with object-oriented (OO) class interfaces. Com- SOCKET HANDLES mon examples of the Wrapper Facade pattern are class li- NETWORK braries like MFC, ACE, and AWT that encapsulate native CONSOLE OS C APIs, such as sockets, pthreads, or GUI functions. CLIENT LOGGING Programming directly to native OS C APIs makes net- RECORDS LOGGING working applications verbose, non-robust, non-portable, and RECORDS hard to maintain because it exposes many low-level, error- CLIENT SERVER prone details to application developers. This paper illus- trates how the Wrapper Facade pattern can help to make these types of applications more concise, robust, portable, and maintainable. Figure 1: Distributed Logging Service This paper is organized as follows: Section 2 describes the Wrapper Facade pattern in detail using the Siemens for- mat [1] and Section 3 presents concluding remarks. The logging server shown in Figure 1 handles connec- tion requests and logging records sent by clients. Logging records and connection requests can arrive concurrently on 2 Wrapper Facade Pattern multiple socket handles. Each handle identifies network communication resources managed within an OS. 2.1 Intent Clients communicate with the logging server using a connection-oriented protocol like TCP [2].
    [Show full text]