1. Confidential – Oracle Internal/Restricted/Highly Restricted

2. PRO4359: Design and Build Microservices Architecture on the Cloud
This is a Title Slide with Picture and Product, Service, or Industry Logo slide ideal for including a picture and product/service/industry or org logo with a brief title, subtitle and presenter information.
To Replace the LOGOs on this sample slide:
Right-click a sample LOGO and choose Change Picture. Navigate to the location where the new logo is stored, select desired logo file and click on the Open button to replace the sample logo.
The Presented with FPO logo placeholder box can be copy and paste to any of the Title Slides.
Maciej Gruszka – Director Product Management, Oracle
Confidential – Oracle Internal/Restricted/Highly Restricted

3. 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, timing, and pricing of any features or functionality described for Oracle’s products may change and remains at the sole discretion of Oracle Corporation.
Confidential – Oracle Internal/Restricted/Highly Restricted

4. Micro Service Architecture
Micro service based application architecture is an increasingly popular technique for building applications that can scale without miring your organization in the monolithic muck.
Oracle Confidential – Internal/Restricted/Highly Restricted

5. Not Monolithic Muck
Oracle Confidential – Internal/Restricted/Highly Restricted 5

6. Monolithic Muck Do you know what its like to patch this?
Oracle Confidential – Internal/Restricted/Highly Restricted

7. Micro Services Architecture
They support the separation of responsibilities critical for building highly scaled applications, allowing work to be done independently on individual services without impacting the work of other developers in other groups working on the same overall application.
Oracle Confidential – Internal/Restricted/Highly Restricted

8. Why not do everything as functions?
Serverless
Scalability
Microservices
Monolith
Organizational Complexity
Oracle Confidential – Internal/Restricted/Highly Restricted

9. Microservices Challenges
Typical Solution
Increased dependency on network communication requires robust, resilient network with flexible routing
Independence of microservices from each other requires strong API contracts between them
Self contained services and serverless functions require dynamic, flexible interconnections to reach full potential
Complex relationship between microservices makes debugging and tracing more difficult
Istio Service Mesh
API Registry
Events Broker
Observability Tools
Add service broker?
Oracle Confidential – Internal/Restricted/Highly Restricted

10. Service Mesh
A service mesh is a software infrastructure layer for controlling and monitoring internal, service-to-service traffic in microservices applications. It typically takes the form of a “data plane” of network proxies deployed alongside application code, and a “control plane” for interacting with these proxies. In this model, developers (“service owners”) are blissfully unaware of the existence of the service mesh, while operators (“platform engineers”) are granted a new set of tools for ensuring reliability, security and visibility. The service mesh is ultimately not an introduction of new functionality, but rather a shift in where functionality is located.
Oracle Confidential – Internal/Restricted/Highly Restricted

11. Benefits Routing / traffic shaping Adaptive/client-side load balancing
Service discovery
Circuit breaking
Timeouts/retries 
Rate limiting
Metrics/logging/tracing
Fault injection
Oracle Confidential – Internal/Restricted/Highly Restricted

12. Timeouts and Retries
Timeouts and retries can be handled at the service mesh layer
Behavior is adjustable but consistent
Supports polyglot development
Saves Application developer from having to implement or explicitly include logic
Application Code
Get
Response
Proxy
Service
Get
Timeout
Get
Timeout
Get
Response
Oracle Confidential – Internal/Restricted/Highly Restricted

13. Circuit Breaker Transparently monitors for connection failures
Failures beyond a threshold limit trigger the circuit breaker to open
Subsequent requests fail fast
After timer triggers, a ’test request’ will be allowed to pass through
Circuit state will be set based on result of that request
Prevents flooding a failed service with retries
Half Open
Failure
(Beyond Threshold)
Success
Reset Timer
Closed
Open
Oracle Confidential – Internal/Restricted/Highly Restricted

14. Canary Deployment Controlled upgrades, transparent to user
Closed
Clients
Controlled upgrades, transparent to user
Portion of traffic is redirected, success is validated, then more traffic is redirected
Eventually, all traffic is redirected and old version can be removed
Can be rolled back any time using same approach
No animals harmed
Service
Version 1
Version 2
Monitor and Verify
Oracle Confidential – Internal/Restricted/Highly Restricted

15. Distributed Tracing Visualization of request across multiple services
Easy to see where time is spent, parallelism, etc
Helps identify issues and optimization opportunities
Would be extremely time consuming to collect, associate and coordinate through raw log files
Oracle Confidential – Internal/Restricted/Highly Restricted

16. API Registry Driving the API first approach
Consumer and producer of an API agree on its definition
Capture it in code (swagger, blueprint)
Publish the API to the registry
Then consumers can develop against a generated mock producer while the producer is developing the actual code
API Registry can generate client libraries (Java, Javascript)
API Registry can be used for discovery of implementing services
API becomes a living, evolving, contract
Complimentary to Apiary, consuming and implementing Apiary output
Confidential – Oracle Internal/Restricted/Highly Restricted

17. Microservices: It’s All About the Events
To build applications capable of dynamic and ever-changing capabilities, architectures should be composed of smaller chunks of code. Which is why event-driven computing and microservices are gaining in popularity. The relationship between these two things is as follows: microservices should be designed so that they notify each other of changes through the use of events.
Oracle Confidential – Internal/Restricted/Highly Restricted

