This document discusses best practices for building cloud native applications using microservices and DevOps principles. It covers architectural considerations like service boundaries and design patterns. It also discusses technologies for service integration like APIs, communication patterns, and service discovery. Additional sections provide guidance on testing, deployment, security, scaling, monitoring, and reference Netflix's cloud architecture.
Enhancing Worker Digital Experience: A Hands-on Workshop for Partners
Cloud Microservices DevOps Architecture
1. Cloud / Microservices / DevOps
Architecture Considerations
o Strategic Goals and Vision
o Architectural Principles to guide development
o Defining boundaries of modules / microservices
Declaring a bounded context
Chattiness / coupling
Expressiveness of model
Feature roadmap
o Design and Delivery Practices
Required Standards
Monitoring
Interfaces
Architectural Safety
Reusable Service Archetypes / Code Libraries
o Iteration – redoing code to become more elegant, vs. striving for a perfect
solution from the start. Not to be confused with slicing, as in Agile.
Cloud
o Programmable infrastructure that you can introspect and make strong
assertions about
o On-demand capacity
o Built on commodity hardware/software
o Competition between cloud platforms is driving down cost
Penalty of lock-in is outweighed by cost reduction curve
Service Design Best Practices
o Loose Coupling
o High Cohesion
o Bounded Contexts
o Single-Responsibility Principle
o Stateless to support horizontal scalability
o Hide implementation details
Service Integration
o Technology-agnostic APIs
JSON / XML
Protocol Buffers
REST and HATEOAS
Spring abstractions
o Request/Response vs. Asynchronous Event-Based Communication
Choreographed architecture preferred over Orchestration
Inform each part of the system through message bus
o Versioning
Semantic Versioning (MAJOR, MINOR, PATCH)
Version in endpoint URL
Version in request header
o API Gateways
Portability layer for forwards/backwards compatibility
2. o Strangler Pattern
Abstraction layer on top of legacy systems
o Discovery and Coordination
Netflix Eureka
Optimized for AWS
Placed behind AWS ELB
Mid-tier round-robin load balancer
Optional Sidecar for non-JVM apps
Consul
DNS
ZooKeeper
Metadata in AWS
Testing
o Unit Tests / TDD
Spock
o Service Tests – Mock/Stub downstream collaborators
o Consumer-Driven Tests
o End-to-End Tests
o Testing in Production
Blue/Green Deployment
Canary Releases
Rolling Upgrades
A/B Testing
Indeed Proctor
Feature Toggles
o MTBF / MTTR
Deployment
o Continuous Integration
o Build Pipeline
o Images as Artifacts / Immutable Servers
Docker containers
Spin up new instance instead of modifying existing.
“Cattle” vs. “Pet” servers
Ephemeral infrastructure
o Environment Definitions
o Rollout Plan
o Rollback Plan
Logging of audit metadata to reverse actions
o AWS CloudFormation
Security
o SSO Gateway / Identity Provider
o Service-to-Service Auth.
oAuth 2.0 / JSON Web Token (JWT)
Network Segmentation
HTTP(S) Basic
X.509
API Keys
3. o Multi-tenancy
o Concerns
Man-in-the-Middle attack
Confused Deputy Problem
Scaling
o Circuit Breakers
o Bulkheads
o Idempotency
o Immutable Data Structures
o Load Balancing
o Worker-based systems
o Data Access Strategies
Scaling for reads
Scaling for writes
Caching
CQRS / Event Sourcing
Explicitly modeling events and state change
Derive current state from series of events
Actor model
o CAP Theorem
Sacrificing Consistency
Sacrificing Availability
Sacrificing Partition Tolerance
Monitoring
o Failure Detection
o Performance Degradation Detection
Latency
Throughput
Utilization
o Capacity Planning
o User Interaction
o Intrusion Detection
o Process Mining
o Tools
Icinga / Nagios
Graphite / Grafana
Logstash
Splunk / ElasticSearch
AWS CloudWatch
Netflix Architecture
o Disk inside EC2 instances
o Triple-replicated Cassandra
o Ribbon/Karyon
o Eureka instance in each availability zone
ZooKeeper “too consistent”
API versioning
o Hystrix circuit breakers
4. o Customer-facing apps optimized for ‘AP’
o Business apps optimized for ‘CA’
o Security Monkey
NoSQL - “Not only SQL”
o Cassandra
o MongoDB
o Couchbase
o Neo4j