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?
They have multiple lines of businesses (each airline) versus one line of business (furniture) requiring support
Their volume spikes are steeper; they are driven by aggressive sales rather than seasonal sales so where we might see something like 2-4x traffic spread over a number of hours or days for furniture, we see closer to 10x traffic spread over a few minutes lasting a few hours or days for airline ticket sales.
We support this by prescaling (eg. they know a sale is going to happen) and by autoscaling (eg. sale was not announced). In either case we can provision the supporting capacity within minutes (again, we are used to dealing with 10x traffic, not 2-4x traffic)
Regardless of the product or service being sold, we focus on creating production environments that are designed to scale and we do this by:
Understanding the application
Benchmarking (where possible), extrapolating from previous real world numbers and proactively monitoring load
Creating the automation to support scaling
Our experience is our customers put focus on scale of the database and application servers whereas we put focus on the entire stack (network, storage, servers, application, etc.); we have helped customers who have experienced scaling issues both internally and on other cloud providers ensure they can meet their scaling demands on AWS
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 7 years ago, and a lot was changed, both in my understanding, the capabilities and the adoption of AWS and Public Cloud in general.