The document discusses the shift towards cloud native application development. Some key points discussed include: 1. Cloud native originated in customer-facing tech companies and emphasizes building applications in, for, and maximizing the benefits of the cloud. 2. When developing new applications, organizations should focus on functional and non-functional requirements to determine the appropriate architecture, runtime environment, and degree of "cloudiness". 3. Cloud native development requires learning new topics like microservices, DevOps, serverless computing, and distributed systems.

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

2. CLOUD NATIVE
ORIGINATED
IN
CUSTOMER FACING
TECH COMPANIES

3. VOICE OF THE VENDORS

4. 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

5. 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

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

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

8. — 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

9. 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

10. 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
….

11. Adam Wiggins
https://12factor.net/
Co-Founder of Heroku Cloud• 12 Factor App principals
are commonly viewed as
defining Cloud Native
• 12 Factor makes sense for
new applications but hard
to retrofit to existing
applications

12. LEGACY ARCHITECTURES
12
Source: Software Architecture Patterns by Mark Richards
Layered Architecture Event Driven Architecture Micro Kernel Architecture
ANALYSIS Overall Agility Deployment Testability Performance Scalability Development
Layered      
Event Driven      
Micro Kernel      

13. SERVICE BASED ARCHITECTURE
MicroServices
Service Oriented Architecture
Service Oriented Integration

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

15. “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

16. 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

17. USE A HIGHER LEVEL OF REST
17
REST 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

18. 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
18

19. 19
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

20. 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

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

22. GARTNER DEVOPS MODEL - CATALOG OF DEVOPS PRACTICES
22
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.

23. 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
23
• 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

24. 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
24

25. 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
25

26. DEVOPS PATTERNS AND TOOLSET AVAILABLE IN MARKET
26
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

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

29. * AS A SERVICE
Requires fundamental shift in how applications are built 29
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

30. EVERYTHING IS NOW SOFTWARE
30
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

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

32. • #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
32
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

33. 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
33
Physical Host
Operating System
Container
App
Container
App
Just One Per Container

34. 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

35. "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

36. DISTRIBUTED COMPUTING
Run your applications across multiple data centers, fault domains, regions, etc36
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

37. 37
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 about tradeoffs

38. 38
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

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