This session introduces the key patterns in Cloud Native application development. It highlights the need of a unique architecture style, further, the fitment of DevOps, usage of Microservices and the runtime of Cloud Native application (* as a Service). The precautions of distributed computing gives insights of how to plan the application design and architecture.

1. CLOUD NATIVE
SHIFT IN APPLICATION DEVELOPMENT PARADIGM
SIVA RAMA KRISHNA

2. @sivachunduru
linkedin.com/in/chunduru
slideshare.net/sivachunduru
SIVA RAMA KRISHNA – SOLUTION SPECIALIST
2

3. WHAT & WHY ?
• History
• Analyst perspective
• Scope for community

4. CLOUD NATIVE
ORIGINATED
IN
CUSTOMER FACING
TECH COMPANIES

5. “Six decades into the computer
revolution, four decades since
the invention of the
microprocessor, and two
decades into the rise of the
modern Internet, all of the
technology required to
transform industries through
software finally works and can
be widely delivered at global
scale.”
- Marc Andreessen
Co-Founder, Andreessen Horowitz
WHAT IS COMMON IN THEM ?
SPEED OF BUSINESS INNOVATION,
ENABLED BY SOFTWARE
Uber was founded in 2009 and launched its service in 2010.
Airbedandbreakfast.com (later to be renamed Airbnb)
was founded in 2008, but only reached 1 million listings in
2014.
Netflix — from a startup in 2011 - they took the
discontinuous leap from technology provider and service to
content creator in 2013.
- HOMOGENIZED software limits innovation
- CUSTOM software enables innovation & differentiation
5

6. IS THE TREATMENT OF
AN ERP SYSTEM
AND
A WEBSITE
SAME ?
PACE LAYERED ARCHITECTURE
Growth
Release
Cycles Fail
Points
Development
Methodologies
Execution
Affinity
Center of
Gravity
6

7. NEW AD PROJECTS WITH IN IT ORGANIZATIONS
ANALYST PERSPECTIVE
1 Focus on functional and non-functional
requirements to drive what “cloudiness”
characteristics are needed to deliver
2 Choose both an application architecture and
runtime environment that supports the
application’s requisite “cloudiness‟
characteristics.
3 The burden of responsibility required to
meet these “cloudiness” characteristics
within application code versus the system
infrastructure.
4 Real world limitations in developer
resources, skills, time, etc. may force you to
reconsider either the choice of deployment
platform OR the degree of “cloudiness”
present in the application
5 Rinse and repeat until you find the solution
that best balances “cloudiness” with both
development and runtime constraints.
STEPS TO BUILD A CLOUD APPLICATION
75%
7

8. WE MUST
RE-INVENT
OUR PROFESSION
Then only we can do better
Cloud Native is difficult
But not doing it is worse
The gist is that applications should be,
- built in the cloud
- for the cloud
- maximizing the benefits of the cloud 8

9. VOICE OF THE VENDORS
9

10. 10
VALUE OF CLOUD NATIVE
Quickly Capitalize
on
Business OpportunitiesSpeed
Quickly move changes to production
Survive failures. Highly available in production
Resiliency
Change your practices as needed
Agility

11. Application Architectures
MicroServices
DevOps
* as a Service
Distributed Computing
TOPICS TO LEARN
11

12. TOPICS TO LEARN
Application Architectures
MicroServices
DevOps
* as a Service
Distributed Computing
• Deployment Target
Types
• Development
Methodology
• Legacy Architectures
• Service Based
Architectures
12

13. — Brian Foote and Joseph
Yoder, Big Ball of Mud. Fourth
Conference on Patterns Languages
of Programs, Monticello, Illinois,
September 1997
A big ball of mud is a software system
that lacks a perceivable architecture.
Although undesirable from a software
engineering point of view, such
systems are common in practice due
to business pressures, developer
turnover and code entropy.
BIG BALL OF MUD – AN ANTI-PATTERN
13

14. QUARRY THE DEPLOYMENT TARGET TYPES
Virtual Machine
Compute with
Operating System,
Networking and
attached Storage
Container
An Operating System
level virtualization
method
Application
Platform as a
Service (aPaaS)
Application deployment
in Containers
Functions
(Serverless)
…code execution model
in which cloud provider
fully manages starting
and stopping of the
function’s container
platform as a service as
necessary to serve
requests
14

