Partner Webcast – Implementing Microservices Architecture Using Oracle Fusion Middleware

Stay Connected

BLOGS.ORACLE.COM/IMC

TWITTER.COM/ORACLEIMC

YOUTUBE.COM/ORACLEIMCTEAM

FACEBOOK.COM/ORACLEIMC

http://blogs.oracle.com/imc

http://twitter.com/oracleimc

https://www.youtube.com/OracleIMCTeam

https://www.facebook.com/OPN.PartnerHub.Migration.Center

Copyright © 2015, Oracle and/or its affiliates. All rights reserved. |

Implementing Microservices Architecture Using Oracle Fusion Middleware Emin Askerov FMW Consultant ISV Migration Center February 4, 2016

Oracle Confidential – Internal/Restricted/Highly Restricted

Presented by


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.

4


Program Agenda

Introduction to Microservices

Implementing Microservices

How Oracle Products Support Microservices

Summary

1

2

3

4

5


Introduction to Microservices

6


Characteristics of Existing Deployment Architecture

7

The status quo has served us well but there are new alternatives

Hardware

Operating System

Hypervisor

Operating System

Application Container

Large Monolithic Application One large archive, including UI(s) and application code

VM

• Three tiers

• Many “named” servers that perform only one function and cannot go down

• Scale by cloning behind load balancer (X-axis scaling)

• One programming language

• Everything centralized – messaging, storage, database, etc

Feature-rich – support large, complicated applications, many use cases

Provide 100% isolation between tenants

Procured and manually set up


Existing Deployment Architecture Has its Limits

8

Too Slow Teams split up by function – UI,

application, middleware, database, etc. Takes forever to get anything done due to

cross-ticketing

Too Fragile A bug will quickly bring down an entire

application. Little resiliency

Inefficient Testing Each time you touch the application, you have to re-test the whole thing. Hard to

support continuous delivery

No Ownership Code falls victim to “tragedy of the

commons” – when there’s little ownership, you see neglect

Too Complex Apps get too big and complicated for a

developer to understand over time. Shared layers (ORM, messaging, etc) have to handle

100% of use cases – no point solutions

No Ownership

Too Slow

No Specialization

Too Complex

Inefficient Testing

Too Fragile

No Specialization Different parts of applications have different needs – more CPU, more

memory, faster network, etc


Introducing Microservices Pattern

9

A definition of this new architectural term

Martin Fowler, Software engineer,

author and international public speaker

«In short, the microservice architectural style is an approach to developing a single application as a suite of

small services, each running in its own process and communicating with lightweight mechanisms, often an

HTTP resource API.»


Monoliths & Microservices

10

A monolithic application is packaged and deployed as a single unit…

Each application instance runs within separate process and can be load balanced…

Business logic modules (pieces of functionality)

Monolithic Approach Microservices Pattern

Idea of Microservices is to split your application into set of smaller, interconnected services…

At runtime, each instance could be a cloud VM or a Docker container…


What Are Microservices?

11

Minimal function services that are deployed separately but can interact together to achieve a broader use-case

Status Quo Microservices

Single, Monolithic App

Must Deploy Entire App

One Database for Entire App

In-process Calls Locally, SOAP Externally

Organized Around Technology Layers

Developers Don’t Do Ops

State In Each Runtime Instance

One Technology Stack for Entire App

Many, Smaller Minimal Function Microservices

Can Deploy Each Microservice Independently

Each Microservice Has Its Own Datastore

REST Calls Over HTTP, Messaging, or Binary

Organized Around Business Capabilities

Developers + Ops Support Production in Perpetuity

State in Distributed Data Grid – Instances Stateless

Choice of Technology for Each Microservice


Microservice Principles Have Been With Us For Decades

12

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


Microservices Are Analogous to Unix Utilities

13

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

14

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

Copyright © 2015, Oracle and/or its affiliates. All rights reserved. | 15

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


Common Microservice Adoption Use Cases

16

I want to extend my 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.


SOA vs. Microservices

17

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


Microservice Principles Are Old; Implementation is New Microservices is not just rebranded SOA

• Teams independently architect, develop, deploy and maintain each microservice

• Each microservice 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


Implementing Microservices

19


Microservices Forces Move To Distributed Computing

20

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


REST: Representational State Transfer

21

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 Require a Higher Level of REST Use

22

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


Technical Ingredients for Microservices Implementation

23

Microservices

Security Scaling Monitoring

