Microservices + Oracle: A Bright Future

Copyright © 2016, Oracle and/or its affiliates. All rights reserved.
Microservices + Oracle | A Bright Future
Kelly Goetsch
Director, Product Management
January 28th 2016

Safe Harbor Statement
The following is intended to outline our general product direction. It is intended for
information purposes only, and may not be incorporated into any contract. It is not a
commitment to deliver any material, code, or functionality, and should not be relied upon
in making purchasing decisions. The development, release, and timing of any features or
functionality described for Oracle’s products remains at the sole discretion of Oracle.
2

Program Agenda
Introduction
History of Microservices
Non-technical Prerequisites
Architectural Prerequisites
Technical Prerequisites
Implementing Microservices
How Oracle Products Support Microservices
Summary
1
2
3
4
5
3
6
7
8

Introduction
4

Copyright © 2016, Oracle and/or its affiliates. All rights reserved. 5
Monolithic Applications
Single, Monolithic App
Must Deploy Entire App
One Database for Entire App
Organized Around Technology Layers
State In Each Runtime Instance
One Technology Stack for Entire App
In-process Calls Locally, SOAP Externally
Microservices
Many, Smaller Minimal Function Microservices
Can Deploy Each Microservice Independently
Each Microservice Often Has Its Own Datastore
Organized Around Business Capabilities
State is Externalized
Choice of Technology for Each Microservice
REST Calls Over HTTP, Messaging, or Binary
What Are Microservices?
Minimal function services that are deployed separately but can interact together to
achieve a broader use-case

