Eric Brewer (VP Infrastructure, Google) on the Main Stage at SpringOne Platform 2017.

1. Building a
higher cloud
SpringOne Platform I December 7, 2017

2. Separating applications
from infrastructure

3. Low-level IaaS
● Raw VMs, network, and disk
● Completely general, but hard to use and too low level
● E.g. users must patch the OS
High-level PaaS
● Highly-abstracted developer experience
● May be opinionated, language or domain specific
Composable services based on Istio Containers

4. Kubernetes

5. Kubernetes: higher level of abstraction
Think about
● Composition of services
● Load balancing
● Names of services
● State management
● Monitoring and Logging
● Upgrading
Don’t worry about
● OS details
● Packages — no
conflicts
● Machine sizes (much)
● Mixing languages
● Port conflicts

6. Usage
S.O. posts,
blogs, meetups
Awareness Use cases
Tools, libraries,
extensions
Users Developers
Vendors
SolutionsGaps 32 Kubernetes
distributions and
platforms
59k+
GitHub stars
5,000+
projects based
on Kubernetes
132k+
Meetup
members
worldwide

7. 1 commit
/33 min
49,000
1 commit
/25 min
1,500Commits Contributors
In 2016 In 2017

8. The new cloud

9. The new cloud
Containers decouple applications from OS images
Services are the unit of deployment and upgrades
...and a good basis for high-velocity teams
Mix languages and frameworks easily
Decouple operations from development
● Keep operational details out of your source
code
Almost fully general, but much more productive
● VMs, OS details are there but mostly hidden
…and based on Open Source
INFRASTRUCTURE
This open design gives developers and
ops teams the widest possible range
of deployments

10. Users can implement services in
VM
Bare Metal
VM VM
Goal: Make it easy to create and consume services across clouds
and on premises
(Hybrid and multi-cloud)
Part of this is Open Service Broker, but the real key is Istio...

11. Istio

12. Envoy
HTTP/1.1, HTTP/2,
gRPC, TCP
HTTP/1.1, HTTP/2, gRPC,
TCP with or without TLS
Internet
svcA
Envoy
Pod
Envoy
Ingress Envoy
(ingress controller
in K8S)
Service A
svcB
Envoy
Service B
Egress Envoy
External
Services
Istio: Interposition on services
● Can mix services from CF & Kubernetes
● Services don’t need to know implementation
● Authenticate services to each other
Open-source version of many internal systems

13. Basic data path:
● Option mutual authentication
mTLS, SPIFFE
● Health checking
● Simple load balancing
Control path (start of request):
● Access control (using identity + other)
● Quota and rate limiting
● Service telemetry: monitoring, billing,
logging
● Fancy load balancing
Decoupled operations: none of these are in the source
code
Istio as an operations layer

14. Service management

15. “Pilot”
Controller that configures all Envoys
Enables uniform policies
E.g. new ACLs, change logging
Detects new pods and services
Reconfigures Envoy proxies
Also instantiates services found in OSB
Separate Istio Auth service manages keys Envoy Envoy Envoy Envoy
RulesAPI
Kubernetes
Mesos
CloudFoundr
y
...
Platform Adapter
Abstract Model
Envoy API
Service discovery
& traffic rules
Pilot

16. Kubernetes
services
Cloud Foundry
services
IaaS layer
Istio Service Mesh Open Service
Broker
ID, Groups,
UAA
Monitoring
logging
billing
Users or other services

17. Hybrid and multi-cloud

18. Two key ideas:
1. Open source enables consistency across
environments
○ Kubernetes, Istio, Tensorflow
2. Services are the unit of partitioning
○ Private data managed by on-prem services
○ Consume cloud services from anywhere
Some customers already do this with Apigee
Istio simplifies cross-environment
service management

19. Moving to the higher cloud

20. A broad, collaborative,
new definition of “cloud”
● Higher level of abstraction, containers and services
● Open source
● Multi-language, multi-framework
● Enabling general-purpose complex applications
● Higher velocity
● Decoupling development from operations
● Simplifying hybrid and multi-cloud deployments

21. Confidential & Proprietary
Google Cloud Platform credits for PCF
Customers