Eventing Logging Messaging

Service Discovery Configuration Security

Service Registry API Gateway API Load Balancer 100% Required 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

24

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 Instances Microservice Infrastructure

Java Cloud Service (instances 1...N)


API Gateways Load Balance and Aggregate Responses

25

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


Microservices Requires Robust Messaging

26

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


Operating System Containers – Lighter Is Better

28

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


Must Place Containers on Physical Hosts

29

Host Host

Host Host

Host Host

Host Host

Host Host

Container • Inventory

Microservice

• AcmeCo • v1.2


Microservice

• AcmeCo • v1.2


Microservice

• AcmeCo • v1.2


Microservice

• AcmeCo • v1.2


Microservice

• AcmeCo • v1.2


Microservice

• AcmeCo • v1.2


Microservice

• AcmeCo • v1.2


Microservice

• AcmeCo • v1.2


Microservice

• AcmeCo • v1.2


Microservice

• AcmeCo • v1.2


Microservice

• AcmeCo • v1.2


Microservice

• AcmeCo • v1.2


Microservice

• AcmeCo • v1.2


Microservice

• AcmeCo • v1.2


Microservice

• AcmeCo • v1.2


Microservice

• AcmeCo • v1.2


Microservice

• AcmeCo • v1.2


Microservice

• AcmeCo • v1.2


Microservice

• AcmeCo • v1.2


Microservice

• AcmeCo • v1.2

Many Containers

Host Host

Host Host

Host Host

Host Host

Host Host

Many Hosts

Problem: How do you deploy each container to the most appropriate host? Must be aware of tenants, versions, environments, etc to avoid single points of failure

Solution: Kubernetes, Swarm, etc all make good solutions. Very much an emerging space.


How Oracle Products Support Microservices

30


JAX-RS: The Java API for RESTful Web Services

31

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


Common JAX-RS Implementations

32

Oracle is the spec lead

Official Reference Implementation

Sponsored by


Jersey: The Reference Implementation of JAX-RS

• Oracle sponsored open source

• Implements the JSR 311 specification

• Contains

– Standalone server

– Client

– JAXB/JSON support

33

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

34

Great for inter-process communication


• Boundary Interfaces

– REST Services with JAX-RS

– REST Clients with JAX-RS

– WebSocket 1.0 API for low-latency, bi-directional communication

– JSON Processing API

– Automated JSON binding with MOxY using JAXB annotations

– Automatic validation of operation response and operation parameters

• Control Interfaces

– Sync and/or Async ready

– Scalable via pooling of instances

– Transactional support if desired

– Injectable into Boundary

– Support for messaging

• Entity Layer – Automated persistence

– Automatic ID generation

– Transactional scope from control layer

35

How Java EE Supports Microservices


Three Great Java-based Offerings for Microservices

Java Cloud Service

Run any Java EE-based application on a

WebLogic-based PaaS

Java SE Cloud Service

Run any Java based application on Java SE. Supports any

programming language that runs on a JVM

Compute Cloud Service

Bring your own JVM


• 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

37

WebLogic Supports Microservices (and then some!)


Efficiently host many microservice instances on a single JVM

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

WebLogic

JVM

Application

OS Process


Application Application

Application Application Application




Standard WebLogic

Single-tenant Multi-tenant – strong isolation between tenants

Multi Tenant WebLogic


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

39

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

40

$ docker run –p 17001:7001

oracle/weblogic:12.1.3-dev

1

2

3


Demonstration Creating WebLogic Server Docker Images

41


Application Builder Cloud Service

• WISIWYG application builder, using REST services as application building blocks

• Use RAML or Swagger-based APIs

• Data validation

• Build custom objects

• All SaaS-based – no coding required

42

Visual Design Time for Wiring Microservices Together


Oracle Messaging Cloud Is Perfect for Microservices

43

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 Datastore Options – Offered On Premise and In Cloud

44

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


Oracle Leads JSON Querying/Processing Initiatives

45

JSONiq

JSON-P

• Query and processing language specification for JSON • Inspired by XQuery • Can be optionally added to XQuery as an extension – query both XML and

JSON using the same syntax • 4 of 6 spec leads are Oracle employees

• JSR 374: Java API for JSON Processing • Portable Java-based APIs to parse, generate, transform, and query JSON

using the streaming API or the object model API • Object and streaming API – similar to DOM and StAX • Oracle employee is the specification lead

JSON-P


