Tuesday, December 2, 2014

Cloud Computing Considerations

This is a follow up to my previous article that compared dedicated servers to cloud and local virtual machine options, make sure to check that out, as well. In this post, we'll we focusing more on the cloud-specific considerations you need to take once you've decided it the best solution for you. We'll also follow up this article with examples of how to architect your cloud resources depending on your needs.


Make sure to review your Service Level Agreement (SLA) and pricing models prior to launching any instances. Most cloud service providers, including Google Compute Engine, Heroku, Digital Ocean, and AWS will factor the following into the total cost:

  • Number of servers
  • Number of CPU cores
  • RAM
  • Storage
  • Availability needs by hour or by week
  • Persistence
  • Load balancing requirements
  • Data transfer

As a side note, while some cloud providers like Digital Ocean offer the basic package of instances, disk images, backups, and support, providers like Heroku also offer add-ons for logging, analytics, and monitoring. Amazon has the most robust offering in the way of a NoSQL database service (DynamoDB), a queue service (SQS), Elastic Load Balancing, in-memory cache (ElastiCache), CDN (Cloudfront), and so on.

You'll also want to be aware of how cost and services are impacted by the location of the physical servers themselves in proximity of your end users. Also keep in mind that some cloud providers will have very specific scenarios that they factor into the cost of their services. Amazon, for instance, will charge you at varying degrees depending on:

  • Traffic between servers within the same datacenter (free)
  • Traffic between servers within the same EC2 (Elastic Compute Cloud) region (cheaper)
  • or traffic between EC2 servers and external servers (costly)

Amazon will also start charging you once you've hit certain thresholds for certain types of requests- SQS Queueing requests or invalidations (clearing the cache across servers for a given resource), for example.


Prior to designing the architecture, you'll want to understand the complexity of your system. How will you be leveraging public, private, and/or hybrid cloud solutions? You also need a strategy for how you'll scale out this system over time, factoring in changes in your offerings and growing/fluctuating traffic demands. Will you have to implement auto-provisioning or auto-scaling? What sort of logging and monitoring solution will you have in place? What parts of your architecture can be scaled out instead up scaled up? How are you distributing load and implementing redundancy? What's your failover strategy? There are all things you need to consider.


Really think about what your services require in terms of memory and CPU. Geographically, in which region should you set up your instances so that you're providing the fastest, most reliable service to customers? Are you benchmarking the speed at which your content is being delivered? How will this impact your decision to leverage a Content Distribution Network (CDN) or caching service? How user-intensive are your applications? Are you depending too much on the cloud for computing power when you can be offloading processes to the front end?

In conclusion, I welcome you to explore all the possible scenarios and to identify which would benefit the most from in-house vs. off-the-shelf solutions. And to also, check out this guide for some example cloud architecture diagrams.

No comments:

Post a Comment