Guest Lecture @University of Colombo - School of Computing on 26/01/2021

1. COPYRIGHT – 1 BILLION TECH | CONFIDENTIAL
ENTERPRISEINTEGRATIONINCLOUD
NATIVE MICROSERVICESARCHITECTURES
GUEST
LECTURE
27TH
JAN 2021

2. ABOUT ME
 Vice President – Technology, One Billion Tech
 Heads Global Technology Office (GTO) at One Billion Tech
 In the IT industry for 25+ years
 Former Head Of Technology, ICTA Sri Lanka
 LinkedIn: https:/
/www.linkedin.com/in/crishantha/
 Blog: https:/
/medium.com/@crishantha
 Twitter: @crishantha

4. AGENDA
 Cloud Native Architectures
 Enterprise Integration
 Microservices Architectures
 Building applications in Cloud Native Microservices environments

5. WHYTHIS TOPIC?
 Today’s applications are deployed to
everything from mobile devices to cloud
based clusters running thousands of
multi-core processes
 Users expect milliseconds response
times and close to 100% up-time.
 Traditional architectures simply won’t
cut anymore.
 Microservices + Cloud Native is the
new norm

6. CLOUD NATIVE ARCHITECTURES

7. CLOUD NATIVE ARCHITECTURES
 “Cloud Native” is an approach of building and running applications that exploits the
advantages of Cloud Computing delivery model.
 Main Requirements for a Cloud Native Architecture:
●
Should run smoothly within cloud native run-time environments (Docker / Kubernetes)
●
Low startup time
●
Low resource consumption
●
Resiliency
●
The ability to port to a different cloud offering with minimal changes

9. WHY CONTAINER BASED ARCHITECTURES?

10. WHY CONTAINER BASED ARCHITECTURES?

11. CONTAINER ORCHESTRATION - KUBERNETES
 The most popular container orchestration
framework is Kubernetes
 Kubenetes cluster consists of multiple
“nodes”
 There are two type of “nodes”. (Master Node
and Worker Nodes)
 Worker nodes consists of one or more
“pods”
 “Pods” are the smallest and the most basic
building block of Kubernetes cluster
 One “pod” can have one or more containers
running within them.

12. ENTERPRISE INTEGRATION

13. Source: https://towardsdatascience.com
EVOLUTION OF ENTERPRISE SYSTEMS

14. Reference: Microservices: The resurgence of SOA principles and an alternative to the monolith (PWC)
EVOLUTION OF ENTERPRISE SYSTEMS

15. MONOLITHIC ARCHITECTURE
 Monolithic solutions are built,
tested and deployed as one large
body of code, typically across a
set of servers or virtual machine
instances.

16. SERVICE ORIENTED ARCHITECTURE
Source: ICTA Sri Lanka

17. SERVICE ORIENTED ARCHITECTURE
Source: Open Source SOA

18. ENTERPRISE INTEGRATION PATTERNS

19. MICROSERVICES ARCHITECTURES

20. MICROSERVICES ARCHITECTURE
Reference: Getting Started with Microservices – By Arun Gupta
 “Microservices are self-
contained units of
functionality with loosely
coupled dependencies on
other services and are
designed, developed, tested
and released independently”

21.  ISOLATION
●
The most important feature
●
Involves independent and complete control of the resource (Bounded Context)
 AUTONOMY
●
Takes the full responsibility of the service
●
The service can be changed with no or minimal impact to other services
●
The maximum autonomy happens with event based inter service communications
 SRP – Single Responsibility Principle
●
The scope of the service responsibility has only one reason to change
●
“micro” – The scope of responsibility
KEY FEATURES OF MICROSERVICES

22.  STATE
●
Microservices need to own their state
exclusively
●
The data is strongly consistent within the
microservice
●
The data is eventually consistent between
microservices
 MOBILITY
●
The possibility of moving services around at
runtime while they are being used (using
container architectures)
KEY FEATURES OF MICROSERVICES

23. DUMB PIPES, SMART ENDPOINTS
 MSA has a lightweight message bus or a gateway with minimal routing capabilities and acting
as a “dumb pipe” and all the business logic resides within Endpoints and they have become
“Smart Endpoints”

24. SERVICE ORCHESTRATION
Orchestration at Microservice Level (RECOMMENDED)

25. SEPARATE DATA STORES

26. HORIZONTAL SCALING

27. HORIZONTAL SCALING

28. SERVICE COMPOSITIONS – SYNCHRONOUS (ACTIVE)

29. SERVICE COMPOSITIONS – ASYNCHRONOUS (REACTIVE)

30. EVENT SOURCING IN REACTIVE
 Persists each state changing events of a service
as a sequence of events. All such events are
stored in an event bus and consumers can
derive a state of a particular service event by
processing the event sourcing log

31. TRANSACTIONS IN MICROSERVICES
 MSA encourages “transaction-less” coordination between microservices
 Transactions should be applicable for only within the scope of the microservice
 Handling transactions orchestrated with multiple microservices can be challenging
 Example: Credit card bill payment
