DevOps Zone is brought to you in partnership with:

Ranjib is a system administrator at Google. Prior to Google, Ranjib was a senior consultant with ThoughtWorks. He works on private cloud implementation strategies, cloud adoption, system automation etc. He has worked on both application development as well as system administration, for past 6 years. Prior to ThoughtWorks, Ranjib was working with Persistent Systems . Ranjib has done his gradation in lifescience and masters in Bioinformatics. Ranjib is a staunch FOSS supporter. Ranjib is a DZone MVB and is not an employee of DZone and has posted 13 posts at DZone. You can read more from them at their website. View Full User Profile

3 Types of Infrastructure Elasticity

05.10.2012
| 7732 views |
  • submit to reddit

Here is a list of three major types of elasticity that I have implemented / experienced so far:

  1. Horizontal : by adding or removing service instances in response to certain amounts of load. Like a load balancer, and behind the load balancer there are multiple webservers.  The number of webservers are dictated by number of requests / second: ELB, haproxy, apache mod_proxy, pound, squid, etc. are examples of load balancers, while nginx, Tomcat, Jetty, Apache, thin, mongrel, etc. are just a few examples of webservers.
  2. Vertical : by adding or removing CPU/RAM in an individual server itself. For example, changing instance the types of an EC2 instance, changing Cgroup settings of an LXC,  or changing UBC params of openVZ containers.
  3. Multi-environment infrastructure : These servers are elastic, as they can belong to different environments at different times. They have the ability to reconfigure themselves against a particular environment. I am trying to improve upon this currently. I am trying to make certain EC2 instances dynamically configurable aginst many different environments. I have modeled my environments and service configurations using Chef. I will configure a server for unit testing jobs (like git clone, rake, spec, etc), and I will configure a server for functional testing jobs (xvfb, x11vnc, firefox, cucumber etc). 
  • chef-client --once -E unit_testing
  • chef-client --once -E functional_testing

 

Since the functional testing is generally triggered after unit testing (and they also take more time) it's ok for me to run them sequentially one after another. But these really enable two different sets of essential services when needed. Thus reutilizing our infrastructure a bit more. Similar transitions should also be possible across UAT, staging, pre-production, and the ease of tranisition indicates the delta of intigration points.

Published at DZone with permission of Ranjib Dey, author and DZone MVB. (source)

(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)