direc>onsindistributedcompu>ng · •...

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

Direc>ons in Distributed Compu>ng

Robert Shimp Group Vice President August 23, 2016


Safe Harbor Statement

The following is intended to outline our general product direc>on. It is intended for informa>on purposes only, and may not be incorporated into any contract. It is not a commitment to deliver any material, code, or func>onality, and should not be relied upon in making purchasing decisions. The development, release, and >ming of any features or func>onality described for Oracle’s products remains at the sole discre>on of Oracle.

3


Core Business Func>ons Are Moving Systems of Record Moving From Your Datacenter to the Public Cloud

Op>mized for Transac>on processing Decision support Content management

4

Enterprise Resource Planning

Marke@ng & Sales

Enterprise Performance Management

Human Capital Management

Talent Management

E-‐Commerce

Service & Support

Supply Chain Management

Manufacturing


Frees Up Your Datacenter And Staff For Innova>ve Applica>ons New Ways to Deliver Content, Interact with the World, Control Your Environment

Cloud Is The Core. Your Datacenter Is The Edge.

Systems of Engagement •  Peer-‐to-‐peer social and mobile applica>ons

•  Virtual reality / rich media applica>ons

Systems of Control •  Real-‐>me control / Internet of Things

5


Intelligence At The Edge Of The Network By 2020

6.1 Billion People will have a smartphone

$1.7 Trillion IoT Market

20.8 Billion Connected Devices

500 smart devices In a typical family home

6


Will Stress The Limits Of The Internet

Hyper-‐Scale Public Cloud

•  10’s of Billions of intelligent devices and users are not all going to directly connect to hyper-‐scale public clouds •  Too expensive •  Too slow (network latency) •  Too much data to manage

•  The world will move to distributed applica>on architectures for: •  Systems of Engagement •  Systems of Control

7


Different Applica>ons Need Different Levels Of Service

8

Hyper-‐Scale Public Clouds

Core Front/Back Office Systems of Record

OLTP/DSS

Small Distributed Clouds

Systems of Engagement

Local Interac@ve Services

Systems of Control

Real-‐Time Services


Many Ini>a>ves To Overcome Internet Latencies

Mesh Networks

5G Networks HTTP/2

Cloudlets

9


HTTP/2

•  HTTP/1.1 requests have a lot of overhead ─  Browsers have used mul>ple TCP connec>ons to issue parallel requests ─  If too many requests are made, it hurts network performance

•  HTTP/2 addresses these problems ─  Data compression of HTTP headers ─  HTTP/2 Server Push ─  Pipelining of requests ─  Fixing the head-‐of-‐line blocking problem in HTTP 1.x ─  Mul>plexing mul>ple requests over a single TCP connec>on

10


Next Genera>on 5G Communica>on Networks

•  Exis>ng cellular networks, e.g. 4G/LTE, are challenged by IoT devices –  A bandwidth-‐constrained network –  IoT devices generate frequent bursty messages, which is expensive –  As the network slows this impacts the limited bagery life of IoT devices

•  5G addresses this with 10,000 >mes more capacity compared to 2010 –  Offers network ‘slices’ available on a priority basis to services –  Enables operators to create an instance of an en>re network virtually

11

5G


Latency Also Can Be Addressed By Distributed Compu>ng Architectures

Peer-‐to-‐Peer Leaf-‐Spine

12

Hierarchical


Cloudlets Compute Resources Distributed Closer to Data

•  A new architectural element that arises from the convergence of mobile compu>ng and cloud compu>ng – Middle >er of a 3-‐>er hierarchy: intelligent device -‐-‐-‐ cloudlet -‐-‐-‐ cloud –  Can be viewed as a "data center in a box" whose goal is to bring the cloud closer to the device

•  Four key agributes –  Small, low-‐cost, maintenance-‐free appliance design •  Powerful, well-‐connected and safe

– Maintains only soj state •  Built for microservices and containers

–  Located at the edge of the network –  Built with standard cloud technology

Cloudlet

13


Example Cloudlet Implementa>ons Many Strategies for Implemen@ng Distributed Infrastructure

Branch Offices, Retail Outlets, Hospitals, Etc.

Global Data Centers @ Cloud Service Providers

5G

Cell Phone Towers or Other Distributed Network Points

14


Mesh Networks

•  Devices can instantly share informa>on •  Eliminates, when possible, the latency and power bogleneck introduced by cellular radios

