Techtonic Summit NYC

Data Center Futures

Bob Wise Samsung SDS Research America

Copyright © 2015 Samsung SDS Co., Ltd. All rights reserved

2


This presentation is intended to provide information concerning Samsung’s efforts around containers and container orchestration. We do our best to make sure that information presented is accurate and fully up-to-date. However, the presentation may be subject to technical inaccuracies, information that is not up-to-date or typographical errors. As a consequence, Samsung does not in any way guarantee the accuracy or completeness of information provided on this presentation. Samsung reserves the right to make improvements, corrections and/or changes to this presentation at any time.

The information in this presentation or accompanying oral statements may include forward-looking statements. These forward-looking statements include all matters that are not historical facts, statements regarding the Samsung Data System' intentions, beliefs or current expectations concerning, among other things, market prospects, growth, strategies, and the industry in which Samsung operates. By their nature, forward-looking statements involve risks and uncertainties, because they relate to events and depend on circumstances that may or may not occur in the future. Samsung cautions you that forward looking statements are not guarantees of future performance and that the actual developments of Samsung, the market, or industry in which Samsung operates may differ materially from those made or suggested by the forward-looking statements contained in this presentation or in the accompanying oral statements. In addition, even if the information contained herein or the oral statements are shown to be accurate, those developments may not be indicative developments in future periods.

Logos remain the property of their respective owners. So there.

3


This presentation is intended to provide information concerning Samsung’s efforts around containers and container orchestration. We do our best to make sure that information presented is accurate and fully up-to-date. However, the presentation may be subject to technical inaccuracies, information that is not up-to-date or typographical errors. As a consequence, Samsung does not in any way guarantee the accuracy or completeness of information provided on this presentation. Samsung reserves the right to make improvements, corrections and/or changes to this presentation at any time.

The information in this presentation or accompanying oral statements may include forward-looking statements. These forward-looking statements include all matters that are not historical facts, statements regarding the Samsung Data System' intentions, beliefs or current expectations concerning, among other things, market prospects, growth, strategies, and the industry in which Samsung operates. By their nature, forward-looking statements involve risks and uncertainties, because they relate to events and depend on circumstances that may or may not occur in the future. Samsung cautions you that forward looking statements are not guarantees of future performance and that the actual developments of Samsung, the market, or industry in which Samsung operates may differ materially from those made or suggested by the forward-looking statements contained in this presentation or in the accompanying oral statements. In addition, even if the information contained herein or the oral statements are shown to be accurate, those developments may not be indicative developments in future periods. Logos remain the property of their respective owners. So there!

4

Here’s a future that sucks… •  Deploy some Openstack •  Deploy some VMware •  Deploy some Mesos for Hadoop and Spark •  Deploy some Cloud Foundry on Openstack •  Deploy some Cloud Foundry on metal •  Use AWS but get locked into their very nice services •  Use some GCE •  Deploy dedicated Unix/Windows/Linux •  Throw swarm, kubernetes, GKE, and ECS into the mix for good measure. Run some on Mesos, some on Openstack.

•  Run some Mesos on Openstack for good measure.

Copyright © 2015 Samsung SDS Co., Ltd. All rights reserved 5

More suck… •  Build experTse on all of those systems… $$$, if you can even do it.

•  Pay lots for support since you have too many different distributed systems

•  Try to figure out how to log, alarm, debug all of that.

•  Try to figure out how secure all of that •  Try to manage complexity by assigning each system it’s own dedicated cluster

•  Enjoy < 10% system uTlizaTon •  Have unsaTsfied customers due to reliability and performance issues.


•  70% Datacenter uTlizaTon

•  MulTple releases a day / CD

•  10,000-‐40,000 servers per admin

•  DestrucTve tesTng in producTon

•  No-‐ops (Self service deployment)

•  Go very fast and break nothing

•  Commodity hardware

•  Extremely low licensing spend (open source)

•  Comprehensive AutomaTon

•  Extensive AnalyTcs

High Bar -‐ Industrial Grade Compute

#GIFEE

Yeah, we want that!


Control and Risk Risk reducTon is about control Vendor lock-‐in is loss of control More control leads to lower cost

Open Source + Samsung Engineers = Control

Goal…

10

Standardize, Containerize, Deploy

…to Samsung Data Centers.

…to developer systems for agility and producTvity.

…to public virtual machine clouds. …to new and even more efficient public container clouds.

Open Source ContainerizaTon •  Breaking vendor lock to expensive proprietary soluTons •  More efficiency in data center uTlizaTon

•  Easier path to commodity compute / white box infrastructure

•  Greater portability to and from public cloud systems

•  More agility in development and deployment

•  Rapid development and deployment

•  Deployment freedom/portability

•  Scaleup/Scale down •  Lowest possible cost deployments (capex and opex)

Strategic Elements •  The dedicated cluster is dead. •  Collorary: We need large shared clusters. •  Only one kind of turtle at the bolom

– AWS Turtles or Google Turtles? –  StandardizaTon –  CommodiTzaTon – AutomaTon – Do one thing well, keep it as simple as possible

•  Need to support legacy applicaTon porTng and cloud naTve

•  Control: Open source, no lock-‐in


ExecuTon


Target Data Center Stack

Bare Metal

Container-‐opTmized host

Container Mgr

Container OpTmized Clustering and Resource AllocaTon

PaaS apps Java/Scala

Ruby Web Dev

Non-‐PaaS Apps Back end processing

Legacy Apps 3rd Party

Public Cloud Bare Metal


Container Mgr



Container Mgr

Public Cloud

PaaS Cluster

PaaS Cluster

RelaTonal DB

Big Data DB

AnalyTcs Cluster

Big Data DB

AnalyTcs Cluster

Apps

Apps

