I'm looking at beginning some work on a cloud based application and I'd be interested to hear of anybody's experiences of pitfalls they have run into particularly from a design/architectural standpoint when working with cloud platforms. Are there any expectations that might change significantly from regular web development practice? Things that you wish you had been aware of before you got started or that might have influenced your choice of platform had you been aware of them? I realise there are significant differences between the different options out there, but I feel there are significant enough similarities to warrant asking this as a general question.

Any experiences with particular platforms would also good- it would be interesting to see whether others have found similar things happening on other platforms too...

  • 6
    I always get rained on. – GrandmasterB Dec 17 '10 at 23:00
  • I just know that something good is going to happen when I get started on this project... – glenatron Dec 18 '10 at 17:49

The eight fallacies of distributed computing:

"Essentially everyone, when they first build a distributed application, makes the following eight assumptions. All prove to be false in the long run and all cause big trouble and painful learning experiences.

  1. The network is reliable
  2. Latency is zero
  3. Bandwidth is infinite
  4. The network is secure
  5. Topology doesn't change
  6. There is one administrator
  7. Transport cost is zero
  8. The network is homogeneous

For more details, read the article by Arnon Rotem-Gal-Oz "


| improve this answer | |
  • One can only wonder how companies like Google, Amazon, Yahoo! and Facebook -- and all the people using their APIs and offering services based on the cloud, managed to make a living seen that apocalyptic description there. Just to be clear: do you think that if one takes into account these height fallacies then cloud computing can work or it's a dead trap from the start? – Cedric Martin Nov 6 '11 at 16:34
  • @CedricMartin by not taking any of them for granted. You may want to read the experiences Netflix had with AWS at techblog.netflix.com/2010/12/…. They explicitly created a Chaos Monkey whose job it was to "randomly kill instances and services within our architecture". An interesting read. – user1249 Apr 3 '12 at 14:13

Assume every node/machine/instance will fail often. Your architecture has to not only be tolerant of these failures but also expect that they will happen frequently. So your system shouldn't only survive such incidents, it should not even be bothered by them and should (ideally) heal itself when they happen.

It's my experience that particular cloud instances are usually much less reliable (in all parameters) than plain old servers. Their strength lies in their numbers, and not in any particular node. So make you system distributed and redundant at its core.

| improve this answer | |

Learn from the Chaos Monkey.

We’ve sometimes referred to the Netflix software architecture in AWS as our Rambo Architecture. Each system has to be able to succeed, no matter what, even all on its own. We’re designing each distributed system to expect and tolerate failure from other systems on which it depends.

One of the first systems our engineers built in AWS is called the Chaos Monkey. The Chaos Monkey’s job is to randomly kill instances and services within our architecture. If we aren’t constantly testing our ability to succeed despite failure, then it isn’t likely to work when it matters most – in the event of an unexpected outage.

| improve this answer | |
  • I agree that this type of testing should be done. It is very important to randomly shut ports, cycle power and (if using remote hands) simulate mistakes that they may make when doing things for you, such as plugging something into the wrong switch. However, it is equally important to identify not only the likely failures, but also the sequence in which they would most commonly happen. This helps self healing to not only deal with failures, but also proactively prevent them. – Tim Post Dec 18 '10 at 9:46

The same pitfalls that people have on non-virtualized platforms.

  • Apps that don't scale horizontally.
  • Poor algorithm choices/implementations.
  • Absence of graceful reduction of features and performance in response to high load/ reduced resources.
  • Ignorance of the common/likely problems on the platforms you run on and having a plan to mitigate the those risks.
| improve this answer | |
  • Surely the whole purpose of designing for the cloud is to mitigate precisely some of these problems- particularly performance and scaling issues? – glenatron Dec 19 '10 at 14:38
  • Do not mistake the limitations of badly written application for the limitations of the platform it runs on and vice-versa. I have seen apps that that couple session/members/transactions to the local machine that they are on which means those connections and therefore the load of those connections cannot be moved off those machines. I have also seen apps which are written such that the additional load they create on the support infrastructure makes it cost prohibitive to add more apps servers because you would need to move to 16 core servers to serve an extra few 100K. – dietbuddha Dec 20 '10 at 5:53

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.