15. QUARRY THE DEPLOYMENT TARGET TYPES - EXAMPLE
Virtual Machine
AWS
Azure
Oracle Cloud
IBM
….
Container
Docker, Rocket, RunC,
LXC, ….
Application
Platform as a
Service (aPaaS)
Heroku, Bluemix, Oracle
Application Container
Functions
(Serverless)
Amazon Lambda
Bluemix OpenWhisk
Microsoft Functions
Oracle Functions
….
15

16. https://12factor.net
Adam Wiggins
Co-Founder
Heroku Cloud
16

17. THE 12 FACTORS
I. Codebase
One codebase tracked in revision control, many deploys
II. Dependencies
Explicitly declare and isolate dependencies
III. Config
Store config in the environment
IV. Backing Services
Treat backing services as attached resources
V. Build, release, run
Strictly separate build and run stages
VI. Processes
Execute the app as one or more stateless processes
VII. Port Binding
Export services via port binding
VIII. Concurrency
Scale out via the process model
IX. Disposability
Maximize robustness with fast startup and graceful shutdown
X. Dev/prod parity
Keep dev, staging and prod as similar as possible
XI. Logs
Treat logs as event streams
XII. Admin processes
Run admin/management tasks as one-off processes
17

18. LEGACY ARCHITECTURES
18
Source: Software Architecture Patterns by Mark Richards
Layered Architecture Event Driven Architecture Micro Kernel Architecture
Analysis Agility Deployment Testability Performance Scalability Development 12-Factor
Code Runtime Admin
Layered         
Event Driven         
Microkernel         

19. MICROSERVICES ARCHITECTURE – HELPS IN SEPARATELY DEPLOYED UNITS
19
Source: Software Architecture Patterns by Mark Richards
Analysis Agility Deployment Testability Performance Scalability Development 12-Factor
Code Runtime Admin
MicroServices         

20. CLOUD ARCHITECTURE – HELPS IN SCALABILITY AND CONCURRENCY
20
Source: Software Architecture Patterns by Mark Richards
Analysis Agility Deployment Testability Performance Scalability Development 12-Factor
Code Runtime Admin
Cloud Based         

21. ARCHITECTURES - ANALYSIS
21
Source: Software Architecture Patterns by Mark Richards

22. SERVICE BASED ARCHITECTURE – SOI (SERVICE ORIENTED INTEGRATION)
Consumer
Consumer
Consumer
Intermediary Application
Function
API exposed by
Application
Published Service
Interface
• Expose Application Functionality
as Service
• Application
- Hosted by SaaS providers
- Hosted by PaaS providers
- Hosted by IaaS providers
• Intermediary
- Mediation, routing
- Security enforcements
- Smart endpoints, Dumb pipes
• Integrate with in the DC / Across
the DCs
• Use APIs to integrate both
Enterprise / Mobile Apps
12-F Treatment for Source Code Runtime Environment Administration
SOI   
22

23. SERVICE BASED ARCHITECTURE – SOA (SERVICE ORIENTED ARCHITECTURE)
Application
Consumer
Consumer
Consumer
Intermediary
Service
API exposed by
Service
Published Service
Interface
• Service orientation to the
architecture of the application
• Application
- Functions as services
- Service code is built as separate,
independent entity
- Services are logically separated
- Service identification basis of
reuse potential
- To enable reuse, service
contract is must additional to
interface specification
- Services can be deployed with
application or independently
• Addresses Agility and Scalability
12-F Treatment for Source Code Runtime Environment Administration
SOA   
23

24. SERVICE BASED ARCHITECTURE - MICROSERVICES
Consumer
Service Discovery
Service
Service
Service
API access can be
direct or mediated
Discovery Query
Service self-registration
12-F Treatment for Source Code Runtime Environment Administration
MicroServices   
• Designed for maximum agility
• Size of the service is limited
• Unit of deployment to 1 service
• Each service is autonomous
• Between services -
- Eliminates dependencies
- No synchronous interactions
• Not focused on enterprise level
reuse
• Addresses the Agility, Rapid
deployment and Scalability
24

25. OTHER PATTERNS YOU HEAR IN THE FIELD
• Externalization Patterns
 Externalized Configuration Pattern
 Externalized State Pattern
 Externalized Channels Pattern
• Runtime Patterns
 Runtime Reconfiguration Pattern
 Concurrent Execution Pattern
 Brick Telemetry Pattern
25
• Integration Patterns
 Event Driven System Pattern
 Contract Management Pattern
 Integration Telemetry Pattern
• Distributed System Patterns
 Service Discovery Pattern
 Edge Gateway Pattern
 Fault Tolerance Pattern

26. Application Architectures
MicroServices
DevOps
* as a Service
Distributed Computing
• Minimal Function
• Service Discovery
• API-first
• Polyglot
• Choreography
• Loose Coupling
TOPICS TO LEARN
26

