When Amazon Web Services Don’t Cut the Bill

Quite literally actually. Amazon has an amazing compute platform that is by far the most advanced in the industry. The idea to bring computing resources to the application in an object orientated, programmatic interface is a real game changer in how people build (and run) production applications.

It seems to be that when AWS first started to gain traction in the tech industry, especially among the silicon valley crowd, it was always recognized as a cost-effective way for a boot-strapping start-up could build an application that would previously have been impractical for such an early stage idea. Data-center co-location is not something you sign up for in an afternoon from a coffee shop, and hardware has become more inexpensive but usually requires significant up-front capital to get the needed components to run a web application. So naturally, the idea of being able to obtain a production ready server in a matter of minutes with just a credit card and an email address for less than a dollar an hour is quite a savings.

This is how many of the trendy tech companies in the bay area  have come to rely on AWS to run their production application. Their success can in some ways be linked to the availability and affordability of AWS during their initial proof of concept, product launch, and subsequent growth. However what some have found as their production infrastructure grew in scale is that the cost benefits were not as great as they appeared when they first started. While flexibly to scale their infrastructure to meet demand quickly and with less risk may still be of great business value, their monthly operating expenses are not lower because of AWS. This by no means is true for every company. There are many companies at a tremendous size and scale that still see AWS as being more cost effective than running their own data-centers. My point is simply that the reputation of AWS being the solution to reducing operating costs for production infrastructure is not accurate, and it really depends on the company and the use case.

Companies looking to build their application AWS infrastructure should carefully evaluate these trade offs. In general an early-stage start-up will be well off to use AWS, but as they grow that principle may not continue. Thankfully there are options for companies who want to run their application that was originally built for the cloud in house, such as Eucalyptus and OpenStack. It’s going to be exciting to see how the industry matures in it’s use of cloud technologies in 2012!

Info-graphic: AppDynamics Customer Survey

Source: www.AppDynamics.com

Vyatta Routing Platform

Been experimenting with Vyatta lately. So far the results have been good overall. There are a lot of issues that I have faced with Vyatta, but the potential for it becoming a powerful contender in the enterprise routing space are promising.

Pros:

• Powerful features – Everything from BGP to active/active HA
• Debian user-land – Familiar command interface speeds up routine tasks and makes the initial investment of time to learn the platform minimal.
• Rich CLI – For working with vyatta specific routing services, there is a rich and easy to use CLI that you can manipulate just about anything on the system with. Tab completion makes it easy to figure out the nomenclature.

Cons

• Stability - issues with stability of the platform. Hardware compatibility may be a factor here, but the beauty of Vytta is it’s Debian base that should allow it to be installed on a variety of hardware. If you really want to go pro with Vyatta, their appliance versions have certified hardware so you don’t have any unknowns in that area.
• Dependence on consulting – Some advanced features are really hard to get to work right unless you are a Vyatta expert, so you can end up being dependent on professional services from commercial entity behind the software. It’s a fair trade-off as you are paying pennies on the dollar compared to Cisco/Juniper solution.

Productivity Orientated Linux Tools

Perhaps not the most productive, but certianly a lot of fun  :

:~$ apt-get install cowsay
:~$ man cowsay:

NAME
cowsay/cowthink – configurable speaking/thinking cow (and a bit more)

SYNOPSIS
cowsay [-e eye_string] [-f cowfile] [-h] [-l] [-n] [-T tongue_string]
[-W column] [-bdgpstwy]

DESCRIPTION
Cowsay generates an ASCII picture of a cow saying something provided by
the user. If run with no arguments, it accepts standard input, word-
wraps the message given at about 40 columns, and prints the cow saying
the given message on standard output.

To aid in the use of arbitrary messages with arbitrary whitespace, use
the -n option. If it is specified, the given message will not be word-
wrapped. This is possibly useful if you want to make the cow think or
speak in figlet(6). If -n is specified, there must not be any command-
line arguments left after all the switches have been processed.