●
Step 1: Debit Savings bank
●
Step 2: Credit Credit Card Account

32. SAGA PATTERN
Source: Microservices for the Enterprise, Apress (2018)
 Saga Pattern Is a pattern for managing failures, where each action has a compensating action
for rollback.

33. POLYGLOT PERSISTENCE
 With the decentralized data management with Saga, you can take advantage of having its own
persistence mechanism for each microservice
 This is one advantage of distributed transaction handling (Saga) over Two phased commit
(2PC) or any other asynchronous transaction handling
 Polyglot persistence means each microservice having its own data store / database

34. MICROSERVICE INVOCATION STYLES
 There are multiple invocation styles
●
Point to Point Style
●
API Gateway Style
●
Message Broker Style

35. POINTTO POINT INVOCATION
 Works only for simple microservices
 When the number of microservices
increases, things can get complex
 Main drawbacks:
●
Not having a central place to execute
non-functional requirements (security,
throttling, monitoring, service discovery)
●
Most of the time these non-functional
requirements are duplicated within
microservices

36. API GATEWAY INVOCATION
 Works as a lightweight message gateway
eliminating issues had with the point-
point style
 Working as a single entry point for all
client service invocations
 Implements common non-functional
requirements
●
Lightweight message routing
●
Filtering
●
Message transformations
●
Security, monitoring and throttling

37. MESSAGE BROKER INVOCATION
 Used for asynchronous / reactive
messaging
 Uses protocols such as AMQP, MQTT
 Apache Kafka is a well known message
brokering framework

38.  To reduce complexity, Microservices Architectures divided its architecture into two main
architectural components,
●
Inner Architecture
●
How you design a microservice itself
●
Domain Drive Design (DDD)
●
Outer Architecture
●
How it communicates with other Microservices
●
Service Discovery, Routing, Error Handing, Observability, Access Control
MICROSERVICE ARCHITECTURE

39. MSA INNER ARCHITECTURE

40. DOMAIN DRIVEN DESIGN (DDD)

41.  Domain Driven Design helps us to scope out Microservices
 The scoping is done using Bounded Contexts
 Each bounded context encapsulates related functionalities into domain models defines
integration points to other bounded contexts.
 Each bounded context has an explicit interface, where it defines what models to share with
other contexts
 These modular boundaries are clearly align with a Microservice
 That means, we can say a “Bounded Context = Microservice”
BOUNDED CONTEXT

42.  Domain = Inventory Management
 Bounded Contexts = Order Processing, Inventory, Supplier Management
●
Order Processing – Encapsulates the functionality related to processing an order
●
Inventory – Takes care of updating the stocks upon receiving items from suppliers and
releasing the delivery
●
Supplier Management – Encapsulates the functionality related to managing suppliers. Upon
releasing an item for delivery, supplier management checks whether it has enough stocks in
the inventory. If not notifies the corresponding suppliers.
BOUNDED CONTEXT - EXAMPLE

43. BOUNDED CONTEXT - EXAMPLE
Source: Microservices for the Enterprise, Apress (2018)

44. MSA OUTER ARCHITECTURE

45. SERVICE MESH
Source: http:/
/philcalcado.com/2017/08/03/pattern_service_mesh.html
 Service Mesh is not a “distributed
ESB”
 It does not contain any business logic
like you find in ESB
 It does contain infrastructure level
features such as tracing, routing,
circuit breaking, load balancing,
service discovery, etc

46. SIDE CAR PATTERN
 Service Mesh overcomes the
microservices inter-service
communication challenges by having
the “Side Car Pattern”
 It consists of “proxies” to intercept all
incoming and outgoing network
traffic.
 Service Mesh divides tasks into two
planes.
●
Data Plane – Consists of
Microserives + Side Car
●
Control Plane – Consists of
components of service discovery,
routing, telemetry, access control,
etc)

47. SIDE CAR PATTERN
Source: https:/
/www.imz-ural.com/blog/waffles-the-sidecar-dog

48. SIDE CAR PATTERN
 Reducing the complexity in
microservices code by abstracting
infrastructure related functionalities
to a different layer
 Reduces the code complications: You
do not need to write any
configuration code within
microservices.
 Provides loose coupling between the
microservice and the infrastructure

49. SERVICE MESH ARCHITECTURES - ISTIO
 Istio has been the most popular open
source service mesh framework in the
market.
 It uses “Envoy” as its Side Car proxy
by default

50. PUBLIC CLOUD SERVICE MESH OFFERINGS

51. INTER SERVICE COMMUNICATIONS - GRPC
Source: Kasun Indrasri (GOTO 2020): Cloud Native Communication Patterns with GRPC

52. AFTER ALL, NOTHING IS EASY.

53. ALTERNATIVE: THE STRANGLER PATTERN?
Source: martinfowler.com

54. REFERENCES


55. Thank You