27. “Erik Doernenburg first shared with
me the idea that we should think of
our role more as town planners than
architects for the built environment”
- Sam Newman
27

28. MICROSERVICES
Break up your application into many small
pieces to get features to market quickly.
Each MicroService Characteristics –
 Small & Independently deployable
 De-coupled
 Has its own team to design, develop, deploy
and maintain
 Exposes an API
 Has its own databases
28

29. A SIMPLE RUBRIC – MINIMUM VIABLE PLATFORM
• Optimize SDLC and Delivery Pipeline with tenets of Cloud Native operability
• It requires Operationally mature platform
• Minimum capabilities of MVP
• Dynamic DNS, routing and load balancing
• Automated service discovery and brokering
• Infrastructure automation
• Health Management, monitoring and recovery
• Immutable artifact repository
• Log aggregation
29

30. • Perform a single function
• should do a small set of things (ideally one thing) really well
• Exposed thru a simple API
• modern cloud-native microservices tend to favor protocols like
REST
• reject protocols that are heavily dependent on specific
programming ecosystems
• Upgraded and evolved independently
• is independent and decoupled from the clients that use it
• fix or evolve it without rewriting or stopping the applications
that use it
• Architected for fault-tolerance
• failure of a single microservice can result in the failures of
multiple different applications
• Accessed over the network
• are designed to run in the cloud and be accessed over the
network from other peers and applications
• Perform a single function
• the DNS does a single thing: map human readable names
into IP addresses
• Exposed thru a simple API
• DNS is typically accessed by clients using a simple UDP-
based request-response protocol
• Upgraded and evolved independently
• DNS names are hierarchical and are administered at
different levels
• Architected for fault-tolerance
• DNS servers are typically deployed in at least pairs and
often in triplicate
• Accessed over the network
• DNS is certainly made to by accessed over the network,
with its popular UDP-based protocol
MICROSERVICES – PROPERTIES & DNS USE CASE
30

31. 31
X-axis scaling
• consists of running multiple copies of an
application behind a load balancer.
Y-axis scaling
• splits the application into multiple,
different services.
Z-axis scaling
• Each server run identical copy of code.
• Each server responsible for subset of
data.
THE ART OF SCALABILITY – ACOLYTE SYSTEM
y-axis
Functionaldecomposition

32. 32
DEVELOPERS WANT POLYGLOT SUPPORT
• Different languages for different
specialized microservices
• Remember – the goal of cloud native
is time to market. It is NOT about
long-term maintainability
• If maintenance becomes an issue,
rewrite the microservice over a
weekend
Use the language that works best
API
Application
Data Store
Infrastructure
Inventory
Microservice
Chat
Microservice
Product Recommendation
Microservice
API
Application
Data Store
Infrastructure
API
Application
Data Store
Infrastructure

33. EACH MICROSERVICE USE ITS OWN DATABASE
33RDBMS is great but not necessary for all use cases
Relational Database
ACID-compliant, suitable for a
wide range of workloads.
Trusted, reliable, wide client
support, easy to use
Object GridsNoSQL
Store objects in and move
business logic into the server-
side grid.
Non-relational organization of
data, including key/value, graph,
document, tabular, etc. Always
BASE and sometimes ACID
compliant

34. 34
REMEMBER THAT LATENCY IS EVERYWHERE
Asynchronously make calls to all remote systems
High latency within a single
cloud. Can no longer
assume 2ms between
application and data tiers
Application is now comprised
of many different
microservices, each with its
own data store/database
Application is now deployed
to multiple data centers, in
multiple availability zones, in
multiple regions

35. SYNCHRONOUS CALLS WITH MICROSERVICES ARE VERY BAD
35
Product Catalog Product Pricing Inventory
Chaining == coupling == downtime
The availability of microservice A depends on B, B depends on C, etc

36. 36
AVOID SYNCHRONOUS CALLS FOR READ-ONLY DATA BY COPYING
Product Pricing
Inventory
Promotions
Product Pricing
Inventory
Promotions
Product Pricing
Inventory
Promotions
Product Catalog
• Synchronous in-memory calls
• Data is 100% consistent
• No data is duplicated
Request for
Category Page
Product Catalog
Product
Pricing
Inventory
Promotions
• Synchronous calls to product catalog microservice
• Product, pricing, inventory and promotions
microservices are systems of record; they publish
asynchronously to Product Catalog microservice when
updated
• Product Catalog microservice is not always consistent
• Data is duplicated – two or more microservices may
contain the same data
Traditional
Monoliths
New
Microservices