The -W specifies roughly where the message should be wrapped. The
default is equivalent to -W 40 i.e. wrap words at or before the 40th
column.

If any command-line arguments are left over after all switches have
been processed, they become the cow’s message. The program will not
accept standard input for a message in this case.

There are several provided modes which change the appearance of the cow
depending on its particular emotional/physical state. The -b option
initiates Borg mode; -d causes the cow to appear dead; -g invokes
greedy mode; -p causes a state of paranoia to come over the cow; -s
makes the cow appear thoroughly stoned; -t yields a tired cow; -w is
somewhat the opposite of -t, and initiates wired mode; -y brings on the
cow’s youthful appearance.

The user may specify the -e option to select the appearance of the
cow’s eyes, in which case the first two characters of the argument
string eye_string will be used. The default eyes are ‘oo’. The tongue
is similarly configurable through -T and tongue_string; it must be two
characters and does not appear by default. However, it does appear in
the ‘dead’ and ‘stoned’ modes. Any configuration done by -e and -T
will be lost if one of the provided modes is used.

The -f option specifies a particular cow picture file (“cowfile”) to
use. If the cowfile spec contains ‘/’ then it will be interpreted as a
path relative to the current directory. Otherwise, cowsay will search
the path specified in the COWPATH environment variable. To list all
cowfiles on the current COWPATH, invoke cowsay with the -l switch.

If the program is invoked as cowthink then the cow will think its mes‐
sage instead of saying it.

COWFILE FORMAT
A cowfile is made up of a simple block of perl(1) code, which assigns a
picture of a cow to the variable $the_cow. Should you wish to custom‐
ize the eyes or the tongue of the cow, then the variables $eyes and
$tongue may be used. The trail leading up to the cow’s message balloon
is composed of the character(s) in the $thoughts variable. Any back‐
slashes must be reduplicated to prevent interpolation. The name of a
cowfile should end with .cow, otherwise it is assumed not to be a cow‐
file. Also, at-signs (“@”) must be backslashed because that is what
Perl 5 expects.

COMPATIBILITY WITH OLDER VERSIONS
What older versions?

Version 3.x is fully backward-compatible with 2.x versions. If you’re
still using a 1.x version, consider upgrading. And tell me where you
got the older versions, since I didn’t exactly put them up for world-
wide access.

Oh, just so you know, this manual page documents version 3.03 of
cowsay.

ENVIRONMENT
The COWPATH environment variable, if present, will be used to search
for cowfiles. It contains a colon-separated list of directories, much
like PATH or MANPATH. It should always contain the
/usr/share/cowsay/cows directory, or at least a directory with a file
called default.cow in it.

FILES
/usr/share/cowsay/cows holds a sample set of cowfiles. If your COWPATH
is not explicitly set, it automatically contains this directory.

BUGS
If there are any, please notify the author at the address below.

AUTHOR
Tony Monroe (tony@nog.net), with suggestions from Shannon Appel
(appel@CSUA.Berkeley.EDU) and contributions from Anthony Polito
(aspolito@CSUA.Berkeley.EDU).

SEE ALSO
perl(1), wall(1), nwrite(1), figlet(6)

$Date: 1999/11/04 19:50:40 $ cowsay(6)

View of SF from the Water

This is a shot from the water on a small cruise rig of San Francisco, specifically in view is Ghirardell Square. This was an event that AppDynmics Inc held for it’s global partners, and it was a fun event to be a part of.

Zynga’s Infrastructure: A blend of private and public clouds

If anyone has proven that socially charged gaming is a viral commodity, Zynga has. And at 215+ Million users, Zynga’s infrastructure has to be rock solid to avoid unnecessary outages. The company’s culture centers around play and recreation; but after doing some research on their infrastructure, delivering massive amounts of content reliably and with flexible scale is some serious business.

