5. Why move to the Cloud?
• Is it cost (dollars and hours) savings?
• Is it because it’s (near infinitely)
scalable?
• Is it a shiny object?
6. Cost Savings
• Minimize/eliminate up front investment in hardware, software,
support, connectivity, etc.
• Adopt a OpEx (versus CapEx) cost model, which might align well
with your business model.
• Minimize/eliminate complexities in cross charging for shared
services
• Achieve higher economies of scale
7. Scalability
• Resource + People + Business
(Increased Agility and Speed to
Market for less)
• Someone else now pays to
maintain that excess hardware
capacity
• Automation allows for the horizontal
scale up/scale down of
infrastructure
• Abstracted services eliminate the
guesswork in scaling of storage and
other services
8. Availability
• Without physical constraints replacement
of failed infrastructure occurs faster
• Applications leverage abstracted
services where the availability
characteristics aren’t your problem
• Human error is minimized with
automation
9. Security
• Each host becomes its own security
zone
• Infrastructure lifecycle management
no longer has a physical component
• Administrative activities are done with
automation in mind
• Shared Responsibility security model
across your cloud environment
11. Where do I start? Knowledge
• Documentation available from AWS
– Documentation
– Community/Meetups/Github
– Wizards/Targeted E-Mails
– Reference Architecture/Quickstarts
– Ecosystem/Marketplace/Partners
– Best Practices/Trusted Advisor/PHD/Targeted E-Mails
– AWS Support
– AWS Training & Certification
• Interacting with AWS
– AWS Console Console
– AWS CLI, Tools, Tookits, SDKs and Mobile SDKs
– AWS Billing and Cost Management
• Keep Up to Date
– Blogs
– Whats New
12. Where do I start? Key Concepts
• AWS Regions and Availability Zones
• AWS Services generally build on one another
• Categories of Services Offered by AWS
– IaaS
• Building Blocks, Comparable to On-Premises virtualization
technologies
– PaaS
• Managed or Abstracted, Typically in support of IaaS
– SaaS
• Enterprise Aligned, Ready out of the box but can be
enhanced with PaaS
16. AZ A AZ B
Asia Pacific
(Singapore)
US West (OR)
AZ A AZ B
AZ C
GovCloud (US)
AZ A AZ B
US EAST (OH)
AZ A AZ B
AZ C
US East (VA)
AZ A AZ B
AZ C AZ D
AZ E
EU (Ireland)
AZ A AZ B
AZ C
Asia Pacific
(Tokyo)
AZ A AZ B
AZ C
EU (Frankfurt)
AZ A AZ B
AWS Regions
China (Beijing)*
AZ A AZ B
China (Bejing)
AZ A AZ B
Asia Pacific
(Seoul)
AZ A AZ B
AZ C
AZ A AZ B
AZ C
S. America
(Sao Paulo)
Asia Pacific
(Sydney)
Asia Pacific
(Mumbai)
AZ A AZ B
US West (CA)
AZ A AZ B
AZ C
EU(London)
AZ A AZ B
Canada
AZ A AZ B
AWS Regions and Availability Zones
17. TECHNICAL &
BUSINESS
SUPPORT
Account
Management
Support
Professional
Services
Solutions
Architects
Training &
Certification
Security
& Pricing
Reports
Partner
Ecosystem
AWS
MARKETPLACE
Backup
Big Data
& HPC
Business
Apps
Databases
Development
Industry
Solutions
Security
MANAGEMENT
TOOLS
Queuing
Notifications
Search
Orchestration
Email
ENTERPRISE
APPS
Virtual
Desktops
Storage
Gateway
Sharing &
Collaboration
Email &
Calendaring
Directories
HYBRID CLOUD
MANAGEMENT
Backups
Deployment
Direct
Connect
Identity
Federation
Integrated
Management
SECURITY &
MANAGEMENT
Virtual Private
Networks
Identity &
Access
Encryption
Keys
Configuration Monitoring Dedicated
INFRASTRUCTURE
SERVICES
Regions
Availability
Zones
Compute
Storage
O b j e c t s
,
B l o c k s ,
F i l e s
Databases
SQL, NoSQL,
Caching
CDNNetworking
PLATFORM
SERVICES
App
Mobile
& Web
Front-end
Functions
Identity
Data Store
Real-time
Development
Containers
Source
Code
Build
Tools
Deploymen
t
DevOps
Mobile
Sync
Identity
Push
Notifications
Mobile
Analytics
Mobile
Backend
Analytics
Data
Warehousing
Hadoop
Streaming
Data
Pipelines
Machine
Learning
Service Breadth & Depth
27. Themes
• Design for failure and nothing fails
• Build security in every layer
• Leverage different storage options
• Implement elasticity
• Think parallel
• Loose coupling sets you free
• Don’t fear constraints
28. Well Architected Framework
5 Pillars of Design, Development and Operations
• Security
• Reliability
• Scalability
• Predicable Performance
• Cost Control
29. Cloud Adoption Framework
• Business Perspective
• Platform Perspective
• Maturity Perspective
• People Perspective
• Process Perspective
• Operating Perspective
• Security Perspective
31. Virtual Machines, Containers, Functions
• Virtual Machines
– AMI
– Patching
– Multi-threaded/Multi-task
– Hours to Months
– Per VM/Per Hour
• Containers
– Container File
– Versioning
– Multi-threaded/Single-task
– Minutes to Days
– Per VM/Per Hour
• Functions
– Code
– Versioning
– Single-threaded/Single-task
– Microseconds to Seconds
– Per Memory/Second/Per Request (Free Tier)
32. AWS Reference Architectures/AWS Marketplace
• Simplified PDFs depicting, at a high
level, an application use case
• Deployment Guides provide detailed
information around deploying a
specific application
• CloudFormation Templates provide
deployment templates to alleviate
much of the manual work
• Often, products traditionally
deployed on-premise can be found
on the AWS Marketplace in pre-build
appliance images or CloudFormation
Templates
33. Partner Ecosystem Products/Services
• Thousands of products/services available on the AWS Marketplace
to support DevOps needs.
• Some delivered as services, some delivered as stacks.
• Our approach is to partner with “one of each”, which helps augment
AWS’ offering and expand our capabilities (many customers are
already invested in a solution.
34. Migration
• AWS Application Discovery Service – Agent based application discovery
• AWS Database Migration Service – Migration and replication of same/disparate
database platforms
• AWS Import/Export – BYOD “sneakernet” migration
• AWS Migration Hub – Ties Application Discovery and Server Migration together
• AWS Server Migration Service – VMWare integrated server migration + replication
• AWS Schema Conversion Tool – Migration of same/disparate database schemas
• AWS Snowball – 80 TB hardened storage device for “sneakernet” migration
• vmimport + vCenter Addon – VM Image or ISO import as an EBS Snapshot or AMI
35. Approaches for architecting for AWS
• Deploy existing apps in AWS with minimal re-design
• Good strategy if starting out on AWS, or if application can’t be re-
architected due to cost or resource constraints
• Primarily use core services such as EC2, EBS, VPC
Lift-and-shift
• Evolve architecture for existing app to leverage AWS services
• Gain cost and performance benefits from using AWS services such
as RDS, SQS, and so on
Cloud-optimized
• Architect app to be cloud-native from the outset
• Leverage the full AWS portfolio
• Truly gain all the benefits of AWS (security, scalability, cost,
durability, low operational burden, etc)
Cloud-native
architecture
36. Leverage Many Storage Options
One size does NOT fit all
• Amazon S3 – large objects
• Amazon Glacier – archive data
• Amazon CloudFront – content distribution
• Amazon DynamoDB – simple non-relational data
• Amazon EC2 Ephemeral Storage – transient data
• Amazon EBS – persistent block storage with snapshots
• Amazon RDS – Automated, managed MySQL
• Amazon Redshift – Data warehouse workloads
Who are you?
Patrick Hannah, CloudHesive (where I’m a co-founder and the VP of Engineering)
What’s your background?
Architecture, Security and Operations on AWS for 6 years, prior to that Contact Center Architecture and Operations for over 8 years.
What do you hope to get out of the presentation?
I want to help folks get as the same out of AWS as I have.
I’d also like to see how others are using AWS – as with just about any thing in technology there are multiple ways to do something right (or wrong).
How are you using cloud services?
At CloudHesive, we provide consulting services to customers who wish to, or who are, leveraging AWS and we also use a number of AWS services to host our managed services customers (and the back-office systems supporting them).
Why did you pick the cloud services that you are using?
AWS is at the forefront of Cloud; their service catalog can support most traditional on-premise software use cases (infrastructure) but they also offer more abstracted services for software built on the cloud (such as SQS, which is one of my favorite) that negate the need to manage server infrastructure – on premise or on cloud.
What about you?
Before we talk about how we do it let’s talk about why.
Cost savings may come to mind; Scalability may come to mind; You may be getting asked by your customers or your management team.
I think a better reason why is you are creating a paradigm shift in your organization – and this is where the true value is:
The acquisition, deployment and management of hardware infrastructure has changed; you are no longer purchasing goods (servers, storage, network), you are purchasing services (IaaS, PaaS, SaaS) and outcomes.
You provision, decommission and manage your infrastructure like a software product and with that you have unprecedented access to automate these activities by eliminating time consuming, manual tasks and uncertainty around the state of infrastructure.
The only hardware you will care about is the endpoints and connectivity to the services you are consuming.
The methodologies that you might have used for ensuring the security, availability and scalability of infrastructure no longer apply.
Organizations can take advantage of these capabilities in a methodical approach overtime; starting with a “lift and drop” and implementing new features in their applications to take advantage of abstracted services (PaaS, etc.)
Moving a single application to AWS is a great start but with some work you can drive change throughout your organization.
Over the next few slides I’ll discuss some of the key benefits of moving to AWS
(Yes, the cloud is more than iTunes and Amazon doesn’t just sell books)
Hardware stops becoming the solution to your problems; whether you are trying to solve a problem with application performance or are clamoring for more hardware to scale due to a business event.
You change your way of thinking; capacity planning stops becoming reactionary, you stop overbuilding and can better support the volume peaks and valleys of your application.
Scale is no longer achieved by finding the largest server to run your application on; Scale is instead achieved by breaking your application up into multiple functional components.
These components can now run on appropriately sized servers, and even multiples servers (in an N+1 configuration) to allow for limitless scalability and support your resiliency objectives.
Data persistence has changed as well; You are no longer limited to two technologies for data persistence (filesystem/block and OLTP database). Your options are much more use case specific.
Now that you’ve gone “hands off” on infrastructure half of the availability problem is solved – when an infrastructure component fails you bring up a replacement with minimal effort.
You design your software to be robust enough to survive an infrastructure failure – and you use abstracted services (more on both later) - A modern application should be componentized, designed to be stateless and distributed and with a persistence layer, limiting the impact of the failure of an infrastructure component and eliminating infrastructure component uniqueness and allowing it to be thrown away.
With a hands off approach you’ve also eliminated the human error factor – no one wants to talk about it but it’s a common cause impact to availability.
Servers are no longer grouped in physical networks (Private, DMZ, etc.); these networks are now logical and are extended to individual servers by way of Host or Hypervisor based Security.
Resources (such as servers) are hands off; Provisioning, Change and Decommissioning is done out of band and in an automated fashion where infrastructure and applications come from a known, version controlled source.
The same approach is applied to break/fix activities as well; Why log into a server to view operational (log and event) data or verify a configuration/file version when you now know, without a doubt, what was deployed AND your operational data is centrally available.
A common preconception is that the public cloud is insecure but in my experience I am seeing more and more security offers cite the public cloud as being more secure. One of these reasons is the Shared Responsibility model
When I first started using AWS, I did what most folks might do, went to the AWS website, read about cloud on Wikipedia, etc.
Mostly what I got out of it was the cloud was about Mashups (composite panels of information comprised of multiple data sources) and AWS had a service called EC2 that acted like an on-premise VM might, except the data was not persistent.
At the time I wasn’t necessarily a VM Advocate either; most of the workloads I was running were latency sensitive and VM technology (and practices) at the time were not ideal.
My initial reaction was that of being underwhelmed.
This was over 6 years ago, and a lot was changed, both in my understanding, the capabilities and the adoption of AWS and Public Cloud in general.
Since today’s audience is a mix of business and technical users, users who may have experience with AWS, another public cloud provider like Azure or GCE, or on premise cloud solutions like VMWare, or are just getting started, I will try to maintain a balance between the basics and diving deep into services.
Feel free to ask questions along the way – if there are specific areas you would like to dive into, I aloted time at the end of the presentation to do so.
The key concept is: if you are consuming an IaaS service, you have more responsibility for the care and feeding of that service than if you were consuming a PaaS or SaaS Service (which is the norm)
A common fallacy is that AWS (which came about in July 2002) was a way to sell unused capacity on the amazon.com side of the business.
Quite the opposite is true. What is more accurate is a lot of amazon.com talent and technologies came to form AWS (in the form of SQS, S3 and EC2) out of a need to consume infrastructure and platform services programmatically.
Amazon.com only moved to AWS in November 2010.
As we talk about AWS, try not to think too much about it in terms of datacenters, but the output or characteristics of the services provided.
Yes, it is true, AWS does operate datacenters but the scale at which AWS operates precludes the use of many traditional datacenter management techniques, which supports scale but also other operational requirements such as security (at scale you are more likely to implement separation of duties).
(And for what it’s worth AWS has never gone down – there have been outages, which are isolated to singular regions, but more typically specific availability zones.
AWS serves hundreds of thousands of customers in more than 190 countries.
Amazon CloudFront and Amazon Route 53 services are offered at AWS Edge Locations
You can choose to deploy and run your applications in multiple physical locations within the AWS cloud.
Our data center footprint is global, spanning 5 continents with highly redundant clusters of data centers in each region.
Amazon Web Services are available in geographic Regions that are independent and separate as much as possible for data sovertenty and as much as possible offer the same services.
When you use AWS, you can specify the Region in which your data will be stored, instances run, queues started, and databases instantiated.
Within each Region are Availability Zones (AZs).
Availability Zones are distinct locations that are engineered to be insulated from failures in other Availability Zones and provide inexpensive, low latency network connectivity to other Availability Zones in the same Region. By launching instances in separate Availability Zones, you can protect your applications from a failure (unlikely as it might be) that affects an entire zone. Regions consist of one or more Availability Zones, are geographically dispersed, and are in separate geographic areas or countries. The Amazon EC2 service level agreement commitment is 99.95% availability for each Amazon EC2 Region.
Our footprint is expanding continuously as we increase capacity, redundancy and add locations to meet the needs of our customers around the world.
AWS maintains Regions, which are major geographic areas, and Availability Zones (AZ), which are individual data centers, or clusters of data centers that make up a Region. Independent and separate that as much as possible offer the same services. But they have isolation as much as possible for data sovertenty.
Today, AWS operates 9 Regions around the world. Each Region has a minimum of 2 Azs (separate power, flood planes, etc) to allow customers to set up high availability architectures and data redundancy. An abstraction of a datacenter with fault isolation but close enough to build high availability architectures.
In addition to Regions, AWS maintains edge locations that supporting Route 53 DNS and Amazon CloudFront (CDN) points of presence.
AWS has developed the broadest collection of services available from any cloud provider.
Our approach to regions, availability zones, and POPs provides global coverage for high availability, low latency applications.
Foundation services across compute, storage, security, and networking offer customers flexibility in their architecture. We have a full spectrum of options to meet most price-to-performance scenarios.
We offer the capability for both managed and unmanaged database options.
The offerings for Analytics and Application Services enable advanced data processing and workloads.
AWS Redshift, our cloud-based data warehouse, is the fastest growing service in the history of AWS.
Our management tools offer a lot of insight and flexibility to let you manage your AWS resources through either our tools or the management tools you’re already familiar with.
Recent expansion into enterprise applications has been entirely driven by customer feedback on where they’d like us to deliver value.
Older AWS deployments may be leveraging their own solutions, running on EC2 to handle a number of services that are now offered as managed or abstracted services
Newer AWS deployments might not even need EC2 – consider Lambda or ECS instead
One of pieces of information we will use in our migration is the reference architecture and marketplace.
Each service has it’s own site and set of documentation
The SlideShare presentations can be an invaluable resource when it comes to diving into the details
The GitHub repositories have excellent examples of applications you can build on AWS