37. CIRCUIT BREAKERS PREVENT CASCADING FAILURES
• Rule #1 of microservices – avoid coupling!
• Synchronous = two systems are coupled
• Asynchronous = no coupling
• Cascading failures happen when request-handling threads are waiting on a
response from a remote system
• Circuit breakers make synchronous calls from another thread pool to avoid
binding up request-handling threads
• Hystrix (Java-based) is well-known and solves this problem
37Cascading failures are more common with microservices

38. USE A HIGHER LEVEL OF REST
38REST is the currency of cloud native
• Level 1
– Start requesting individual resources
– Interact with /OrderService/12345
• Level 2
– Start using HTTP verbs - HTTP GET/POST/PUT/DELETE/etc
– Responses come back using correct HTTP codes – e.g. HTTP 409 for a conflict
• Level 3
– Application itself tells client how to interact with it - similar to hyperlinks in a web page
– <link rel = "delete" uri = "/OrderService/12345/delete"/> under <order id="12345">
Richardson Maturity Model
• Level 0
• Use HTTP as a tunneling mechanism only
• Interact with /OrderService
• Use HTTP GET/POST only

39. 39
EMIT LOGS AS EVENT STREAMS
Can’t do anything with log files sitting on a container’s local storage volume
Log Entry Log Entry
Log Entry
Log Entry
Log Entry
Log Entry
Log Entry
Log Entry
Log Entry
Log Entry
Log Entry
Log Entry
Log Entry
Log Entry
Log Entry Log Entry
Container
Instance of Application
Log Entry Log Entry
Log Entry
Log Entry
Log Entry
Log Entry
Log Entry
Log Entry
Log Entry
Log Entry
Log Entry
Log Entry
Log Entry
Log Entry
Log Entry Log Entry
Container
Instance of Application
Log Entry Log Entry
Log Entry
Log Entry
Log Entry
Log Entry
Log Entry
Log Entry
Log Entry
Log Entry
Log Entry
Log Entry
Log Entry
Log Entry
Log Entry Log Entry
Container
Instance of Application
Capture, Aggregate, Search, Troubleshoot, etc

40. Orchestration
• Top-down coordination of
discrete actions
• Used in centralized,
monolithic applications
• Brittle – centralized by
nature
• Each “action” registers
with centralized system –
single point of failure that
is not very flexible
Choreography
• Bottom-up coordination
of discrete actions
• Used in distributed,
microservice applications
• Resilient – distributed by
nature
• Each microservice
asynchronously throws up a
message that other
microservices can consume
40
CHOREOGRAPHY OVER ORCHESTRATION BETWEEN MICROSERVICES

41. 41
EXAMPLE OF CHOREOGRAPHY
Scenario: eCommerce user returns a widget through web-facing .com
Centralized Workflow
Self Service
Help
Initiate
Return
Workflow
Increment
Inventory
Done
Inventory
Record
Refund
Done
Customer
Profile
Done
Payment
Refund
Money
Brittle | Centralized | Tightly Coupled

42. 42
EXAMPLE OF CHOREOGRAPHY
Scenario: Inventory microservice
Inventory
Microservice
All asynchronous
Event Bus
New
Inventory
Events This Microservice Cares About Events This Microservice Emits
Product
Returned
Product Sold
Product
Recalled
Inventory
Incremented
Inventory
Created
Inventory
Decremented
Inventory
Deleted
For Anyone
Who Cares...

43. 43
ADOPT AN API GATEWAY
API gateways provide a "backend for each frontend"
• Builds a XML or JSON response for each
type of client – web, mobile, etc
• Asynchronously calls each of the N
microservices required to build a response
• Handles security and hides back-end
• Load balances
• Applies limited business logic
• Meters APIs
• Logs centrally
Client
Public Internet
Microservice Microservice Microservice
Microservice Microservice Microservice
Data Center
API Gateway
Microservice Microservice Microservice

44. Application Architectures
MicroServices
DevOps
* as a Service
Distributed Computing
TOPICS TO LEARN
•Automated
Provisioning
•Automated Setup
•Continuous
Integration
•Continuous Delivery
•Automated Testing
•Agile
•Culture Change
44

45. 45
The nicest thing about Teamwork is
that
You always have others on your side.