Cloud based computing is often separated into two categories: public and private clouds. Services provided by companies like Amazon Web Services and Rackspace Cloud are examples of public cloud computing grids. These are probably the most common association when one hears about someone running their application ‘in the cloud’. Private clouds are also of increasing interest and offer many things that their public counterparts can’t. Software like Eucalyptus and Open Stack allow for anyone with physical systems to create scalable and distributed computing while still maintaining control on the security, performance, or cost of the infrastructure.

Zynga makes use of both types of cloud computing, and leverages the benefits that each one provides. While the specifics of their approach are not disclosed by the company, you can learn a lot by observing the technologies they associate with. Their use of RightScale to manage Amazon EC2 instances is well known in the industry. Its interesting to speculate about the technology Zynga uses for running their private clouds in their various datacenters. Zynga’s VP of Network Operations Mark Williams explains in a GigaOM interview that they leverage the public cloud (AWS EC2 in this case) for the launch of new gaming products, and then migrate parts of that same application back into their private cloud as needed for optimizing performance.

The use of AWS as their primary public cloud provider, so it would make sense that they are using an cloud computing platform for their datacenters that is compatible with AWS APIs, like Ecaulyptus or Nimbus. However, their use of RighScale as their orchestration engine and template management tool would give them the ability to use other types of platforms. Open Stack is another cloud infrastructure offering that takes a different approach and is based on the technologies developed by Rackspace Inc for their Rackspace Cloud product. Zynga’s use of RightScale allows them to utilize both types of platforms in their private clouds even with AWS being the primary infrastructure for their apps.

As vendor lock-in is an ever increasing concern in the IaaS spaces, services like RightScale offer a bit of freedom to use different platforms. Apparently people are seeing the value; RightScale boasts their deployment usage doubled in the last year. I still have to wonder though if this solution to a problem is really no solution at all. Using a orchestration tool with all the bells-and-whistles (instance templates, auto-scaling, etc) means you have some autonomy over cloud providers, but aren’t you still locked into that orchestration tool? Seems like a layer of abstraction is added to the stack, but the same business risk with being dependent on a vendor applies.

Zynga is got a good thing going no doubt, and it’s exciting to see them on the frontier of cloud computing and IaaS. Much like the Amazon Web Services poster-child Netflix, they are really setting the pace for the industry’s adoption of these technologies. As much as talk about this subject is in abundance, the amount of large production shops that are putting their mission critical stuff in the cloud is still a small percentage. Quantifiable stories are needed to establish credibility with developers and system architects in the field. Keep up the good work guys!

Sources:

http://www.kavistechnology.com/blog/?p=1625
http://www.datacenterknowledge.com/archives/2010/05/12/zynga-leases-data-center-in-virginia/
http://www.puppetlabs.com/blog/case-study-zynga-rapidly-scales-its-infrastructure-with-puppet/
http://venturebeat.com/2010/03/16/northscale-zynga-memcached/
http://www.zynga.com/about/facts.php http://www.cio.com/article/545713/Gaming_Company_Zynga_Sets_Up_India_Development_Center

My Zerply Profile

Check out my Zerply profile! :

zerp.ly/wjimenez5271

Google Ventures

Stumbled upon a site (not using a popular social bookmarking service ) today about Google’s VC arm. My first thought was, ‘wow that’s full circle for investing in startups.’ It makes sense though, Google has some unique insight into where the market is going and what the hot companies are today. Their search data alone is invaluable in this respect, and they have built a sizable portion of the industry where these startups are being incubated.

It doesn’t discredit companies like Sequioa, who was around before Google’s success….they obviously know a thing or two about venture capital. Worth a look:

http://www.google.com/ventures/index.html

Clever system downtime page

Mint.com (Intuit) has always had a pretty straightforward and conservative customer image, natural for a company dealing with your finances. Today they are showing a little humor as I noticed in their scheduled downtime page.

A screen shot from the Mint.com downtime page