•  By serving user requests on the actual device, mesh networks can mi>gate pressure on cellular networks

•  Since the service resides on the device, private informa>on can be stored on the device and possibly protect informa>on beger

15


Always-‐On Device-‐To-‐Device Proximal Discovery And Communica>on

Direct Communica@ons Between Devices

16


Example: Concert In The Park Real-‐Time Geo-‐Centric Video Sharing

Share live video feeds between concert-‐goers

17


Next Gen Systems Of Engagement In A Hyper-‐Connected World Intelligent Devices at the Edge of the Network are Aware of the User and Surroundings

Discovers things relevant to you.

Senses your environment and

mo@on.

Learns your preferences.

Filters for things relevant to you.

Knows you and what’s around you.

Interacts with your surroundings.

Source: Qualcomm

18


Not Just People, Devices Too Next Gen Systems of Control

Discovers things relevant to the

device.

Senses the device’s environment and

mo@on.

Learns the device’s opera@ons.

Filters for things relevant to the

device.

Knows the device’s capabili@es.

Interacts with the device’s surroundings.

19


N-‐Tier Cloud Infrastructure Architecture Puts Services And Data As Close As Possible To The Consumer

20

Public Clouds

Private Clouds

Cloudlet 1

Cloudlet N

Oracle, AWS, Azure, …

WAN

Mesh Networks

5G


Which Will Lead To Many New Distributed Applica>ons

Con@nuous Discovery

•  Social Discovery •  Retail Discovery •  Event Discovery •  Service Discovery

Personalized Interac@ons •  Loyalty Programs •  Reverse Auc>ons •  Digital Out of Home •  Personalized Services

Automated Transac@ons •  Financial Seglement •  Import/Export •  Supply Chain Management

Distributed Control •  Traffic Management •  Construc>on • Manufacturing •  Agriculture

21


How Will Distributed Applica>ons Be Built?

Microservices • Minimal func>on services • Deploy each independently • Has its own datastore • Organized around business • State is externalized

Containers • Environmentals built in • Quick to download • Fast to start up • Disposable

22

•  Small single-‐purpose services are easier to deploy

•  Small footprint fits well with smaller distributed sites

•  Don’t patch or update the code, replace it

•  Fast start up – microseconds to start


Microservices Forces Move To Distributed Compu>ng Introduces Enormous Complexity – Monoliths Don’t Suffer From This

23

API

Applica@on

Datastore

Infrastructure

API

Applica@on

Datastore

Infrastructure

API

Applica@on

Datastore

Infrastructure

API

Applica@on

Datastore

Infrastructure

Microservice A Microservice B Microservice C Microservice D

•  Distributed compu>ng is a natural consequence of microservices because each microservice has its own data store.

•  Sharing data stores 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 data stores across microservices

•  Must implement high-‐speed messaging between microservices. REST + HTTP probably isn’t fast enough

•  May end up duplica>ng data across data stores – e.g. a customer’s profile


Rules of Distributed Compu>ng Computer Science is About Trade-‐offs

Consistency Each node shows the same data at all /mes Availability Each node is available for writes at all /mes Par@@on Tolerance Able to handle network outages

CAP Theorem – Pick Any Two

C

A P

Theory

Pick Any Two

Prac@ce Pick Either Consistency or Availability Par//on Tolerance is non-‐nego/able because we have networks that can always fail Enterprise IT Systems: Ojen CP Microservice Systems: Ojen AP Each microservice can be CP, AP or CA but the system as a whole is always CP or AP

24


•  Developers care because: –  Quickly create ready-‐to-‐run packaged applica>ons

–  A clean, safe, hygienic, portable run>me environment

–  No missing/conflic>ng dependencies or packages

–  Each app runs in an isolated container –  Automate tes>ng, integra>on, packaging –  Reduce/eliminate plavorm compa>bility issues –  Cheap/zero cost deployment, with instant replay and reset

•  Administrators care because: –  Configure once, run many >mes – Makes app lifecycle efficient, consistent and repeatable

–  Eliminate environment inconsistencies between development, test, produc>on

–  Supports segrega>on of du>es –  Improve speed and reliability of con>nuous integra>on and deployment

–  Lightweight containers address performance, costs, deployment and portability issues

25

Why Should IT Care About Containers?


Applica>on Containers Developed, Staged And Pushed To Users Based On Applica>on Type And Loca>on

Delivery

Cloudlet 1

Cloudlet N