46. GARTNER DEVOPS MODEL - CATALOG OF DEVOPS PRACTICES
46
People
Process
Culture
Technical Debt
Test-driven
Development
Test-Driven
Deployment
Test Everything
Instrument
Everything
Trust Culture
Engineering Culture
Collective
Ownership
Autonomous Teams
Joint Meetings
Learning
Culture
Job RotationFull-Stack Teams
Minimum
Viable Process
Common
Metrics
Feature Flags
Optimize Flow
Chaos
Monkey
Value Streams
Collaborative Culture
Never Done
Small Batches
Automated
Testing
Minimum Viable
Product
Release Automation
Automated Builds
Canary
Rollouts
Fail Forward
Version
Everything
Servant
Leadership
Site Reliability
Engineers
Platform
Engineers
Technology
Continuous
Monitoring
Integrated Tool
Chains
Monitor
Everything
Infrastructure as Code
Developer Self-
Service
Continuous Testing
Continuous
Integration
ChatOpsOne-Step Build, Test,
Deploy
Continuous
Delivery
Feature Teams
Starting point of DevOps could be from any of the categories: People, Process, Culture or Technology.

47. TAKE THE BARRICADES OUT TO KICK START THE DISCUSSION
• Code Quality
• MTBF
• MTTR
• Bug Escape Distance
• Code Complexity
• Impacts the speed
• Unit Test Coverage
• Lower values turns to risk
• Commit Rates
• Longer the rates, more code to
be merged – can cause
problems, delays, bugs
47
• Environment Stability
• Continuous Automated Tests
• Combine Tests & System
Monitoring
• Real time Application
Monitoring
• Faster Platform Upgradation
• Business Metrics
• # of deployments
• Time to production
• # of release candidates built
• Software stack under CD
pipeline
Engineering Operations

48. 48
3 WAYS – THE PRINCIPLES BENEATH DEVOPS
http://itrevolution.com/the-three-ways-principles-underpinning-devops/
Standardized Environments
Automated Provisioning
Continuous Integration
Continuous Delivery
Developer Self Service
Rapid Prototyping
Learn from failures Amplify +ve feedback

49. Plan
Code
Build
Test
Package
Release
Deploy
Monitor
DEVOPS PIPELINE
Pattern Description
Plan Agile Project Management
Code Team Infrastructure (Code, Review, Merging,
Version Control, Documentation etc.)
Build Continuous Integration
Test Continuous Testing
Package Artifact repository
Release Change Management, Release automation
Deploy Deployment plans, Infra provisioning, Infra
configuration & management
Monitor Application performance monitoring, End
user experience
49

50. Plan
Code
Build
Test
Package
Release
Deploy
Monitor
HARNESS THE DELIVERY PROCESS
Plan
Code
Build
Test
Package
Release
Deploy
Monitor
Agile Continuous
Integration
Plan
Code
Build
Test
Package
Release
Deploy
Monitor
Continuous
Delivery
If Agile software development was the opening act to a
great performance, continuous delivery is the headliner.
- Kurt Bittner, Principle Analyst
50

51. DEVOPS PATTERNS AND TOOLSET AVAILABLE IN MARKET
51
A shared version control system
that contains system provisioning
scripts as well as application code.
One tool to manage both
application configuration and
infrastructure configuration.
Common methods and tools for
building, testing and quality
assurance.
Dev Ops
Both Coding &
Platform for
Application
Both System &
Application on
Platform
Source Code
Management
Continuous Integration/
Deployment
Configuration
Management
Software defined
Infrastructure
Monitoring

52. 52
INFRASTRUCTURE AS CODE
Manage it as you would do any other source code
Base Image
Install Binaries
Configure Software
Make Software Work Together
Patch/Push Config Changes
Step 1
Pick a Tool
Step 2
Script your environment
Step 3
Run your scripts against all hosts

53. • Single system for code and
build artifacts
• Every time someone
commits a change, consider
triggering a build +
automatic verification tests
• Always ship trunk!
• Enable features through flags
53
SHARED VERSION CONTROL

54. •Manual one button
build/deploy
•Scheduled builds - every
day, every week, etc
•Builds triggered by code
checkins
•If post-build validation
fails, report it
54
ONE STEP BUILD/DEPLOY

55. 55
EXAMPLE OF AUTOMATED TESTING USING ROBOT
1. Integrate Robot With Maven 2. Write a Simple Selenium-based Test
4. View Results3. Run Test

