Hosting

Grant Shipley gshipley at gmail.com
Wed Dec 11 21:44:43 MST 2013


On Wed, Dec 11, 2013 at 8:03 PM, Sasha Pachev <sasha at asksasha.com> wrote:

> >Not picking on you but do you honestly think someone hosting their own
> >server will have better uptime than using one of the current top tier
> cloud
> >providers?
>
> I do not work much with clouds, but I have had some experiences that
> makes me wonder about the stability of the current cloud solutions:
>

Disclaimer: I am certainly biased as I have been evangelizing cloud
computing full time for over two years.  Keep that in mind when you read my
thoughts.

Just curious on your opinion here.  Why do you think the industry as a
whole is rapidly moving to cloud based infrastructure as a service?

We often see when ec2 goes down that it is a major news story because
netflix, reddit and pinterest stop working.  This is a big deal and *is*
newsworthy.  One could argue, I am not, that they could have better uptime
if they owned their own datacenters.  But we will never know because it is
hypothetical.  IMO, it is not for cost savings.  Moving your workloads to
the cloud often (90% of the time) actually cost you more money that buying
your own equipment.  I don't buy the argument that people are moving
because its the hot buzz word.  That will work for smaller companies but
not large public corporations where every change is scrutinized by the
shareholders, board, customers, and media.


Forbes reports more than half of us businesses are using cloud. [1]
Amazon reports that Netflix, dropbox, reddit, Instagram, spotify, Pinterest
etc [2]
Groupon is hosted via engine yard (PaaS) [3]
Netflix is largest single source of internet traffic in North America
(running on ec2) [4]
EC2 alone had 500,000 linux servers in early 2012.  That number is probably
much larger now [5]



> * I have seen MySQL stuck due to failed I/O several times on Amazon
> cloud. Never quite like that on a dedicated machine - not so
> spectacularly where every read() syscall would just sit there
> indefinitely instead of coming back with some kind of an error.
> * Netflix outage due to cloud failure made the news recently. I do not
> recall a major news item that had to do with a regular dedicated
> server failure. In fact, it was quite exciting - does not happen
> often.
> * I ran the Big Cottonwood Canyon Half-Marathon this year. When I got
> home I went to their website to check the results and got an error
> several times. Retried several times after giving it some time to
> auto-heal or have the admin take care of it. Then after some time  the
> site started loading, but was extremely slow. I saw the domain of the
> backend scripts was rhcloud.com. I realize that a poorly written PHP
> script combined with a poorly written MySQL query can produce some
> wonderful results, but you can only botch it so much while fetching
> only 5K records on modern hardware. I have seen horrendously
> inefficient code perform just fine even under load on a normal
> dedicated server.
>

Yikes, that is bad.  rhcloud.com is actually OpenShift, the project I work
on. Do you know if this was because poorly written code or the service
itself?

The big thing I always talk about when giving conference sessions is that
people think cloud computing will solve all of their problems.  Think back
to the Microsoft commercial a few years ago where a family was sitting
around looking at vacation photos.  They were horrible photos.  The wife
suddenly says "To the cloud" and the photos magically get better.  Let it
be known that the cloud will not automagically correct your horrible
vacation photos and it *certainly* will not fix the crappy code that
developers write.  In fact, it will expose crappy code faster because
suddenly crappy developers are no longer developing for a single system.
 They are coding for a clustered environment that can scale.

Just as you can list instances where public cloud has had failure, I could
certainly provide a list of sites I visit regularly that are hosted in
their own datacenter that has a outage.  Outages will always exist to some
extent no matter where you hosted.


> Now the idea of clouds is great. However, I fear that our ability to
> get excited about them exceeds our ability to implement them properly
> which is not an easy task.
>

I do think we see a lot of challenges by programmers and sys admins who are
not accustomed to a cloud environment making mistakes.  Why would you host
all of your servers in one availability zone as opposed to multiple ones
for example?  I see this everyday.  I also see a lot of programmers
thinking the old way when approaching things like:

Session Storage:  In php, I still see most users putting sessions on the
file system as opposed to the database.  What they don't realize is that
unless you have shared storage across your cloud deployments, scale events
will break sessions.
Media Storage: Same of session storage.  Stop placing files directly on the
file system.  Most PaaS providers suggest you use an object store that
scales as your nodes grow.
Clustering:  Let's be honest here -- Most developers have zero clue how to
code for a clustered environment.  Once they move their app to a cloud
provider that promises autoscaling based on traffic, their app dies as soon
as it scales up.


Just my 1.02.


[0] This is the number I keep hearing from people but I don't have a link
to back it up.  I did find that 1/3 of all internet users visits at least
one ec2 hosted site a day though.
[1]
http://www.forbes.com/sites/reuvencohen/2013/04/16/the-cloud-hits-the-mainstream-more-than-half-of-u-s-businesses-now-use-cloud-computing/
[2] http://aws.amazon.com/solutions/case-studies/
[3]
https://blog.engineyard.com/2011/groupon-makes-history-in-more-ways-than-one
[4] http://techcrunch.com/2011/05/17/netflix-largest-internet-traffic/
[5]
http://www.zdnet.com/blog/open-source/amazon-ec2-cloud-is-made-up-of-almost-half-a-million-linux-servers/10620


>
> --
> Sasha Pachev
>
> Fast Running Blog.
> http://fastrunningblog.com
> Run. Blog. Improve. Repeat.
>
> /*
> PLUG: http://plug.org, #utah on irc.freenode.net
> Unsubscribe: http://plug.org/mailman/options/plug
> Don't fear the penguin.
> */
>


More information about the PLUG mailing list