Should I Move to Amazon AWS?
It’s not that I don’t want people to migrate to AWS. For several years, I’ve witnessed many IT professionals move to AWS before I had a chance to assess their application. So far, I’ve seen mixed results as far as performance and cost. Many of these people have been kind enough to share their experience with me, which in turn I’ll share with you today.
Some AWS History
I am sure many web hosting firms are still wondering where they went wrong. In a brief look back, it appears that AWS came out of nowhere and passed industry giants that were in the business during the dot-com boom. I think the success of AWS was a result of these things:
- You can do anything in the AWS console with almost no limitation. Things that before took a massive effort and support tickets are done instantly.
- The pricing was never a mystery, you can look at the pricing calculator and know what you were going to spend beforehand. (Auto-scaling issues aside).
- You could enter your credit card and instantly have access to services.
- AWS started off by giving 1-year free trial accounts. Once built, who wants to move their application?
- If you got upset or received poor service, you weren’t bound by a contract.
- AWS had brand recognition thanks to Amazon being an online retail force known for solid customer service.
Examples of Moves to AWS that Went Well
I have clients that made the move to AWS that were successful. Here are some examples of clients that made the move to AWS and were better off for it. I’ll do my best to outline the circumstances that made it a good fit for them.
AWS Success story #1 – Moved from Heroku
For those on Heroku, there’s a high probability that you will fit well in AWS due to the modernity of your application and architecture. There’s a good chance that the application is container-based and horizontally scaling which makes a good fit in AWS with their Elastic Beanstalk product.
AWS Success story #2 – Had orchestration / software-defined datacenter in place
I have clients that use orchestration in their software-defined data centers. The orchestration they implemented was made possible by different software vendors. Here are some that we’ve encountered:
Saltstack – Allows Intelligent Orchestration of Software Defined Datacenters.
Redhat Cloudforms – Cloudforms also allows intelligent orchestration of public and private virtual instances and containers. Not only can this be used with AWS, but it’s also able to orchestrate between on-premise and Azure clouds. You may be familiar with Cloud forms if you used its Open Source counterpart called ManagedIQ. (Disclosure: we are a Redhat partner)
Because there was orchestration in place, VM sprawl is kept in check along with a host of other policies which keep the environment secure and properly utilized.
AWS Success Story #3 – Application built on AWS initially (DevOps)
I have a client that runs a SaaS that serves HR recruiters. My client needed a good place to build the application where the developers could all collaborate. Since this was built on AWS, it naturally fit the AWS ecosystem when they went live.
AWS Not So Successful Stories
We’ve also worked with those that haven’t had great experiences with AWS. Here are some examples of those cases:
AWS Not So Successful Story # 1 – Vertically Scaling App with Large Databases
There are many legacy applications out there that don’t do great when virtualized. Although AWS can give you really large server instances, they are still virtualized. This is particularly an issue for larger databases that cannot be clustered for performance or sharded. My client runs a SaaS where there’s a database for each client. This means that the database server has a ton of work and the IOPS are just too low in virtualized instances. Our client is best served by a cloud provider that can mix virtual and physical servers. While this may seem old or dated, there are many firms that have an application that feels like it’s multi-tenant but behind the scenes it’s old fashioned. Old fashioned doesn’t mean unreliable.
AWS Not So Successful Story #2 – Legacy Application on Sparc Solaris
Ok, so this application never made it to AWS but in an evaluation, AWS was on the list of places to check out. To AWS’ credit, there are 23 pages of supported platforms they can handle but Solaris isn’t one of them. The client had an ERP that excelled in multi-currency finances and so a new ERP system was not an option. The ultimate home for this application was a traditional hosting provider that had Sun Solaris capabilities.
AWS Not So Successful Story #3 – Cost Overruns
This story isn’t specific to a particular client of ours but it’s the on-going complaint we hear about cost overruns on AWS. Vertically scaling applications, as well as auto-scaling configurations that are turned on without billing alerts, have led to some very high computing bills.
Actually, this seems to be the biggest concern when using AWS. I don’t fault AWS for this, the nature of technology is that there will be strange things that happen. An application that spins out of control can easily trip auto-scaling features to give a client a very high bill. Developers may spin up some test server instances and then forget about them for months before catching it on the bill. This is where
Here’s an excerpt with Corey Quinn (AWS expert) on the Cloudcast Podcast speaking to the issue of AWS bills in general:[Excerpt] The Cloudcast #305 – Last Week in AWSAaron Delp and Brian Gracely
It’s a bit unfair for me to take Corey’s interview out of context so check out the entire podcast on your own.
I’ve tried to outline some of the successes and failures we’ve seen on AWS. These examples can be made for any public cloud including Azure and Google Compute. I think the best advice to heed is something I read on Reddit from user “sithadmin” when he says the following, “If you’re moving to AWS without actually having workloads suited for it, prepare to start burning wads of cash without noticeable improvements in performance or reliability. Doubly so if you’re not right-sizing your VM.”