Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Microservices, Containers, Kubernetes, Kafka, Kanban

2,075 views

Published on

Understanding Microservices Architecture
Understanding Docker, Kubernetes and Kafka
Design Patterns - Domain Driven Design, Event Sourcing, and CQRS and Functional Reactive Programming, Distributed Computing and Saga Design Pattern
Infrastructure Patterns: API Gateway, Service Discovery, Circuit Breaker, Service Mesh, Event Streams (Kafka).
Microservices Testing Strategies
Security Best Practices for Containers and Kubernetes,

Published in: Technology
  • Login to see the comments

Microservices, Containers, Kubernetes, Kafka, Kanban

  1. 1. ARAF KARSH HAMID Co-Founder / CTO MetaMagic Global Inc., NJ, USA @arafkarsh arafkarsh Microservices Architecture Containers, Saga, Testing, Kanban World API & DevOps Summit Bangalore, February 15, 2019
  2. 2. 2 Microservices Containers & Kubernetes, Kafka Capability Centric Design DDD / ES & CQRS Agile: Kanban Continuous Delivery Testing Strategies Security Best Practices
  3. 3. MICROSERVICES • CONCEPTS • WHEN SHOULD YOU USE MICROSERVICES? • WHAT’S THE RIGHT SIZE? • ARCHITECTURE (INFRATRUCTURE AND SOFTWRE) 2/19/2019 3
  4. 4. Pioneers in Microservices Implementation 19-02-2019 4 New Entrants
  5. 5. Microservices Characteristics 5 By James Lewis and Martin Fowler We can scale our operation independently, maintain unparalleled system availability, and introduce new services quickly without the need for massive reconfiguration. — Werner Vogels, CTO, Amazon Web Services Modularity ... is to a technological economy what the division of labor is to a manufacturing one. W. Brian Arthur, author of e Nature of Technology The key in making great and growable systems is much more to design how its modules communicate rather than what their internal properties and behaviors should be. Alan Kay, 1998 email to the Squeak-dev list Components via Services Organized around Business Capabilities Products NOT Projects Smart Endpoints & Dumb Pipes Decentralized Governance & Data Management Infrastructure Automation Design for Failure Evolutionary Design
  6. 6. When should I use them (Microservices)? 19-02-2019 6 • Strong Module Boundaries: Microservices reinforce modular structure, which is particularly important for larger teams. • Independent Deployment: Simple services are easier to deploy, and since they are autonomous, are less likely to cause system failures when they go wrong. • Technology Diversity: With microservices you can mix multiple languages, development frameworks and data- storage technologies. When you have What’s the Cost Distribution: Distributed systems are harder to program, since remote calls are slow and are always at risk of failure. Eventual Consistency: Maintaining strong consistency is extremely difficult for a distributed system, which means everyone has to manage eventual consistency. Operational Complexity: You need a mature operations team to manage lots of services, which are being redeployed regularly. Source: https://www.martinfowler.com/microservices/
  7. 7. What is the right size for a Microservice? 19-02-2019 7 • Rather than the size what matters is the Business Function / Domain of the service. • One Microservice may have half a dozen entities and other a couple of dozen entities. What’s more important is the role Microservices plays. • Bounded Context from DDD helps you to decompose a large multi domain Monolith into a Microservice for each Bounded Context. • Focusing on User stories will help you clearly define the boundaries of the Business Domain.
  8. 8. Microservices Architecture 19-02-2019 8 • API Gateway • Service Discovery • Config Service • Event Bus / Streams • Service Mesh • Hexagonal Architecture • Domain Driven Design • Event Sourcing & CQRS • Functional Reactive Programming Infrastructure Architecture
  9. 9. 19-02-20199 Monolithic vs. Microservices Example Traditional Monolithic App using Single Technology Stack Micro Services with Multiple Technology Stack This 3 tier model is obsolete now. Source: Gartner Market Guide for Application Platforms Nov 23, 2016 Event Stream API Gateway (Zuul Edge Server) Load Balancer (Ribbon) Circuit Breaker (Hystrix) Service Discovery (Eureka) Load Balancer (Ribbon) Circuit Breaker (Hystrix) Load Balancer (Ribbon) Circuit Breaker (Hystrix) UI Layer Web Services Business Logic Database Layer Micro Service 4 EE 7 Inventory UI Layer Web Services Business Logic Database Layer Micro Service 1 Customer SE 8 UI Layer Web Services Business Logic Database Layer Micro Service 3 ShoppingCart UI Layer Web Services Business Logic Database Layer Micro Service 2 Order UI Layer WS BL DL Database ShoppingCart Order Customer Inventory
  10. 10. 19-02-2019 10 SOA vs. Microservices Example Traditional Monolithic App with SOA Micro Services with Multiple Technology Stack Event Stream UI Layer Web Services Business Logic Database Layer Micro Service 1 Customer SE 8 UI Layer Web Services Business Logic Database Layer Micro Service 3 ShoppingCart UI Layer Web Services Business Logic Database Layer Micro Service 2 Order API Gateway Load Balancer Circuit Breaker Service Discovery Load Balancer Circuit Breaker Load Balancer Circuit Breaker UI Layer Database ShoppingCart Order Customer Inventory Enterprise Service Bus Messaging REST / SOAP HTTP MOM JMS ODBC / JDBC Translation Web Services XML WSDL Addressing Security Registry Management Producers Shared Database Consumers3rd Party Apps Smart Pipes Lot of Business logic resides in the Pipe
  11. 11. Microservices Deployment Model Micro Services with Multiple Technology Stack Event Stream Users Service Discovery (Eureka) Config Server (Spring) API (Zuul) Gateway UI Layer Web Services Business Logic Database Layer Micro Service 2 ShoppingCart SE 8 LB = Ribbon CB = Hystrix LB = Ribbon CB = Hystrix UI Layer Web Services Business Logic Database Layer Product SE 8 Micro Service 1 With 4 node cluster LB = Ribbon CB = Hystrix UI Layer Web Services Business Logic Database Layer Order SE 8 Micro Service 3 With 2 node Cluster LB = Ribbon CB = Hystrix UI Layer Web Services Business Logic Database Layer Customer Micro Service 4 With 2 node cluster HTTP Server All UI Code is bundled Virtual Private Network 19-02-2019 11
  12. 12. Pros 1. Adds Complexity 2. Skillset shortage 3. Confusion on getting the right size 4. Team need to manage end-to-end of the Service (From UI to Backend to Running in Production). 19-02-2019 12 1. Robust 2. Scalable 3. Testable (Local) 4. Easy to Change and Replace 5. Easy to Deploy 6. Technology Agnostic Cons Microservices Pros and Cons
  13. 13. Monolithic > Microservices • FORRESTER RESEARCH • MODERNIZATION JOURNEY • ASSESS AND CLASSIFY YOUR APP PORTFOLIO • PLAN AND PRIORITIZE 2/19/2019 (C)COPYRIGHTMETAMAGICGLOBALINC.,NEWJERSEY,USA 13
  14. 14. * For IT Services : They can do one more project of same size with ZERO COST in Platform Licensing (Based on 20 developer pack USD $50K per month for 3 months License cost = $150K) 1419-02-2019
  15. 15. Modernization Journey 2/19/2019 (C)COPYRIGHTMETAMAGICGLOBALINC.,NEWJERSEY,USA 15  Start new features as Microservices Incrementally establish the success early.  Expose Legacy On-Premise Apps API’s If legacy Apps cant be shifted to Cloud  Refactor Monolithic features to Microservices Breakdown and Deploy Feature by Feature  Containerize the Microservice Reduce costs, simplifies the operations and consistent environment between Dev, QA and Production  Monolith De-commission Plan Incrementally sunset the Monolith Velocity as you transform Increase your Delivery Velocity along the Journey High FuturePresent Low
  16. 16. Assess and Classify your App Portfolio 2/19/2019 16  Take inventory of your Apps Classify the Apps based on technology, complexity.  Align Apps to your Business Priorities Identify the Apps that are critical for Modernization.  Identify Business Modernization Requirements Create a Roadmap with faster go to market strategy  Understand the effort and Cost Evaluate all possible Modernization options Container Refactor Expose APIsLift & Shift BusinessValueCostComplexity Product Catalogue Product Review Inventory Shopping Cart Customer Profile Order Management
  17. 17. Plan and Prioritize 2/19/2019 17 Complexity Cost Value Score Rank Weightage 35% 25% 40% Product Reviews Med 3 High 5 Med 3 3.50 11 3 Shopping Cart High 5 Med 3 Med 3 3.70 11 4 Customer Med 3 Med 3 Low 1 2.20 7 6 Product Catalogue Med 3 Med 3 High 5 4.80 11 1 Order Very High 7 Med 3 High 5 5.20 15 2 Inventory Very High 7 High 5 Med 3 4.90 15 5  Prioritize Low Priority projects are good test cases but does not bring much business value.  Quick Wins Identify a feature / project which has good business value and low in complexity.  Project Duration Focus on shorter duration projects with high Business Value. Shopping Portal Features Prioritization
  18. 18. Containers & Kubernetes • DOCKER CONTAINERS • KUBERNETES – CONTAINER ORCHESTRATION • ISTIO – TRAFFIC MANAGEMENT / NETWORK POLICIES 2/19/2019 (C)COPYRIGHTMETAMAGICGLOBALINC.,NEWJERSEY,USA 18
  19. 19. Servers / Virtual Machines / Containers Hardware OS BINS / LIB App 1 App 2 App 3 Server Hardware Host OS HYPERVISOR App 1 App 2 App 3 Guest OS BINS / LIB Guest OS BINS / LIB Guest OS BINS / LIB Type 1 Hypervisor Hardware Host OS App 1 App 2 App 3 BINS / LIB BINS / LIB BINS / LIB Container Hardware HYPERVISOR App 1 App 2 App 3 Guest OS BINS / LIB Guest OS BINS / LIB Guest OS BINS / LIB Type 2 Hypervisor19-02-2019 19
  20. 20. Linux Kernel 20 HOST OS (Ubuntu) Client Docker Daemon Cent OS Alpine Debian HostLinuxKernel Host Kernel Host Kernel Host Kernel All the containers will have the same Host OS Kernel If you require a specific Kernel version then Host Kernel needs to be updated HOST OS (Windows 10) Client Docker Daemon Nano Server Server Core Nano Server WindowsKernel Host Kernel Host Kernel Host Kernel Windows Kernel
  21. 21. Docker DaemonDocker Client How Docker works…. $ docker search …. $ docker build …. $ docker container create .. Docker Hub Images Containers $ docker container run .. $ docker container start .. $ docker container stop .. $ docker container ls .. $ docker push …. $ docker swarm .. 19-02-2019 21 21 34 1. Search for the Container 2. Docker Daemon Sends the request to Hub 3. Downloads the image 4. Run the Container from the image
  22. 22. Kubernetes Key Concepts 2/19/2019 (C)COPYRIGHTMETAMAGICGLOBALINC.,NEWJERSEY,USA 22 o Declarative Model Infrastructure as a code o Desired State Minimum state of your App / Microservice o Current State Current State of the due to error or load factor Pods Replicas Deploy Service
  23. 23. Deployment – Updates and rollbacks, Canary Release D ReplicaSet – Self Healing, Scalability, Desired State R Worker Node 1 Master Node (Control Plane) Kubernetes Architecture POD POD itself is a Linux Container, Docker container will run inside the POD. PODs with single or multiple containers (Sidecar Pattern) will share Cgroup, Volumes, Namespaces of the POD. (Cgroup / Namespaces) Scheduler Controller Manager Using yaml or json declare the desired state of the app. State is stored in the Cluster store. Self healing is done by Kubernetes using watch loops if the desired state is changed. POD POD POD BE 1.210.1.2.34 BE 1.210.1.2.35 BE 1.210.1.2.36 BE 15.1.2.100 DNS: a.b.com 1.2 Service Pod IP Address is dynamic, communication should be based on Service which will have routable IP and DNS Name. Labels (BE, 1.2) play a critical role in ReplicaSet, Deployment, & Services etc. Cluster Store etcd Key Value Store Pod Pod Pod Label Selector selects pods based on the Labels. Label Selector Label Selector Label Selector Node Controller End Point Controller Deployment Controller Pod Controller …. Labels Internet Firewall K8s Cluster Cloud Controller For the cloud providers to manage nodes, services, routes, volumes etc. Kubelet Node Manager Container Runtime Interface Port 10255 gRPC ProtoBuf Kube-Proxy Network Proxy TCP / UDP Forwarding IPTABLES / IPVS Allows multiple implementation of containers from v1.7 RESTful yaml / json $ kubectl …. Port 443API Server Pod IP ...34 ...35 ...36EP • Declarative Model • Desired State Key Aspects Namespace1Namespace2 • Pods • ReplicaSet • Deployment • Service • Endpoints • StatefulSet • Namespace • Resource Quota • Limit Range • Persistent Volume Kind Secrets Kind • apiVersion: • kind: • metadata: • spec: Declarative Model • Pod • ReplicaSet • Service • Deployment • Virtual Service • Gateway, SE, DR • Policy, MeshPolicy • RbaConfig • Prometheus, Rule, • ListChekcer … @ @ Annotations Names Cluster IP Node Port Load Balancer External Name @ Ingress 19-02-2019 23
  24. 24. Service Mesh – Sidecar Design Pattern 19-02-2019 24 CB – Circuit Breaker LB – Load Balancer SD – Service Discovery Microservice Process1Process2 Service Mesh Control Plane Service Discovery Routing Rules Control Plane will have all the rules for Routing and Service Discovery. Local Service Mesh will download the rules from the Control pane will have a local copy. Service Discovery Calls Service Mesh Calls Customer Microservice Application Localhost calls http://localhost/api/order/ Router Network Stack LBCB SD ServiceMesh Sidecar UI Layer Web Services Business Logic Order Microservice Application Localhost calls http://localhost/api/payment/ Router Network Stack LBCB SD ServiceMesh Sidecar UI Layer Web Services Business Logic Data Plane
  25. 25. Shopping Portal /ui /productms /productreview Gateway Virtual Service UI Pod UI Pod UI Pod UI Service Product Pod Product Pod Product Pod Product Service Review Pod Review Pod Review Pod Review Service Deployment / Replica / Pod N1 N2 N2 MySQL Pod N4 N3 N1 N4 N3 NodesIstio Sidecar - Envoy Destination Rule Destination Rule Destination Rule Load Balancer Kubernetes Objects Istio Objects Firewall P M CIstio Control Plane UI Pod N5 v1 v2 Stable / v1 Canary v2User X = Canary Others = Stable A / B Testing using Canary Deployment Service Call Kube DNS EndPoints EndPoints EndPoints Internal Load Balancers 25 Source:https://github.com/meta-magic/kubernetes_workshop
  26. 26. Shopping Portal /ui /productms /productreview Gateway Virtual Service UI Pod UI Pod UI Pod UI Service Product Pod Product Pod Product Pod Product Service Review Pod Review Pod Review Pod Review Service Deployment / Replica / Pod N1 N2 N2 MySQL Pod N4 N3 N1 N4 N3 NodesIstio Sidecar - Envoy Destination Rule Destination Rule Destination Rule Load Balancer Kubernetes Objects Istio Objects Firewall P M CIstio Control Plane UI Pod N5 v1 v2 Stable / v1 Canary v210% = Canary 90% = Stable Traffic Shifting Canary Deployment Service Call Kube DNS EndPoints EndPoints EndPoints Internal Load Balancers 26 Source:https://github.com/meta-magic/kubernetes_workshop
  27. 27. 27 Shopping Portal /ui /productms /productreview Gateway Virtual Service UI Pod UI Pod UI Pod UI Service Review Pod Review Pod Review Pod Review Service Deployment / Replica / Pod N1 N2 N2 MySQL Pod N4 N3 N1 N4 N3 NodesIstio Sidecar - Envoy Destination Rule Destination Rule Destination Rule Load Balancer Kubernetes Objects Istio Objects Firewall P M CIstio Control Plane v1 Fault Injection Delay = 2 Sec Abort = 10% Fault Injection Product Pod Product Pod Product Pod Product Service Service Call Kube DNS EndPoints EndPoints EndPoints Internal Load Balancers 27 Source:https://github.com/meta-magic/kubernetes_workshop
  28. 28. Kafka • CONCEPTS : QUEUES / PUB – SUB / EVENT STREAMING • WHY IS IT DIFFERENT FROM TRADITIONAL MESSAGE QUEUES? • DATA STORAGE / CLUSTER / DURABILITY • PERFORMANCE 2/19/2019 (C)COPYRIGHTMETAMAGICGLOBALINC.,NEWJERSEY,USA 28
  29. 29. Kafka Core Concepts 19-02-2019 29 Publish & Subscribe Read and write streams of data like a messaging system Process Write scalable stream processing apps that react to events in real- time. Store Store streams of data safely in a distributed, replicated, fault tolerant cluster.
  30. 30. Traditional Queue / Pub-Sub Vs. Kafka 19-02-2019 30 0 1 2 3 4 5 6 7 8 9 8 7 9 Consumer 1 Consumer 2 Consumer 3 Queues Data Data can be partitioned for scalability for parallel processing by same type of consumers Pros: Cons: Queues are not multi subscribers. Once a Consumer reads the data, its gone from the queue. Ordering of records will be lost in asynchronous parallel processing. 0 1 2 3 4 5 6 7 8 9 9 9 9 Consumer 1 Consumer 2 Consumer 3 Pub – Sub Data Multiple subscribers can get the same data.Pros: Scaling is difficult as every message goes to every subscriber. Cons: Kafka generalizes these two concepts.  As with a queue the consumer group allows you to divide up processing over a collection of processes (the members of the consumer group).  As with publish-subscribe, Kafka allows you to broadcast messages to multiple consumer groups.
  31. 31. Anatomy of a Topic 19-02-2019 31 Source : https://kafka.apache.org/intro • A Topic is a category or feed name to which records are published. • Topics in Kafka are always multi subscriber. • That is, a Topic can have zero, one, or many consumers that subscribe to the data written to it. • Each Partition is an ordered, immutable sequence of records that is continually appended to—a structured commit log. • A Partition is nothing but a directory of Log Files • The records in the partitions are each assigned a sequential id number called the offset that uniquely identifies each record within the partition.
  32. 32. 19-02-2019 32 Partition Log Segment • Partition (Kafka’s Storage unit) is Directory of Log Files. • A partition cannot be split across multiple brokers or even multiple disks • Partitions are split into Segments • Segments are two files: 000.log & 000.index • Segments are named by their base offset. The base offset of a segment is an offset greater than offsets in previous segments and less than or equal to offsets in that segment. • Indexes store offsets relative to its segments base offset • Indexes map each offset to their message position in the log and they are used to look up messages. • Purging of data is based on oldest segment and one segment at a time. 0 1 2 3 4 5 6 7 8 9 Partition Data 6 3 0 Segment 0 Segment 3 Segment 6 9 Segment 9 - Active $ tree kafka-logs | head -n 6 kafka-logs |──── SigmaHawk-2 | |──── 00000000006109871597.index | |──── 00000000006109871597.log | |──── 00000000007306321253.index | |──── 00000000007306321253.log Topic / Partition Segment 1 Segment 2 Rel.Offset, Position Offset, Position, Size, Payload 0000.index 0000.log 0 0 0 0 7 ABCDEFG 1 7 1 7 4 ABCD 2 11 2 11 9 ABCDEFGIJ 4 Bytes 4 Bytes
  33. 33. 19-02-2019 33 Kafka Cluster – Topics & Partitions • The partitions of the log are distributed over the servers in the Kafka cluster with each server handling data and requests for a share of the partitions. Source : https://kafka.apache.org/intro Broker 1 Leader Broker 2 Follower Broker 3 Follower Broker 4 Follower Broker 5 Leader Partition 1 Partition 0 Topic ABC • Each server acts as a leader for some of its partitions and a follower for others so load is well balanced within the cluster. • Each partition has one server which acts as the "leader" and zero or more servers which act as "followers".
  34. 34. 19-02-2019 34 Record Commit Process Broker 1 Leader Topic 1 Broker 2 Follower Producer Consumer 2 2 Commit 3 ack • Each partition is replicated across a configurable number of servers for fault tolerance. • The leader handles all read and write requests for the partition while the followers passively replicate the leader. • If the leader fails, one of the followers will automatically become the new leader.1 Message with Offset 4 777743 Broker 3 Follower Data Durability From Kafka v0.8.0 onwards acks Acknowledgement Description 0 If set to zero then the producer will NOT wait for any acknowledgment from the server at all. The record will be immediately added to the socket buffer and considered sent. No guarantee can be made that the server has received the record in this case, and the retries configuration will not take effect (as the client won't generally know of any failures). The offset given back for each record will always be set to -1. 1 This will mean the leader will write the record to its local log but will respond without awaiting full acknowledgement from all followers. In this case should the leader fail immediately after acknowledging the record but before the followers have replicated it then the record will be lost. All / -1 This means the leader will wait for the full set of in-sync replicas to acknowledge the record. This guarantees that the record will not be lost as long as at least one in-sync replica remains alive. This is the strongest available guarantee. This is equivalent to the acks=-1 setting. Source: https://kafka.apache.org/documentation/#topicconfigs acks Steps 0 1 1 1,3 -1 1,2,3 Producer Configuration
  35. 35. 19-02-2019 35 Replication 6 3.2 m1 m2 m3 L(A) m1 m2 F(B) m1 F(C)ISR = (A, B, C) Leader A commits Message m1. Message m2 & m3 not yet committed. 1 m1 m2 F(C) m1 m2 L(B) m1 m2 m3 L(A) ISR = (B,C) A fails and B is the new Leader. B commits m22 m1 m2 m3 L(A) m1 m2 L(B) m4 m5 m1 m2 F(C) m4 m5 ISR = (B,C) B commits new messages m4 and m5 3 m1 m2 L(B) m4 m5 m1 m2 F(C) m4 m5 m1 F(A) ISR = (A, B,C) A comes back, restores to last commit and catches up to latest messages. 4 m1 m2 L(B) m4 m5 m1 m2 F(C) m4 m5 m1 m2 F(A) m4 m5 ISR – In-sync Replica • Instead of majority vote, Kafka dynamically maintains a set of in-sync replicas (ISR) that are caught-up to the leader. • Only members of this set are eligible for election as leader. • A write to a Kafka partition is not considered committed until all in-sync replicas have received the write. • This ISR set is persisted to ZooKeeper whenever it changes. Because of this, any replica in the ISR is eligible to be elected leader.
  36. 36. LinkedIn Kafka Cluster 19-02-2019 36 Brokers60 Partitions50K Messages / Second800K MB / Second inbound300 MB / Second Outbound1024 The tuning looks fairly aggressive, but all of the brokers in that cluster have a 90% GC pause time of about 21ms, and they’re doing less than 1 young GC per second.
  37. 37. Uber Kafka Cluster 19-02-2019 37 Topics10K+ Events / Second11M Petabyte of Data1PB+
  38. 38. 12 Factor App Methodology 19-02-2019 38 4 Backing Services Treat Backing services like DB, Cache as attached resources 5 Build, Release, Run Separate Build and Run Stages 6 Process Execute App as One or more Stateless Process 7 Port Binding Export Services with Specific Port Binding 8 Concurrency Scale out via the process Model 9 Disposability Maximize robustness with fast startup and graceful exit 10 Dev / Prod Parity Keep Development, Staging and Production as similar as possible 11 Logs Treat logs as Event Streams 12 Admin Process Run Admin Tasks as one of Process Source:https://12factor.net/ Factors Description 1 Codebase One Code base tracked in revision control 2 Dependencies Explicitly declare dependencies 3 Configuration Configuration driven Apps
  39. 39. CAPABILITY CENTRIC DESIGN • BUSINESS FUNCTIONS • BUSINESS PROCESS • TEAM STRUCTURE 2/19/2019 39
  40. 40. Business Solution & Business Process 2/19/2019 40  Business Solution focuses the entire Journey of the User which can run across multiple Micro Services.  Business Solution comprises a set of Business Processes.  A specific Micro Service functionality will be focused on a Business Process / Concern Business Solution: Customer Dining Experience Order PaymentFood Menu KitchenDining Browse Menu Order Dinner Dinner Served Get Bill Make Payment
  41. 41. 2/19/2019 41 Capability Centric Design Vertically sliced Product Team Business Centric Development • Focus on Business Capabilities • Entire team is aligned towards Business Capability. • From Specs to Operations – The team handles the entire spectrum of Software development. • Every vertical will have it’s own Code Pipeline Front-End-Team Back-End-Team Database-Team In a typical Monolithic way the team is divided based on technology / skill set rather than business functions. This leads to not only bottlenecks but also lack of understanding of the Business Domain. QA / QC Team Front-End Back-End Database Business Capability 1 QA/QCTeam Front-End Back-End Database Business Capability 2 QA/QCTeam Front-End Back-End Database Business Capability 3 QA/QCTeam
  42. 42. 2/19/2019 (C)COPYRIGHTMETAMAGICGLOBALINC.,NEWJERSEY,USA 42 Architecture / Design • DOMAIN DRIVEN DESIGN • EVENT SOURCING AND CQRS • FUNCTIONAL REACTIVE PROGRAMMING • DISTRIBUTED TRANSACTIONS • CASE STUDY
  43. 43. 2/19/2019 43 Ubiquitous Language Vocabulary shared by all involved parties Used in all forms of spoken / written communication Ubiquitous Language Domain Expert Analyst Developers QA Design Docs Test Cases Code Restaurant Context – Food Item : Eg. Food Item (Navrathnakurma) can have different meaning or properties depends on the context. • In the Menu Context it’s a Veg Dish. • In the Kitchen Context it’s is recipe. • And in the Dining Context it will have more info related to user feed back etc. DDD: Ubiquitous Language: Strategic Design As an Restaurant Owner I want to know who my Customers are So that I can serve them better Role-Feature-Reason Matrix BDD – Behavior Driven Development Given Customer John Doe exists When Customer orders food Then Assign customer preferences as Veg or Non Veg customer BDD Construct
  44. 44. 2/19/2019 44 Domain Driven Design – Tactical Design Source: Domain-Driven Design Reference by Eric Evans
  45. 45. 2/19/2019 45 Shopping Portal Modules – Code Packaging Auth Products Cart OrderCustomer Domain Layer • Models • Repo • Services • Factories Adapters • Repo • Services • Web Services Domain Layer • Models • Repo • Services • Factories Adapters • Repo • Services • Web Services Domain Layer • Models • Repo • Services • Factories Adapters • Repo • Services • Web Services Packaging Structure Bounded Context Implementation (Repositories, Business Services, Web Services) Domain Models (Entities, Value Objects, DTOs) (Repositories, Business Services, Web Services) Entity Factories Interfaces (Ports)
  46. 46. 2/19/2019 46 DDD: Use Case Order Module Models Value Object • Currency • Item Value • Order Status • Payment Type • Record State • Audit Log Entity • Order (Aggregate Root) • Order Item • Shipping Address • Payment DTO • Order • Order Item • Shipping Address • Payment Domain Layer Adapters • Order Repository • Order Service • Order Web Service • Order Query Web Service • Shipping Address Web Service • Payment Web Service Adapters Consists of Actual Implementation of the Ports like Database Access, Web Services API etc. Converters are used to convert an Enum value to a proper Integer value in the Database. For Example Order Status Complete is mapped to integer value 100 in the database. Services / Ports • Order Repository • Order Service • Order Web Service Utils • Order Factory • Order Status Converter • Record State Converter • Order Query Web Service • Shipping Address Web Service • Payment Web Service Shopping Portal
  47. 47. 2/19/2019 47 Event Sourcing Intro Standard CRUD Operations – Customer Profile – Aggregate Root Profile Created Title Updated New Address added Derived Notes Removed Time T1 T2 T4T3 Event Sourcing and Derived Aggregate Root Commands 1. Create Profile 2. Update Title 3. Add Address 4. Delete Notes 2 Events 1. Profile Created Event 2. Title Updated Event 3. Address Added Event 4. Notes Deleted Event 3 Current State of the Customer Profile 4 Event store Single Source of Truth Greg Young
  48. 48. 2/19/2019 48 Functional Reactive Programming: 4 Building Blocks of RxJava Source of Data Stream [ Sender ]Observable1 Listens for emitted values [ Receiver ]Observer2 Source: http://reactivex.io/ Schedulers3 Schedulers are used to manage and control concurrency. 1. observeOn: Thread Observable is executed 2. subscribeOn: Thread subscribe is executed 4 Operators Content Filtering Time Filtering Transformation Operators that let you Transform, Combine, Manipulate, and work with the sequence of items emitted by Observables
  49. 49. 2/19/2019 49 Comparison : Iterable / Streams / Observable 1Building Block First Class Visitor (Consumer) Serial Operations Parallel Streams (10x Speed) Still On Next, On Complete and On Error are Serial Operations Completely Asynchronous Operations Java 8 – Blocking CallJava 6 – Blocking Call Rx Java - Freedom Source Code: https://github.com/meta-magic/rxjava
  50. 50. 2/19/2019 50 Rx 2 Java Operator : Filter / Sort / FlatMap 4Building Block Objective: toSortedList() returns an Observable with a single List containing Fruits. Using FlatMap to Transform Observable <List> to Observable <Fruit> Rx Example 2 SourceCodeGitHub:https://github.com/meta-magic/Rx-Java-2 • Merge • Filter • Sort • Take
  51. 51. 2/19/2019 51 Distributed Tx: SAGA Design Pattern instead of 2PC Long Lived Transactions (LLTs) hold on to DB resources for relatively long periods of time, significantly delaying the termination of shorter and more common transactions. Source: SAGAS (1987) Hector Garcia Molina / Kenneth Salem, Dept. of Computer Science, Princeton University, NJ, USA T1 T2 Tn Local Transactions C1 C2 Cn-1 Compensating Transaction Divide long–lived, distributed transactions into quick local ones with compensating actions for recovery. Travel : Flight Ticket & Hotel Booking Example BASE (Basic Availability, Soft State, Eventual Consistency) Room ReservedT1 Room PaymentT2 Seat ReservedT3 Ticket PaymentT4 Cancelled Room Reservation C1 Cancelled Room Payment C2 Cancelled Ticket Reservation C3
  52. 52. 2/19/2019 52 Case Study: Restaurant Dining – Event Sourcing and CQRS Order Payment • Add Drinks • Add Food • Update Food Commands • Open Table • Add Juice • Add Soda • Add Appetizer 1 • Add Appetizer 2 • Serve Drinks • Prepare Food • Serve Food Events • Drinks Added • Food Added • Food Updated • Food Discontinued • Table Opened • Juice Added • Soda Added • Appetizer 1 Added • Appetizer 2 Added • Juice Served • Soda Served • Appetizer Served • Food Prepared • Food Served • Prepare Bill • Process Payment • Bill Prepared • Payment Processed • Payment Approved • Payment Declined • Cash Paid When people arrive at the Restaurant and take a table, a Table is opened. They may then order drinks and food. Drinks are served immediately by the table staff, however food must be cooked by a chef. Once the chef prepared the food it can then be served. Table is closed then the bill is prepared. Microservices • Dinning Order • Billable Order Customer Journey thru Dinning Processes Processes Food Menu KitchenDining • Remove Soda • Add Food 1 • Add Food 2 • Place Order • Close Table • Remove Soda • Food 1 Added • Food 2 Added • Order Placed • Table Closed ES Aggregate 3 2 4 1
  53. 53. 2/19/2019 53 RESTful APIs • STANDARDS • API VERSIONING STANDARDS
  54. 54. 2/19/2019 54 RESTful Guidelines 1. Endpoints as nouns, NOT verbs Ex. /catalogues /orders /catalogues/products and NOT /getProducts/ /updateProducts/ 2. Use plurals Ex. /catalogues/{catalogueId} and NOT /catalogue/{catalogueId} 3. Documenting 4. Paging 5. Use SSL 6. HTTP Methods GET / POST / PUT / DELETE / OPTIONS / HEAD 7. HTTP Status Codes (Effective usage) 8. Versioning Media Type Version GET /account/5555 HTTP/1.1 Accept: application/vnd.catalogues.v1+json URL path version https://domain/v1/catalogues/products
  55. 55. 2/19/2019 55 RESTful Guidelines – Query Examples Search All Products Search Products By Catalogue ID Search Products By Catalogue ID & Product ID
  56. 56. 2/19/2019 56 RESTful Guidelines – Query Examples Two different implementation of same query
  57. 57. 2/19/2019 57 # Name * Who Uses Pros Cons 1 Media Type Versioning Accept: Application/vnd.api.article+xml; version=1.0 Med GitHub • Version Directly @ resource level • Preserve URI • Close to RESTful Specs • Harder to Test • Distort HTTP Headers purpose • Tools required for testing 2 Custom Headers Versioning X-API-Version: 2. Med Microsoft • Preservers URI • Harder to Test • Tools required for testing 3 URI Versioning api.example.com/v1/resource High Google Twitter Amazon • Most common method • Versions can be explored using Browser • Easy to use • Disrupts RESTful Compliance. URI should represent resource and not versions 4 Domain Versioning apiv1.example.com/resource Low Facebook • Same as are URI Versioning • Same as URI Versioning 5 Request Parameter Versioning GET /something/?version=0.1 High Pivotal NetFlix • Similar to URI versioning • It can get messy 6 Date Versioning First request saves the date. Low Clearbit • New APIs can be shipped without changing the end points • Complex to implement • Traceability is difficult. API Versioning
  58. 58. 2/19/2019 58 Testing Strategies • UNIT TESTING • COMPONENT TESTING • INTEGRATION CONTRACT TESTING • INTEGRATION TESTING
  59. 59. 2/19/2019 59 Microservices Testing Strategies Ubiquitous Language Domain Expert Analyst Developers QA Design Docs Test Cases Code E2E Testing Integration Testing Contract Testing Component Testing Unit Testing Number of Tests Speed Cost Time Mike Cohen’s Testing Pyramid Test Pyramid: https://martinfowler.com/bliki/TestPyramid.html 70% 20% 10%
  60. 60. 2/19/2019 60 Microservices Testing Strategy Unit Testing A unit test exercises the smallest piece of testable software in the application to determine whether it behaves as expected. Source: https://martinfowler.com/articles/microservice-testing/#agenda Component Testing A component test limits the scope of the exercised software to a portion of the system under test, manipulating the system through internal code interfaces and using test doubles to isolate the code under test from other components. Integration Testing An integration test verifies the communication paths and interactions between components to detect interface defects Integration Contract Testing An Integration Contract test is a test at the boundary of an external service verifying that it meets the contract expected by a consuming service. End 2 End Testing An end-to-end test verifies that a system meets external requirements and achieves its goals, testing the entire system, from end to end Say NO to End 2 End Tests - Mike Walker April 22, 2015. Google Test Blog
  61. 61. 2/19/2019 61 Testing ToolsMicroservices Testing Scenarios / Tools Contract Testing Scope Integration Testing Verifies the communication paths and interactions between components to detect interface defects Contract Testing It is a test at the boundary of an external service verifying that it meets the contract expected by a consuming service. Payment Mock IntegrationContractTestingScope Test Double Montebank Cart Component Testing Unit Testing IntegrationTestingScope Order REST / HTTP or Events / Kafka Item ID, Quantity, Address.. Mock Order Component Testing A component test limits the scope of the exercised software to a portion of the system under test. Order Payment Unit Testing Firewall Integration Testing Scope REST / HTTP Payment Sandbox Component Testing
  62. 62. 2/19/2019 62 Security Best Practices • DOCKER • KUBERNETES
  63. 63. 2/19/2019 63 Build Small Container Images • Simple Java Web Apps with Ubuntu & Tomcat can have a size of 700 MB • Use Alpine Image as your base Linux OS • Alpine images are 10x smaller than base Ubuntu images • Smaller Image size reduce the Container vulnerabilities. • Ensure that only Runtime Environments are there in your container. For Example your Alpine + Java + Tomcat image should contain only the JRE and NOT JDK. • Log the App output to Container Std out and Std error. 1
  64. 64. 2/19/2019 64 Docker: To Root or Not to Root! • Create Multiple layers of Images • Create a User account • Add Runtime software’s based on the User Account. • Run the App under the user account • This gives added security to the container. • Add Security module SELinux or AppArmour to increase the security, Alpine JRE 8 Tomcat 8 My App 1 2
  65. 65. 2/19/2019 65 Docker: Container Security 1. Secure your HOST OS! Containers runs on Host Kernel. 2. No Runtime software downloads inside the container. Declare the software requirements at the build time itself. 3. Download Docker base images from Authentic site. 4. Limit the resource utilization using Container orchestrators like Kubernetes. 5. Don’t run anything on Super privileged mode. 3
  66. 66. 2/19/2019 66 Kubernetes: Naked Pods • Never use a Naked Pod, that is Pod without any ReplicaSet or Deployments. Naked pods will never get re-scheduled if the Pod goes down. • Never access a Pod directly from another Pod. Always use a Service to access a Pod. • User labels to select the pods { app: myapp, tier: frontend, phase: test, deployment: v3 }. • Never use :latest tag in the image in the production scenario. 4
  67. 67. 2/19/2019 67 Kubernetes: Namespace default Kube system Kube public Kubernetes Cluster• Group your Services / Pods / Traffic Rules based on Specific Namespace. • This helps you apply specific Network Policies for that Namespace with increase in Security and Performance. • Handle specific Resource Allocations for a Namespace. • If you have more than a dozen Microservices then it’s time to bring in Namespaces. Service-Name.Namespace.svc.cluster.local $ kubectl config set-context $(kubectl config current-context) --namespace=your-ns The above command will let you switch the namespace to your namespace (your-ns). 5
  68. 68. 2/19/2019 68 Kubernetes: Pod Health Check • Pod Health check is critical to increase the overall resiliency of the network. • Readiness • Liveness • Ensure that all your Pods have Readiness and Liveness Probes. • Choose the Protocol wisely (HTTP, Command & TCP) 6
  69. 69. 2/19/2019 69 Kubernetes: Resource Utilization • For the Best Quality define the requests and limits for your Pods. • You can set specific resource requests for a Dev Namespace to ensure that developers don’t create pods with a very large resource or a very small resource. • Limit Range can be set to ensure that containers were create with too low resource or too large resource. 7
  70. 70. 2/19/2019 70 Kubernetes: Pod Termination Lifecycle • Make sure that the Application to Handle SIGTERM message. • You can use preStop Hook • Set the terminationGracePeriodSeconds: 60 • Ensure that you clean up the connections or any other artefacts and ready for clean shutdown of the App (Microservice). • If the Container is still running after the grace period, Kubernetes sends a SIGKILL event to shutdown the Pod. 8
  71. 71. 2/19/2019 71 Kubernetes: External Services • There are systems that can be outside the Kubernetes cluster like • Databases or • external services in the cloud. • You can create an Endpoint with Specific IP Address and Port with the same name as Service. • You can create a Service with an External Name (URL) which does a CNAME redirection at the Kernel level. 9
  72. 72. 2/19/2019 72 Kubernetes: Upgrade Cluster • Make sure that the Master behind a Load Balancer. • Upgrade Master • Scale up the Node with an extra Node • Drain the Node and • Upgrade Node • Cluster will be running even if the master is not working. Only Kubectl and any master specific functions will be down until the master is up. 10
  73. 73. 2/19/2019 73 Kanban • BOARDS AND CARDS • KANBAN VS SCRUM • BENEFITS OF KANBAN
  74. 74. 2/19/2019 74 What is Kanban Kanban is a method for managing the creation of products with an emphasis on • continual delivery while • not overburdening the development team. Like Scrum, Kanban is a process designed to help teams work together more effectively. Kanban is a visual management method that was developed by Hirotaka Takeuchi and Ikujiro Nonaka
  75. 75. 2/19/2019 75 Three Principles of Kanban Source: https://resources.collab.net/agile-101/what-is-kanban • Visualize what you do today (workflow): seeing all the items in context of each other can be very informative • Limit the amount of work in progress (WIP): this helps balance the flow-based approach so teams don’t start and commit to too much work at once • Enhance flow: when something is finished, the next highest thing from the backlog is pulled into play
  76. 76. 2/19/2019 76 Kanban Release Cycles Preparation Requirements Design Development Testing Release 1 – 4 Weeks Cycle
  77. 77. 2/19/2019 77 Kanban Boards and Cards
  78. 78. 2/19/2019 78 Kanban vs. Scrum Kanban Scrum Roles & Responsibilities No prescribed roles Pre-defined roles of Scrum master, Product owner and team member Delivery Time Lines Continuous Delivery Time boxed sprints Delegation & Prioritization Work is pulled through the system (single piece flow) Work is pulled through the system in batches (the sprint backlog) Modifications Changes can be made at any time No changes allowed mid-sprint Measurement of Productivity Cycle time Velocity When to Use? More appropriate in operational environments with a high degree of variability in priority More appropriate in situations where work can be prioritized in batches that can be left alone Source: https://leankit.com/learn/kanban/kanban-vs-scrum/
  79. 79. 2/19/2019 79 Benefits of Kanban • Shorter cycle times can deliver features faster. • Responsiveness to Change: • When priorities change very frequently, Kanban is ideal. • Balancing demand against throughput guarantees that most the customer-centric features are always being worked. • Requires fewer organization / room set-up changes to get started • Reducing waste and removing activities that don’t add value to the team/department/organization • Rapid feedback loops improve the chances of more motivated, empowered and higher-performing team members
  80. 80. 2/19/2019 80 Design Patterns are solutions to general problems that software developers faced during software development. Design Patterns
  81. 81. 2/19/2019 81 Araf Karsh Hamid : Co-Founder / CTO araf.karsh@metamagic.in USA: +1 (973) 969-2921 India: +91.999.545.8627 Skype / LinkedIn / Twitter / Slideshare : arafkarsh http://www.slideshare.net/arafkarsh https://www.linkedin.com/in/arafkarsh/ http://www.arafkarsh.com/ DREAM | AUTOMATE | EMPOWER
  82. 82. 2/19/2019 82 UI DesignPatterns MVC/ MVP/ MVVM View Controller Model Passes calls To Fire Events Manipulates • The Controller is responsible to process incoming requests. It receives input from users via the View, then process the user's data with the help of Model and passing the results back to the View. • Typically, it acts as the coordinator between the View and the Model. Model View Controller 1 * • The View Model is responsible for exposing methods, commands, and other properties that helps to maintain the state of the view, manipulate the model as the result of actions on the view, and trigger events in the view itself. • There is many-to-one relationship between View and ViewModel means many View can be mapped to one ViewModel. • Supports two-way data binding between View and ViewModel. View ViewModel Model Passes calls To Manipulates Updates Fire Events Model View ViewModel • The Presenter is responsible for handling all UI events on behalf of the view. This receive input from users via the View, then process the user's data with the help of Model and passing the results back to the View. • Unlike view and controller, view and presenter are completely decoupled from each other’s and communicate to each other’s by an interface. Also, presenter does not manage the incoming request traffic as controller. • Supports two-way data binding. Model View Presenter View Presenter Model Passes calls To Fire Events Manipulates Updates1 1
  83. 83. 2/19/2019 83 UI Design Patterns Flux / Redux ViewDispatcher Every action is sent to all Stores via callbacks the stores register with the Dispatcher Store Action Action 1 * Controller-Views • Listens to Store changes • Emit Actions to Dispatcher Dispatcher • Single Dispatcher per Application • Manages the Data Flow View to Model • Receives Actions and dispatch them to Stores Stores • Contains state for a Domain (Vs. Specific Component) • In Charge of modifying the Data • Inform the views when the Data is changed by emitting the Changed Event. Flux Core Concepts 1. One way Data Flow 2. No Event Chaining 3. Entire App State is resolved in store before Views Update 4. Data Manipulation ONLY happen in one place (Store). Actions • Simple JS Objects • Contains Name of the Action and Data (Payload) • Action represent something that has happened. • Has No Business Logic
  84. 84. 2/19/2019 84 UI Design Patterns Redux Actions • Simple JS Objects • Contains Name of the Action and Data (Payload) • Has NO Business Logic • Action represent something that has happened. Store • Multiple View layers can Subscribe • View layer to Dispatch actions • Single Store for the Entire Application • Data manipulation logic moves out of store to Reducers Reducer • Pure JS Functions • No External calls • Can combine multiple reducers • A function that specifies how the state changes in response to an Action. • Reducer does NOT modify the state. It returns the NEW State. Redux Core Concepts 1. One way Data Flow 2. No Dispatcher compared to Flux 3. Immutable Store Available for React & Angular View Action State Dispatcher Reducer R R R Store Middleware Middleware Middleware • Handles External calls • Multiple Middleware's can be chained.

×