Cloud Adoption: From Start to PaaS

Copyright © 2017 HashiCorp
Cloud Adoption:
From Start to PaaS
Moving to the cloud and the effect on an
organization

▪ Andrew Khoury (andrew@hashicorp.com)
▪ Ex-Consultant and Engineer for the Fortune 1000
▪ Love to innovate as much as possible
▪ Architected & built 12 *aaS platforms
▪ Admittedly, the first few weren't very pretty
Who am I?
2

We enable organizations to Provision, Secure, Connect,
and Run any infrastructure for any application
Company overview
3
Mission
Key
Products
Investors Mayfield Fund, GGV Capital, Redpoint and True Ventures
Founded 2012 by Mitchell Hashimoto and Armon Dadgar

Broad adoption across heterogeneous infrastructure
Software Innovators Technology Partners
4

s
Copyright © 2017 HashiCorp 5
Cloud Migration
Challenges

Datacenter Deployment Model
▪ In the Datacenter, hardware is a relatively fixed pool of resources available for use
▪ Asset lifecycles are tracked
▪ Resources are allocated and configured before being made available for use by applications
▪ Stack installed in discrete layers
6
Server 7
Server 6
Server 3
Server 5
Server 4
Server 2
Server 1
Hardware
Hypervisor
Virtual Machine
Operating System
Java Runtime
VM
OS
DBMS
VM
OS
MQ
Application Layer
Virtualization Layer
Physical Layer
Java Application SQL AMQP
Stack Layer

Cloud Deployment Model
▪ In the cloud, capacity planning is a much smaller concern
▪ Application stack components live in the same layer as OS's and VMs
▪ No assets to track
▪ All layers treated as one stack
7
Virtual Machine
Operating System
DBMS MQ
Cloud Layer
Java Application SQL AMQP
Java Runtime
Stack Layer
Application Layer

▪ Organizations want to leverage the "provision-on-demand" nature of
the cloud
▪ How do we provide this while still placing control around it?
▪ Organizations want to avoid lock-in to a single cloud vendor
▪ The network edge is blurred, reducing the ability to rely on "Perimeter
Defense" network security strategies
▪ How do we ensure that application-level security is sufficient?
▪ Infrastructure needs to be provisioned and de-provisioned when batch
jobs start and terminate
▪ How do we deal with configuration that automatically changes
throughout the lifetime of the deployment?
Challenges
8

s
The Evolution of Cloud
Adoption

▪ Cloud deployments are identical to datacenter deployments
▪ If running on VMs, it can usually be achieved by uploading VM
snapshots to the cloud provider
Technique 1 - The Lift and Shift
10

Technique 1 - The Lift and Shift
11
Pros and Cons
▪ No need to modify any
application architectures
▪ Requires little to no change in
the engineering organization
▪ CapEx converted to OpEx
▪ Migration path is extremely
easy if running in VMs
▪ Doesn't allow for cost-reduction
techniques (i.e. autoscaling)
▪ Doesn't offload management
costs of component services (i.e.
databases, message queues)
▪ Doesn't enhance engineering
productivity
Good for applications with low operational costs
and little to no active development

▪ Self-managed services are replaced with cloud-native counterparts
▪ i.e., MySQL running on AWS RDS instead of directly on instances
▪ Applications may be modified to leverage cloud-native components
▪ Applications may be separated into stateful and stateless
components
Technique 2 - Cloud-Native Migrations
12

▪ Allows using cost-reduction
techniques (i.e. autoscaling)
▪ Allows offloading management
costs of native services
(databases, etc)
▪ Fewer static configurations to
manage (IP addresses, etc)
Technique 2 - Cloud-Native Migrations
13
Pros and Cons
▪ Engineering workflows still
fundamentally unchanged
▪ Requires upfront investment for
the migration, where long-term
gains are largely unknown
▪ Major effort required to avoid
vendor lock-in
▪ Requires more frequent
collaboration between
developers and operators
Good for applications with high operational costs
but little to no active development

▪ A platform is built as an abstraction layer between engineers and the
cloud
▪ Deployments are standardized and potentially automated, from source
control to "dev" to "prod" environments
▪ Infrastructure can become self-serve for engineers
▪ Interfaces are defined for common systems to be automatically
configured (i.e. log collection, monitoring)
▪ DevOps becomes the standard way of working
Technique 3 - Build-your-own-Platform
14

Technique 3 - Build-your-own-Platform
15
Pros and Cons
▪ All of the benefits of running
cloud-native apps
▪ Creating pre-approved templates
for on-demand provisioning
reduces lead times
▪ Workflows between security,
operations, and developers can
be parallelized
▪ Codifies infrastructure alongside
the application
▪ Automates common procedures
(i.e. blue-green deployments,
failover, credential rotation, etc)
▪ Large upfront investment
▪ Long lead times - Typically
6mo~1yr before the first
applications are migrated
Good for applications with ongoing
development, regardless of
operational costs...
and if you build the platform, then
it can cover the use cases for
Technique 2 as well

s
Buliding a Cloud-
Agnostic Platform

Buliding a Cloud-Agnostic Platform
17
AWS Azure GCPPrivate cloud
Application Platform
Core Infrastructure
Security
HYBRID DATACENTER
TRADITIONAL
DATACENTER