Cloudlet 2

Ar>factory Ar>factory Ar>factory QA & Staging

Public & Private Clouds

Developer Cloud

Deploy ar>facts & BOM

Deploy to Produc>on

26

5G


Pillars Of A Complete Solu>on

Providing an immutable Infrastructure focused on containers

Applica>on portability through use of industry standards and best of breed solu>ons

Managing the lifecycle of containers: building, publishing, orchestra>on, repor>ng and audi>ng

Ensure the infrastructure and deliverables are secure

27


Immutable Infrastructure Developing the Right Host Image

• Provide an immutable OS designed for applica>ons running in containers – It is one part of emerging ideas around programmable infrastructure

•  Small footprint – Reduce security risk by elimina>ng the number of packages

• No tradi>onal patching – Simply replace the base while leaving container image(s), metadata and any persistent content intact

The right host image is key to crea>ng immutable infrastructure

28


Minimal Host Image: Least Number Of Packages And Space

29

0 50 100 150 200 250 300

VMWare Photon

CoreOS

Red Hat Atomic

Ubuntu Snappy

RancherOS

Instance Size (MB)

Source: Inovex, May 2015


Various Upda>ng Strategies For Minimal OS’s

•  Red Hat Atomic –  New directory structure with update system rpm-ostree (includes rollback features)

•  CoreOS –  Par>>on based model (Ac>ve|Passive) – updates are automa>cally sent to the passive par>>on which is promoted to ac>ve at the >me of reboot (includes rollback)

•  RancherOS –  Base Linux Kernel with all other components managed as Docker containers –  The System Docker containers replaces tradi>onal Linux init systems like systemd –  The Docker container is launched by System Docker and manages all user containers –  Two persistent directories: /home and /opt –  Updates done using Docker container commands

30


Applica>on Portability

•  Containers offer the best possible op>on for true applica>on portability between clouds •  Open Container Ini>a>ve is an open project, formed under the auspices of the Linux Founda>on, for the express purpose of crea>ng open industry standards around container formats and run>me


Containers Are A New Security Challenge •  Pets vs. cagle – you don’t patch, you replace • Who is the gatekeeper – Developer? Opera>ons?

• What tools provide informa>on to query report for compliance and what ac>on can be taken if there is a risk? –  Isolate the container? –  Stop the container? –  No>fy the developer?

•  Is hot patching s>ll needed in an immutable infrastructure?

• Will standard Linux tools provide value? –  OpenSCAP –  SELinux

32


Containers Enable Beger Management Of Distributed Systems Can Eliminate Manually Fixing Problems In no case should an administrator fix issues by hand. Should be 100% automated

Auto-‐scaling will automa>cally launch a new container on new hardware as load dictates

Hardware Failure Example: motherboard failed

Auto-‐scaling will automa>cally launch new containers as load dictates

Network Failure Example: switch failed

Health checking should fail and the container will be culled. Auto-‐scaling will automa>cally launch a new container as load dictates

System Sofware Failure Example: kernel panic

Applica@on Sofware Failure Example: bad file permissions

Fix the source (your applica>on, your container, your Dockerfile, etc) and re-‐deploy your en>re applica>on

33


How Will Distributed Systems Be Managed? OpenStack Cloud Management Sofware

OpenStack Shared Services Layer

Horizon Dashboard

APIs

Compute Services

Networking Services

Storage Services

Systems, Networks and Storage

Other Services

Your Applica>ons

34


Managing Distributed Infrastructure OpenStack and Containers

•  The OpenStack community is developing a service, Magnum, for enabling containers as a 1st class resource in the OpenStack framework (like VMs) • Magnum, by itself, is not a container orchestra>on u>lity •  It depends on a backend container orchestra>on engine (COE) – currently support is enabled for Kubernetes and Swarm

35

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

More than 80% of enterprise IT organiza>ons will commit to hybrid cloud architectures by 2017, vastly driving the rate and pace of change in IT organiza>ons.

-‐-‐ IDC, 2015

80%


Summary •  Execu>ve recogni>on of the importance of a distributed compu>ng strategy (in addi>on to centralized SaaS/PaaS strategy) – Business value – Technology requirements

•  Ins>tu>on of a Dev-‐Ops capability •  Examina>on of business process and infrastructure requirements • Plan the implementa>on and matura>on model

37

direc>ons*in*distributed*compu>ng* · •...

Documents

direc>onsindistributedcompu>ng · •...