56. • PaaS and IaaS is exceptionally
easy to provision
• Cloud offers a large elastic pool
of resources to pull from. Not
worth the time to fix
• If you automate your
environment setup, it’s quick to
deploy more hardware
• VMs should be ephemeral -
nothing worth saving
56
IF SOMETHING BREAKS, RE-DEPLOY IT ON NEW INFRASTRUCTURE
In each cluster’s [of 10,000 servers] first year, it’s
typical that 1,000 individual machine failures will
occur; thousands of hard drive failures will occur;
one power distribution unit will fail, bringing
down 500 to 1,000 machines for about 6 hours;
20 racks will fail, each time causing 40 to 80
machines to vanish from the network; 5 racks will
“go wonky,” with half their network packets
missing in action; and the cluster will have to be
rewired once, affecting 5 percent of the machines
at any given moment over a 2-day span, Dean
said. And there’s about a 50 percent chance that
the cluster will overheat, taking down most of
the servers in less than 5 minutes and taking 1 to
2 days to recover.
Jeff Dean, Fellow, Google

57. Application Architectures
MicroServices
DevOps
* as a Service
Distributed Computing
TOPICS TO LEARN
•Consume IaaS and
PaaS
•Fault Tolerant by
Definition
•Auto-scaling
•Infinite Elasticity
57

58. 58

59. * AS A SERVICE
Requires fundamental shift in how applications are built 59
Your Code
Highly innovative,
differentiated, etc
Configuration
Caching
Load Balancing Eventing
Logging
Monitoring
Database
NoSQLState
Messaging
Building
Block
Building
Block
Building
Block
Building
Block
Building
Block
Building
Block
Building
Block
Building
Block
Building
Block
Building
Block
Building
Block
Building
Block
Where you’re not
differentiating,
consume building
blocks from 3rd party
cloud vendor

60. EVERYTHING IS NOW SOFTWARE
60
Person p = new Person();
$ docker run -v /host:/container example/myapp
curl -X POST "name=MyFirstApp" "runtime=java” "archiveURL=/binaries/myapp.zip"
$ puppet module install puppetlabs-java
Today, Everything is
100% Code.
Automation at scale
is standard
Provision a new server just like you would provision a new object in Java

61. CONTAINERS
Is it compulsion to be part of?
61

62. 62
DISPOSABILITY RULES OF 12-FACTOR APP
Start with one script
– no manual
intervention. This
script will be called
when container is
provisioned
Start up quickly – try
for under 10 seconds.
If it takes minutes,
auto-scaling won’t
work properly
Shut down cleanly
without warning.
Containers will be
killed with no
warning whatsoever

63. CLOUD NATIVE
VS
CONTAINER NATIVE
• Create highly
differentiated apps &
services
 Faster
 With high quality
 Geo reach
 Compelling CX

64. SOFTWARE LANDSCAPE IN CONTAINER ARCHITECTURE
•Container strategies are critical to digital
business
•Container based application platforms are key to
container strategies
•Container software vendor landscape is
diversified and growing fast
Source: Forrester - Master The Cloud-Native Solution Ecosystem Of Container Software 64

65. • #1 value – app packaging
• MicroServices doesn't rely
on containers but they do
help:
• Higher density
• Easy to start/stop
• Portability
• Containers are lightweight,
just like MicroServices
themselves
• Containers can run in VMs
too
65
Helpful to MicroServices but not a requirement
Hardware
Hypervisor
VM 1
OS
App
VM 2
OS
App
Hardware Virtualization
Hardware
Operating System
Hypervisor
VM 1
OS
App
VM 2
OS
App
Para-virtualization
Hardware
Operating System
Container 1
App
Container 2
App
Containers
START USING CONTAINERS

66. 66
CONTAINERS – DIFFERENT USE CASES
Hardware
Operating System
Container
App
Container
App
Container
App
Container
App
Container
App
Container
App
Container
App
Container
App
Container
App
Application Packaging
Continuous Integration DIY PaaS
Infrastructure Consolidation
Neatly package applications
and supporting environment
in immutable, portable
containers
All changes to an app are
contained in one immutable
container image. Container is tested
and deployed as one atomic unit
Get infrastructure utilization up to
100% (vs 5-10% with VMs) due to
over-subscription of resources and
near bare metal performance.
Build a simple PaaS by wiring up
containers to a load balancer.
New code, patches, etc pushed
as new immutable containers.
Hardware
Operating System
Container
App
Container
App
Container
App
Container
App
Container
App
Container
App
Container
App
Container
App
Container
App
Hardware
Operating System
Container
App
Container
App
Container
App
Container
App
Container
App
Container
App
Container
App
Container
App
Container
App
Hardware
Operating System
Container
App
Container
App
Container
App
Container
App
Container
App
Container
App
Container
App
Container
App
Container
App
Hardware
Operating System
Container
App
Container
App
Container
App
Container
App
Container
App
Container
App
Container
App
Container
App
Container
App
Hardware
Operating System
Container
App
Container
App
Container
App
Container
App
Container
App
Container
App
Container
App
Container
App
Container
App

