From talking to 130+ of our cloud monitoring customers about their AWS environment and perspective, we at Stackdriver find ourselves in a unique position to talk about the journey that AWS users find themselves on.

There are 5 different categories in the AWS journey:

If we analyze these different stages, what I’ve found about each category is pretty interesting:

Experimental

Most customers, especially those that are startups, or those that have on premise infrastructure, start off by using AWS for test or experimental use cases. These customers often like to start with a T1 micro, perhaps spin up an ELB and store some content on S3. The customers here are most often comparing the performance of AWS to what they’ve been accustomed to on other infrastructure. They’re also testing how they can either move or design their new application to leverage the scale out properties of public cloud while also accounting for failure use cases. It’s actually really interesting to speak to customers here because given the ease of trying new AWS services, they move along this stage very quickly.

Unsatisfied

Some customers that I’ve spoken to have been using AWS for an extended period of time (9 months +) and have had so many challenges that they know they will switch, but just haven’t established plans to do so yet. These customers tend to have used lots of different AWS services and have had issues every step of the way. For example, one customer used RDS but realized it’s difficult to spin up a replica copy of RDS quickly. Furthermore, he’s had several of his instances, same size/region/flavor, derive completely different performance for the same application workload. Though this customer values AWS’ flexibility, he would rather have more consistent performance. Many in this category haven’t switched yet because they’re too busy keeping up with day to day business growth to plan for an application migration. Based on my discussions with customers in a more positive stage of AWS maturity, I would argue that there could be some key actions these customers could take, to be happier with AWS and stick with the platform longer term.

Switching

A small segment of customers are not believers in AWS. They’ve tried it and just weren’t as impressed with it as they were expecting to be. Some of the reasons I’ve heard that customers have switched are, for example, that their application was very memory intensive and AWS just couldn’t perform well with this type of app. Another reason I’ve heard was that cost just spiraled out of control very quickly and they knew they could do it cheaper themselves. This segment is definitely the smallest, but it still exists and I’m sure these customers could do things to make them happier with AWS than just switching platforms.

Happy

There are lots of customers that are happy with AWS so far, but also point out niggling issues with it which preclude them from saying that they’re long term customers. Many people in this category cite inability to link cost and component, or inconsistent performance of AWS services as the leading drivers for their hesitance. Many customers in this category also claim they are avoiding vendor lock-in by only using EC2 and EBS while not using packaged services like Dynamo, or RDS. This is what I hear when I speak to this audience live during a customer demo. However, when they deploy Stackdriver and start monitoring their environment, I’m shocked to see that they very often use SQS, RDS, ELB, S3 and other services where it will take some real effort if they wanted to switch platforms. My guess is it’s too convenient for them to not use instead of an open source alternative which requires setup and ongoing maintenance (or in some cases they’ve just started out with them for testing purposes).

Bliss

There are a group of customers that are just blown away by how flexible and easy AWS is for their applications. These users have typically run in private datacenters before, experienced pain first hand, and are wowed by the benefits of public cloud. 100% of these customers that I’ve spoken to are using multiple AWS services beyond the standard EC2, S3, and EBS. Most are using some combination of ELB, SQS, RDS, and SES. Others try to or are using nearly every service offered. A very small % of this category have never been negatively surprised by anything in their AWS environment. However, the larger majority of these customers have had one or more surprising performance and availability experiences with AWS which have them continually learning and re-designing their applications. For example, one customer realized that ELB’s are useful; not as a load balancer, but as a gateway. It is important to note that not all of these customers build for resiliency, – maybe these are just lucky so far? Surprisingly, these are not just small startups – this group includes customers with thousands of resources. This is about 5% of our customer base.

AWS Bliss – Not Far Away

As I mentioned earlier, this analysis is based on hundreds of customer conversations and over 125 customer deployments of the Stackdriver Intelligent Monitoring Service. The size of customers includes those running 1 instance with ephemeral storage all the way to a publicly traded company in the digital media industry with over 10,000 resources. If you fall into a category that I may have missed, please let me know. No matter where customers are on the AWS maturity journey, is that there’s a lot of support they can get to move closer to AWS Bliss. Whether it’s designing their app to have stateless nodes, leveraging the community in the thousands of AWS meetup groups, using productive discussion forums like Stackoverflow, using AWS’s Trusted Advisor dashboard, to even leveraging 3rd party tools designed for public cloud like cost management, monitoring, or security; there’s a lot out there. However, one thing’s for sure, public cloud is here to stay and it will only get better, so it’s best to start the journey now. I’ll have some more specific suggestions for each stage in the journey in a follow up post.

The post An AWS User’s Journey appeared first on SaaS Monitoring for AWS - Stackdriver.