Microservices + DevOps + Oracle Cloud

= A Bright Future
Sai Janakiram Penumuru
Chief Technologist, Oracle ACE Director
 Introduction

Sai Janakiram Penumuru

o Chief Technologist Apps Transformations - DXC Technology
o Co-Fonder, Vice President - All India Oracle Users Group (AIOUG)
o Oracle ACE Director, Oracle Developer Champion
o Oracle VM SIG Leader www.oracl evmsig.org
o Blog: www.oadba.com; www.oracle12c.info
o Contacts ps.janakiram@gmail.com ; twitter - @sai_penumuru
Agenda
For 45 Minutes

Microservices
DevOps
Oracle Cloud
Microservices
What is Microservices

The first one, Microservices is a software

architecture style in which complex
applications are composed of small,
independent processes communicating with
each other using language-agnostic APIs.

The second one describes Microservices

Architecture as a style of architecture that
promotes business alignment by developing
applications as set
of small independent and self-
contained services that directly caters to
an atomic business activity.
Martin Fowler: Microservices

5
Microservices are Analogous to Unix Utilities
Same Concept, Different Decade

6
 Monolithic versus Microservices
A monolithic application
puts all its functionality
into a single module
and scales by replicating
the module on multiple
servers
A microservices
architecture puts each
element of business
functionality into a
separate service
and scales by
distributing these services,
in parallel, across servers,
replicating as needed.
7
 Single, Monolithic App
Must Deploy Entire App
One Database for Entire App
Organized around Technology Layers
One Technology Stack for Entire App
Many, smaller minimal function Microservices
Can deploy Each Microservices independently
Each Microservices often has its own Data store
Organized around Business capabilities
Choice of Technology for each Microservices 8
Fundamentally

9
Microservices Apps Are Developed/Deployed Independently

10
Conway's Law in Action
Any piece of software reflects the organizational structure that produce it

11
Successful Teams Structure their teams around Products
Build Small vertical teams

12
What is the right level
No
Lets make breakfast - objective of the use of Microservices is to increase re-use Services

INPUTS: eggs, milk, bread,

OUTPUTS: scrambled
butter, bacon, plates, 1
utensils, cookware, Make Breakfast eggs, toast, crisp bacon,
pan-fried potatoes
potatoes

Prepare 3
Cook Ingredients Serve Ingredients
Ingredients

12
Cook Bacon Cook eggs Toast Bread Fry Potatoes

Pour Remove 60
Heat Pan Stir Mixture Add Pepper
Mixture Eggs

The right level of decomposition is Business and Organization dependent.

What that entity executes as an atomic business function. 13
Characteristics of Microservices
Organized around business capabilities
Traditional Approach Microservices Approach

Presentation Layer

Application Layer

Services are organized

around business
capabilities, including
Database Layer user interface,
persistent storage and
external collaboration

14
Siloed functional Teams Cross-functional Teams
Traditional Transaction
Lets go to the pub

Tab
Open Close

A session remains open during your presence at the pub.

15
Transaction less coordination between services
The Starbucks model

Eric Rose Jim John

Short Real-time Transaction Message Queue Second, asynchronous Transaction

If something goes wrong compensating operations are used to address the issue. Failure does not
result in loss of state as Microservices are stateless.
Failure is imminent, graceful recovery is paramount.

By making the link between Microservices asynchronous, having one service going down does not
affect the operation of the other. Synchronous calls are considered harmful. If one service no longer
respond, the other keeps hanging for a response and becomes unavailable.

16
Characteristics of Microservices
Design for Failure
Traditional Approach Microservices Approach
Graceful recovery and process
resilience are mandatory in the
architecture and design of Unfortunately the XYZ
Microservices based solutions.
service is currently down,
we apologize for the
inconvenience. However
our remaining services are
500 Internal Server Error operating normally.

1. Service down, recognize the failure, spin up a new

parallel instance or do graceful degradation.
2. If the service is slow, timeout, either act (spawn a new
parallel instance to compensate for extra workload) or
report to the user the unavailability and potentially
allow him to retry.
3. Service responds with unexpected content, is your
service capable of recognizing and handling this?
Microservices must have a stable and published
contract.
4. When-ever possible, use caching mechanisms so the
service can still respond if the back-end is down.
17
What is required for Microservices?

Rapid Provisioning
Monitoring
Rapid Application Deployment
DevOps Culture

19
DevOps
Familiar?
DevOps seeks to solve this

22
Dev and Ops Constantly Argue
Code is written its your problem now

23
Shift in priorities is demanding DevOps
Waterfall

Business Dev Test Ops

Design,
Requiremen Quality Staging and
Build and
ts Assurance Production
Unit Test

Business Dev Test

Agile

Design, Build and Unit Test

Ops
Quality Assurance
Staging and
Production
0 1 2 3 4 5 6 7 Iterations

Business + Dev + Ops + Test

DevOps

One product team!