67. STRICT REQUIREMENT: ONE INSTANCE PER CONTAINER
• Run ONE instance (unique
host/port combination) per
container
• Running multiple instances of
the same application or
different applications will
make scheduling very difficult
• Expose one port per
container
67
Physical Host
Operating System
Container
App
Container
App
Just One Per Container

68. 68
CONTAINER ORCHESTRATION
Host
Host
Host
Host
Host
Host
Host
Host
Host
Host
Container
• Inventory
Microserv
ice
• AcmeCo
• v1.2
Container
• Inventory
Microserv
ice
• AcmeCo
• v1.2
Container
• Inventory
Microserv
ice
• AcmeCo
• v1.2
Container
• Inventory
Microserv
ice
• AcmeCo
• v1.2
Container
• Inventory
Microserv
ice
• AcmeCo
• v1.2
Container
• Inventory
Microserv
ice
• AcmeCo
• v1.2
Container
• Inventory
Microserv
ice
• AcmeCo
• v1.2
Container
• Inventory
Microserv
ice
• AcmeCo
• v1.2
Container
• Inventory
Microserv
ice
• AcmeCo
• v1.2
Container
App
Container
• Inventory
Microserv
ice
• AcmeCo
• v1.2
Container
• Inventory
Microserv
ice
• AcmeCo
• v1.2
Container
• Inventory
Microserv
ice
• AcmeCo
• v1.2
Container
• Inventory
Microserv
ice
• AcmeCo
• v1.2
Container
• Inventory
Microserv
ice
• AcmeCo
• v1.2
Container
• Inventory
Microserv
ice
• AcmeCo
• v1.2
Container
• Inventory
Microserv
ice
• AcmeCo
• v1.2
Container
• Inventory
Microserv
ice
• AcmeCo
• v1.2
Container
• Inventory
Microserv
ice
• AcmeCo
• v1.2
Container
App
Many Containers
Host
Host
Host
Host
Host
Host
Host
Host
Host
Host
Many Hosts
Docker Swarm
• Map containers back to physical
hosts, taking into account user-
defined placement rules, the
utilization of each host, and the
needs of each container. Can be
very complex
• Set up overlay networking,
firewalls, ensure network QoS,
etc
• Auto-scaling
• Local and external load
balancers
• Service registry / discovery

69. 69
ADOPT AUTO-SCALING
Hardware Provisioned Without Auto-scaling
Time
Traffic
Resources Provisioned
Try to
track

70. CONTAINERS VS FUNCTIONS
• Containers
- A container image is a lightweight, stand-alone, executable package of a piece of software that includes
everything needed to run it: code, runtime, system tools, system libraries, settings.
• Functions
- Functions are blocks of code, ideally small and single-purpose. In the context of serverless, they are
coordinated and scheduled by a Functions-as-a-service (FaaS) platform such as vendor services AWS
Lambda, Azure Functions, and Google Cloud Functions, or open source frameworks such as the Fn Project
(by Oracle), OpenWhisk, and OpenFaas.
• Serverless
- A category of software design where the abstraction layer for developers is at the application tier, above
the operating system, infrastructure, and cloud IaaS API’s. In other words, developers never think about
infrastructure.
70

71. CHARACTERISTICS OF A FUNCTION
• Short Running – function live for a short amount of time and then the process ends.
• Ephemeral – the outer container running the function may only live for a single
invocation of the function.
• Stateless – function does not inherently hold any state. All state must be pushed to
structured or unstructured storage.
• Invoked – function is invoked by defined events over either HTTP, TCP, or some other
protocol.
• Single Purpose – function have a clear and defined purpose with minimal API surface
area, meaning it takes a reasonably short input, and provide a reasonably short output.
• Autonomous – function can run and serve it’s purpose by itself. Although a function is
likely just part of a broader grouping of functions, by itself, it can run independently as
long as it gets it’s required input.
71
A function packaged in a container gives us a new “atomic unit of computing”

72. ATOMIC UNIT – RELEVANT CONCEPTS
• Functions as Unit of Scaling
- Scale Up/Down at much finer grained precision than machines (precision of single process)
- Effective way of scaling of functions coupled with universal packaging/runtime of containers
• Functions as Unit of Billing
- No baseline on Servers or VMs
- Enables huge cost reduction of lightly used applications
• Functions as Unit of Design
- Functions in containers with their own contract are shareable, so that composite applications
can be built and reused
- This requires function orchestration tools
72

