Remember the early nineties film Groundhog Day? In the movie, Bill Murray’s character, Phil, was required to live the same day repeatedly until he got it right. For a while, he makes the best of it by saving lives, learning to play the piano and even taking up poetry. But, waking up at 6 a.m. to the same day over and over again eventually takes its toll, and Phil decides to figure a way out. At this point I’m sure you are asking yourself, what does this have to do with AWS and why am I still reading? Well, hang in there a little longer and I’ll tell you.
For many companies, the journey to the cloud feels like Groundhog Day. It feels like they have made the journey to the cloud and ended up in the same place they started with minimal to no improvement. This is generally the case when a company does a “lift and shift” to the cloud — replicating an on-premise architecture in the cloud using EC2 instances to run all aspects of the application.
It’s critical to understand, a lift and shift is a viable first step to getting to the cloud. However, this is where many companies stop and then wonder why they are not seeing the benefits of the cloud. Instead, they see the same high costs of infrastructure and management they had in the original location. Yep, Groundhog Day.
Often the misconception of cloud computing is, “If I can just get my workload to AWS, I will save a ton of money and life will be perfect.” However, like any other platform, the reality of cloud computing can be disheartening if done improperly. Now, am I saying AWS cannot save you money and improve the quality of your life right off the bat? Of course not! That would make me a poor AWS Evangelist and probably unemployed. What I am saying is, understanding AWS services and transforming your applications in response is paramount to taking advantage of the technical superiority and cost reductions offered by AWS.
The first step to escaping Groundhog Day is to build a cloud awareness. At last year’s re:Invent, during a presentation entitled Attitude of Iteration, James Cowe and I discussed the importance of being an AWS lifetime student.
This means to have a competitive edge in business today, it’s critical to stay informed of the technical advancements going on in cloud computing. This does not imply that you need a deep understanding of every service AWS has to offer. With the pace of innovation set by AWS, it becomes an insurmountable task for companies who do not have cloud computing as a core competency. However, a conceptual knowledge of AWS services and how they can benefit your company is critical.
When working with customers, I encourage them to at least read the information pages on an AWS service to understand it’s purpose and if it is something that applies to their business. If it does, then the next step is to dive in and learn. Understandably, if a company is unable to do this internally, the next option is to work with a partner, such as Rackspace, that makes understanding cloud it’s full-time job.
The second step to escaping Groundhog Day is to start implementing changes based on what you have learned about AWS services. I generally break this into two phases. The first is something I refer to as optimisation. When optimising an application to run on AWS, there are generally changes that can be made that require little or no code changes. Most optimising changes will happen in the architecture.
One example of optimisation is as simple as implementing Auto Scaling to introduce elasticity to your infrastructure. This allows you to provision resources automatically to meet rising or diminishing loads. Another example is to move compatible databases from an EC2 instance to run on Amazon Relational Database Service (RDS) instead. Hosting your database on RDS provides a secured, replicable and reliable way to provide database access while offloading the infrastructure management to the experts at AWS.
The second phase of implementing changes to your AWS workloads is what we call transformation. Transformation generally requires infrastructure changes as well as code changes. While these changes may take more initial effort, this is also where you will see the greatest cost and management savings as well as an increase in performance. A primary example of transforming your application is to move from EC2 virtual machines hosting monolithic apps to a micro-service architecture using AWS Lambda.
The advantages of a micro-service architecture are many. First of all, by removing EC2 instances from the equation and running on Lambdas, you are no longer responsible for the care and maintenance of the infrastructure. In this new architecture, you are also working with transactional pricing rather than a fixed monthly price that is charged, even when there are no transactions happening. You can read more about this type of computing in this recent blog post.
Another way you can transform your applications to take advantage of AWS technologies is through your database story. If you’re running big data or map reductions, then Amazon EMR or Amazon Redshift should be evaluated. If you’re running a NoSQL or document database, the Amazon DynamoDB provides a managed solution that is incredibly performant.
The bottom line is, there is always another step that can be taken. Once you have finished with a transformation, it is time to re-evaluate and see what the next transformation will be for your workload. By continually transforming you will never have to worry about Groundhog Day, whether Punxsutawney Phil sees his shadow or not!