Direc>ons in Distributed Compu>ng

Transcription

1

2 Direc>ons in Distributed Compu>ng Robert Shimp Group Vice President August 23, 2016 Copyright 2016 Oracle and/or its affiliates. All rights reserved.

3 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

4 Core Business Func>ons Are Moving Systems of Record Moving From Your Datacenter to the Public Cloud Enterprise Resource Planning Supply Chain Management Enterprise Performance Management & Sales Manufacturing E- Commerce Service & Support Human Capital Management Talent Management Op>mized for Transac>on processing Decision support Content management 4

5 Frees Up Your Datacenter And Staff For Innova>ve Applica>ons New Ways to Deliver Content, Interact with the World, Control Your Environment 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 Cloud Is The Core. Your Datacenter Is The Edge. 5

6 Intelligence At The Edge Of The Network By Billion Connected Devices $1.7 Trillion IoT Market 6.1 Billion People will have a smartphone 500 smart devices In a typical family home 6

7 Will Stress The Limits Of The Internet 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 Hyper- Scale Public Cloud 7

8 Different Applica>ons Need Different Levels Of Service Small Distributed Clouds Hyper- Scale Public Clouds Systems of Control Real- Time Services Systems of Engagement Local Services Core Front/Back Office Systems of Record OLTP/DSS 8

9 Many Ini>a>ves To Overcome Internet Latencies HTTP/2 5G Networks Mesh Networks Cloudlets 9

10 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

11 Next Genera>on 5G Communica>on Networks 5G 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

12 Latency Also Can Be Addressed By Distributed Compu>ng Architectures Hierarchical Leaf- Spine Peer- to- Peer 12

13 Cloudlets Compute Resources Distributed Closer to Data Cloudlet 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 13

14 Example Cloudlet Implementa>ons Many Strategies for Distributed Infrastructure 5G Global Data Cloud Service Providers Cell Phone Towers or Other Distributed Network Points Branch Offices, Retail Outlets, Hospitals, Etc. 14

15 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

16 Always- On Device- To- Device Proximal Discovery And Communica>on Direct Between Devices 16

17 Example: Concert In The Park Real- Time Geo- Centric Video Sharing Share live video feeds between concert- goers 17

18 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. Filters for things relevant to you. Senses your environment and mo@on. Interacts with your surroundings. Learns your preferences. Knows you and what s around you. Source: Qualcomm 18

19 Not Just People, Devices Too Next Gen Systems of Control Discovers things relevant to the device. Filters for things relevant to the device. Senses the device s environment and mo@on. Interacts with the device s surroundings. Learns the device s opera@ons. Knows the device s capabili@es. 19

20 N- Tier Cloud Infrastructure Architecture Puts Services And Data As Close As Possible To The Consumer Cloudlet 1 Public Clouds Oracle, AWS, Azure, 5G WAN Mesh Networks Cloudlet N Private Clouds 20

21 Which Will Lead To Many New Distributed Applica>ons Discovery Social Discovery Retail Discovery Event Discovery Service Discovery Distributed Control Traffic Management Construc>on Manufacturing Agriculture Personalized Loyalty Programs Reverse Auc>ons Digital Out of Home Personalized Services Automated Financial Seglement Import/Export Supply Chain Management 21

22 How Will Distributed Applica>ons Be Built? Microservices Containers Minimal func>on services Deploy each independently Has its own datastore Organized around business State is externalized Environmentals built in Quick to download Fast to start up Disposable 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 22

23 Microservices Forces Move To Distributed Compu>ng Introduces Enormous Complexity Monoliths Don t Suffer From This Microservice A Microservice B Microservice C Microservice D API Applica@on Datastore Infrastructure API Applica@on Datastore Infrastructure API Applica@on Datastore Infrastructure API Applica@on Datastore Infrastructure 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 23

24 Rules of Distributed Compu>ng Computer Science is About Trade- offs A CAP Theorem Pick Any Two C Pick Any Two P Theory 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 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

25 Why Should IT Care About Containers? 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

26 Applica>on Containers Developed, Staged And Pushed To Users Based On Applica>on Type And Loca>on Cloudlet 1 Cloudlet 2 5G Delivery Deploy to Produc>on Developer Cloud Cloudlet N Ar>factory QA & Staging Deploy ar>facts & BOM Public & Private Clouds 26

27 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

28 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

29 Minimal Host Image: Least Number Of Packages And Space Instance Size (MB) RancherOS Ubuntu Snappy Red Hat Atomic CoreOS VMWare Photon Source: Inovex, May

30 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

31 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

32 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

33 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 Hardware Failure Example: motherboard failed Auto- scaling will automa>cally launch a new container on new hardware as load dictates Network Failure Example: switch failed System Sofware Failure Example: kernel panic Applica@on Sofware Failure Example: bad file permissions Auto- scaling will automa>cally launch new containers as load dictates Health checking should fail and the container will be culled. Auto- scaling will automa>cally launch a new container as load dictates Fix the source (your applica>on, your container, your Dockerfile, etc) and re- deploy your en>re applica>on 33

34 How Will Distributed Systems Be Managed? OpenStack Cloud Management Sofware Your Applica>ons APIs Horizon Dashboard Compute Services Networking Services Storage Services Other Services OpenStack Shared Services Layer Systems, Networks and Storage 34

35 Managing Distributed Infrastructure OpenStack and Containers The OpenStack community is developing a service, Magnum, for enabling containers as a 1 st 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

36 80% 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,

37 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

38