This document provides an overview of microservices and various methodologies for deploying microservices. It begins with an introduction comparing monolithic and microservice architectures. Next, it discusses considerations for microservice design like scalability and complexity. It then covers challenges of deploying microservices like monitoring and scaling. The document proceeds to introduce Kubernetes as a container orchestration tool for deploying microservices. It includes descriptions of various Kubernetes components like pods, deployments, services, and ingress. Finally, it demonstrates deploying microservices locally using Minikube to simulate a Kubernetes cluster on a single node.

1. Microservices
and
Deploying Methodologies
1
26th April, 2019

2. Microservices over Monolithic
Kubernetes for Deployment
Deploying of Microservices in local Environment
Deploying of Microservices over GCP
Overview of Kubernetes
(Anil Chauhan)
(Anil Chauhan)
(Rahul Abrol)
(Sapna Upreti)
(Sapna Upreti)

3. Anil Kumar Chauhan, Head of Engineering - Successive Technologies
About Me
anil.chauhan@successive.tech
facebook.com/anil.livelife
www.linkedin.com/in/anilkchauhan/
❖ 10+ Years of IT Experience
❖ Technical Architect and Trainer
❖ Worked as full stack developer on numerous web
technologies
❖ Proficient on Cloud Agnostic Platform
twitter.com/anillivelife

4. Enterprise Application - Checklist
Use of emerging technologiesTeam must own the code
Easy to understand and
enhance
Productive new members
Scalability and availability
Support to continuous
deployment

5. Main Components:
Monolithic Applications
Traditional way to build enterprise app, and deployed and scaled as a single package
● Client-side user interface
● Server-side application
○ Design Pattern(Services & Repositories)
● A database server

6. Monolithic Application
Services
Repositories
Scaling and deployed
as a single package
Business Layer
Data Store
User Interface

7. Monolithic Application: Example
Products
- product_id
- product_name
- product_price
- market_id
Users
- user_id
- user_name
- market_id
Markets
- market_id
- market_name
A query to get the list of products and market name of the logged in
user say with id=40 under price 300?
SELECT product_name, market_name
FROM products
INNER JOIN markets on products.maket_id = markets.id
INNER JOIN users on users.market_id = markets.id
WHERE users.user_id = 40
AND products.product_price < 300

8. Monolithic Application - MVP version
Dev Team 1
What if a big hit?

9. Monolithic Application - After few releases
Dev Team 1
Dev Team 2
Dev Team 3
Dev Team 4
Areas where multiple teams
working on same part

10. Monolithic - Pros / Cons
Not ideal for growing codebase.
Barrier to adopting new technologies
Steep learning curve
Simple to develop, for small codebases
Simple to Test
Simple to deploy and scale Pros
&
Cons
Slower release for large code base
IDE-friendly

11. Checklist - Revisit
Use of emerging
technologies
Team must own the
code
Easy to understand and
enhance
Productive new
members
Scalability and
availability
Support to continuous
deployment

12. Design Considerations
Micro Services
Suites of independently deployable services
● Organized around business capability
● Decentralized Database
● Loosely Coupled and Highly Cohesive
● Independently deployed

13. Microservice Application
Users Service
Market Service
Products
Service
API Gateway
Events
2 Replica
1 Replica

14. Microservice Application: Example
products
{
id: 1,
name: ‘AWS’
price: 300,
market: {
id: 1,
name: US
}
}
Users
{
id: 1,
name: ‘John Smith’
market: {
id: 1,
name: US
}
}
markets
{
id: 1,
name: US,
currency: ‘$’,
created_at: ‘123’,
updated_at: ‘abc’
}
● Separate database per service as per business domain
● Maintain Duplicacy of data with single source of truth
● Eventual Consistency among services

15. Microservice - Pros / Cons
More moving parts
Documentation overhead
Complex infrastructure
Better for complex application
High scalability
Ease of deployment Pros
&
Cons
Harder to Debugging
Easy to understand

16. Checklist - Revisit
Use of emerging
technologies
Team must own the
code
Easy to understand and
enhance
Productive new
members
Scalability and
availability
Support to continuous
deployment