Databases and Analy>cs Hadoop

Non-‐SQL DB (Cassandra, Mongo, etc) SQL DB (MySQL, Postgress, etc)

Container OpTmized Network

Target Data Center Stack

Bare Metal


Container Mgr

Container OpTmized Clustering and Resource AllocaTon

PaaS apps Java/Scala

Ruby Web Dev

Non-‐PaaS Apps Back end processing

Legacy Apps 3rd Party



Container Mgr



Container Mgr

Public Cloud

PaaS Cluster

PaaS Cluster

RelaTonal DB

Big Data DB

AnalyTcs Cluster

Big Data DB

AnalyTcs Cluster

Apps

Apps

Databases and Analy>cs Hadoop

Non-‐SQL DB (Cassandra, Mongo, etc) SQL DB (MySQL, Postgress, etc)

Container OpTmized Network

Container OpTmized •  Container OpTmized Hosts

–  Very small footprint – only what is needed to run containers –  Very fast booTng –  Very fast update – security requires up-‐to-‐date infrastructure –  Examples: –  CoreOS –  Atomic (Redhat) –  Snappy (Ubuntu) –  RancherOS

•  Container OpTmized Network –  Explosion of IP addresses: IP Address per container –  IPV6

•  Container OpTmized OrchestraTon –  High rate of container start/stop –  Higher density per server

“Opinionated” Cats Ahead…


Wrong Turtles at the Bolom


Openstack

Kubernetes

Upside Down


Kubernetes

Swarm

Much More Sensible


Swarm

Kubernetes

Turtles Stacked Too Deep


Openstack

Kubernetes

Mesos

Kubernetes is not a PaaS.

Type I Kubernetes User: Wants to manage a single app Type II Kubernetes User: Wants to manage data centers

Beler


Openstack

Kubernetes Mesos

Beler sTll…


Mesos

Openstack Kubernetes

Where we are headed…


The VMs, too. In containers.

Mesos Openstack Swarm

Kubernetes

PaaS

Strategic Conclusion


There Can Be Only One*

* For each enterprise. IF you really want GIFEE.

OpTon: Openstack •  MulTple support opTons – no support lockin. •  Wrong type of turtle •  Burdened by featuriTs

–  Collorary: Not keeping it simple

•  Lack of strong technical leadership •  Known issues at scale •  Too much religious fervor

– Nobody expects the Pythonistas! •  Have used this in produc3on, opinion is qualified.


OpTon: Mesos •  A decent choice, proven track record at scale •  Single vendor contributor ecosystem

–  Feels like lock-‐in to Mesosphere if you want commercial support

–  Confusing posiTon from Mesosphere vs DCOS •  Complex and needing significant experTse to configure

operate –  …but beler than openstack!

•  Good ecosystem around big data (Spark, Hadoop) •  Roots in scienTfic compuTng, not modern service

development…. –  Container networking –  Service discovery

•  Have not used this in produc3on.


OpTon: Swarm •  Not really in the same category as these other systems, but Docker seems headed that way

•  Really a deployment tool, not a cluster management system

•  Not suitable for large scale •  Single vendor dominated •  Support for APCC, RKT, etc seems challenged. •  Very small contributor base •  Wouldn’t consider using this in produc3on at scale, so opinion is unlikely to change for a while.


Choice: Kubernetes •  Good design by a vibrant, healthy community

–  MulT-‐contributor •  Built from scratch for modern service develop/deploy

–  Pods are the right abstracTon •  Rapid pace of improvement

–  Behind Mesos at point in Tme, but higher velocity –  Our “Best Future” bet

•  MulT-‐vendor support opTons (no support lock-‐in) –  STll nascent.

•  Great contributors with the right experience •  Best high scale public cloud container opTon

–  Google Container Engine •  Supports mulTple container specs: Docker and APCC

29

Kubernetes Concerns •  CNCF is the right direcTon, but slow gevng off the ground. •  Featuri3s risk is ever present. •  We are concerned and will con3nue to push as priori3es:

–  HA –  Scaling –  Reliability –  OperaTons tooling

•  Accessibility for new users is criTcal to ecosystem health: –  Quick start –  DocumentaTon –  UIs

•  Looking forward to more companies in the direct support ecosystem.

30

A Few Words About PaaS

•  We need to support mulTple PaaS frameworks.

•  We do not want to dedicate clusters to each PaaS system. – Cloud Foundry / Diego/ BOSH

•  PaaS workload needs to shared with other workloads

•  A PaaS should not be in the container scheduling business!


A Few More Words About PaaS

•  Cloud Foundry needs to rebase to Kubernetes (and Mesos) to live in this world. – Ditch BOSH – Ditch Diego – Focus on value up the stack rather than down.

•  Kudos to Deis, Apache Stratos, and OpenShiw


SDSA Ref Architecture EvoluTon

CoreOS

Docker

Kubernetes 1.1+

AWS

Flannel

Apps

Terraform

Ansible

1000 Node Stack Baseline

OpTmized OS

Container

OrchestraTon

Compute

Networking

Provisioning

Samsung Kubernetes Engagement

•  We are not forking •  We are pushing back our work either into kubernetes or into our github repo – Samsung-‐AG.

•  2016 – more work on networking and storage, with 1000 node clusters as the baseline


Why are we involved in K8Scale?

•  We want very large clusters with cross applicaTon resource sharing – Also looking forward to Ubernetes

•  We believe we can make a posiTve contribuTon to make this happen faster and beler.

•  We believe we need deep technical involvement to build/deploy/operate at scale.

•  We learn by doing.


Contact Info

[email protected] bobwise on kubernetes slack hlps://github.com/Samsung-‐AG Sealle, WA

(Please reach out if interested in K8scale as well)


Technology

Techtonic Summit NYC