important questions moving to the cloud (or even splitting the environment) stephen wynkoop (...

Important Questions Moving to the Cloud

(Or even splitting the environment)

Stephen Wynkoop (swynk@sswug.org)SSWUG.ORG

My Background• Databases– Early (very) Access– First version of SQL Server – Even dBase and other platforms

• Coding along the way, books, SSWUG.ORG

Agenda• Different, But the Same Approach• Lessons Learned Along the Way• Getting Started

Key To Success • Understand your application(s) and

environment.

No Kidding!

Important to Remember• Cloud resources are NOT an all or nothing

proposition.

Overall, Breaking Into Pieces• Functional• Security• Availability• Fault Tolerance

Sound familiar?

Environment

Functional Considerations• Understand the application– What storage requirements are there?– What type of security is needed?– Recovery?– Processing – and what types • Reporting, transactional, etc.

– Spikes – elasticity in demand/requirements

Functionality – Questions #1• Usage patterns – “When is the application used,

are there spikes or critical periods?”• Authentication – “Beyond login, are there other

authentication requirements? Think single sign-on, or application roles/logins.”

• 3rd Party Apps – “What are the interface requirements?”

Functionality – Questions #2• Usage – “What comes out of the front-end

inputs?” (reporting, exports, sharing)• Recovery – “What is acceptable downtime?”

and “What is the downtime process?”

Security Considerations• Authentication• Data protection• Network segmentation• Data in transit, data in use, data at rest• Archived information• Information sharing/reporting

Security – Questions #1• General – “How are users authenticated?” –

this could be cards, UID/PW, etc.• Protection – “What regulatory bodies care

about this information?”– Remember, there may be multiples – HIPAA, PCI,

etc. plus simple best practices

Security – Questions #2• Segmentation – “Who will have access, and

why, and what protection is needed?” Firewalls, segmentation, VPN, etc.

• Protection – “Where does information go?” – protection of that information - encryption

• Sharing – “Who uses this information, how is it provided to them?”

Availability• Drives system sizing• Drives load balancing• Drives scale up and down• Drives associated resources, tool selection

This drives the entire environment “chain”

Availability Surprises• This was our biggest challenge area– Still is. Architecting correctly to support this is

challenging.• Physical System requirements• Logical System requirements• Application requirements• Oddities, licensing, support

Fault Tolerance• Determines functional components– Database, OS, app tools

• Determines failover requirements• Determines feature selection within tools and

platforms

Fault Tolerance – Questions #1• Application – “What happens when the application

“crashes” – what does recovery look like?” Process drives how you recover…

• Consider recovery like trauma – – What is the immediate assessment and action process?– What is the short term stop-gap process?– What is recovery like?– What is confirmed recovery?

Fault Tolerance – Questions #2• Understand – Transparent recovery vs. ‘please

wait’ – component approach can help OR HINDER fault tolerance. – Key: How do components interact?

Fault Tolerance - Surprises• Things to consider:– IP Address changes (DNS, IPs, etc.)– Machine name changes/DNS name changes– Cached DNS– Cycle times on availability checks– Firewalls, other items that reference IP/machine name– Application configurations, database connections, etc.

Data Entry Security • Encryption at the source• Access controls

These can become architecture issues because services can be involved.

A LOOK AT SSWUG ARCHITECTURE

Auto Scaling group

Availability Zone #1

www.sswug.org

security group

root volume

data volume

Elastic Load Balancing

Amazon S3 bucket

S3-served Video,

graphics

EC2 instance

web appserver

DNS

FlashServer

“Main” Server root volume

data volumedata volumedata volumedata volume

Default 2 instances, Max 10Medium instances

M1.large

M1.large

“Dev” Server

“Test” Server

M1.medium

Site source

AMI for Servers

github

Key Services Enabled• Elastic Load balancing• Auto-scaling groups• AMIs• Multiple availability zones• Cloudfront• S3 - storage• SES – email• DNS (Route 53)

• Resized instances for services

• Encoding services

• Challenges:– Full-text services– Encryption options– Managing emergence of

technologies

Interesting Trends• Many start with “co-locating” approach• Instead:– “Peel” off services you need– Consider backup, bursting to the cloud services– Use the elasticity, fault tolerance to your

advantage – excellent place to start

Interesting Trends 2• Database services for analysis, reporting great

starting points, etc.• Supporting services (DNS, backups, etc.)

Pro tip: Watch for incremental costs that can slowly snowball (storage, other usage-based)

Biggest Mistake• Not figuring out services, components and

implementation options that will enhance your environment.

Pet Peeve• Billing– Monitor– Analyze– Trend– Trim

All of these different pieces do make itmore difficult to manage costs.

Where Do You Start?• Ask the questions• Understand the applications and the

requirements

Historic process applied to current technologies

Questions? • Email: swynk@sswug.org

• Twitter: @swynk• Phone: 520-760-2400 x1030