- Shared objectives, Shared customer-oriented goals, Shared accountability 24
Building a continuous application development supply chain
Create BizDevOps

Agile Ops
Biz Dev DevOps
development
fixes this
fixes this

Per What is Devops by dev2ops.org

It worked
Culture Clash
fine in dev
its ops
$^(#)*
&%$^*
!
problem now

DEV OPS
Todays application delivery is full of obstacles and challenges

One way flow

Manual
Testing
increases InfoSec &
Lack of effective latency or Poor confidence compliance patch in
customer insight drives in test data engaged late production
and high latency Isolated build limited fosters release driving leads to
drives kitchen Rapidly increasing and integration test High # aversion driving vulnerabilities & snowflake Revenue
sink requirements WIP processes coverage defects more WIP re-work systems External
$
customers

Business
Planning
App
App Testing
Release
App release Deployed App
The Poor
user
Demand Development decision Market
experience

Long waiting time to setup and $

test environments Internal
Customers
Manual and error prone app deployments
Costs

Error prone manual hand-offs and processes

Siloed Teams, Lack of end to end visibility

27
 Technology Stack - Tools
32
Change in Culture
Resistance to
Directive Task Focused Dedicated Roles Manual Project Focused
Change
Development Life Cycle

Long and rigid Step-by-step delivery Departmentalized Changes are Slow and costly Working in silos leads
planning process in a waterfall or roles working in silos problematic as they manual deployments to a narrow view
Traditional IT

related to current and production line and throwing jobs need re-defining, re- and implementations aligned with limited
historical needs approach over the wall scheduling and re- or initial
working, leading to requirements
delays and increased
costs
Define
Build
Test
Release
Run

Responsive to
Adaptive Goal Focused Teamwork Automated Business Focused
Change
Development Life Cycle

React and responds to A business oriented Collaborative and Agile methods quickly Automated Working in teams
Agile/DevOps

changing needs approach and attitude integrated methods to identify areas for deployment tools and leads to a holistic view
constantly which sees the bigger empower teams change or virtualized in line with todays
picture across the business improvements environments to business needs
and the client accelerate releases

Define Build Test Define Build Test Define Build Test Define Build Test Define Build Test

Run Release Run Release Run Release Run Release Run Release

33
Why Do DevOps?
enabling faster feature time to market
increased customer satisfaction & market share
employee productivity and happiness
organizations to win in the marketplace
In contrast, organizations that require weeks or months to deploy software are at a significant disadvantage in the marketplace.

34
PaaS/IaaS Now Allows Resources to be Easily Provisioned

35
DevOps Principles
Cultural movement enabled by technology

36
Characteristics of DevOps Movement
Principles have been around for decades

37
DevOps = Culture + Technology Movement
Culture is whats behind DevOps; Technology is the enabler

38
DevOps Tenet #1: Culture

39
Build Respect

40
Discuss

41
Avoid Blaming

42
Actively Build Trust
Trust is the #1 ingredient to a successful DevOps culture

43
DevOps Tenet #2: Technology

44
Infrastructure as Code
Manage it as you would any other source code

45
Shared Version Control
Surprisingly not well adopted

46
One Step Build/Deploy
Set it and forget it

47
Automated Testing using Robot

48
Core Tools required

49
Where to use DevOps
Analyze your portfolio

50
Oracle Cloud
Oracle can help you Lead change in your Organization

53
Oracle Products support DevOps

54
Oracle Developer Cloud Service Whats In It

55
 Development Experience
Oracle Developer Cloud Service

Effortless Project Management

Teamwork Through Integrated Tools
What You Need, Before You Need It
From Just an Idea, to Product Release

56
Project Management

Team members
Activity stream
Usage tracking
Repositories
Custom attributes

57
Requirements/Issue Tracking

Create Requirements/Bugs/ERs
Assign to team members and sprints
Custom attributes

58
Agile Process Management

Create dashboard
Manage issues backlog
Manage development sprints
View team/tasks status
Reports

59
 Source Code Management

Git repositories
Branch, tag, merge
Web interface
View changes online
Accessible from any Git client
External repositories integration
(for example GitHub)
Snippets for reusable code

60
Code Reviews

Request code review

Invite team members
Comment on Code
Accept / Reject / Iterate Reviews
Merge Code
Merge Conflict Resolution

61
Project Builds

Maven
Ant
Gradle
Node.JS npm, grunt, bower, gulp
Dashboard
Logs and Audit

62
Deployment Automation

Create deployment configurations

Start/Stop a deployment
Redeploy/Un-deploy applications
In the cloud or on premise deployment

63
Continuous Integration

Hudson
Automate
Triggers
Schedule
Dashboard

64
Wikis

Share information
Attachment support
Wiki markup of choice

65
Merger of disciplines
Iterative Planning, Development and Release

66
Q&A
Thank you
Sai Penumuru
Contacts ps.janakiram@gmail.com ; twitter - @sai_penumuru