17. Comparison (Productivity vs Complexity)
Productivity
Complexity
For less complex app managing
microservices will leads to extra
efforts.
Decoupling nature of
microservices really pay off.
Microservice
Monolithic

18. Deployment Challenges with Microservices
Deployment and configuration of
high number of services
Monitoring of services for node
failures
Scaling of particular services and
distribution of traffic
Service Logs and Debugging
Update strategy with zero downtime
Rollback in case of any trouble

19. ● Invented by Google
● Managed by open source community
● Adopted by Microsoft and Amazon
● Run Anywhere
Why to Choose?
Kubernetes (K8s)
An open-source system for automating deployment, scaling, and management of
containerized apps

20. Overview of K8s
20
(Rahul Abrol)

21. Rahul Abrol, DevOps Engineer - Successive Technologies
About Me
rahul.abrol@successive.tech
facebook.com/rahul.abrol.96
www.linkedin.com/in/rahul-abrol-002042ab
❖ 3+ Years of IT Experience
❖ Site Reliability Engineer and Automation Expert
❖ Delivered Solutions for various Projects
twitter.com/RahulAb75631000

22. Basic components of Kubernetes (Cloud)
Cluster
CLI
Kubectl
Master Node
API Server
Scheduler
Controller Manager
etcd
Worker Node 1
kubelet kube-proxy
docker
Pod 1 Pod 2 Pod N
Worker Node N
kubelet kube-proxy
docker
Pod 1 Pod 2 Pod N
UI
Dashboard

23. Basic components of Kubernetes (local)
CLI
Kubectl
Minikube
Master Node
Single Worker Node
kubelet kube-proxy
docker
Pod 1 Pod 2 Pod N
Local Cluster
UI
Dashboard

24. Basic components: Pods
Worker Node
kubelet kube-proxy
docker
Pod 1 Pod 2 Pod N
Containers
● Basic and smallest building block.
● All the connected containers
deployed to a single pod
● Containers inside pod will live and
die together
● All containers have common IP,
and resources.
● Each POD has unique IP.
User
Log
Product Report
Log

25. Basic components: Deployments
● Scaling up and down of the pods.
● Manages releases and rollback
● Self Healing of system
● Assign a unique label to every set
of pods, and used by services for
discovery.
Deployment
Replica Set
Replica: 2
Pod Pod
User User
Log Log
label=user-service label=user-service

26. Basic components: Service
● Stable endpoint that load
balances traffic among pods with
similar label
● Discover the respective pods by
the selectors
● With Service you don’t have to
remember how many pods are
running or where
Deployment
Replica Set
Replica: 2
Pod Pod
label=user-service label=user-service
Service
selector: user-service

27. Basic components: Ingress
Service: user-service
Type: NodePort
Service: market-service
Type: NodePort
Service: product-service
Type: NodePort
Pod A
label: user-service
Pod B
label: user-service
Pod C
label: market-service
Pod D
label: product-service
Pod E
label: product-service
Pod Ingress
Controller
Service: ingress
Type: LoadBalancer
Public IP
-Path: /users
Service: user-service
-Path: /markets
Service: market-service
-Path: /products
Service: product-service

28. Deployment on GCP
28
(Sapna Upreti)

29. Sapna Upreti, Sr. Software Engineer - Successive Technologies
About Me
sapna.upreti@successive.tech
facebook.com/sapna0214
www.linkedin.com/in/sapna-upreti-a093525b/
❖ 4+ Years of IT Experience
❖ Technology Specialist
❖ Blogger
❖ Tech Speaker
https://twitter.com/sapna0214

30. GKE: Prerequisites
● gcloud CLI
● Enabled the Google
Kubernetes Engine API
● gloud init

31. GKE: Create Cluster

32. GKE: Create k8s Cluster
gcloud container clusters get-credentials NAME [--internal-ip] [--region=REGION | --zone=ZONE, -z
ZONE] [GCLOUD_WIDE_FLAG …]

33. GKE: in action
33