18. Eventing – Best of Both Worlds
An Event Broker can be used not just to connect loosely coupled microservices, but can be a bridge to serverless functions - allowing a hybrid approach that combines the advantages of both styles of architecture.
Microservices
Serverless
Events
Oracle Confidential – Internal/Restricted/Highly Restricted

19. Event Manager - Goals
Infrastructure to invoke application logic in response to customizable events
Any service can become an event provider
Any service may become an event handler.
Application logic may be
Function in the fn serverless environment
Any other service
Flexible, declarative rules to map events to actions

20. Open Service Broker API – What the spec defines
Talk to the picture, How SB arch is currently implemented
Managed Service == PAAS Service
Oracle Confidential – Internal/Restricted/Highly Restricted

21. Service Broker Marketplace
Marketplace makes service brokers easy to register, easy to use, provides a single operation to provision and connect to services
Services may be provisioned within the cluster or externally
Many brokers can be supported to provide a wide range of services
Service brokers written to standards can be included in any cloud provider’s Kubernetes platform, making it easy for Oracle and non-Oracle platforms to consume Oracle services
Can include the new OpenPaaSServiceBroker to provision PaaS services
Oracle Confidential – Internal/Restricted/Highly Restricted

22. Oracle’s proposal of the solution
Confidential – Oracle Internal/Restricted/Highly Restricted

23. Oracle Strategy for Container Based Infrastructure
Complete
Open
Managed Services
Deliver container services that are complete, integrated and open
Continuous Integration & Deployment, Registry, Orchestration/Scheduling, Management/Operations, Analytics/Introspection
With an application development platform for serverless and microservices
Actively participate in com- munity driven open source container technologies
Investing in Kubernetes, Docker, Fn, & CNCF, with engineering resources, code contributions & sponsorships
Active support from Oracle’s portfolio of open source assets (Java, etc.)
Differentiate on quality of service and operational excellence
Full, transparent management
Deployed to Oracle Cloud Infrastructure
Enterprise grade performance, security, HA, and governance

24. Oracle Cloud Infrastructure and Kubernetes
Roll Your Own, Pre-Built Installer, Managed Service
Quickstart Experience OSS Terraform Installer on GitHub
OCI
OCI Container Engine
for Kubernetes (OKE)
DIY Container Management
Self Managed Kubernetes Service
Enterprise Class Managed Kubernetes Service
IaaS
CaaS

25. Introducing Container Engine for Kubernetes - OKE
What is It?
Managed Kubernetes container service to deploy and run your own container based apps
Tooling to create, scale, manage & control your own standard Kubernetes clusters instantly
What Problems Does it Solve?
Too complex, costly and time consuming to build & maintain Kubernetes environments
Too hard to integrate Kubernetes with a registry and build process for container lifecycle management
Too difficult to manage and control team access to production clusters
Formal name: Oracle Cloud Infrastructure Container Engine for Kubernetes
Enables developers to get started and deploy containers quickly, DevOps teams with Kubernetes management, visibility and control.
Combines production grade container orchestration of open Kubernetes, with control, security and high predictable performance of Oracle’s next generation OCI cloud infrastructure
Key Benefits
Enables developers to get started and deploy containers quickly. Gives DevOps teams visibility and control for Kubernetes management.
Combines production grade container orchestration of open Kubernetes, with control, security, IAM, and high predictable performance of Oracle’s next generation cloud infrastructure

26. Kubernetes Platform Services Goals
Simplify the experience for the average Enterprise developer building Kubernetes-based microservices on OKE/OCI
Lower the barrier to entry
Similar model to what we did for Java EE with Oracle customers
Deliver a set of tools, integrations and new services that makes OKE a richer platform to Build, Deploy  and Operate containerized applications and workloads. 
Confidential – Oracle Internal/Restricted/Highly Restricted

27. Kubernetes Platform Services on OKE
Initiatives in the initial phase 
Helm Workflow Manager
Enhanced industrial strength Workflow Manager complementing OKE cluster lifecycle
Foundational component for MPK
Service Catalog
In Cluster Service Catalog and OSB based Service Broker enabling binding OCI Services 
Add on Store
Integration with OCI Marketplace for Add Ons enabling installing OSS components on OKE
Managed Istio / Istio  via Add Ons catalog
Out of the box support for Istio on OKE clusters
Available as a Add On in the short term
Telemetry and Logging - Sauron
Container Native integration for Prometheus and ELK stack ( CNCF tools
Drive the installation and management of components to an OKE cluster
Reliable workflow based on Helm
Enable installation of components  during cluster creation as well additional components from the Add On store on an existing cluster
Foundational component for 
Istio,
Service Broker 
Event Broker
Extend the OCI Market place to host OSS components which are Kubernetes native
Enables applications to use components that are not yet available as managed services
E.g. Caching layer, OSS queuing layer
Integrate with Helm Workflow Manager to deploy and manage these components on OKE
Extend the Market place UI
Oracle Confidential – Internal/Restricted/Highly Restricted

28. Planned ACCS Updates EARLY DESIGN PHASE Build as OCI-native service
Built on top of Kubernetes Platform Services
We handle deployment, keeping it running and provide logs and curated set of metrics
Provide service bindings to other services inside or outside of OCI
Support “bring your runtime” and “create your container from source” scenarios
Oracle Confidential – Internal