MongoDB and Cloud Foundry
A Match Made for the Cloud
Rick Ross
Advisory Platform Architect, Pivotal
June, 2018 Photo By J.D. Hancock
Agenda
■ Scaling Applications is Hard
■ Principles for Scaling Applications
■ Cloud Foundry
■ Leveraging MongoDB
■ Demo
■ Scaling the Application
■ Cloud Native Principles
■ Questions
Where will they run? vSphere Openstack
OnPremise
AWS Google
Cloud Azure
Public Cloud
Compute, Networking, Storage, OS, Firewalls, Monitoring,
etcWhat Infrastructure?
Data stores, Caching, Message Queues, etcWhat Backing Services?
Tomcat, WebLogic, WebSphere, IIS, etc.What Middleware?
How to scale the
application?
AppA AppA AppA
Horizontal Scaling
Scaling Questions
Scaling Applications is Hard!
• Never have done it before
• Learn the patterns – usually through research, trial & error
• Architectural & Infrastructure Decisions & Concerns
• Languages, Frameworks
• Clustering / Distributed Systems
• High Availability
• Data Store choices
• Session State
• And…
• Deploying Applications is Hard
Photo By J.D. Hancock
Cloud Native – What Does that Mean?
DevOps
● Common incentives, tools, and
processes builds a culture of
shared responsibility.
● Collaboration is paramount.
Continuous Delivery
● With automated tests, teams
release early and often.
● The results: higher quality
code and lower risk.
● There’s fewer bugs in
production.
Microservices
● Loosely coupled components
help teams deploy
independently.
● No more waiting for integrated
test teams.
Cloud Native Drives Complexity
DevOps Continuous
Delivery
Microservices
Development & Operational
Complexity
Multiple
Stakeholders Rapid Pace
Many Moving
Parts
vSphere Openstack AWS Google
Cloud
Azure &
Azure Stack
Infrastructure
Application Code & Frameworks
Spring Boot / Spring Cloud / .NET / Steeltoe
PAS
Pivotal Application
Service
PKS
Pivotal Container
Service
Operations
(Infrastructure Automation)
Contract: Cloud Provider Interface
Contract: BOSH Release
Pivotal Services
Marketplac
e
Pivotal and
Partner Products
Containers
Pre-Packaged Apps / Backing Services
Services in Cloud Foundry
• Backing Resource such as
• Data stores, Message Queues, Caches, etc.
• Managed & Unmanaged Services
• BOSH Managed or Externally Managed
• Service Broker
• Open Service Broker API - https://www.openservicebrokerapi.org/
• Services made available to developers
• Creating and Accessing Services Simplified
• MongoDB and Pivotal co-engineered
Cloud Foundry integration
• BOSH installs the Ops Manager agent
• Calls the Ops Manager API to provision,
configure, monitor & backup the cluster
• Enables users to integrate MongoDB as
an on-demand DBaaS resource within
Cloud Foundry platforms
Ops Manager
Cloud Foundry Integration
Atlas: The only true multi-cloud database as a service
Database as a service
Database that runs
the same everywhere
Consistent experience
across AWS, Azure,
and GCP
Coverage in
any geography
Deploy in over 50 regions
worldwide
Create globally
distributed databases
with a few clicks
Leverage the benefits
of a multi-cloud
strategy
Exploit the benefits of
AWS, Azure, or GCP
services on your data
Avoid lock-in
Easily migrate data
between cloud providers
Spring-Person Architecture
Spring-Person
REST API
Spring Boot (Java)
Pivotal Application Service
User Provided Service
Atlas URI
Accessing MongoDB Atlas
• IP Address Whitelisting Strategies
• Internet Access via a Proxy
• Limit via an Network Range
• Externalize the Configuration
• User Provided Service
• Use External Config Service
• Spring Cloud Config
Photo By J.D. Hancock
I. Codebase
One codebase tracked in SCM,
many deploys
II. Dependencies
Explicitly declare and isolate
dependencies
III. Configuration
Store config in the environment
VI. Processes
Execute app as stateless
processes
V. Build, Release, Run
Strictly separate build and
run stages
IV. Backing Services
Treat backing services as
attached resources
IX. Disposability
Maximize robustness with fast
startup and graceful shutdown
VIII. Concurrency
Scale out via the process
model
VII. Port binding
Export services via port
binding
XII. Admin processes
Run admin / mgmt tasks as
one-off processes
X. Dev/prod parity
Keep dev, staging, prod as
similar as possible
XI. Logs
Treat logs as event streams
12-Factor Applications
http://12factor.net https://content.pivotal.io/blog/beyond-the-twelve-factor-app
I. Codebase
One codebase tracked in SCM,
many deploys
II. Dependencies
Explicitly declare and isolate
dependencies
III. Configuration
Store config in the environment
VI. Processes
Execute app as stateless
processes
V. Build, Release, Run
Strictly separate build and
run stages
IV. Backing Services
Treat backing services as
attached resources
IX. Disposability
Maximize robustness with fast
startup and graceful shutdown
VIII. Concurrency
Scale out via the process
model
VII. Port binding
Export services via port
binding
XII. Admin processes
Run admin / mgmt tasks as
one-off processes
X. Dev/prod parity
Keep dev, staging, prod as
similar as possible
XI. Logs
Treat logs as event streams
12-Factor Applications
http://12factor.net https://content.pivotal.io/blog/beyond-the-twelve-factor-app
I. Codebase
One codebase tracked in SCM,
many deploys
II. Dependencies
Explicitly declare and isolate
dependencies
III. Configuration
Store config in the environment
VI. Processes
Execute app as stateless
processes
V. Build, Release, Run
Strictly separate build and
run stages
IV. Backing Services
Treat backing services as
attached resources
IX. Disposability
Maximize robustness with fast
startup and graceful shutdown
VIII. Concurrency
Scale out via the process
model
VII. Port binding
Export services via port
binding
XII. Admin processes
Run admin / mgmt tasks as
one-off processes
X. Dev/prod parity
Keep dev, staging, prod as
similar as possible
XI. Logs
Treat logs as event streams
12-Factor Applications
http://12factor.net https://content.pivotal.io/blog/beyond-the-twelve-factor-app
I. Codebase
One codebase tracked in SCM,
many deploys
II. Dependencies
Explicitly declare and isolate
dependencies
III. Configuration
Store config in the environment
VI. Processes
Execute app as stateless
processes
V. Build, Release, Run
Strictly separate build and
run stages
IV. Backing Services
Treat backing services as
attached resources
IX. Disposability
Maximize robustness with fast
startup and graceful shutdown
VIII. Concurrency
Scale out via the process
model
VII. Port binding
Export services via port
binding
XII. Admin processes
Run admin / mgmt tasks as
one-off processes
X. Dev/prod parity
Keep dev, staging, prod as
similar as possible
XI. Logs
Treat logs as event streams
12-Factor Applications
http://12factor.net https://content.pivotal.io/blog/beyond-the-twelve-factor-app
I. Codebase
One codebase tracked in SCM,
many deploys
II. Dependencies
Explicitly declare and isolate
dependencies
III. Configuration
Store config in the environment
VI. Processes
Execute app as stateless
processes
V. Build, Release, Run
Strictly separate build and
run stages
IV. Backing Services
Treat backing services as
attached resources
IX. Disposability
Maximize robustness with fast
startup and graceful shutdown
VIII. Concurrency
Scale out via the process
model
VII. Port binding
Export services via port
binding
XII. Admin processes
Run admin / mgmt tasks as
one-off processes
X. Dev/prod parity
Keep dev, staging, prod as
similar as possible
XI. Logs
Treat logs as event streams
12-Factor Applications
http://12factor.net https://content.pivotal.io/blog/beyond-the-twelve-factor-app
Scaling Options in Pivotal Cloud Foundry
• Scale the Platform
• Scale your applications
• Manually
• Auto Scaling – Via Schedule
• Auto Scaling – Via Metrics
• HTTP Throughput
• HTTP Latency
• CPU Usage
• Memory Usage
• RabbitMQ Depth
Where will they run? vSphere Openstack
OnPremise
AWS Google
Cloud Azure
Public Cloud
Compute, Networking, Storage, OS, Firewalls, Monitoring,
etcWhat Infrastructure?
Data stores, Caching, Message Queues, etcWhat Backing Services?
Tomcat, WebLogic, WebSphere, IIS, etc.What Middleware?
How to scale the
application?
AppA AppA AppA
Horizontal Scaling
Answering Your Scaling Needs
PAS
Pivotal Application
Service
Autoscaler
Buildpacks
Cloud Provider
Interface
What about Day 2 Operations?
• High Availability & Self-Healing
• Platform
• Applications
• Rolling Upgrades with No Downtime
• Dynamic Scaling
• Security
• Repair Software Vulnerabilities ASAP
• Repave servers and apps from known good states
• Rotate user credentials
What about Day 2 Operations?
• Adding Additional Cluster Capacity
• High Availability
• Backups
• Security
Conclusion
• Writing Scalable Applications is Very Hard
• Unless you follow 12 Factor principles
• Scaling Applications is Very Hard
• Unless you are using Cloud Foundry
• Scaling Data Stores is Very Hard
• Unless you are using MongoDB
The image part with relationship ID rId3 was not found in the file.
Rick Ross
Email: rick@rick-ross.com
LinkedIn: www.linkedin.com/in/rickross
App Source: http://bit.ly/MongoDBWorldSrc
© C o p y r ig h t 2 0 1 8 P iv o ta l S o ftw a r e , I n c . A ll r ig h ts R e s e r v e d .