35. K8s: Rollbacks
● Rolling out your application to
previous version
● Set the revision that you want
● Kubernetes will scale up the
corresponding ReplicaSet, and
scaled down the current one
Handy Commands:
● kubectl rollout history deployments products
● kubectl rollout status deployments products
● kubectl rollout undo deployments products

36. K8s: Rollbacks in action
36

38. Deployment Strategies: Rolling Updates
● Replace each pod in the deployment with a new one
● Backwards compatibility
● New ReplicaSet created and old ones gets decreased
V1
V1
V1
V1
V1
V1
V2
V1
V1
V1
V1
V2
V2
V2
V2
V2
V2
V2` ` ` `

39. Deployment Strategies: Rolling Updates (example)

40. Deployment Strategies: Recreate Strategy
Terminate the old version and release the new one
V1
V1
V1
V1
V1
V1
V1
V1
V2
V2
V2
V2` ` `

41. Deployment Strategies: Blue/Green
● Run two complete deployments of your application
● “green” version of the application is deployed alongside the “blue”
version
V1
V1
V1
V1
V2
V2
V1
V1
V2
V2
V2
V2

42. Deployment Strategies: Blue/Green (example)

43. Deployment Strategies in
action
43

45. Deployment on Local
45
(Sapna Upreti)

46. Minikube: K8s cluster on Local
UI
CLI
Kubectl
Minikube
Master Node
API
Server
Scheduler
Controller
Manager
etcd
Single Node
kubelet kube-proxy
docker
Pod 1 Pod 2 Pod N
Local Cluster
Dashboard

47. Minikube: Prerequisites
Few handy commands:
● minikube start (pass VM option),
default is VirtualBox
● minikube addons enable ingress
● VM Driver
○ macOS: VirtualBox, VMware
Fusion, HyperKit
○ Linux: VirtualBox, KVM
○ Windows: VirtualBox, Hyper-V
● Install Minikube
○ brew cask install minikube
(macOS)
● Install kubectl
● VT-x/AMD-v virtualization
must be enabled in BIOS
● Internet connection on first run

48. Minikube: K8s Cluster
Hurrah! Now we have K8s cluster
running named as minikube
● kubectl config get-contexts

49. Minikube: K8s Cluster
Change context to minikube
● kubectl config use-context
minikube
● kubectl config get-contexts

50. Minikube: Deployment
Deployments are requirements you give to Kubernetes regarding your applications
(your Pods)
“Hey Kube, always keep 5 instances (or replicas) of these Pods running — always”

51. Minikube: Deployment (Markets Service)
Container Port is the port that the
application is running on.
Readiness probes: when a Container
is ready to start accepting traffic.
A Pod is considered ready when all of
its Containers are ready

52. Minikube: Deployment (Products Service)
● A Deployment named
demo-product is created
● four replicated Pods
● Pods are labeled as
demo-products
● Image from docker
● Environment variables

53. Minikube: Deployment (Users Service)
● A Deployment named demo-users
is created
● Two replicated Pods
● Pods are labeled as demo-users
● Image from docker
● Environment variables

54. Minikube: Service
Expose our pods using Services.
“Not healthy? Killed.
Not in the right place? Cloned, and killed.”

55. Minikube: Service (Markets Service)
Each Pod has a unique IP address,
those IPs are not exposed outside the
cluster without a Service
demo-markets service
Selects demo-markets Pods

56. Minikube: Service (Products Service)
Each Pod has a unique IP address,
those IPs are not exposed outside the
cluster without a Service
demo-products service
Selects demo-products Pods

57. Minikube: Service (Users Service)
Each Pod has a unique IP address,
those IPs are not exposed outside the
cluster without a Service
demo-users service
Selects demo-users Pod

58. Minikube: Ingress
Ingress objects are the rules
that define the routes that
should exist.
Annotations to configure some
options depending on the
Ingress controller
Target URI where the traffic
must be redirected

59. Minikube- in action
59

61. Minikube: UI Deployment and Service

62. Minikube: Dashboard (minikube dashboard)

63. Minikube- in action (UI)
63

65. Tools and Clouds
65

66. Clouds and Tools
We at Successive Technologies use following tools for building Cloud Agnostic Platform.

67. Queries?

68. Thank You