RUN
CONNECT
SECURE
PROVISION
Applications
Infrastructure & applications
Infrastructure & applications
Infrastructure
4 Essential elements of Modern infrastructure
18
OSS TOOL SUITE PRODUCT SUITE
Consul
Terraform
Vault
Packer
Vagrant
Nomad Enterprise
Consul Enterprise
Vault Enterprise
Terraform Enterprise
FOR TEAMSFOR INDIVIDUALS
Nomad

s

Consistent Workflow for teams
20
COLLABORATE
on infrastructure as code
using a version control
system (VCS)
VALIDATE
with a common integrated
workflow for Plan & Apply
AUTOMATE
public cloud, private cloud,
and external services

resource "google_compute_instance" "server" {
name = "server"
machine_type = "g1-small"
zone = "us-central1-a"
disk {
image = "ubuntu-1404-trusty-v20160114e"
}
}
resource "dnsimple_record" "hello" {
domain = "example.com"
name = "server"
value = "${google_compute_instance.server.network_interface.0.address}"
type = "A"
}
21
Example
Infrastructure as
code

provisions multi-cloud, with a single
workflow using TERRAFORM
22
Key
Products
Solution ▪ One workflow to operate any infrastructure as code, which enables one system of
record for visibility, reducing mistakes and empowering users. Provide developers
pre-defined configurations so they can provision and secure their own infrastructure.
▪ Empower and enforce, rather than block and control
▪ They’re starting with Terraform integrated within their CI/CD workflow. Invested in
complete HashiCorp stack that will be deployed over the course of the next 6-18
months.
Challenge ▪ Huge transformation - moving 70% of workloads to the cloud, while providing the
necessary DevOps integration
▪ Securely federating control to developers so they achieve speed at scale

s

Secure any application on any infrastructure
24
Vault is a product to centrally
secure, store, and tightly control
access to secrets across hybrid
infrastructure and applications.
Vault
Security
Vault Enterprise
Centralized Secrets Management
• Centralize secrets management
to reduce secret sprawl
• Encryption as a Service to
protect all data
• Privilege Access Management for
granular access control to any
cloud resource

Example

leverages VAULT for securing their hybrid
infrastructure (modern & legacy apps)
26
Key
Products
Solution ▪ They have standardized on Vault as their secrets management platform. Which
enables them to easily set and revoke leases, credentials and policies. Vault critical
in helping secure internal systems and applications.
▪ Given the trillions of monetary transactions they deal with annyally, they can audit
every interaction made to ensure they are in compliance
Challenge ▪ They need to centralize and manage secrets for 200 legacy applications and 1000
microservices across 15 datacenters
▪ They are under constant attack by hackers both internally and externally. They need
a flexible developer friendly, secrets management system which can support their
complex hybrid infrastructure

s

Run any application across any infrastructure
28
Nomad is a distributed, highly
available, datacenter-aware cluster
manager and scheduler for the
purpose of deploying applications
on any infrastructure, at any scale.
Nomad
Development
Nomad Enterprise
Run Any Application Across Any
Infrastructure

Jobfile
Example
job "redis" {
datacenters = ["us-east-1"] # Run only in us-east-1
type = "service" # Use the service scheduler
# Define the single redis task using Docker
task "redis" {
driver = "docker"
config {
image = "redis:latest"
}
resources {
cpu = 500 # Mhz
memory = 256 # MB
network {
mbits = 10
dynamic_ports = ["redis"]
}
}
}
}

performs rapid scaling of elastic compute in
the cloud using NOMAD & CONSUL
30
Key
Products
Solution ▪ Spin up millions of containers in GCP, to analyse trade data. Shoot the cluster in the
head when done. Doing this 4-5 x a day
▪ Multi-cloud scheduling of tasks (Batch / Dispatch / Long running services)
Challenge ▪ Rapidly assess their market risk
▪ Hundreds of computational problems, need for a solution that allows them to
consume elastic compute.
▪ Speed of analysing trade data for competitive advantage

s

Discover & Configure any application on any infrastructure
32
Consul is a distributed, highly
available, and datacenter aware
solution for service discovery,
runtime configuration, and
orchestration.
Consul Operations/Development
Connect Any Application
Across Any Infrastructure

backend frontend
maxconn {{ key "frontend/maxconn" }}
balance roundrobin{{range service "app.frontend "}}
service {{.ID}} {{.Address}}:{{.Port}}{{end}}
backend frontend
maxconn 256
balance roundrobin
server web1 10.0.1.100:80
server web2 10.0.2.200:80
Edit Header
Consul
Template

performs dynamic service discovery with
CONSUL
34
Key
Products
Solution ▪ Service discovery via HTTP and DNS simplifies connecting services as they are
deployed and updated across distributed infrastructure
▪ Distributed runtime configuration using a gossip protocol enables environment
configuration at scale
▪ Automatically orchestrate application changes based on datacenter events to
maintain availability across global fleets.
Challenge ▪ Need a robust solution that allows them to keep a record of every service in their
environment
▪ Microservices running across thousands of machines need a scalable way to accept
environment configuration
▪ Microservices running across thousands of machines have frequent failures

Questions?

Thank you.
hello@hashicorp.comwww.hashicorp.com

Cloud Adoption: From Start to PaaS

More Related Content

What's hot

Similar to Cloud Adoption: From Start to PaaS

Recently uploaded

Cloud Adoption: From Start to PaaS

Editor's Notes