MongoDB World 2016: MongoDB + Google Cloud

Confidential & ProprietaryGoogle Cloud Platform 1

MongoDB + Google CloudEric BrewerVP Infrastructure, Google

Confidential & ProprietaryGoogle Cloud Platform 2Confidential & ProprietaryGoogle Cloud Platform 2

Brief History of SQL/NoSQL1960 1965 1970 1975 1980 1985 1990 1995 2000 2005 2010 2015 Today

Pre-SQL

• Programming and data are tightly integrated • One kind of developer • More control

SQL

• Strong data model • Two kinds of developers • Invariants first (ACID)

NoSQL

• Back to tight integration • One kind of programmer • Both models make sense


NoSQL is essential to the rapid evolution of cloud native datasets & applications.

The Rise of NoSQL

Delivers required control for Highly Available

Applications

Bottom-up Layering: Unix systems view

applied to data management


Continuous Evolution

High availability makes continuous evolution extremely challenging.

The ability to continuously improve and modify a production application, through many, small changes...without taking it down.


Continuous EvolutionDrive incremental improvements to a production system

In-Production ChangeRollback

In-Production Change

TIME

VERSION

Confidential & ProprietaryGoogle Cloud Platform 6Google Cloud Platform 6

Building block: Sets of Containers

Containers● Handle package dependencies● Different versions, same machine● No “DLL hell”

Pods● Co-locate containers● Shared volumes● IP address, independent port space● Unit of deployment, migration

/data

Pod

MyServicepython 3.4.2

glibc 2.21

MySQLpython 2.7.9

glibc 2.19

Confidential & ProprietaryGoogle Cloud Platform 7Google Cloud Platform

Unit of deployment: Services

Service:● Replicated pods• Source pod is a template

● Auto-restart member pods● Abstract name (DNS)• IP address for the service

● Load balancing among replicas

Load Balancer

Service IP


replicas: 1

replicas: 0

replicas: 3

replicas: 2

replicas: 4

Example: Rolling Upgrade with Labels

Pods:

Labels:

frontend

v1.3

frontend

v1.3

frontend

v1.3

Replication Controller

v1.3replicas:

1

v1.2

Replication Controller frontend

replicas: 2

replicas: 3

frontend

v1.3

frontend

v1.2

frontend

v1.2

frontend

v1.2

frontend

v1.2

replicas: 4

Load Balancer


How do we do the same for stateful that we’ve done for

stateless?


Stateful Services (in Kubernetes 1.3)

Persistent resolvable name: e.g. UserDB-Mongo-2● Persistent ⇒ Name stays as pod comes/goes● Resolvable ⇒ other replicas can find this one

Clean initialization:● An init hook — recover or initialize state● Staggered start for replica groups

Persistent volumes and claims● Persistent volumes reliably keep state (magic disks!)● Claim ensures you mount the same volume on restart


Driving Continuous Evolution for Stateful ServicesCore idea: schema/API upgrade must be a reality● Easy: API, schema version numbers● Clients need version awareness/negotiation

Servers require automated way to convert data to new version● Atomically● Partition data by key (to enable incremental conversion)● Must be able to roll back partial changes● Ideally this would be automated


Today: Deployment Manager support for MongoDB Cloud Manager.

Just Announced: Google Cloud Platform support in MongoDB Atlas coming soon!

MongoDB and Google Cloud Platform

Atlas


MongoDB in the Google Cloud Ecosystem

BigQuery Cloud ML


At MongoDB World: Learn More

‣

‣

Attend Sandeep’s TalkRunning MongoDB on GCP – Sandeep ParikhWednesday 3:10 - 3:50 PM, Nassau

Learn More About GCP ServicesCodelabs

http://drive.google.com/a/google.com/open?id=1uhhJv9nYGfsqyyrK_WdEc0CzAq_10ToWch1o1r6Y-hY


Thank You

MongoDB World 2016: MongoDB + Google Cloud

Technology

Transcript of MongoDB World 2016: MongoDB + Google Cloud