Microservices Meetup Deck as presented

1. 2018 Newt Global |www.NewtGlobal.com | Confidential
Follow us on:

2. ▪ Founded in 2004 ,HQ at Dallas TX,
present in multiple locations in USA and
India
▪ Leader in DevOps Transformation, Cloud
Enablement and Test Automation
▪ One of top 100 fastest growing
companies of Dallas twice in a row
▪ Clientele includes Fortune 50 companies
About Newt Global

3. Speakers
6/15/2018 Copyright 3
• Venkat is DevOps Practice Leader, His area of expertise includes DevOps &
Cloud, Consulting Fortune 100 customers on DevOps IT Strategy. R
• Responsible for building the global pre-sales, consulting and delivery team
for Newt Global Consulting LLC
• He has 16+ years of IT industry experience and delivered multiple enterprise
scale projects for Fortune 500 customer base
Venkatnadhan Thirunalai
DevOps, Practice Leader
NewtGlobal

4. Newt Global Overall Offerings
Onboarding Zone Engineering Zone Re-Architecture Zone
DevOps Pipeline
CI/CD Enabled
QA
Infrastructure
Automation
Cloud
Enablement
Modernize
Architecture
Consulting Tool chain
selection,
Implementation and
Integration
Test Automation
framework,
Intelligent # Tag
Infrastructure as
code. Spin up/down
infrastructure on
demand and
manage it as code
Assessment of application
Refactor application
Data Migration services
Micro services based
architecture &
domain based
design
Engagements at various levels of maturity
Agile Process
Benefits:
Improve Agility
To enable instant change deployment
Accelerate time to market
Shorten the development to
deployment lifecycle
Increase Productivity
Reduce downtime during deployment &
errors caused by manual intervention
Enhance ROI
Optimize tooling expenditure, increase
productivity,

5. Monolithic Application
• Sample Ecommerce Monolithic application
Browser Apache
Tomcat
WAR
Ecommerce UI
Search
Product
Catlog
Checkout
Payment
MySql

6. Sample Ecommerce App as Microservices
Ecommerce UI
Search
Product
Checkout
Catalog
Payment
Product
DB
Catalog
DB
Checkout
DB
Browser
Containers not necessary but desirable
Better Infra Utilization
Save Cloud costs
Better response to erratic workloads.
Benefits Microservices  Containers  Cloud

8. App
A
Containers vs. VMs
Hypervisor (Type 2)
Host OS
Server
Guest
OS
Bins/
Libs
App
A’
Guest
OS
Bins/
Libs
App
B
Guest
OS
Bins/
Libs
AppA’
Docker
Host OS
Server
Bins/Libs
AppA
Bins/Libs
AppB
AppB’
AppB’
AppB’
VM
Container
Containers are isolated,
but share OS and, where
appropriate, bins/libraries
Guest
OS
Guest
OS
…result is significantly faster deployment,
much less overhead, easier migration,
faster restart

9. Why are Docker containers lightweight?
Bins/
Libs
App
A
Original App
(No OS to take
up space, resources,
or require restart)
AppΔ
Bins/
App
A
Bins/
Libs
App
A’
Guest
OS
Bins/
Libs
Modified App
Copy on write
capabilities allow
us to only save the diffs
Between container A
and container
A’
VMs
Every app, every copy of an
app, and every slight modification
of the app requires a new virtual server
App
A
Guest
OS
Bins/
Libs
Copy of
App
No OS. Can
Share bins/libs
App
A
Guest
OS
Guest
OS
VMs Containers

10. Some Docker vocabulary
Docker Image
The basis of a Docker container. Represents a full application
Docker Container
The standard unit in which the application service resides and executes
Docker Engine
Creates, ships and runs Docker containers deployable on a physical or virtual, host
locally, in a datacenter or cloud service provider
Registry Service (Docker Hub or Docker Trusted Registry)
Cloud or server based storage and distribution service for your images
10

11. What exactly is docker
CGroups
Namespaces
Image
Container

12. Docker in production
Quick deployment
Resource Management
Backup management
System security
Container monitoring
Image and storage management

13. Docker Swarm for Container Orchestration

14. On Failure Rescheduling

15. On failure Rescheduling

16. High Availability and State Replication

17. High Availability and State Replication

18. Manager Back up Instances

19. Manager Back up Instances

20. Manager Back up Instances

21. Orchestration Of Services in Production: Sample Ecommerce Application
Ecommerce UI
Search
Product
Checkout
Catalog
Payment
Product
DB
Catalog
DB
Checkout
DB
Browser
Around 1000 users traffic at any given time
995 do window shopping
5 actually add something to cart
3 End up buying something
A General Ecommerce Scenario

22. Search Search Search Search
Non Linear Scaling based on service load
Search
Product
Checkout
Catalog
Payment
Product
DB
Catalog
DB
Checkout
DB
Product Product Product Product Product
Search

23. You could have also used K8S
23
API
UI
CLI
Kubernetes
Master
Node 1
Node 2
Node 3
Node 4
Registry

24. As we move to services
architectures, we push the
complexity to the space
between our services.

26. The Magical Bus

27. Microservices libraries

29. The need evolves
• Service discovery
• Retries
• Timeouts
• Load balancing
• Rate limiting
• Thread bulk heading
• Circuit breaking
• Routing between services (adaptive,
zone-aware)
• Deadlines
• Back pressure
• Outlier detection
• Health checking
• Traffic shaping
• Request shadowing
• Edge/DMZ routing
• Surgical / fine / per-request routing
• A/B rollout
• Internal releases / dark launches
• Fault injection
• Stats, metric, collection
• Logging
• Tracing

30. Drawbacks to library approach
•need one for each combination language/framework
•need to maintain, upgrade, retire
•classpath/namespace pollution
•increases operational complexity
•force specific languages
•inconsistency
•correctness

31. Solution ????
• Let’s abstract this functionality to a single binary and apply to all services.
• Allow heterogeneous architectures
• Remove application-specific implementations of this functionality
• Consistently enforce these properties
• Correctly enforce these properties
• Opt-in as well as safety nets

32. Service Mesh
• A service mesh is a dedicated infrastructure layer for making service-to service communication safe, reliable,
observable and configurable
• Valuable as we move from deployment of complicated monoliths/services to orchestration of complex “cloud
native” services
32

33. Benefits of a Service Mesh
• Service discovery
• Advanced routing
• Auto retries
• Retry budgets
• Request deadlines
• Circuit breaking
• Latency observed load-balancing
• Advanced orchestration
• Canary, blue/green
• Per request routing
• Standardised metrics / logging
• Central control plane
• Distributed tracing
• Rate limiting
• Authentication
33

34. Service Mesh: Envoy
• service proxy
• written in C++, highly parallel, non-
blocking
• L3/4 network filter
• out of the box L7 filters
• HTTP 2, including gRPC
• baked in service discovery/health
checking
• advanced load balancing
• stats, metrics, tracing
• dynamic configuration through xDS
• zone aware, least request load
balancing
• circuit breaking
• Outlier detection
• retries, retry policies
• timeout (including budgets)
• traffic shadowing rate limiting
• access logging, statistics collection
• Many other features!

35. Various Implementations