73. APP RUNTIME PLATFORM (APAAS)
• Useful for
 Cloud Native Application
Developers
• Value Proposition
 Let developers focus on building
awesome applications
 Platform handles the complexity
of running and scaling an
application
CONTAINER RUNTIME PLATFORM
• Useful for
 Cloud Native Ops, IT
Administrators
• Value Proposition
 Developers/DevOps collaborate
with IT Ops to deploy, scale the
applications
73
DEPLOYMENT MODELS UNDER CONTAINERS

74. APP RUNTIME PLATFORM (APAAS)
Lambda, Elastic Beanstalk
Web Apps, Functions
App Engine, Functions
Pivotal Cloud Service
OpenShift Origin
Dynos
ACCS, ACCS Functions
CONTAINER RUNTIME PLATFORM
74
DEPLOYMENT MODELS UNDER CONTAINERS - POPULAR CHOICES
Elastic Container Service
Container Service/Instance
App Engine Flex, GKE
Pivotal Container Service
OpenShift
Container Runtime
Container Engine, Functions

75. App tier
75
CLOUD NATIVE TRANSITION TO APAAS
Web tier
WebLogic Cluster
DB tier
Customer
Catalog
Order
Load
Balancer
Service
APIGateway/Security
Events
Customer Order
Catalog

76. Application Architectures
MicroServices
DevOps
* as a Service
Distributed Computing
TOPICS TO LEARN
•Multi-master
•Many Data Centers
•Many Fault
Domains
•Many Regions
•Global Server Load
Balancing
•Replication
76

77. "I don't need a hard disk in my
computer if I can get to the server
faster... carrying around these non-
connected computers is byzantine by
comparison."
- Steve Jobs
77

78. 78
EVERYTHING IS NOW DISTRIBUTED. GET USED TO IT
Applications Infrastructure Teams
Applications are now
broken up into small
microservices, with
separate frontends and
back-ends
Different data centers, fault
domains, regions, etc. Even
within the same data
center, latency may be
unacceptably high
Many small teams, each
responsible for their own
microservice. Each team is
often geographically
distributed

79. DISTRIBUTED COMPUTING
Run your applications across multiple data centers, fault domains, regions, etc79
Cloud
Region
Fault Domain
Data Center
Host
Container
Microservice
Microservice
Microservice
Microservice
Hundreds of
milliseconds
of latency
Everything is now distributed
Even within the same data center

80. 80
SMUGLY OPTION TO CHOOSE
Consistency
Each node shows the same data at all times
Availability
Each node is available for writes at all times
Partition Tolerance
Able to handle network outages
CAP Theorem – Pick Any Two
C
A P
Theory Practice
Pick One
Partition Tolerance is non-negotiable
because we have networks that can
always fail
Enterprise IT Systems: Often CP
Microservice Systems: Often AP
Each microservice can be CP, AP or
CA but the system as a whole is
always CP or AP
Pick
Any
Two
Computer science is all about tradeoffs

81. 81
MICROSERVICES FORCES MOVE TO DISTRIBUTED COMPUTING
• Distributed computing is a natural consequence of microservices because
each microservice has its own data store
• Sharing data stores across microservices introduces coupling – very bad!
• There will always be latency between microservices
• Latency leads to eventual consistency
API
Application
Datastore
Infrastructure
API
Application
Datastore
Infrastructure
API
Application
Datastore
Infrastructure
API
Application
Datastore
Infrastructure
Microservice A Microservice B Microservice C Microservice D
Monoliths don’t suffer from this

82. 82
MAKE YOUR MIDDLE TIER STATELESS
Push all state and configuration down to highly available cloud services
Application Server
File System
Application Server
File System
Application Server
File System
Application Server
File System
Application
Instance
File System
Load Balancer
Sticky to an
Individual
Instance
Application
InstanceApplication
InstanceApplication
InstanceApplication
Instance
Load Balancer
NOT Sticky to
an Individual
Instance
State
Service
Configuration
Service
Application
Instance
Key to Cloud Native
Session State
Shopping cart contents, page
view data, personalization, etc
Application Configuration
Port numbers, file system
paths, host names, etc
Legacy Cloud Native

83. 83
REMOVE ALL HARD-CODED IPS, HOST NAMES ETC.
Use service discovery, DNS, Environment
Variables etc. Everything should be dynamic

84. DevOps + * as a Service + Microservices + Distributed
Make Cloud Native Available to Everyone Else
84

85. 85