Java EE for Cloud Native and ... - otndnld.oracle.co.jpotndnld.oracle.co.jp/.../java-2016/AnilGaur_JavaEE-CloudNative.pdf · Some public cloud vendors (not Oracle) use velcro to attach

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

Java EE for Cloud Native and Microservices

2016/12/2 Anil Gaur GVP Engineering Oracle Cloud Platform Application Development


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

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

AppDev is About our Customer’s Entire Portfolio

3

Innovation Software - Find the Next Business

Differentiation Software - Run Current Business

Core Software - Keep the Lights On

Release Hourly

Fail Early

Agile

Business-centric

Top Line Growth

Bespoke Software

Product-based

Release Quarterly

Fail Late

Waterfall

IT-centric

Bottom Line Savings

Packaged Software

Project-based

Copyright © 2016, Oracle and/or its affiliates. All rights reserved. 3


4

Cloud Native Software Is Overtaking the World


Microservices • Minimal Function • Service Discovery • API-first

3 • Polyglot • Choreography • Loose Coupling

DevOps • Automated Provisioning • Automated Setup • Continuous Integration

1 • Continuous Delivery • Automated Testing • Agile • Culture Change

* as a Service • Consume Infrastructure and

Software as a Service • Fault Tolerant by Definition

2 • Auto-scaling • Infinite Elasticity

5

What is Cloud Native? A new style of architecture

Distributed Computing • Multi-master • Many Data Centers • Many Fault Domains

4 • Many Regions • Global Server Load Balancing • Replication

Co

mp

eten

cy


Prerequisite #1 - DevOps It's

not m

y m

achin

es, it's

your

code!

6

DevOps seeks to solve this It's not my code, it's your machines!

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

Cultural movement enabled by technology

DevOps Principles

Paid to add new features

Dev Ops

DevOps

Paid to keep system stable, fast and available

New goal: Add new features and keep the system stable, fast and available


Set it and forget it

Everyone Should Be Able to Build Anything At Any Time

• Manual one button build/deploy

• Scheduled builds - every day, every week, etc

• Builds triggered by code checkins

• If post-build validation fails, report it


Assume Your Infrastructure is Unreliable Even though it is actually pretty reliable these days

Some public cloud vendors (not Oracle) use velcro to attach components to

motherboards, given how frequently these components fail


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


Make Your Middle Tier Stateless 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 Instance Application

Instance Application Instance Application

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

Legacy Cloud Native


Remember That Latency is Everywhere Asynchronously make calls to all remote systems

High latency within a single cloud. Can no longer assume 2ms between

application and data tiers

Application is now comprised of many different microservices, each

with its own datastore/database

Application is now deployed to multiple data centers, in multiple

availability zones, in multiple regions

12 Copyright © 2016, Oracle and/or its affiliates. All rights reserved.


Microservices Architecture & Technology


Why Microservices?

14


Conway’s Law In Action Any piece of software reflects the organizational structure that produced it

User Interface

Application

Datastore

Infrastructure

Resulting Software Typical 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


Even Simple Changes Are Hard to Implement With Monoliths Organizational boundaries introduce the need to extensively coordinate

User Interface

Application

Datastore

Infrastructure

New requirement: Add a birthdate property to the customer’s profile. How does this get implemented?

Application developer tickets DBAs to have them add that property as a column in the database

1.

Application developer tickets UI team to have them add that property to the profile screens

3.

Application developer adds the new property to the application-level code

2. Different Teams Different Timelines Different Priorities Different Ticketing


Much Faster Turnaround With Microservices

The profile microservice team – three people total, all sitting together

Turn around changes in hours vs. months

Hey Jim, can you add that column to the

database before lunch?


Low latency, high bandwidth communication


Re-structure Your Organization – Put Conway’s Law to Work Build small product-focused teams – strict one team to one microservice mapping

Resulting Software Microservices Organization Structure

Many Small Microservices

API

Application

Datastore

Infrastructure

API

Application

Datastore

Infrastructure

API

Application

Datastore

Infrastructure

API

Application

Datastore

Infrastructure

Product Lead

Project Manager

Sys Admin DBA JavaScript Developer

Developer

Developer

Sys Admin

Storage Admin

Graphic Artist NoSQL Admin

Product Lead

Project Manager


Developer

Developer

Sys Admin

Storage Admin


Product Lead

Project Manager


Developer

Developer

Sys Admin

Storage Admin


Product Lead

Project Manager


Developer

Developer

Sys Admin