MongoDB World 2018: MongoDB and Cloud Foundry – A Match Made for the Cloud

  • 1.
    MongoDB and CloudFoundry A Match Made for the Cloud Rick Ross Advisory Platform Architect, Pivotal June, 2018 Photo By J.D. Hancock
  • 2.
    Agenda ■ Scaling Applicationsis Hard ■ Principles for Scaling Applications ■ Cloud Foundry ■ Leveraging MongoDB ■ Demo ■ Scaling the Application ■ Cloud Native Principles ■ Questions
  • 3.
    Where will theyrun? vSphere Openstack OnPremise AWS Google Cloud Azure Public Cloud Compute, Networking, Storage, OS, Firewalls, Monitoring, etcWhat Infrastructure? Data stores, Caching, Message Queues, etcWhat Backing Services? Tomcat, WebLogic, WebSphere, IIS, etc.What Middleware? How to scale the application? AppA AppA AppA Horizontal Scaling Scaling Questions
  • 4.
    Scaling Applications isHard! • Never have done it before • Learn the patterns – usually through research, trial & error • Architectural & Infrastructure Decisions & Concerns • Languages, Frameworks • Clustering / Distributed Systems • High Availability • Data Store choices • Session State • And… • Deploying Applications is Hard Photo By J.D. Hancock
  • 5.
    Cloud Native –What Does that Mean? DevOps ● Common incentives, tools, and processes builds a culture of shared responsibility. ● Collaboration is paramount. Continuous Delivery ● With automated tests, teams release early and often. ● The results: higher quality code and lower risk. ● There’s fewer bugs in production. Microservices ● Loosely coupled components help teams deploy independently. ● No more waiting for integrated test teams.
  • 6.
    Cloud Native DrivesComplexity DevOps Continuous Delivery Microservices Development & Operational Complexity Multiple Stakeholders Rapid Pace Many Moving Parts
  • 7.
    vSphere Openstack AWSGoogle Cloud Azure & Azure Stack Infrastructure Application Code & Frameworks Spring Boot / Spring Cloud / .NET / Steeltoe PAS Pivotal Application Service PKS Pivotal Container Service Operations (Infrastructure Automation) Contract: Cloud Provider Interface Contract: BOSH Release Pivotal Services Marketplac e Pivotal and Partner Products Containers Pre-Packaged Apps / Backing Services
  • 8.
    Services in CloudFoundry • Backing Resource such as • Data stores, Message Queues, Caches, etc. • Managed & Unmanaged Services • BOSH Managed or Externally Managed • Service Broker • Open Service Broker API - https://www.openservicebrokerapi.org/ • Services made available to developers • Creating and Accessing Services Simplified
  • 9.
    • MongoDB andPivotal co-engineered Cloud Foundry integration • BOSH installs the Ops Manager agent • Calls the Ops Manager API to provision, configure, monitor & backup the cluster • Enables users to integrate MongoDB as an on-demand DBaaS resource within Cloud Foundry platforms Ops Manager Cloud Foundry Integration
  • 10.
    Atlas: The onlytrue multi-cloud database as a service Database as a service Database that runs the same everywhere Consistent experience across AWS, Azure, and GCP Coverage in any geography Deploy in over 50 regions worldwide Create globally distributed databases with a few clicks Leverage the benefits of a multi-cloud strategy Exploit the benefits of AWS, Azure, or GCP services on your data Avoid lock-in Easily migrate data between cloud providers
  • 11.
    Spring-Person Architecture Spring-Person REST API SpringBoot (Java) Pivotal Application Service User Provided Service Atlas URI
  • 12.
    Accessing MongoDB Atlas •IP Address Whitelisting Strategies • Internet Access via a Proxy • Limit via an Network Range • Externalize the Configuration • User Provided Service • Use External Config Service • Spring Cloud Config Photo By J.D. Hancock
  • 13.
    I. Codebase One codebasetracked in SCM, many deploys II. Dependencies Explicitly declare and isolate dependencies III. Configuration Store config in the environment VI. Processes Execute app as stateless processes V. Build, Release, Run Strictly separate build and run stages IV. Backing Services Treat backing services as attached resources IX. Disposability Maximize robustness with fast startup and graceful shutdown VIII. Concurrency Scale out via the process model VII. Port binding Export services via port binding XII. Admin processes Run admin / mgmt tasks as one-off processes X. Dev/prod parity Keep dev, staging, prod as similar as possible XI. Logs Treat logs as event streams 12-Factor Applications http://12factor.net https://content.pivotal.io/blog/beyond-the-twelve-factor-app
  • 14.
    I. Codebase One codebasetracked in SCM, many deploys II. Dependencies Explicitly declare and isolate dependencies III. Configuration Store config in the environment VI. Processes Execute app as stateless processes V. Build, Release, Run Strictly separate build and run stages IV. Backing Services Treat backing services as attached resources IX. Disposability Maximize robustness with fast startup and graceful shutdown VIII. Concurrency Scale out via the process model VII. Port binding Export services via port binding XII. Admin processes Run admin / mgmt tasks as one-off processes X. Dev/prod parity Keep dev, staging, prod as similar as possible XI. Logs Treat logs as event streams 12-Factor Applications http://12factor.net https://content.pivotal.io/blog/beyond-the-twelve-factor-app
  • 15.
    I. Codebase One codebasetracked in SCM, many deploys II. Dependencies Explicitly declare and isolate dependencies III. Configuration Store config in the environment VI. Processes Execute app as stateless processes V. Build, Release, Run Strictly separate build and run stages IV. Backing Services Treat backing services as attached resources IX. Disposability Maximize robustness with fast startup and graceful shutdown VIII. Concurrency Scale out via the process model VII. Port binding Export services via port binding XII. Admin processes Run admin / mgmt tasks as one-off processes X. Dev/prod parity Keep dev, staging, prod as similar as possible XI. Logs Treat logs as event streams 12-Factor Applications http://12factor.net https://content.pivotal.io/blog/beyond-the-twelve-factor-app
  • 16.
    I. Codebase One codebasetracked in SCM, many deploys II. Dependencies Explicitly declare and isolate dependencies III. Configuration Store config in the environment VI. Processes Execute app as stateless processes V. Build, Release, Run Strictly separate build and run stages IV. Backing Services Treat backing services as attached resources IX. Disposability Maximize robustness with fast startup and graceful shutdown VIII. Concurrency Scale out via the process model VII. Port binding Export services via port binding XII. Admin processes Run admin / mgmt tasks as one-off processes X. Dev/prod parity Keep dev, staging, prod as similar as possible XI. Logs Treat logs as event streams 12-Factor Applications http://12factor.net https://content.pivotal.io/blog/beyond-the-twelve-factor-app
  • 17.
    I. Codebase One codebasetracked in SCM, many deploys II. Dependencies Explicitly declare and isolate dependencies III. Configuration Store config in the environment VI. Processes Execute app as stateless processes V. Build, Release, Run Strictly separate build and run stages IV. Backing Services Treat backing services as attached resources IX. Disposability Maximize robustness with fast startup and graceful shutdown VIII. Concurrency Scale out via the process model VII. Port binding Export services via port binding XII. Admin processes Run admin / mgmt tasks as one-off processes X. Dev/prod parity Keep dev, staging, prod as similar as possible XI. Logs Treat logs as event streams 12-Factor Applications http://12factor.net https://content.pivotal.io/blog/beyond-the-twelve-factor-app
  • 18.
    Scaling Options inPivotal Cloud Foundry • Scale the Platform • Scale your applications • Manually • Auto Scaling – Via Schedule • Auto Scaling – Via Metrics • HTTP Throughput • HTTP Latency • CPU Usage • Memory Usage • RabbitMQ Depth
  • 19.
    Where will theyrun? vSphere Openstack OnPremise AWS Google Cloud Azure Public Cloud Compute, Networking, Storage, OS, Firewalls, Monitoring, etcWhat Infrastructure? Data stores, Caching, Message Queues, etcWhat Backing Services? Tomcat, WebLogic, WebSphere, IIS, etc.What Middleware? How to scale the application? AppA AppA AppA Horizontal Scaling Answering Your Scaling Needs PAS Pivotal Application Service Autoscaler Buildpacks Cloud Provider Interface
  • 20.
    What about Day2 Operations? • High Availability & Self-Healing • Platform • Applications • Rolling Upgrades with No Downtime • Dynamic Scaling • Security • Repair Software Vulnerabilities ASAP • Repave servers and apps from known good states • Rotate user credentials
  • 21.
    What about Day2 Operations? • Adding Additional Cluster Capacity • High Availability • Backups • Security
  • 22.
    Conclusion • Writing ScalableApplications is Very Hard • Unless you follow 12 Factor principles • Scaling Applications is Very Hard • Unless you are using Cloud Foundry • Scaling Data Stores is Very Hard • Unless you are using MongoDB
  • 23.
    The image partwith relationship ID rId3 was not found in the file. Rick Ross Email: rick@rick-ross.com LinkedIn: www.linkedin.com/in/rickross App Source: http://bit.ly/MongoDBWorldSrc © C o p y r ig h t 2 0 1 8 P iv o ta l S o ftw a r e , I n c . A ll r ig h ts R e s e r v e d .