Microservices Are Analogous to Unix Utilities
6
Same concept, different decade
Doug McIlroy
Inventor of the Unix Pipe
“Write programs that do one thing and do it well. Write
programs to work together. Write programs to handle text
streams, because that is a universal interface.”
curl -v -H "Accept: application/json” -H "Content-type: application/json” -X POST
-d ’{"productId":645887","quantity":"1"}'
"http://localhost:8840/rest/ShoppingCart/”
• Unix Executable: Does one thing and does it well
• Runs independent of other commands
• Produces text-based response
• Microservice: Does one thing and does it well
• Runs independent of other microservices
• Produces text-based response to clients

Microservices Apps Are Developed/Deployed Independently
7
User Interface
Application
Datastore
Infrastructure
Status Quo
One Application
Microservices
Many Small Microservices
API
Application
Datastore
Infrastructure
Inventory
Microservice
API
Application
Datastore
Infrastructure
Payment
Microservice
API
Application
Datastore
Infrastructure
Profile
Microservice
API
Application
Datastore
Infrastructure
Product Catalog
Microservice

Owners
Support in
Production
Every Team
Service Has
an Owner
Owners
Implement
Owners
Architect
Owners
Care
Owners Can
Fix Things
Ownership is Key
to the Success of
Microservices
In traditional enterprises, anyone individual
has very low ownership of anything. It’s classic
tragedy of the commons
8Copyright © 2016, Oracle and/or its affiliates. All rights reserved.

Fundamentally, Microservices is a Tradeoff
9
Easier Deployment/Ops Easier Development
Do you want...
Traditional App Development Microservices
• One big block of code,
sometimes broken into semi-
porous modules
• Complexity handled inside
the big block of code
• Each big block is hard to
develop but easy to deploy
• Many small blocks of code,
each developed and deployed
independently
• Complexity encapsulated in
each microservice
• Each microservice is easy to
develop but hard to deploy

1. 100+ developers for an app
2. 5m lines of code for an app
3. Monthly or quarterly releases to production
4. > 1 quarter backlog of development work
5. > 20% developer turnover
Top 5 Signs It’s Time To Look at Microservices

Common Microservice Adoption Use Cases
11
I want to extendmy existing
monolithic application by adding
microservices on the periphery.
I want to decompose
an existing modular application into
a microservices-style application
I want to build a net new
microservices-style application
from the ground up.

Sometimes Monolithic Applications Are Still a Good Fit
• For less complex applications,
monoliths are always better in both the
long and short-run
• For moderately complex applications,
monoliths are still probably better in
both the long and short-run
• For complex apps, microservices may
pay off over time but it takes a long
time to offset the high up-front
investment required to do it
12
Microservices add complexity
Time
Complexity
Complexity Over Time

Do One Thing and
Do It Well
Focus on Business
Capabilities
Avoid Inter-
dependencies
How Big Should a Microservice Be?
Can have hundreds of microservices for a larger application
Large
Medium
Small
11-15 People
Example: Order Microservice
4-10 People
Example: Inventory Microservice
1-3 People
Example: Order Status Microservice
13

Small Teams = Much Better Communication
14
Low Latency/High Bandwidth Communication
Legacy Microservices

Definitive Guide to Deciding Microservice Size
• Bounded Context is a central pattern in
Domain-Driven Design
• Deals with designing software based on the
underlying domain
• You can't build a big unified domain model for
an entire system
• Divides a large system into Bounded Contexts,
each of which can have a unified model
15
Domain-Driven Design: Tackling Complexity in the Heart of Software by Eric Evans

“Micro” in Microservices != Runtime Weight
16
Microservices tend to use smaller runtimes but you can use what you have today
Middleware
Module 1 Module 2 Module N
Datastore
Must support the
requirements of
ALL modules
Fully Featured Runtimes
That Support All Use Cases
Middleware
Module 1
Datastore
Must support the
requirements of
one module
Light Runtimes That
Do One Thing
Monoliths Microservices

You’re Doing Microservices If You...
17
Can build a
microservice
independently
Can release each
microservice
independently
Don’t share a
datasource across
microservices

Technical Complexity
• Microservices doesn't
eliminate complexity - it
just moves it and often
adds to it
• Monolithic applications
allow you to deal with
complexity in one body of
code
• Forces move to
distributed computing
Effort
• Testing, logging,
monitoring, security,
versioning, etc all become
much harder
• Polyglot exponentially
increases the number of
lifecycles required
• A lot of duplicated effort
since each team is
independent and goal is
to minimize
dependencies
18
Organization
• Most organizations are
organized around
horizontal technology
layers – need to build
small product-focused
teams
• Much higher skills
required
• Many developers will not
want to do production
support
Microservices Are Not a Panacea

History of Microservices
Microservices go way back
19

Microservice Principles Have Been With Us For Decades
20
The principles behind microservices are
often just good architecture principles
Loose
Coupling
Focus on Business
Capabilities, Not
Technology Layers
Reduce Complexity
Through
Modularization
Do One Thing and
Do It Well

History of Microservices as a Term
• First Google search of "microservices" occurred in October of 2013
- expanded exponentially from there
• Began in the mid to late 2000's as a reaction against monoliths and
against traditional SOA
• No one person is credited with inventing the term or popularizing
it. It was an idea whose time had come
21
A trend without a name, until “microservices” was used in 2013

SOA vs. Microservices
22
SOA is the general idea, where microservices are a very specific way of achieving it
 Favors centralized orchestration
 Needlessly complicated by SOAP
 “Dumb endpoints, smart pipes”
SOA
Microservices
 Favors distributed choreography
 REST + HTTP/S = simple
 “Smart endpoints, dumb pipes”
1. Keeping consumption of services separate from the
provisioning of services
2. Separating infra management from the delivery of
application capability
3. Separating teams and decoupling services
Implementation Differences
All of the tenets of SOA also apply to microservices

SOA vs. Microservices Misconceptions
23
“Microservices removes the need
for an Enterprise Service Bus”
Don’t confuse the product with the pattern
“Microservices solves the problems
of SOA”
Don’t confuse improper SOA
deployments as problems with SOA
“Companies like Netflix and
LinkedIn use microservices, so we
should too”
Netflix and LinkedIn are in the platform
business. Is that your business too?
“We must choose microservices, or
SOA”
Use both

SOA Still Reigns Supreme
24
SOA isn’t going anywhere
“Microservices”
“SOA”

Microservice Principles Are Old; Implementation is New
Microservices is not just rebranded SOA
• Teams independently architect, develop, deploy and maintain each microservice
• Each microservice often has its own datastore, which may not always be 100% up-to-date
• Microservices is fully decentralized - no ESBs, no single database, no top-down anything
• Responses from microservices are not manipulated by an intermediary, like an ESB
• Microservices favors simple transports - XML or JSON over HTTP/S. No SOAP
• Any given instance of a microservice is stateless - state, config, and data pushed externally
• Microservices support polyglot - each microservice team is free to pick the best technology
• DevOps principles - automated setup and developers owning production support
• Use of containers, which allow for simple app packaging and fast startup time
• Use of cloud, for the elastic infrastructure, platform and software services

26

Conway’s Law
27
“Any piece of software reflects
the organizational
structure that produced it”
Melvin Conway
1968

Conway’s Law In Action
28
Any piece of software reflects the organizational structure that produced it
User Interface
Application
Datastore
Infrastructure
Resulting SoftwareTypical Enterprise Organization Structure
Head of IT
Head of
Operations
Head of DBAs
Head of
Infrastructure
Head of App
Dev
Head of UI
Head of
Development
An Enormous Monolith

Characteristics of Different Organization Types
29
 Produce microservices
 Small teams can make any change
they want to an individual
microservice
 Architecture clean because
developers have 100% control
 True ownership
 Produce monoliths
 Simple change requires extensive
coordination across all of the
different layers
 Business logic is spread
everywhere because it’s easier to
bury it in the layer you own
 No real ownership
Centralized Organizations
Focused on Technology Layers
Distributed Organizations
Focused on Products

Successful Teams Structure Their Teams Around Products
30
Build small vertical teams
Resulting SoftwareMicroservices Organization Structure
Product
Lead
Developer Sys Admin DBA
JavaScript
Developer
Many Small Microservices
Developer
Developer
Sys Admin
Storage Admin
Graphic ArtistNoSQL Admin
API
Application
Datastore
Infrastructure
API
Application
Datastore
Infrastructure
API
Application
Datastore
Infrastructure
API
Application
Datastore
Infrastructure

Horizontal -> Vertical Teams
Oracle Confidential – Internal/Restricted/Highly Restricted 31

Standardize Where it Makes Sense. Be Pragmatic
32
Teams do not have 100% freedom
Custom Code
Communication Protocol
Data Format
Infrastructure
Datastore
SourceControl
ConfigurationManagement
DevelopmentTooling
Alerting
Monitoring
Standardize on One
Offer a Menu of 2-3 Options
Team Has Complete Choice
Programming Language
Messaging

Each Team Should Treat Other Teams as External Vendors
• Clear interfaces
• Clear SLAs
• Chargeback
33
Good fences make good neighbors
Microservice A Microservice B

DevOps Must Also Be Adopted Prior to Microservices
34
Mostly a function of culture
Culture Technology
Respect
Discuss
Avoid Blaming
“Done” Means
Released
Infra as Code
Shared Version
Control
One Step
Build/Deploy
Don’t Fix
Anything
• Dev respect for ops
• Ops respect for dev
• Ops should be in dev discussions
• Dev should be in ops discussions
• Shared runbooks
• No fingerpointing!
• Everyone should have some
culpability
• Dev’s responsibility shouldn’t ever
end – production support required
• “Throwing it over the wall” is dead
• Don’t build envs by hand
• Scripts checked in and
managed as src
• Single system
• Ship trunk
• Enable features through flags
• One button build/deploy
• If verification fails, stop and
alert or take action
• If something breaks, re-deploy.
Don’t fix
• Fix environment setup scripts

More About DevOps
http://www.slideshare.net/KellyGoetsch/mastering-devops-with-oracle

36

Microservices Forces Move To Distributed Computing
37
Introduces enormous complexity – monoliths don’t suffer from this
API
Application
Datastore
Infrastructure
API
Application
Datastore
Infrastructure
API
Application
Datastore
Infrastructure
API
Application
Datastore
Infrastructure
Microservice A Microservice B Microservice C Microservice D
• Distributed computing is a natural consequence of microservices
because each microservice has its own datastore
• Sharing datastores across microservices introduces coupling – very bad!
• There will always be latency between microservices
• Latency = eventual consistency
• All data exchange between
microservices must be
through API layer or
messaging – no accessing
datastores cross-
microservices
• Must implement high-
speed messaging between
microservices. REST + HTTP
probably isn’t fast enough
• May end up duplicating
data across datastores –
e.g. a customer’s profile

Rules of Distributed Computing
38
Computer science is about tradeoffs
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 APMore Information
Pick
Any
Two

Microservices Usually Forces Eventual Consistency
39
Synchronous communication leads to availability and performance problems
API
Application
Datastore
Infrastructure
API
Application
Datastore
Infrastructure
API
Application
Datastore
Infrastructure
API
Application
Datastore
Infrastructure
Self Service Help Inventory Customer Profile Payment
Initiate
Return
Increment
Inventory
Document
Refund
Refund
Money
Customer Logs in to Self Service.
Accidentally ordered three
widgets, not the two he wanted.
Returns one of the widgets
Each Microservice Receives the Change and Saves it to Its Datastore
OneApplication

Synchronous Calls With Microservices Are Very Bad
40
Product Catalog Product Pricing Inventory
Chaining == coupling == downtime
The availability of microservice A depends on B, B depends on C, etc

Avoid Synchronous Calls for Read-only Data By Copying
41
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

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
42
Choreography Tends to Be Better Than Orchestration

Orchestration vs. Choreography

Scenario: eCommerce user returns a widget through web-facing .com
Example of Orchestration
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

Scenario: Inventory microservice
Example of Choreography
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...

Best to Ship Your Applications Headless
Put your front and back ends in different clouds, different geographies
Design, develop, deploy and manage your front and back ends differently
46
API
Application
Datastore
Infrastructure
API
Application
Datastore
Infrastructure
API
Application
Datastore
Infrastructure
API
Application
Datastore
Infrastructure
BackEnd
Add to Cart Inventory Product Details Search
FrontEnd
API Gateway
Web Content
Management System
Custom Application
Very Different
Requirements
• Security
• Elasticity
• Performance
• Traffic patterns
or

Make Your Middle Tier Stateless If You Can
47
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
Current Cloud Native

Remove All Hard-coded IPs, Host Names, etc
48
Use service discovery, DNS, etc instead. Everything should be dynamic

<credit>
<amount>100</amount>
<forAccount>1234</account>
<creditMemoID>4567</creditMemoId>
</credit>
<credit>
<amount>100</amount>
<forAccount>1234</account>
</credit>
Modify Messaging To Be Less Fragile
49
Messages should be constructed to be able to be applied over and over
Not Idempotent Idempotent
• Can execute exactly once
• Works fine in a monolith
• Will break with microservices
• Can execute many times
• Works fine in monolith and microservices
• Allows the pipes to be dumb – message
just needs to be applied once
Best For Microservices
* Idempotent = the outcome doesn’t change after the first application

Approaches to Synchronous Network Calls
50
XML/JSON Over HTTP Binary Over Wire
Primary Use
Communicating with clients over
the public internet
Communicating with other
microservices over a private network
Pros
 Universally understood format
 Easy to implement and
understand
 Very fast
Cons  Slow since it’s text-based  Can be hard to implement
Implementations
 No special software required –
natively supported by all major
programming languages
 HTTP is the language of the
web!
 Oracle Portable Object Format
 Google Protocol Buffers
 Apache Avro
 Apache Thrift

REST: Representational State Transfer
51
Strongly associated with microservices but not a technical requirement
HTTP
REST
XML or JSON
HTTP
Response
Codes
• Much simpler alternative to SOAP
• Uses GET, POST, PUT, DELETE, etc – just
like web browsers do
• Synchronous inter-microservice
communication often occurs over binary
• Can version APIs - /v1.2/customer
• Can use XML or JSON
– XML is often better - supports XPath, CSS
selectors
• Can't generate strongly typed stubs
REST =

Microservices Requires a Higher Level of REST Use
52
Oracle fully supports level 3
• Level 0
– Use HTTP as a tunneling mechanism only
– Interact with /OrderService
– Use HTTP GET/POST only
• 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">

Message Compatibility Across Versions
53
Design for backwards compatibility
<product>
<id>329340224</id>
</product>
API
Application
Datastore
Infrastructure
v1.1
API
Application
Datastore
Infrastructure
v1.2
Send update to Product
Catalog microservice
<product>
<id>329340224</id>
<shipToStore>true</shipToStore>
</product>Send update to Product
Catalog microservice but
v1.2 adds a new required
property
Don’t make properties required!
Assume any given microservice has two or more different
versions running concurrently. Build for backwards compatibility

54

Requirements for Microservices Implementation
55
Microservices
Security ScalingMonitoring
Eventing LoggingMessaging
Service Discovery ConfigurationSecurity
Service Registry API GatewayAPI Load Balancer Generally Recommended
for Microservices

Key Microservices Technology – Service Registry
• Manages the lifecycle of each
microservice endpoint
– Newly-instantiated endpoints
register with Service Registry
– Service Registry continually polls
each endpoint’s health
• Aware of tenants, microservice
versions, and environments
– Health checking and selecting the
most appropriate endpoint are
very much dependent upon the
tenant, version, and environment
– Can query for an endpoint based
on those attributes
56
API Load Balancer
What’s the best
endpoint to use
for microservice
X?
Client HTTP
request
Service Registry
Java SE Cloud Service
(instances 1...N)
Node Cloud Service
(instances 1...N)
Compute Cloud Service
(instances 1...N)
Runtime X
(instances 1...N)
Just
added a
new
endpoint
Runtime InstancesMicroservice Infrastructure
Java Cloud Service
(instances 1...N)

Key Microservices Technology – API Load Balancer
• Matches each request to the
best endpoint
• Queries Service Registry to
determine the best endpoint
• Ideally stateless – looks up the
best endpoint for each HTTP
request
• Uses load balancer or web server
as the core. Typical
implementations are customized
Oracle Traffic Director, Nginx, or
Apache mod_rewrite
• Handles logging, request rate
limiting, authentication
57
API Load Balancer
What’s the best
endpoint to use
for microservice
X?
Client HTTP
request
Service Registry
Java SE Cloud Service
(instances 1...N)
Node Cloud Service
(instances 1...N)
Compute Cloud Service
(instances 1...N)
Runtime X
(instances 1...N)
Just
added a
new
endpoint
Runtime InstancesMicroservice Infrastructure
Java Cloud Service
(instances 1...N)

API Gateways Load Balance and Aggregate Responses
58
API gateways provide a "backend for each frontend"
Client
Public Internet
Microservice Microservice Microservice
Data Center
API Gateway
• 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
• Common solutions: Netty, Vertex, Nginx,
Kong, Apigee

API Load Balancer vs. API Gateway
 Matches each request to the
best endpoint
API Load Balancer
 Queries Service Registry to
 Handles logging, request rate
 Matches each request to the best
endpoint
 Queries Service Registry to
 Handles logging, request rate
 Aggregates the responses of many
microservices
API Gateway
API Load Balancers are missing aggregation
but...
It’s best to build a microservice that does aggregation. Keep the
API Load Balancer or Gateway as free of business logic as possible

Service Discovery – Generally Not a Problem With Monoliths
60
Requirements
 Must resolve:
- Host/port
- Version for each microservice
 Must be discoverable
Because
 Many microservices in an environment
 Many environments
 Many versions of each microservice
 Hosts/ports can change quickly
 It’s not practical to manage by hand
Approaches Include
 Plain DNS - limited to IP only
 SRV DNS records - gives IP + port
 Hierarchical namespaces
 Instance tagging in the cloud
Solutions Include
 Any DNS provider
 Consul
 Zookeeper
 Custom coding to search instance tags

Microservices Requires Robust Messaging
61
Both traditional durable messaging and non-durable eventing
Microservice
Microservice
Microservice
Microservice
• Message broker can buffer
messages until the consumer
is able to process them –
prevents synchronous
coupling which leads to
outages
• “Smart endpoints, dumb pipes” is the
philosophy of microservices – messaging should
just pass messages. Not manipulate them
• Should support a variety of communication patterns
including one-way requests and publish-subscribe
Why Use Messaging?
Requirements for Messaging
Types of Messaging
Normal Messaging
• Durable, ordered
• Relatively low throughput
• Usually brokered
• Often used to keep the data
across different microservices
in sync, as each microservice
has its own data store
Eventing
• Non-durable, un-ordered
• Very high throughput
• Usually non-brokered
• Often used to distribute notification
events – scale up, scale down, etc

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
62
Cascading failures are more common with microservices

Emit Logs as Event Streams
63
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
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
Capture, Aggregate, Search, Troubleshoot, etc

Private Subnet
Security: Requires New Paradigms to Properly Secure
64
More microservices, more principals, more technologies, more everything
Client
Microservice Microservice
API Gateway
Public Internet
Data Center
• HTTPS
• HTTPS Basic
• Client certificates
• Public/private keys
• SAML
• OpenID Connect
Datastore Datastore
Private Subnet
• HTTPS
• Must authorize and authenticate
every single principal – best to
use common approach
• Monolithic apps typically do
authentication and authorization
on their own
• Secure every single remote
network call
• Use network segmentation to
isolate microservices from each
other

Microservices Complicates Testing
65
More code, more microservices to test
Acceptance Testing Usability Testing Component Testing
Did we build the right
thing? Do business
requirements make
sense?
Performed manually
directly by business
users
Entire system is
tested using end-
clients
How usable is the
system? Will end-
users like it? Is it fast
enough?
Performed manually
by business users
Entire system is
tested using end-
clients
Does each
microservice work in
isolation? Is it fast
enough?
Performed
automatically with
each microservice
release
Each microservice is
tested in isolation.
Dependencies
stubbed out
Does each fragment
of code work in
isolation?
Performed
automatically with
each build
Each method, or
similar fragment is
captured
Unit Testing
Frequency of Testing

What/How To Monitor
66
Monitoring a monolith is relatively easy – one app. Microservices = many apps
Requirements for Monitoring Microservices
1. Monitor throughput, performance,
and business metrics
2. Trace each end-request through
every microservice – end-to-end
3. Track the health of downstream
dependencies
4. Monitor each process, OS, host, etc Dropwizard Metrics
Popular Tooling

Containers Make Microservices Easier
67
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
• #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

Many See Containers As the Standard
68
Four main use cases
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
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
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.

Containers Should Be Immutable
69
Patches to
System Software
New Version of
Application
Configuration
Changes
Build and deploy a new container
Never touch a container that’s already been built

One Instance Per Container is Typical
• Best to 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
70
Physical Host
Operating System
Container
App
Container
App
Just One Per Container

How Do You Deploy Containers to Physical Hosts?
71
The emerging space of container orchestration
What Do Container
Orchestration Solutions Do?
• 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
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
Emerging space. Solutions are very early and lack any real
notion of an application. Still very much infrastructure-focused

Artifacts Are Now Immutable Containers – Not EARs, WARs
72
Containers can have anything in them and are highly portable
Hardware
Operating System
Hypervisor
VM 1 VM 2
Current
Hardware
Operating System
Container 1 Container 2
Cloud Native
• No more installing a JVM,
app server, and then
deploying the artifacts to
them
• Build the container once,
deploy it anywhere. Can
include complex
environment variables,
scripts, etc
• Containers should be free of
state and configuration
• Containers should not
assume they are able to
write to a persistent local
file system
OS
App Server
EAR/WAR
OS
App Server
EAR/WAR The Artifact You Deploy

Constantly Deploy Each Microservice
73
No need to batch together many changes to single app
One Application Many Microservices – Deploy Many Times/Day
API
Application
Datastore
Infrastructure
Inventory
Microservice
API
Application
Datastore
Infrastructure
Payment
Microservice
API
Application
Datastore
Infrastructure
Profile
Microservice
API
Application
Datastore
Infrastructure
Product Catalog
Microservice
By definition, each microservice can be
written, built, and deployed independently
User Interface
Application
Datastore
Infrastructure
Deploy Constantly – Even HourlyDeploy Quarterly
Long, serial process to
deploy anything

Run Many Versions of the Same Microservice Concurrently
74
Monolithic
Application
v1.1
Microservice A
Microservice A
Microservice A
Microservice A
Microservice AMicroservice B
v1.1
Microservice A
Microservice A
Microservice A
Microservice A
Microservice A
Microservice A
Microservice A
Microservice A
Microservice A
Microservice AMicroservice B
v1.2
Microservice A
Microservice A
Microservice A
Microservice A
Microservice A
Run only one version of the same
application in the same environment
Run many versions of each
microservice in the same environment
Microservice A
v1.2
Microservice A
v1.1

Application Containers – Use What You Have Today
75
Characteristics of Microservices-
friendly Application Server
Characteristics of Existing
Application Server
• Run a smaller, microservice that
does one thing really well
• Few features
• External dependency
management
• Many instances per host
• Stateless
• Run a very large, complicated
monolithic application
• Many advanced features
• Integrated dependency
management
• Few instances per host
• Stateful
Run whatever works best – few firm requirements

How Oracle Products Support Microservices
76

Copyright © 2016, Oracle and/or its affiliates. All rights reserved.Copyright © 2016, Oracle and/or its affiliates. All rights reserved.
Oracle’s Microservices Strategy
Oracle’s Microservices Roadmap Today With Oracle Products
Runtime
Management/Logging/Alerting
Messaging
Datastore
API Gateway/Load Balancer
Central Source of Truth
Infrastructure
Build/Deploy
77
Container Orchestration
Service Discovery
Eventing
Configuration
State Planned - Oracle Cloud State Service
Planned - Oracle Cloud Config Service
Planned - Runtime - Jersey + Grizzly
Planned - Oracle Cloud Eventing Service
Oracle Messaging Cloud Service
Oracle Management Cloud Service
Oracle Database or NoSQL Cloud Service
Oracle Cloud
Planned - Oracle Microservices Platform
Oracle Developer Cloud Service
Oracle Coherence or Oracle WebLogic
Oracle Coherence
Oracle WebLogic, Node, Java SE, etc
Oracle Coherence
Oracle Messaging Cloud Service
Oracle Management Cloud Service
Oracle Database or NoSQL Cloud Service
Oracle Cloud
Oracle App Container Cloud Service
Oracle Developer Cloud Service
Oracle Coherence

An All-New Microservices Platform From Oracle
Oracle Confidential – Internal/Restricted/Highly Restricted
• Config
• State
• Eventing
• Messaging
• Logging
• Monitoring
• Database
• NoSQL
• Caching
• Integration
• Big Data
• Mobile
• Process
• Developer
Infrastructure Agnostic High Availability Hybrid Cloud
Placement Constraints High Density Internal Load Balancing
Rolling Upgrades Rollbacks
Blue/Green Releases
Canary Testing
Health MonitoringService DiscoveryStateless Support
Stateful Support
Microservices
Platform
Language-specific Tooling
Install Platform On Any IaaS, On Or Off Premise (future)Consume Platform as PaaS on Oracle Cloud
Oracle Public Cloud
Oracle Public Cloud
Machine
AllNew
Services Available
for Consumption
Inside the Platform
Runtime
Light/fast
Jersey-based
Easy Packaging
New!
78

Using Application Container Cloud Service For Microservices
79
A modern platform for lightweight application development
Database Cloud Service
Oracle Cloud
Application Container Cloud Service NoSQL Cloud Service
Oracle Management Cloud - Management/Logging/Alerting
Messaging Cloud Service
Caching Cloud Service for State
Java SE
Cloud
Service
API Load Balancer
Service Discovery
Configuration
Node
Cloud
Service
Other
Polyglot
Runtimes
Bring
Your Own
Container
Jersey +
Grizzly
Docker Containers
Container Placement
DeveloperCloudService

Introducing Oracle App Container Cloud Service
80
Key Features
• Useful for any Java, Node.js, or polyglot runtime
• IDE Choice - JDeveloper, Eclipse, NetBeans - and API access
• Continuous integration with Oracle Developer Cloud Service
• Cloud tooling for lifecycle management
• Integrated load balancer, support for service discovery
• Bring-your-own-container model supported shortly
Benefits
• Self-service application platform with advanced cloud tools
• Secure, Highly Available with Clustering
• Fully automated provisioning, patching, backup, and recovery
Java SE
Node
Your Own
Container

JAX-RS: The Java API for RESTful Web Services
81
Oracle is a spec lead
@Path("/atm/{cardId}”)
public class AtmService {
@GET @Path("/balance”)
@Produces("text/plain”)
public String balance(
@PathParam("cardId") String card,
@QueryParam("pin") String pin) {
Client client = ClientFactory.newClient();
String balance =
client.target("http://xxxx/atm/{cardId}/
balance")
.pathParam("cardId", "1234567890123456")
.queryParam("pin", "1111")
.request("text/plain")
.get(String.class);
Server-side Code
Simply annotate Java code to expose as REST
Client-side Code
Use REST without having to parse text
Updated as JSR 339 in 2013 - 2.0
Part of Java EE 7 Spec
|Originally defined in JSR 311 - 1.0
Part of Java EE 6 Spec

Jersey: The Reference Implementation of JAX-RS
• Oracle sponsored open source
• Implements the JSR 311 specification
• Contains
– Standalone server
– Client
– JAXB/JSON support
82
Oracle continues to lead the spec

Grizzly: High Performance I/O
• Oracle sponsored open source
• Allows developers to take advantage of the
Java NIO to provide very fast inter-process
communication
• Brings non-blocking sockets to the protocol
processing layer
– Support for non-blocking HTTP processing
• WebSocket Support
• APIs make non-blocking interactions simple
83
Great for inter-process communication

Using WebLogic + Java EE For Microservices
A proven, enterprise-grade platform for application development
Database Cloud Service
Oracle Cloud
Oracle Compute Cloud Service NoSQL Cloud Service
Oracle Management Cloud - Management/Logging/Alerting
Messaging Cloud Service
Caching Cloud Service
For State, Configuration, Service Discovery
DeveloperCloudService
Oracle Traffic Director
Docker Containers
Container Placement
WebLogic Multi-tenant WebLogic Multi-tenant
Jersey + Grizzly Jersey + Grizzly
WebLogic Partition

Java EE Platform Supports Microservices
• Standards based infrastructure
– Prescribed, validated set of APIs and services
– WAR file deployment for service boundary
• Enables development of thin Microservices
– Assemble application code and resources only
– APIs and implementation libraries supplied by
platform
• Freedom to choose best service topology
– One service per server, multiple services per server
– One server per container/host
– Multiple containers/servers per host
85
JAX-RS
CDI
HTTP/S WebSocket
EJB
JPA
JSON
JDBC
υS υS
Data
Store
Data
Store
JAX-RS
CDI
HTTP/S WebSocket
EJB
JPA
JSON
JDBC
υS υS
PDB PDB

• Java EE Platform Support
– With latest Java language support
• Fully automatable infrastructure
– Scriptable provisioning, configuration,
deployment supporting code-as-
infrastructure
– REST API, WLST, JMX
– Callable from Maven, Gradle, Arquillian
– Easily incorporated into Continuous
Integration and Delivery workflows
• Flexible placement models
– Single server, multiple servers, clusters of
servers
• Diverse datastore options
– Traditional multi-vendor relational
database support
– Integrated Oracle Database 12c pluggable
database support as independent data
stores for services
– Simple configuration for Document/Graph
databases
– Container, application, embedded
application scoped database resources
86
WebLogic Supports Microservices (and then some!)

Partition is now a first-class object
WebLogic Multi Tenant
WebLogic
JVM
Application
OS Process
WebLogic
JVM
Application
OS Process
WebLogic
JVM
Application
OS Process
WebLogic
JVM
Application
OS Process
Operating System Instance
Standard WebLogic
Single-tenant Multi-tenant – strong isolation between tenants
Multi Tenant WebLogic
WebLogic
JVM
OS Process
WebLogic
JVM
OS Process
Application 2 Application 2
Partition 2Partition 2
Application 1 Application 1
Partition 1Partition 1

WebLogic Multi Tenant is Perfect for Microservices
• Each microservice instance can have
its own light-weight WebLogic
container-like partition
• Easily move partitions between
WebLogic hosts
• Each partition is exceptionally light
• Each WebLogic host can support
hundreds of partitions
88
Similar to Oracle Database pluggable/container databases
WebLogic
JVM
Microservice
OS Process
Microservice Microservice
Multi Tenant WebLogic

WebLogic Runs Great on Docker
• Build
oracle/weblogic:12.1.3-
dev image
• Start 3 WebLogic Server
Containers in seconds
• View status
89
$ docker run –p 17001:7001
oracle/weblogic:12.1.3-dev
1
2
3

Oracle Coherence – Oracle’s Distributed Data Grid
• Reliable in-memory key-value store
– Dynamically scalable
– Scale processing with data
– Flexible topology support
• Java, .NET, C++, REST, Memcached,
Jcache client support
• In-place distributed processing
• Queries & continuous queries
• Map-reduce aggregation
• Event notification / event programming
model
• Distributed Lambdas and Streams
91
Architected for microservice state management

Oracle Messaging Cloud Is Perfect for Microservices
92
Implements AMQP standard
Standardized Interfaces
REST
JMS
Message push over HTTP
Versatile
Oracle Cloud
On Premise
Hybrid
Delivery Choices
Pull
Push
Filter
Reliability Mechanisms
Transactions
Acknowledgements
Durable subscriptions

Oracle Management Cloud Services – Initial Offerings
Application Performance
Monitoring
Improve End-User Experience
and System Performance;
Diagnose Performance Issues
Faster
Log Analytics
Extract Value from Logs by
Collecting, Correlating, and
Searching Any Kind of Log Data;
Quickly Discover Anomalies
IT Analytics
Make Critical Decisions About Your
IT Estate; Plan For Growth, Run
What-If Analyses, Compare
Resource Usage
93

Oracle Datastore Options – Offered On Premise and In Cloud
94
DESCRIPTION
Supports JSON, XML, CLOBs,
BLOBs, and multi-media. Accessible
over client-specific APIs, REST
Distributed key/value pairs, schema-
less, nearly ACID compliant, scale
out. Berkeley DB behind the scenes
Distributed data grid that supports
grid-side processing
PRODUCTS
Fraud Detection
CATEGORY
RDBMS
Key/Value Stores
Object Data Grid

Pluggable Databases
• Container Database
– Multi-tenant database that includes zero, one or
many pluggable databases
– Upgrades, etc are performed against container
• Pluggable Database
– A full database to the client except that behind the
scenes it doesn’t have its own controlfiles, redo logs,
undo, etc
– Just a collection of datafiles and tempfiles to handle
its own objects, including its own data dictionary
– Can easily move Pluggable Databases from one
container to another
95
One Container Database per application, one Pluggable Database per microservice

Oracle Database: Simple Oracle Document Access (SODA)
• Enable schemaless development on
top of an Oracle Database
– Provide a simple NoSQL-style API for
working with documents
• Make it easy to use Oracle as a
NoSQL-style document store
• Supports all common application
development environments
• Supports SQL!
• Works with Oracle Database tooling
– backup, restore, security, etc
96
NoSQL backed by Oracle Database
POST /DBJSON/SCOTT/CUSTOMERS?action=query HTTP/1.0
Content-Type: application/json
Body: {
"company" : ”Oracle“,
"$or" : {"$startsWith" : {"name": "Melissa"}}}
select "JKEY",“VERSION", "LAST_MODIFIED“, “CREATED”
from "SCOTT".“CUSTOMERS"
where JSON_EXISTS(
"JVALUE",
'$?( $.company == $B0 && ( $.name starts with $B2))'
PASSING ‘Oracle’AS "B0" ,‘Melissa’AS ”B1”)
{
"items": [ {
"id": "09615A98B2B941AF94D84FD44D04AB9C",
"etag": "D78FBD… B879E",
"lastModified": "2015-02-10T01:15:13.631231“,
"created": "2015-02-10T01:15:13.631231”
}, … {more records...}
],
"hasMore": true,
"count": 4,
"offset": 0,
"limit": 4
}
RESTSQLJSON

SODA For Java
• Provides:
– Connection to the database
(replaces JDBC!)
– Collection Management
– CRUD operations
– Query-by-Example
– Utility and control functions
• SODA for Java applications can
use a JDBC connection to talk to
the database
• SODA for Java is transactional
– Supports Hybrid model with JDBC
and SODA based operations
97
Native library for Java
// Create a Connection
OracleRDBMSClient client = new OracleRDBMSClient();
OracleDatabase database = client.getDatabase(conn);
// Now create a collection
OracleCollection collection =
database.getDatabaseAdmin().createCollection(“MyCollection”);
// Create a document
OracleDocument document = database.createDocumentFromString("{
”name" : ”Alexander” }”);
// Next, insert it into the collection
OracleDocument insertedDocument = collection.insertAndGet(document);
// Get the key of the inserted document
String key = insertedDocument.getKey();
// Get the version of the inserted document
String version = insertedDocument.getVersion();

SODA For REST
• Standard REST based model
• CRUD operations map to HTTP Verbs
– Create / Update : PUT / POST
– Retrieve : GET
– Delete : DELETE
• Other operations, such as Query by
Example, Bulk Insert and Indexing are
mapped to variants of POST
• JSON document forms the payload of
the HTTP Request or Response
• Stateless model, no transaction
support
• Implemented as a Java Servlet
98
Can be invoked from any programming language
GET /DBSODA/schema List all collections in a schema
GET
/DBSODA/schema/colle
ction
Get all objects in collection
GET
ction/id
Get specific object in collection
PUT
ction
Create a collection if necessary
PUT
ction/id
Update object with id
POST
ction
Insert object into collection
POST Find objects matching filter in

SODA For REST Architecture
99
Clean architecture
 Data stored in Oracle Database as JSON documents
 App Developer make standard HTTP(S) calls to SODA for REST API
Oracle DatabaseHTTP(S) client
Oracle REST Data Services
SODA 4 REST Generated SQL
Transform JSONPass thruJSON JSON
URI
JAVA Container

Summary
100

Problems to Solve With Microservices
101
Many, very sticky problems to solve

Microservices Adoption Patterns
102
Start with a monolith
Adopt Microservices
(Only if the monolith gets too big and
you’ve met the other prerequisites)

Microservice Takeaways for Enterprises
103
The term “microservices” is probably a passing fad, but there is real business value
Ability to Execute
Time | Competency | Resources
Constraints:

Remember: Microservices Are Not a Silver Bullet
"There is no single development, in either
technology or management technique, which by
itself promises even one order of magnitude
[tenfold] improvement within a decade in
productivity, in reliability, in simplicity.”
"We cannot expect ever to see two-fold gains every
two years" in software development, like there is in
hardware development (Moore's law)
104
It’s probably best to stick with monoliths

Microservices + Oracle: A Bright Future

Microservices + Oracle: A Bright Future

Recommended

Recommended

More Related Content

What's hot

What's hot (20)

Viewers also liked

Viewers also liked (20)

Similar to Microservices + Oracle: A Bright Future

Similar to Microservices + Oracle: A Bright Future (20)

Recently uploaded

Recently uploaded (20)

Microservices + Oracle: A Bright Future

Editor's Notes