Summary

46


Problems to Solve With Microservices

47

Many, very sticky problems to solve


Microservices Adoption Patterns

48

Start with a monolith Adopt Microservices

(Only if the monolith gets too big and you’ve met the other prerequisites)

«…don't even consider microservices unless you have a system that's too complex to manage as a monolith.»

Martin Fowler


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

49

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


Oracle Offers Developer-centric PaaS Solutions

50

Deploy your microservices to these runtimes

Database WebLogic Developer Mobile JavaSE Node.JS DataGrid Application Builder

NoSQL

Identity Service API

Catalog Source Control

Development Tools

Application Composer

22

Integrated PaaS for Developers Foundation

Infrastructure-as-a-Service

PaaS Service Manager

JRuby


Resources • Microservices (article by Martin Fowler)

– http://martinfowler.com/articles/microservices.html

• «Building Microservices» (1st Edition, by Sam Newman, ISBN-13: 978-1491950357)

– http://www.amazon.com/Building-Microservices-Sam-Newman/dp/1491950358

• Oracle WebLogic Server – http://www.oracle.com/technetwork/middleware/weblogic/overview/index-

085209.html

• WebLogic & Docker

– https://blogs.oracle.com/brunoborges/entry/docker_and_weblogic_enabling_cloud

– https://blogs.oracle.com/imc/entry/getting_started_with_oracle_weblogic

http://martinfowler.com/articles/microservices.html

http://martinfowler.com/articles/microservices.html

http://www.amazon.com/Building-Microservices-Sam-Newman/dp/1491950358







http://www.oracle.com/technetwork/middleware/weblogic/overview/index-085209.html




https://blogs.oracle.com/brunoborges/entry/docker_and_weblogic_enabling_cloud

https://blogs.oracle.com/brunoborges/entry/docker_and_weblogic_enabling_cloud

https://blogs.oracle.com/imc/entry/getting_started_with_oracle_weblogic

https://blogs.oracle.com/imc/entry/getting_started_with_oracle_weblogic


Resources (continuation) • GlassFish Server

– https://glassfish.java.net/

• Project Jersey

– https://jersey.java.net/

• Project Grizzly – https://grizzly.java.net/

• Oracle Java Cloud Service

– https://cloud.oracle.com/java

• Oracle Application Container Cloud Service

– https://cloud.oracle.com/en_US/acc

https://glassfish.java.net/

https://jersey.java.net/

https://jersey.java.net/

https://grizzly.java.net/

https://cloud.oracle.com/java

https://cloud.oracle.com/en_US/acc

https://cloud.oracle.com/en_US/acc


Resources (continuation) • Oracle Messaging Cloud Service

– https://cloud.oracle.com/messaging

• Microservices and SOA (article by Bob Rhubart, Oracle Magazine)

– http://www.oracle.com/technetwork/issue-archive/2015/15-mar/o25architect-2458702.html

• Microservices and the Integration Platform (article by Robert Wunderlich) – https://blogs.oracle.com/integration/entry/microservices_and_the_integration_platf

orm

https://cloud.oracle.com/messaging

https://cloud.oracle.com/messaging

http://www.oracle.com/technetwork/issue-archive/2015/15-mar/o25architect-2458702.html








https://blogs.oracle.com/integration/entry/microservices_and_the_integration_platform

https://blogs.oracle.com/integration/entry/microservices_and_the_integration_platform


Q&A

54

Emin Askerov Oracle IMC FMW Consultant [email protected] ISV Migration Center blog: http://blogs.oracle.com/imc ISV Migration Center email: [email protected]



mailto:[email protected]


Q&A Oracle IMC blog: http://blogs.oracle.com/imc

Oracle ECEMEA Partner Hub Homepage: http://oracle.com/goto/hub-ecemea

Oracle IMC Mail: [email protected]

Twitter: http://twitter.com/oracleimc

Facebook: http://facebook.com/oracleimc

LinkedIn: http://linkedin.com/groups/OracleIMC-4535240

Google+: http://plus.google.com/+OracleIMC

Stay Connected

BLOGS.ORACLE.COM/IMC

TWITTER.COM/ORACLEIMC

YOUTUBE.COM/ORACLEIMCTEAM

FACEBOOK.COM/ORACLEIMC


http://twitter.com/oracleimc

https://www.youtube.com/OracleIMCTeam

https://www.facebook.com/OPN.PartnerHub.Migration.Center
