Microservices + DevOps + Oracle Cloud = A Bright Future · What is Microservices 5 • The first...

Microservices + DevOps + Oracle Cloud = A Bright Future

Sai Janakiram PenumuruChief Technologist, Oracle ACE Director

Introduction

Sai Janakiram Penumuruo Chief Technologist – Apps Transformations - DXC Technologyo Co-Fonder, Vice President - All India Oracle Users Group (AIOUG)o Oracle ACE Director, Oracle Developer Championo Oracle VM SIG Leader www.oracl evmsig.orgo Blog: www.oadba.com; www.oracle12c.infoo Contacts – ps.janakiram@gmail.com ; twitter - @sai_penumuru

AgendaFor 45 Minutes

–Microservices

–DevOps

–Oracle Cloud

Microservices

What is Microservices

5

• 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

Same Concept, Different DecadeMicroservices are Analogous to Unix Utilities

6

Monolithic versus Microservices

7

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.

8

• 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

Fundamentally

9

Microservices Apps Are Developed/Deployed Independently

10

Conway's Law in Action

11

Any piece of software reflects the organizational structure that produce it

12

Successful Teams Structure their teams around ProductsBuild Small vertical teams

What is the right levelLet’s make breakfast - objective of the use of Microservices is to increase re-use

13

Make Breakfast

Prepare Ingredients

Cook Ingredients Serve Ingredients

Cook Bacon Cook eggs Toast Bread Fry Potatoes

Heat PanPour

MixtureStir Mixture Add Pepper

Remove Eggs

INPUTS: eggs, milk, bread, butter, bacon, plates, utensils, cookware, potatoes

OUTPUTS: scrambled eggs, toast, crisp bacon, pan-fried potatoes

3

12

60

1

No Services

The right level of decomposition is Business and Organization dependent. What that entity executes as an atomic business function.

Characteristics of MicroservicesOrganized around business capabilities

14

Traditional Approach Microservices Approach

Presentation Layer

Application Layer

Database Layer

Services are organized around business capabilities, including user interface, persistent storage and external collaboration

Siloed functional Teams Cross-functional Teams

Traditional TransactionLet’s go to the pub

15

Tab

Open Close

A session remains open during your presence at the pub.

Transaction less coordination between servicesThe Starbucks model

16

JohnJimRoseEric

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.

Characteristics of MicroservicesDesign for Failure

17

Traditional Approach Microservices Approach

500 Internal Server Error

Unfortunately the XYZ service is currently down,

we apologize for the inconvenience. However

our remaining services are 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.

Graceful recovery and process resilience are mandatory in the architecture and design of Microservices based solutions.

What is required for Microservices?

19

Rapid ProvisioningMonitoringRapid Application DeploymentDevOps Culture

DevOps

DevOps seeks to solve thisFamiliar?

22

Code is written… it’s your problem nowDev and Ops Constantly Argue

23

Business + Dev + Ops + Test

TestDev

Shift in priorities is demanding DevOps

24

Wat

erfa

llA

gile

Dev

Op

s

Dev Test OpsBusinessRequiremen

ts

Design, Build and Unit Test

Quality Assurance

Staging and Production

Business

Design, Build and Unit Test

Quality Assurance

0 1 2 3 4 5 6 7 Iterations

OpsStaging and Production

One product team!- Shared objectives, Shared customer-oriented goals, Shared accountability

Building a continuous application development supply chainCreate “BizDevOps”

BizAgile

development fixes this

DevOps fixes this

OpsDev

Per “What is Devops” by dev2ops.org

DEV OPS

It worked fine in dev… it’s ops’ problem now

$^(#)*&%$^*

!Culture Clash

Siloed Teams, Lack of end to end visibility

Error prone manual hand-offs and processes

Manual and error prone app deployments

Long waiting time to setup and test environments

Today’s application delivery is full of obstacles and challenges

Lack of effective customer insight and high latency drives “kitchen

sink” requirementsRapidly increasing

WIP

Poor confidence in test data

fosters “release aversion” driving

more WIP

Isolated build and integration

processes

Manual Testing

increases latency or

drives limited

test coverage

“patch in production”

leads to snowflake

systems

InfoSec & compliance

engaged late driving

vulnerabilities & re-work

High # defects

One way flow

App Testing

Internal Customers

External customers

PlanningApp

DevelopmentApp release Deployed App

Business Demand

Release decision

The Market

$

Revenue$

Costs

Poor user

experience

27

– Technology Stack - Tools

32

Change in Culture

33

Tra

dit

ion

al I

T

Dev

elo

pm

ent

Lif

e C

ycle

Agi

le/D

evO

ps

Dev

elo

pm

ent

Lif

e C

ycle

Directive

Long and rigid planning process related to current and historical needs

Task Focused

Step-by-step delivery in a waterfall or production line approach

Dedicated Roles

Departmentalized roles working in silos and throwing jobs over the wall

Resistance to Change

Changes are problematic as they need re-defining, re-scheduling and re-working, leading to delays and increased costs

Manual

Slow and costly manual deployments and implementations

Project Focused

Working in silos leads to a narrow view aligned with limited or initial requirements

Define

Build

Test

Release

Run

Adaptive

React and responds to changing needs constantly

Goal Focused

A business oriented approach and attitude which sees “the bigger picture”

Teamwork

Collaborative and integrated methods to empower teams across the business and the client

Responsive to Change

Agile methods quickly identify areas for change or improvements

Automated

Automated deployment tools and virtualized environments to accelerate releases

Business Focused

Working in teams leads to a holistic view in line with todays business needs

ReleaseRun Release Release Release Release

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

Run RunRun Run

Why Do DevOps?

– enabling faster feature time to market

– increased customer satisfaction & market share

– employee productivity and happiness

– organizations to win in the marketplace

34

In contrast, organizations that require weeks or months to deploy software are at a significant disadvantage in the marketplace.

PaaS/IaaS Now Allows Resources to be Easily Provisioned

35

Cultural movement enabled by technologyDevOps Principles

36

Principles have been around for decadesCharacteristics of DevOps Movement

37

Culture is what’s behind DevOps; Technology is the enablerDevOps = Culture + Technology Movement

38

DevOps Tenet #1: Culture

39

Build Respect

40

Discuss

41

Avoid Blaming

42

Trust is the #1 ingredient to a successful DevOps cultureActively Build Trust

43

DevOps Tenet #2: Technology

44

Manage it as you would any other source codeInfrastructure as Code

45

Surprisingly not well adoptedShared Version Control

46

Set it and forget itOne Step Build/Deploy

47

Automated Testing using Robot

48

Core Tools required

49

Analyze your portfolioWhere to use DevOps

50

Oracle Cloud

Oracle can help you Lead change in your Organization

53

Oracle Products support DevOps

54

Oracle Developer Cloud Service – What’s In It

55

Oracle Developer Cloud ServiceDevelopment Experience

56

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

Project Management

57

• Team members• Activity stream• Usage tracking• Repositories• Custom attributes

Requirements/Issue Tracking

58

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

Agile Process Management

59

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

Source Code Management

60

• 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

Code Reviews

61

• Request code review• Invite team members• Comment on Code• Accept / Reject / Iterate Reviews• Merge Code• Merge Conflict Resolution

Project Builds

62

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

Deployment Automation

63

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

Continuous Integration

64

•Hudson•Automate–Triggers–Schedule•Dashboard

Wikis

65

• Share information• Attachment support• Wiki markup of choice

Iterative Planning, Development and ReleaseMerger of disciplines

66

Q & A

Thank youSai Penumuru

Contacts – ps.janakiram@gmail.com ; twitter - @sai_penumuru