Slides for the session "A Primer On Cloud Native Distributed Systems Architectures" at CodeUp Kochi- Cloud Native Application Architecture

1. A Primer On Cloud-Native
Distributed Systems Architectures
Shiju Varghese
https://medium.com/@shijuvar
CodeUp Kochi- Cloud Native Application Architecture
21st April, 2018

2. About Me
• Consulting Solutions Architect: Go and Distributed Systems
• Early adopter of Go
• Speaker at GopherCon India, Great Indian Developer Summit
• Published Author
• Honoured with Microsoft MVP Award Seven Times
Blog: https://medium.com/@shijuvar | Github: https://github.com/shijuvar | LinkedIn: https://in.linkedin.com/in/shijuv

3. Author

4. Agenda
• Introduction to Cloud-Native
• Overview on Cloud-Native Distributed Systems Architectures
• Overview on Microservices based Distributed Systems

5. What is Cloud-Native?
• Containerized. Each part (applications, processes, etc) is packaged in
its own container. This facilitates reproducibility, transparency, and
resource isolation.
• Dynamically orchestrated. Containers are actively scheduled and
managed to optimize resource utilization.
• Microservices oriented. Applications are segmented into
microservices. This significantly increases the overall agility and
maintainability of applications.

6. Attributes of Cloud Native Applications
• Packages as light weight containers
• Isolated from hardware and operating system dependencies
• Leverage best of the breed languages and frameworks
• Designed as loosely coupled services
• Deployed on self-service, elastic and cloud infrastructure
• APIs are backbone for interaction and collaboration
• Clean separation of stateless and stateful services
• Managed through agile DevOps processes
• Take advantage of automation capabilities

7. • NATS for Messaging
• containerd for Container Runtime
• rkt for Container Runtime
• Kubernetes for Container Orchestration
• Linkerd for Service Mesh
• gRPC for Remote Procedure Call
• Container Network Interface (CNI) for Container Networking
• CoreDNS for Service Discovery
• Prometheus for Monitoring
• OpenTracing for Tracing
• Fluentd for Logging

8. Eric Brewer’s CAP Theorem
• Consistency: Every read receives the most recent write or an error
• Availability: Every request receives a (non-error) response – without
guarantee that it contains the most recent write
• Partition tolerance: The system continues to operate despite an
arbitrary number of messages being dropped (or delayed) by the
network between nodes
A system can only have two of the following three properties:

9. Microservices Architecture
• Composed of a suite of small services
• Each service runs in its own process
• Greater flexibility for scalability

10. Monolithic Architecture
f
eCom Store
Catalog Management
Customer Accounts
Orders Management
Payment
SQL Server
(Monolithic
Database)
Mobile
Client
Browser
Client
Monolithic Commerce App

11. Microservices Architecture
Product
Catalog
Service
Customer
Service
Order
Service
Payment
Service
Product
Catalog
Database
Customer
Database
Order
Database
Payment
Database
API
Gateway
Browser
Client
Mobile
Client
REST
REST

13. Microservices is an architectural style for building highly
scalable applications, in which an application
decomposes into a set of services as functional
components.
Microservices Architecture is all about functional
decomposition.

14. Autonomous Services around Bounded Context
• Software broken up into functional components.
• Componentization via Services in which each service is packaged as one
unit of execution.
• Independent, autonomous process with no dependency on other
Microservices.
• Services are organized around business capability.
• Decentralization of Data Management.
• Independently replaceable and upgradeable.

15. Product
Catalog
Service
Customer
Service
Order
Service
Payment
Service
Product
Catalog
Database
Customer
Database
Order
Database
Payment
Database
• Single-purpose, domain model
based bounded context
• Database per service
• Isolated persistence

16. Challenges
• Decentralised data that is scattered amongst many databases
• How do you make inter-process communication?
• Can we use RESTful APIs
• What are the alternatives if RESTful APIs are not scalable
• How do you manage data persistence that spans in multiple multiples databases?
• How do you query data that spans in multiple multiples databases?
• How do you manage data consistency?

17. gRPC for inter-process communication in Cloud-
Native architectures

18. gRPC
• High performance, open-source RPC framework
• Open source version of Google’s internal framework Stubby
• Uses Protocol Buffers as the IDL
• HTTP/2 for transport
• Bi-Directional streaming
• RPC is Efficient, Domain-Specific and Strongly-Typed
• Works across languages and platforms

19. Types of RPC Methods
• Simple RPC
• Server-side streaming RPC
• Client-side streaming RPC
• Bi-directional streaming RPC

20. gRPC Workflow
ProtoBuf
Definitions
protoc
Compiler
Go
Ruby
Java
gRPC
Server
gRPC Client
Define1 Compile2
Implement3
Generate Code
protoc --go_out=plugins=grpc

21. Event-Driven Architectures for Cloud-Native
Distributed Systems

22. Event-Driven Approach
Customer
Service
Order
Service
Order
Database
Publish Events
Message
Broker
Publish Events
Subscribe Events
Subscribe Events
Event: OrderCreated

23. Events As Facts
• A fact represents something that has happened in the past.
• Facts are immutable - they can’t be changed or be retracted

24. Event-Driven Architectures
• Application Events
• Transaction log tailing
• Event Sourcing

25. Event Sourcing

26. • An event-centric pattern for implementing business logic and
persisting aggregates
• Events represent state changes of aggregates; Publishes domain
events on mutations of aggregates
• Event log for the aggregates
• Preserves the history of aggregates
• Avoids the O/R impedance mismatch problem

27. Aggregate ID Aggregate Type Event ID Event Type Event Date
301 Order 1001 OrderCreated …
301 Order 1002 OrderApproved …
301 Order 1003 OrderShipped …
301 Order 1004 OrderDelivered …
Event Table of Event-Sourcing

28. CQRS
Image Courtesy: http://martinfowler.com

29. Event Sourcing defines Microservices
architecture as a web of event-driven aggregates

30. Query Model Sync with NATS QueueGroup
Demo
Client App
Order Service
REST API
Event Store
gRPC Server
NATS ProducerProtoBuf
Command -CockroachDB
Cluster
Node 1 Node 2 Node N
Events
NATS Streaming
Server
Event Logs
Restaurant
Service
NATS Consumer
Query Store -1
NATS Consumer
Query Store -2
NATS Consumer
Query -CockroachDB
Cluster
Node 1 Node 2 Node N
Technology:
• Go
• gRPC with ProtoBuf
• NATS Streaming
• CockroachDB
Source:https://github.com/shijuvar/gokit/tree/master/examples/nats-streaming
Example Events:
• OrderCreated
• OrderApproved
• OrderRejected
• OrderShipped
• OrderDelivered

31. Distributed Saga
Distributed Saga
Local Transaction 1
Aggregate A
Microservice 1
Command
Local Transaction 2
Aggregate B
Microservice 2
Command
Local Transaction 3
Aggregate C
Microservice 3
Command
Saga Orchestrator orchestrates the transactions spans in multiple
services on aggregates that ensures the data consistency

32. Thanks
Shiju Varghese
gophermonk@gmail.com
https://medium.com/@shijuvar
https://github.com/shijuvar
https://linkedin.com/in/shijuvar
Go Programming Workshops: https://github.com/shijuvar/gokit/tree/master/training