Storage Admin



Defining Characteristics of Microservices

Tens of versions of each microservice running concurrently

Thousands of microservices

Polyglot - each microservice can have its own tech stack

Firm boundaries between services

Distributed coupling - loose coupling, extensive messaging


Common Microservices Best Practices

Can build a microservice

independently

Can release each microservice

independently

Don’t share a datasource across

microservices


Common Microservice Adoption Use Cases

21

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.


Do One Thing and Do It Well

Focus on Business Capabilities

Avoid Inter- dependencies

22

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


Each Team Should Treat Other Teams as External Vendors

• Clear interfaces

• Clear SLAs

• Chargeback

Good fences make good neighbors

Microservice A Microservice B


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 Physical Host

Operating System

Container

App

Container

App

Just One Per Container


Artifacts Are Now Immutable Containers – Not EARs, WARs • Containers can have anything in them and are highly portable

• 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

Hardware

Operating System

Hypervisor

VM 1 VM 2

Current

Hardware

Operating System

Container 1 Container 2

Cloud Native

OS

App Server

EAR/WAR

OS

App Server

EAR/WAR The Artifact You Deploy


Java EE – What’s Next?

New AppDev Style for Cloud and Microservices


Java EE - Available On Premise and in the Cloud

12/5/2016 Confidential – Oracle Internal/Restricted/Highly Restricted 27

Cloud

On Premise

WebLogic Red Hat JBoss


Choice of Implementations

IBM Bluemix

IBM WebSphere

Red Hat OPENSHIFT

CAUCHO NEC Cosminexus TmaxSoft Red Hat® JBoss Enterprise Application Platform SAP INFORS FUJITSU

7as WildFly OW2 IBM

Tong Tech® GERONIMO


Rapid Changes Over Past Few Years Driven by increasing business needs

Microservices Apps divided into many small pieces

Distributed Computing Many data centers, AZs, regions, etc.

Polyglot Java leads but use of others increasing

New Technology Docker, Cloud, DevOps, etc.


Doesn’t matter what decade we’re in – building blocks are fairly constant

Back to Basics: Apps Have Always Required the Same Building Blocks

Custom Code

Messaging Clustering Consensus Configuration

Naming Logging Persistence Caching

Not

An I

nclu

siv

e L

ist


How Do We Make This Easier?

31

Building on the Lessons Learned


Use lessons learned and

successful implementations

JAX-RS

Servlet

Interceptors

JMS

JSON-P CDI

JTA JPA

WebSocket

Be pragmatic

Choice of Implementations

CAUCHO NEC Cosminexus TmaxSoft Red Hat® JBoss Enterprise Application Platform SAP INFORS FUJITSU

WildFly OW2 IBM

Tong Tech® GERONIMO


Java EE APIs - Backbone of Leading Open Source Projects

32

Java EE Containers

Microservices Web Containers

Web Frameworks

PaaS REST

http://tomcat.apache.org/

Red Hat® OPENSHIFT CLOUD Foundary

WildFly


Cloud Development

Heterogeneous Clients

• Mobile, REST, HTML5

Stateless Services

• Managed and scaled independently

Data Sources

• Relational, non-relational

User profile service

Order service

Partner service

Catalog service

Notification service

Import service

HTTP/2 REST JSON XML/HTTP

Event JAX-RS/JSON Notifications JAX-WS

RDBMS NoSQL DB XML DB Data Streams

Key Value Events Key Value JDBC

33


It’s Confusing!

Too many choices.... Which components? Overall architecture? Standards? Vendor commitment?


Proposed Enhancements for Java Enterprise Edition

• New AppDev style for Cloud and Microservices

• Build on proven technologies

• Comprehensive

– Programming Model, Packaging, Portability

• Standards-based

– This is a proposal only

– Will work with the community and follow the JCP process

35


Designed for Agility and Scalability with Security • Programming model

– Extend for reactive programming

– Unified event model, event messaging API

– JAX-RS, HTTP/2, Lambda, JSON-B, …

• Eventual consistency

– Automatically event out changes to observed data structures

• Key value/document store

– Persistence and query interface for Key Value and Document DB

• Security

– Secret management

– OAuth/OpenID support

36

App

App

App

App


Location Transparency and Resiliency

• Configuration

– Separate service packaging and configuration

– API for external configuration

• State

– API for external state

• Resiliency – Circuit breakers

– Resilient commands

– Standardized health reporting

37

Reliability, Monitoring

Container Management

Scheduling & Elastic Scaling

