Solution Architecture

@arafkarsh arafkarsh
8 Years
Network &
Security
6+ Years
Microservices
Blockchain
8 Years
Cloud
Computing
8 Years
Distributed
Computing
Architecting
& Building Apps
a tech presentorial
Combination of
presentation & tutorial
ARAF KARSH HAMID
Co-Founder / CTO
MetaMagic Global Inc., NJ, USA
@arafkarsh
arafkarsh
1
Solutions
Architecture
To Build Cloud Native Apps
Using Composable Enterprise Architecture
To Manage
SpecOps: From Specs to Ops
Introduction to 12 Part Series

View Slide

Management
Pipeline Automation
Architecture
SpecOps Workflow - SDLC
2
Green
Field
Brown
Field
Domain Driven Design
Event Sourcing / CQRS
Migration Patterns
Strangler Fig, CDC…
Build
Design Develop Test Stage Ops
Cloud
• Fault Tolerance
• Reliability
• Scalability
• Traffic Routing
• Security
• Policies
• Observability
• Unit Testing
• Component
• Integration
• Contract
• Package
Repositories
• Mvn, npm,
docker hub
• Infrastructure
• Containers
• Orchestration
• Serverless
• Traffic Routing
• Security (mTLS, JWT)
• Policies (Network / Security
• Observability
Infra Code
• Feature
Code
• Configs
Source Code
Specs

View Slide

Modernization Journey towards Cloud Native Apps
3
Source:
Page 16
US DoD Enterprise
DevSecOps 2.0
Fundamentals

View Slide

Enterprise Architecture
4
Business Architecture:
Describes the organization's
business processes, functions,
and capabilities.
Data Architecture:
data structures, data flows,
and data storage.
Application Architecture:
Describes the organization's software
applications and their
interconnections.
Technology Architecture:
software applications and
their interconnections.
Security Architecture:
security policies, procedures,
and controls.
The benefits of EA include:
1. Improved alignment between business and technology.
2. Increased efficiency and effectiveness of business processes.
3. Reduced complexity and cost of technology infrastructure.
4. Better management of technology risks.
5. Increased agility and ability to respond to changing business
needs.

View Slide

Solutions Architecture
5
High-Level Blueprint of a System that defines
Structure
of its components.
Behaviour Relationship
It describes how the system will be
Designed Developed Deployed
It may include specifications for
Hardware /
Software
Data Security Ops

View Slide

@arafkarsh arafkarsh 6
Solutions
Architecture
Global
Teams
5
Global
Compliance
6
Business
Requirements
End User
Requirements
Infrastructure
Requirements
Budget
Project
Timelines
1. Non-Functional
2. Functional
1
2
3
4
0 Technology
Selection
Solution
Implementation
Solution
Maintenance
7
8
9

View Slide

1 2 3 4 5 6 7 8 9
Let us dive into these sections

View Slide

Non-Functional Requirements
8
Disaster
Recovery
Business
Continuity
Security &
Compliances
Application
Performance
Load &
Scalability
High
Availability
1

View Slide

Functional Requirements – Epics / Stories
9
Theme Epic User Story Sprint
ShopEasy – eCommerce Application
1. Customer Management
2. Search Product
3. Catalogue
4. Shopping Cart
5. Order Processing
6. Payments
2. Search Product
Release 1
1. Global Search
Release 2
1. Search by Brand
2. Search by Price
Range
Release 3
1. Search by Model
2. Search by Rating
Stories
1. Global Search
2. Search by Brand
3. Search by Price
Range
4. Search by Model
5. Search by Rating
1

View Slide

Functional Requirements: User Story
10
Role-Feature-Reason Matrix
Story Card
These three elements
(WHO, WHAT, WHY)
are the building blocks
of User stories.
Element Example
Role WHO: As an e-Commerce Retailer
Feature WHAT:
I want to know who my Gold
Customers are
Reason WHY: So that I sell more
Element Definition
WHO:
Establishes the user or users or another
service.
WHAT:
Describes the Activity – Key Axis of the
Story. What the user does in the story.
WHY: This describes the purpose of the story.
Source: User Story A Pragmatic View, Page 9. Published 0ct 19, 2019
User stories are NOT
1. IEEE 830 Software Specs
2. Use Cases
Use Cases are a combination of User
Story and Acceptance Criteria
3. Scenarios
1

View Slide

Functional Requirement: Acceptance Criteria / BDD
11
Source: https://dannorth.net/introducing-bdd/
Given Customer John Doe exists
When he buys products ABC for $1000 USD
Then He becomes a Gold Customer
BDD Construct
Acceptance Criteria
The definition of Done – As per Scrum
These three elements
(GIVEN WHEN THEN)
are the building blocks
of Acceptance Criteria.
Typical SDLC Life Cycle
Analyst Specifies the Use Case
Developer Developer builds software based on Specific
Usage scenarios with respect to the Use Case
Tester Tester builds test cased based on Use Case
Scenarios and finds issues.
The Gaps identified in this
process is filled up by
linking the User Stories
with Acceptance Criteria.
1
BDD – Behaviour Driven Development

View Slide

End User Requirements
12
Browse Products Add to Shopping Cart Select Shipping Address Confirm Order Make Payment
Catalogue Shopping Cart Order Payment
Customer
View Product
Search
User Journey
Search by Price Image Gallery Update Qty Use UPI
R2
Global Search Product Details Add to Cart
Delete Item
Select Address Confirm Order
Pay Credit Card
Make
Payment
R1
Registration
Minimum Viable Product
Scrum Sprint Cycle
Search by Price Image Gallery Update Qty Use UPI
Kanban Cycle: Each of the Story can be released without waiting for other stories to be completed resulting
in Shorter Releases as all the stories are independent!
Microservices / User Journey /
Story Map & Release Cycles
2

View Slide

Infrastructure: Servers / Virtual Machines / Containers
13
Hardware
Host OS
HYPERVISOR
App 1 App 1 App 1
Guest
OS
BINS
/ LIB
Guest
OS
BINS
/ LIB
Guest
OS
BINS
/ LIB
Type 2 Hypervisor
App 2
App 3
App 2
OS
Hardware
Desktop / Laptop
BINS
/ LIB
App
BINS
/ LIB
App
Container 1 Container 2
Type 1 Hypervisor
Hardware
HYPERVISOR
App 1 App 1 App 1
Guest
OS
BINS
/ LIB
Guest
OS
BINS
/ LIB
Guest
OS
BINS
/ LIB
App 2
App 3
App 2
Guest OS
Hardware
Type 1 Hypervisor
BINS
/ LIB
App
BINS
/ LIB
App
BINS
/ LIB
App
Container 1 Container 2 Container 3
HYPERVISOR
Virtualizes the OS
Create Secure Sandboxes in OS
Virtualizes the Hardware
Creates Virtual Machines
Hardware
OS
BINS / LIB
App
1
App
2
App
3
Server
Data Center
No Virtualization
Cloud Elastic Computing
3

View Slide

Deployment – Updates and rollbacks, Canary Release
D
ReplicaSet – Self Healing, Scalability, Desired State
R
Worker Node 1
Master Node (Control Plane)
Kubernetes
Architecture
14
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.2
10.1.2.34
BE
1.2
10.1.2.35
BE
1.2
10.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 Virtual
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 443
API Server
Pod IP ...34 ...35 ...36
EP
• Declarative Model
• Desired State
Key Aspects
N1
N2
N3
Namespace 1
N1
N2
N3
Namespace 2
• 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
3

View Slide

Infrastructure Specs
15
Applications
Data
Runtime
Middleware
OS
Virtualization
Servers
Storage
Networking
On Premise
Applications
Data
Runtime
Middleware
OS
Virtualization
Servers
Storage
Networking
IaaS
Applications
Data
Runtime
Middleware
OS
Virtualization
Servers
Storage
Networking
SaaS
Customer Managed Cloud Provider Managed
Applications
Data
Runtime
Middleware
OS
Virtualization
Servers
Storage
Networking
PaaS
Applications
Data
Container
K8s
OS
Virtualization
Servers
Storage
Networking
PaaS
Applications
Data
Container
K8s / Knative
OS
Virtualization
Servers
Storage
Networking
FaaS
3

View Slide

Analytics: Apache Flink Architecture
16
3

View Slide

SDN Architecture
Software Defined Network
17
Control
Plane
Management
Plane
Data
Plane
Southbound APIs
Northbound APIs
Security
Controller
QoS
MPLS…
Routing
• OpenFlow
• SNMP
• NetConf
RESTful or Java APIs
Business Applications
Network Elements
Controller
Application
Layer
Control
Layer
Infrastructure
Layer
East – West APIs
Multiple Controllers to avoid
Single Point of Failure
vRouter vSwitch vFirewall SDN Appliance – vEdge.
vController
vManage
3

View Slide

Mana
SD-WAN
Edge
Appliances
Routers
MPLS
DIA
DSL
4G/5G
Branch Remote Data Center Branch Cloud Branch
• Zero Touch Provisioning
• On-Premise or Cloud
• Physical or Virtual
Data Plane
vSmart Controllers
• Routing and Security Policies
• Horizontal Scaling
Control Plane
vManage
• Single Pane of Glass
• RBAC and APIs
• Monitoring / Troubleshooting
Management Plane
Cisco
SD-WAN
(Viptela)
Architecture
vEdge
vEdge
vAnalytics • Carrier Performance
• Bandwidth Forecasting
• Machine Learning
Analytics Plane
SD-WAN
Fabric
vEdge Cloud
Overlay
Network
Source: Cisco SD-WAN
Getting Started Guide
Cloud /
On-Premise
vBond
3

View Slide

Traditional VPN Vs. Zero Trust
19
Enterprise
VPN
User System
VPN
Client
User
App
VPN
Server IAM
WAN
WAN
Split
Tunnel
Optional
Resource = Data, Documents, Apps, Services, Files etc.
Relies on Shared secret
and/or Shared root of Trust
If Split tunneling is enabled
only traffic to Enterprise
will be tunneled.
Zero Trust
User System
Agent
PEP
User
App
PEP
Encrypted Tunnel
Normal Traffic
LAN
IAM
PDP
PEP PEP
• Dynamically adjust the Context
• Multiple Entry Points
• Support Remote and On Premise
Resource
Resource Resource
Resource
3

View Slide

Cisco SD-Access
20
Source: Cisco SDA Enabling Intent based Networking, 2nd Edition – Page 20
o Software- Defined Access is the industry’s first intent- based net working.
o An intent- based network treats the network as a single system that provides
the translation and validation of the business intent (or goals) into the network
and returns actionable insights.
3

View Slide

Infrastructure: Service Mesh: Istio Security
21
Source: https://istio.io/docs/concepts/security/
It provide strong identity, powerful policy, transparent TLS encryption, and authentication,
authorization and audit (AAA) tools to protect your services and data. The goals of Istio
security are
• Security by default: no changes
needed for application code
and infrastructure
• Defense in Depth: integrate
with existing security systems to
provide multiple layers of
Defense
• Zero-trust network: build
security solutions on untrusted
networks
3

View Slide

Infrastructure: Distributed Cloud / Multi Cloud
22
Clouds
Public
Cloud
On Premise
Edge
Network
K8s K8s K8s
Cloud On-Prem Edge
DevOps
o Consistent Environment
o Auto Scale Across Env
DevOps
o Portable Workloads
o AI/ML Across All Environment
DevSecOps
o Governance
o Security Policies
o Network Policies
Private Cloud
Technology Stack
o Containers
o Kubernetes
o Service Mesh
3

View Slide

Product Discovery
23
Increasing
level of
Evidence of
Value
Increasing level of Effort
Developing a product without finding evidence of
its value is a waste of time and resources.
Observe &
Interact Protypes
Explainer
Videos
Landing
Pages
Concierge
MVP
Wizard
of OZ
MVP
Beta
Release
Product
Launch
Design
Thinking Lean Agile
Explore the
Problem
Build the
right things
Build the
things right
If You are NOT doing these
Then this is waste
Single
Customer
Example
Amazon had
Human Book
Reviewers
before they
automated it
Example
Dropbox: Customer
interests went up
from 5K to 70K
4

View Slide

Project Timelines
24
Kanban
Preparation
Requirements
Design
Development
Testing
Release
1 Day – 1 Weeks Cycle
Scrum
4-6 Weeks (Max) Cycle
1 or 2 Weeks Cycle
also allowed
4

View Slide

Project Timelines: Kanban Board
25
Backlog
Done
Work breakdown
Active Done
To Do List
A Backlog item is broken down to
tasks and each Task should NOT
take more than 1-3 days at max.
It’s a good practice to keep all the
tasks of similar size.
Tasks are assigned to respective
team members.
4
Work In Progress
Active Done
Track
Task blocked due to
Dependency.
Once the dependent
Task is ready the
blocked task will be
moved to Active State
Max items in WIP must be
1.4x of total Resources

View Slide

Global Teams: Business Capability Centric Design
26
Business Centric Development
• Focus on Business Capabilities
• The entire team is aligned towards
Business Capability.
• From Specs to Operations – The
team handles the entire spectrum
of Software development.
• Every vertical will have its own
Code Pipeline, Build 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 Team
QA = Quality Assurance
PO = Product Owner
Vertically sliced Product Team
Front-End
Back-End
Database
Business
Capability 1
QA
PO Ops
Front-End
Back-End
Database
Business
Capability 2
QA
PO Ops
Front-End
Back-End
Database
Business
Capability - n
QA
PO Ops
5

View Slide

Management
Pipeline Automation
Architecture
Global Teams: Engineering Pods
27
Build
Design Develop Test Stage Production
Specs
Cloud
Manager
Cloud
Architect
Cloud
Sr. Engineer
Cloud
Engineers
Product
Owner
Elastic Engineering Pod
2-6 Engineers
Customer 1-3 Engineers
5

View Slide

Global Teams: Roles & Responsibilities
28
Category Role Type Responsibilities
1 Customer Product Owner External
• Complete Product Vision
• Specifications
2 Engineering Pod
Cloud Manager /
Analyst
Internal
• Analyst & Specifications (User Stories, Acceptance Criteria)
• Feature Management in Production & Focused on Outcome
• Scrum Master & Team Management
3 Engineering Pod Cloud Architect Internal
• Technology Stack, Mentor / Guiding Team on Technology
• Data Models and Interface Definitions (Hexagonal Architecture)
• Research & Coding (Feature and Infra Code)
4 Engineering Pod Cloud Sr. Engineer Internal
• Mentor / Guiding Team on Technology
• All the Responsibilities of Cloud Engineer also
5 Engineering Pod
Cloud Engineer /
SRE
Internal
• Feature Coding (Open API Specs)
• Feature Test Cases (Unit, Component, Contract, Integration)
• Infra Coding (Infra, Security, Network)
• Build Pipeline Automation
6 Engineering Pod
Cloud Network /
Security Lead
External
Specialist
• Define Network Policies
• Define Security Policies
• Review Infra Code for Network & Security Policies
7 Engineering Pod
Cloud User
Experience Lead
External
Specialist
• Usability Guidelines
• Data Flow Guidelines
5

View Slide

Global Compliance
29
6
• General Data Protection Regulation
• The GDPR aims to give individuals greater control over their personal data, and to ensure that
organizations that collect, use, and store personal data do so in a transparent, secure, and
lawful manner. It applies to all organizations that process personal data of individuals in the
EU and EEA (European Economic Area), regardless of where the organization is based.
• Payment Card Industry – Data Security Standard
• PCI-DSS is a set of 12 requirements that cover various aspects of data security, including
maintaining a secure network, protecting cardholder data, regularly monitoring and testing
security systems, and maintaining an information security policy.
Compliance Examples from Personal Data, Payment Industry & Health
• Health Insurance Portability and Accountability Act
• A US federal law that sets the standards for protecting sensitive patient health information.
• HIPAA compliance applies to all entities that handle protected health information (PHI),
including healthcare providers, insurance companies, business associates, and other entities
that have access to PHI.

View Slide

Technology Selection
30
Microservices with Multiple Technology Stack – Kubernetes (K8s) for Networking
Event Stream / Queues / Pub-Sub / Storage / CDC
Users
API Gateway (K8s/Istio Ingress Controller / Spring Cloud Stack)
Web Services
Business Logic
Database Layer
Cart
Micro
Service
Shopping Cart
SE 8
Load Balancer
Circuit Breaker
Load Balancer (K8s Linux IPVS / Spring)
Circuit Breaker
Web Services
Business Logic
Database Layer
Product
SE 17
Product
Microservice
With 4 node cluster
Load Balancer
Circuit Breaker
Web Services
Business Logic
Database Layer
Customer
Customer
Microservice
With 2 node
cluster
Virtual
Private
Network
Load Balancer
Circuit Breaker
Web Services
Business Logic
Database Layer
Order
Order
Microservice
With 2 node
Cluster
7
Spring Cloud / Config
OR
Kubernetes
API GW /
LB /
Service
Discovery
(DNS)
Service
Mesh
External Load Balancer
Angular / React
Flutter / React Native
HTML 5 / JavaScript
Kotlin / Dart / Swift
FE: UI Layer
FE: Front End
BE: Backend
BE BE BE BE

View Slide

Technology Selection: Front End
31
# Features Native Apps Cross Platform Hybrid Progressive Web Apps
1 Build
Using Android
or iOS SDK
Different Programming Languages
Compiled Native Platform
JS, HTML, CSS
Bundled as a Web App and Runs in a Web
Container inside the Browser (Web View)
A Web App Running with a link to
run as Smart Device App and
works inside a Web Browser
2 Performance High Medium Low Low
3 Code Base
Multiple
Codebase
Single Codebase
Build differently
Single Codebase Single Codebase
4 Cost High Medium Medium Low
5
Hardware
Support
Full
Limited - Additional Coding is
required in some cases Bluetooth,
NFC, AR/VR etc.
Limited - Additional Coding is required in
some cases Bluetooth, NFC, AR/VR etc.
Limited - Additional Coding is
required in some cases Bluetooth,
NFC, AR/VR etc.
6 UX High Medium Medium Medium
7 Languages
Swift for iOS
Java for Android
Dart for Flutter
JS for React Native
C# for Xamarin
JS, HTML, CSS JS, HTML, CSS
8 Tools
iOS SDK
Android SDK
Google: Flutter
Facebook: React Native
Microsoft: Xamarin
Apache Cordova, Ionic
7

View Slide

Technology Selection: Backend
32
7
• MongoDB: Document Database –
Shopping Cart
• Complex Schema (JSON)
• Supports Schema Changes
• Schema Extensions
• Redis DB: Key Value Database –
Customer, Shipping Service
• Supports Schema Changes
• Schema Extensions
• Geo Location based on Address
• Location based Features
(Latitude/Longitude)
• Kafka Distributed Logs
(Scalable & Resilient)
• Pub / Sub (Highly Scalable)
• Streaming Data
• Change Data Capture (CDC)
• Kubernetes – Container Orchestration
• Container Management
• API Gateway & Traffic Routing
• Network Policies
• Docker – Containers
• Microservice Packaging
• Write Once, Deploy Anywhere
• Dev / Staging / Production Parity
• Istio – Service Mesh
• Observability
• Advanced Traffic Routing
• Security: Defense in Depth
• Policies: Security & Network

View Slide

Analytics: AWS Kinesis – Architecture (Flink)
33
AWS Cloud
Kinesis Data Analytics
Elastic Kubernetes Service
Job Manager
Task Manager
Task Manager Task Manager
S3 Bucket
Auto Scaling
Zookeeper
Cloud Watch
Cloud Watch Logs
Flink Web UI
7

View Slide

What is Apache Flink
34
Stateful Computations over Data Streams
Batch
Processing
Process Static &
historic Data
Data Stream
Processing
Realtime Results
from Data Streams
Event Driven
Applications
Data Driven Actions
and Services
Instead of Spark + Hadoop
7

View Slide

Use Case: Periodic ETL vs Streaming CTL
35
Traditional
Periodic ETL
• External Tool
Periodically
triggers ETL
Batch Job
Batch
Processing
Process Static &
historic Data
Data Stream
Processing
Realtime Results
from Data Streams
Continuous
Streaming Data
Pipeline
• Ingestion with
Low Latency
• No Artificial
Boundaries
Streaming
App
Ingest Append
Real Time Events
Event Logs
Batch
Process
Module
Read
Write
Transactional Data
Extract, Transform, Load Capture, Transform, Load
State
Source: GoTo: Intro to Stateful Stream Processing – Robert Metzger
7

View Slide

Use Case: Data Analytics
36
• Great for Ad-Hoc Queries
• Queries changes faster than data
Batch
Analytics
Stream
Analytics
Ingest
K-V Data Store
Real Time Events
Batch
Analytics
Read Write
Recorded Events
• High Performance Low Latency Result
• Data Changes faster than Queries
Analytics
App
State
State
Update
7

View Slide

Use Case: Event Driven Application
37
• Compute & Data Tier Architecture
• React to Process Events
• State is stored in (Remote) Database
Traditional
Application
Design
Event Driven
Application
• High Performance Low Latency Result
• Data Changes faster than Queries
Application
Read Write
Events
Trigger
Action
Ingest
Real Time Events
Application
State
Append
Periodically write
asynchronous checkpoints
in Remote Database
Event Logs
Event Logs
Trigger
Action
7

View Slide

Specs, Architecture, Design, Packaging
38
EPIC
Bounded
Context
Micro
Service
Pod
User Stories
MVP
Domain Driven
Design
Service
Architecture
Container
Orchestration
Design Thinking
Lean Startup
Agile (Scrum/Kanban)
CI/CD/CD,
DevSecOps
Specs Deploy
Design / Develop
Code
Process
Test Automation Code, Continuous Integration / Delivery / Deployment, Infra Code
8

View Slide

12 Factor App Methodology
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 Processes
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 / Staging /
Production Parity
Keep Development, Staging and Production as similar as possible
Checkout the Shift – Left in DevOps (Slide No. 48., Section 9)
11 Logs Treat logs as Event Streams
12 Admin Process
Run Admin Tasks as one of Process (Eg. DB Migration, Software
upgrades, etc..)
Factors Description
1 Codebase One Code base tracked in revision control
2 Dependencies Explicitly declare dependencies
3 Configuration Configuration driven Apps
Source: https://12factor.net/
8

View Slide

Additional Factors Description
13 API
API Driven
Contract Driven Development
14 Telemetry
Application Monitoring, Domain Specific
Telemetry, Health & System Logs
15 Security
Authentication & Authorization
Implement RBAC (Role Based Access Control)
Auth and Authorization Tokens
15 Factor App Methodology
8

View Slide

API Architecture Maturity Levels
41
Source: https://www.apiscene.io/lifecycle/7-layers-of-api-architecture-maturity/
• REST & gRPC – API Communication in Microservices: https://www.apiscene.io/lifecycle/rest-grpc-api-communication-in-microservices/
• A Postman API Governance Collection: https://www.apiscene.io/lifecycle/a-postman-api-governance-collection/
• Impact of Distributed Architecture to API Lifecycle: https://www.apiscene.io/lifecycle/what-is-the-impact-of-distributed-architecture-to-api-lifecycle/
•
8

View Slide

Composable Enterprise Architecture
42
Source: Gartner: Future of Applications: Delivering the Composable Enterprise | Why does it matter?
On Demand
Scalability
Service & Apps
Integrated
with Clients &
Devices
Automated
On Demand
Services
Self Service
Options for
App & Data
MASA
Mesh App & Service
Architecture
Enterprise Data
Available, Accessible, &
Integrated into Data Flow
Delivers > Packaged Business Capabilities
8

View Slide

Architecture Styles, Patterns & Design Patterns
43
• Component-based
• Client-server
• Event-driven
• Layered Architecture
• Monolithic application
• Plug-ins
• Publish-subscribe
• Service Based
• Service-Oriented
• Microservices
Architecture Style:
1. How to Organize the Code,
2. Creating high-level modules
& layers and how they
interact each other.
Architecture Patterns:
A Recurring solution to a
recurring problem.
Providing the Solution to
an Architecture Style. Ex.
How a request is processed
from the outer layer to
inner layer.
• Three Tier
• Micro Kernel
• Model View Controller
• Event Sourcing and CQRS
• Domain Driven Design
Design Patterns:
The scope of the Design
Patterns is much
narrower compared to an
Architecture Pattern.
It focuses on instantiating
an object, and its
behaviour of the object.
• Adapter
• Builder / Factory
• Saga
• Repository
• Aggregate Root
Wider Scope Narrow Scope
Critical Architectural Styles & Patterns
8

View Slide

Event Driven & Pub Sub Architectures
44
Check Out
Cart
4. Data Durability (Replication)
5. Ordering Guarantee (Per
Partition)
Use Partition Key
Kafka Producer API
Kafka
Consumer API
Order Topic (Total Partitions 6)
Kafka Storage
Replicated Logs
Kafka Cluster
5 6 7 8
7 8
What will happen to
Inventory Instance 7 and 8?
As there are only 6 Partitions
Kafka can serve ONLY 6
consumers within a partition
1 2 3 4
1 2 3 4
3 4
Service
Instances
2 5
1
All the above Consumers will get same
orders available in the Order Topic
Broadcast Orders to following
Consumers
Order Consumer Group Inv Consumer Group Multiple Subscriber
1. Highly Scalable
2. Multi Subscriber
3. Loosely Coupled
Systems
8

View Slide

Microservices Characteristics
45
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
via IaC
Design for
Failure
Evolutionary
Design
Source: US DoD DevSecOps Fundamentals Playbook. Page 6
8

View Slide

Microservices Architecture
46
/ui
/productms
/auth
/order
Gateway
Virtual Service
Deployment / Replica / Pod Nodes
Istio Sidecar - Envoy
Load Balancer
Kubernetes
Objects
Istio Objects
Firewall
P M C
Istio Control Plane
UI Pod N5
v2
Canary
v2
User X = Canary
Others = Stable
v1 UI Pod
UI Pod
UI Pod
UI
Service
N1
N2
N2
Destination
Rule
Stable / v1
EndPoints
Internal
Load Balancers
Source: https://github.com/meta-magic/kubernetes_workshop
Users
Product Pod
Product Pod
Product Pod
Product
Service
MySQL
Pod
N4
N3
Destination
Rule
EndPoints
Review Pod
Review Pod
Review Pod
Review
Service
N1
N4
N3
Service Call
Kube DNS
EndPoints
8

View Slide

Domain Driven Design – Tactical Design
47
Source: Domain-Driven Design Reference by Eric Evans
8

View Slide

Monolithic Data Models across bounded contexts.
Source: Patterns, Principles and Practices of DDD – Page 124
This model shows multiple
responsibilities of the
shared Model – Product.
This is a classic example of
Big Ball of Mud.
48
8

View Slide

Product Model in Different Bounded Context
49
Catalogue
Product
• Product UUID
• Name
• Description
• SKU
• Product Price
• Currency
• Product Images
• Brand
• Manufacturer
Cart
Product
• Product UUID
• Name
• Value
• Quantity
o Product Model has different attributes in different contexts. So, it avoids storing
all the Product info in one place and then sharing that across multiple Bounded
Contexts (Microservices).
o If you want to change Product details related to Package, then only Order
Bounded Context (Microservice) needs to be updated.
Order
Product
• Product UUID
• Name
• Value
• Quantity
• Shipping Type
• Package Type
8

View Slide

Process
• Define your Business Processes. Eg. Various aspects of Order
Processing in an E-Commerce Site, Movie Ticket Booking,
Patient visit in Hospital.
1
Commands • Define the Commands (End-User interaction with your App) to
execute the Process. Eg. Add Item to Cart is a Command.
2
Event Sourced
Aggregate
• Current state of the Aggregate is always derived from the Event
Store. Eg. Shopping Cart, Order etc. This will be part of the Rich
Domain Model (Bounded Context) of the Micro Service.
4
Projections
• Projections focuses on the View perspective of the Application.
As the Read & Write are different Models, you can have
different Projections based on your View perspective.
5
Write
Data
Read
Data
Events • Commands generates the Events to be stored in Event Store.
Eg. Item Added Event (in the Shopping Cart).
3
Event Storming – Concept
50
8

View Slide

Event Sourcing Intro
51
Standard CRUD Operations – Customer Profile – Aggregate Root
Profile
Address
Title
Profile Created
Profile
Address
New Title
Title Updated
Profile
New
Address
New Title
New Address added
Derived
Profile
Address
Notes
Notes Removed
Time T1 T2 T4
T3
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
Profile
Address
New Title
Current State of the
Customer Profile
4
Snapshot
Event store
Single Source of Truth
Greg
Young
8

View Slide

Event Sourcing: Case Study: Shopping Site – Event Sourcing / CQRS
52
Catalogue Shopping Cart Order Payment
• Search Products
• Add Products
• Update Products
Commands
• Add to Cart
• Remove Item
• Update Quantity
Customer
• Select Address
• Select Delivery Mode
• Process Order
Events
• Product Added
• Product Updated
• Product Discontinued
• Item Added
• Item Removed /
Discontinued
• Item Updated
• Order Initiated
• Address Selected
• Delivery Mode Selected
• Order Created
• Confirm Order for
Payment
• Proceed for Payment
• Cancel Order
• Payment Initiated
• Order Cancelled
• Order Confirmed
• OTP Send
• Payment Approved
• Payment Declined
Microservices
• Customer
• Shopping Cart
• Order
Customer Journey thru Shopping Process
2
Processes 1
Customers will browse through the Product catalogue to find the products, their ratings and reviews. Once the product is
narrowed down, the customer will add the product to the shopping cart. Once the customer is ready for the purchase, he/she
will start the order processing by selecting the Delivery address, delivery method, and payment option. Once the payment is
made, the customer will get the order tracking details.
ES Aggregate 4
Core Domain
Sub Domain Sub Domain Sub Domain Generic Domain
3
8

View Slide

Event Sourcing: Case Study: Patient Diagnosis and Treatment
53
Payment
• Register
Patient
• Search Doctor
Commands
• Add Patient
Info
• Add Details
• Add BP
• Add Diagnosis
• Add
Prescription
Events
• Doctor
Scheduled
• Patient Added
• Patient Info
Added
• Details Added
• BP Added
• Diagnosis
Added
• Prescription
Added
• Add
Medicine
• Add Bill
• Medicine
Added
• Bill Prepared
• Payment
Approved
• Payment Declined
• Cash Paid
The patient registers and makes an appointment with the doctor. Patient details and history is recorded. The
doctor makes the diagnosis and creates the prescription. The patient buys the medicine from the Pharmacy.
A ward appointment is scheduled and disclosed to the ward if a patient needs to be admitted. Once the
treatment is over, the patient is discharged from the Hospital.
Microservices
• Diagnosis
• Prescription
• Hospital Bill
• Discharge Summary
Patient Journey thru Treatment Process
Registration
• Add Doctor
• Add
Appointment
• Add Patient File
• Doctor Added
• Appointment
Added
• Patient File Added
ES Aggregate
2 4
Processes 1
Doctors Diagnosis Pharmacy
Ward
Patient
• Add Checkup
• Add Treatment
• Add Food
• Add Discharge
• Checkup Added
• Treatment
Added
• Food Added
• Discharge Added
Core Domain Sub Domain Sub Domain
Sub Domain
Sub Domain Generic Domain
Sub Domain
3
8

View Slide

Design Pattern
1 Decomposition Identify the Modules and Boundaries
2 Strangler Fig Product Service (Query Only with Apache Solr)
3 Branch By Abstraction Shopping Cart as Service using Monolithic DB
4 Decorating Collaborator New Shipping Service with Database
5 Change Data Capture Enhance Loyalty Module as a new Service
6 Aggregate API Expose Customer API on Monolith
7 Split Table
Product Split into 2 Services as Product Management
and Warehouse
8 Change Data Ownership Order Service using Monolithic DB
9 Move Foreign Key to Code
Foreign Key in Order (item) with Product Table moved to
Order Service Code
10 Strangler Fig Move out Customer Module and decommission the Monolith
Legacy Migration Design Patterns
54
• Prioritize the Modules / Services For Implementation & Deployment
Setup
Transition Plan: Example Shopping Portal
UI Layer
WS
BL
DL
Database
Cart
Order
Customer
Product
Monolith
8

View Slide

Migration Design Patterns: Strangler Fig Pattern
55
API Gateway / Proxy
Web Services
Business Logic
Database Layer
Product
Micro
Service
Product
SE 8
UI Layer
WS
BL
DL
Database
Cart
Order
Customer
Product
UI Layer
WS
BL
DL
Database
Cart
Order
Customer
Product
UI Layer
WS
BL
DL
Database
Cart
Order
Customer
Product
Web Services
Business Logic
Database Layer
Product
Micro
Service
Product
SE 8
API Gateway / Proxy
Step 1
Identity the Module
Step 2
Move the Service
Step 3
Redirect the Calls to New Service
Source: Monolith to Microservices By Sam Newman
1. New Service
(Code)
2. Better Search
Capabilities
Product DB will be used
by other modules in
Monolithic App
Monolith Monolith Monolith
Only used for Search
Capabilities and
Scalability.
8

View Slide

Microservices Testing Strategies
56
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%
Ubiquitous
Language
Domain
Expert
Analyst Developers
QA
Design
Docs
Test Cases
Code
Architect
8

View Slide

Microservices Testing Strategy
57
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
8

View Slide

Microservices Testing Scenarios / Tools
58
Testing 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
Integration Contract Testing Scope
Test Double
Montebank
Cart
Component Testing
Unit
Testing
Integration Testing Scope
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
U
8

View Slide

Chaos Engineering – Load / Stress / Performance
59
Chaos Monkey Randomly disables production instances
Chaos Kong
Similar to Chaos Monkey, simulates an outage of an
entire Amazon availability zone.
Doctor Monkey
Checks CPU load, Memory usage and removes it
from network if the health is bad.
Janitor Monkey Search for unused resources and disposes them.
Compliance Monkey
Finds instances that don’t adhere to best-practices
and shuts them down.
Latency Monkey Induces Artificial delays
Security Monkey
Is an extension of Compliance Monkey. Find security
vulnerabilities and terminates offending instances.
Source: https://github.com/Netflix/SimianArmy/wiki
Source: http://principlesofchaos.org/
8

View Slide

SANS Cloud Security Architecture Principles
60
Source: RSA Conference 2019 – A Cloud Security Architecture workshop. Dave Shackleford Sr. Instructor SANS Institute
Think
Components
Design for
Failure
Always
Think of
Feedback Loops
Use Different
Storages
Options
Built-In
Security
at every Layer
CENTRALIZATION
Focus on
Centralization
Standards & Automation
Design for
Elasticity
8

View Slide

SDLC: Agile & DevOps
61
Build
Design Develop Test Deploy Ops
Specs
Agile
DevOps
Go Live Support
Specs / Design / Development
CI/CD and Tests Automation
Operations
9

View Slide

Production Environment
Continuous Monitoring
Fully
Automated
Continuous Deployment
Shift Left – Operational Concerns
62
• Operations Concerns move earlier in software delivery life cycle, towards development.
• The Goal is to enable Developers and QC Team to Develop and Test the software that
behave like Production System in fully automated way.
Development Environment
Build
Build
Build
Test Environment
Continuous Integration
Unit
Testing
Component
Testing
Contract
Testing
Integration
Testing
Continuous Testing
Shift Left moves operations earlier in development cycle.
Stage Environment
Acceptance Testing
Pull Request / Merge
Continuous Delivery
GitOps – CD/CD
9

View Slide

DevOps
63
Source: https://www.atlassian.com/devops/what-is-devops
9

View Slide

5 DevOps Principles – CALMS Framework
64
Source: https://www.atlassian.com/devops/frameworks/calms-framework
DevOps isn’t a process,
or a different approach
to development.
It’s a culture change.
DevOps culture is
collaboration.
Build, Test, Deploy, and Provisioning automation
are typical starting points for teams.
Another major contribution of DevOps is
“configuration as code.” Developers strive to
create modular, composable applications
because they are more reliable and maintainable.
CULTURE AUTOMATION
LEAN MEASUREMENT SHARING
Continuous
Improvement
with Canary
Releases and A/B
Testing
Continuous
Improvement
requires Data to
measure the
changes
Sharing responsibility,
success, failure goes a
long way toward
bridging that divide
between Dev and Ops.
You built it, You run it.
9

View Slide

Implementing CALMS – DevOps Principles
65
Capability Centric Design
Reduce
Organization Silos
CULTURE
Leverage
Tooling &
Automation
Tests, CI/CD Pipeline & Container Orchestration
AUTOMATION
Implement
Gradual
Change
& Agile: Kanban
LEAN
Measure
Everything
Service Mesh: Observability
MEASUREMENT
Accept
Failure as
Normal
Design for Failure
SHARING
Source: IBM DevOps Vs. SRE https://www.youtube.com/watch?v=KCzNd3StIoU Google: https://www.youtube.com/watch?v=uTEL8Ff1Zvk
9

View Slide

class SRE implements DevOps – CALMS
66
Capability Centric Design
Reduce
Organization Silos
CULTURE
Leverage
Tooling &
Automation
Tests, CI/CD Pipeline & Container Orchestration
AUTOMATION
Implement
Gradual
Change
& Agile: Kanban
LEAN
Measure
Everything
Service Mesh: Observability
MEASUREMENT
Accept
Failure as
Normal
Design for Failure
SHARING
ü Share Ownership
ü SLOs & Blameless PM
ü Canary Deployment, A/B Testing
ü Automate this years Job
ü Measure toil & reliability
9
SRE – Site Reliability Engineering

View Slide

DevSecOps
67
Recommended by US DoD (Dept of Defense) DevSecOps Best Practices
Source:
Page 17
US DoD
Enterprise
DevSecOps
Fundamentals
9

View Slide

6
DevSecOps Playbook
68
1 Adopt a DevSecOps Culture
2 Adopt Infrastructure as Code
3 Adopt Containerized
Microservices
4 Adopt a Capability Model, not a
Maturity Model
5 Drive Continuous Improvement
through Key Capabilities
Establish a Software Factory
7 Define a meaningful
DevSecOps pipeline
8 Adapt an Agile Acquisition
Policy for Software
9 Tirelessly Pursue Cyber
Resilience
10 Shift Left: Operational Test &
Eval
Source: US DoD DevSecOps Fundamentals Playbook
9

View Slide

DREAM | AUTOMATE | EMPOWER
Araf Karsh Hamid :
India: +91.999.545.8627
https://speakerdeck.com/arafkarsh
http://www.slideshare.net/arafkarsh
https://www.linkedin.com/in/arafkarsh/
https://www.youtube.com/user/arafkarsh/playlists
http://www.arafkarsh.com/
@arafkarsh
arafkarsh

View Slide

Solution Architecture

Solution Architecture

Araf Karsh Hamid

More Decks by Araf Karsh Hamid

Other Decks in Technology

Featured

Transcript