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 – [email protected] ; 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