Key Value

Database

Logging

Config

State

Security

Notification


Order service

Catalog service


Packaging for Simplicity • Packaging – Docker model

– Package applications, runtimes into containers

– Separate service package and configuration

– Standalone immutable executable binary

– Multi-artifact archives, leveraging Java 9

• Serverless – New spec – interfaces, packaging format, manifest

– Ephemeral instantiation

• Multitenancy – Increased density

– Tenant-aware routing and deployment

38

App

Server

Order service

App

Server

Catalog service

App

Server



Platform Architecture Orchestration – Deployment, Scheduling, and Standup

BareMetal

Orchestration

Deployment Manager

Local Service Impls

Additional Local Classfiles

Java EE Cloud Native App

Container Container

Container


JLink

Local Service Impls Additional Local Classfiles

Java EE Cloud Native App With Just Enough

Container

Container Container



Platform Architecture Orchestration – Inspection, Injection, and Wiring

BareMetal

Orchestration

Container

Config

Cache

Logging

Platform Services

Service Registry



@Config @Cache @Logging @Service Name

Impl

Impl

Impl

Impl


Recent Java EE 7 compatibility updates: Congratulations! Technical Focus Areas

Extend for reactive programming

Unified event model

Event messaging API

JAX-RS, HTTP/2, Lambda, JSON-B, ...

Programming Model

API to store externalized state

State

Automatically event out changes to observed data structures

Eventual Consistency

Extension to support client-side circuit breakers

Resilient commands

Standardize on client-side format for reporting health

Resiliency

New spec – interfaces, packaging format, manifest

Ephemeral instantiation

Serverless

Secret management

OAuth

OpenID

Security Package applications,

runtimes into services

Standalone immutable executable binary

Multi-artifact archives

Packaging Increased density

Tenant-aware routing and deployment

Multitenancy

Externalize configuration

Unified API for accessing configuration

Configuration

Persistence and query interface for key value and document DB

Key Value/Doc Store

41


Proposed Platform Architecture

Java EE Packaging, Serverless, Multitenancy

OS / Hypervisor

Container Runtime

Java SE Runtime

Java EE Runtime

Programming Model

API Gateway

Load Balancer

HTTP/2

JSON-B

Event API

REST API

Security API State API Config API

Eventual Consistency

Resiliency Key Value Store API

42

Key Value

Database

Logging

Config

State

Security

Notification

Rel

iab

ility

, Mo

nit

ori

ng

Man

agem

ent

and

Orc

hes

trat

ion

Sch

edu

ling

and

Ela

stic

Sca

ling


Java EE 7

Connector JAXB JSP Debugging

Managed Beans JSP Concurrency EE Interceptors JAX-WS WebSocket

Bean Validation JASPIC Servlet JMS JTA Deployment

Batch JACC Dependency Injection JAXR JSTL Management

CDI EJB JAX-RPC Web Services JSF JPA

JSON-P Common Annotations EL JAX-RS Web Services

Metadata JavaMail


Java EE 8 (Revised Proposal, 2016)

Connector JAXB JSP Debugging

Managed Beans JSP Concurrency EE Interceptors JAX-WS WebSocket

Bean Validation JASPIC Servlet JMS JTA Deployment

Batch JACC Dependency Injection JAXR JSTL Management

CDI EJB JAX-RPC Web Services JSF JPA

Common Annotations EL JAX-RS Web Services

Metadata JavaMail

CDI

JSON-B Security

Bean Validation

JSF

JAX-RS JSON-P

Servlet

JSP


Engage Java EE Community • Feedback through Survey • Launch Java EE Next JSRs

2016 Java EE 8 • Specs, RI, TCK complete • Initial microservices support • Define Java EE 9 • Early access implementation

of Java EE 9

Java EE 9 • Specs, RI, TCK complete • Modular Java EE runtime • Enhanced microservices

support

Java EE Roadmap

2017

2018

ご質問・ご相談等ございましたら、終了後もお受けしております

0120-155-096 （平日9:00-12:00 / 13:00-18:00）

http://www.oracle.com/jp/contact-us/overview/index.html

各種無償支援サービスもございます。

Oracle Digital 検索

Oracle Digital あなたにいちばん近いオラクル

46





Documents

Java EE for Cloud Native and ... - otndnld.oracle.co.jpotndnld.oracle.co.jp/.../java-2016/AnilGaur_JavaEE-CloudNative.pdf · Some public cloud vendors (not Oracle) use velcro to attach