Taking Requests

It’s the end of a long, hard, day and I’m thinking about writing a blog entry. But… I usually only write when something is happening somewhere which gets me sparked… Because I’m at a loss when trying to think about what would be interesting or not to other people. So I figure I’ll take requests. I have maybe a reader base of 10 one-time readers, and 2 full time readers (unless I dont count then its probably just 1… :D) but surely you guys must have some topics that you’d like some input on? So think of this as a text-based radio station and it’s the all-request lunch hour.

Or, if no one responds, I’ll have to just wait till the muse strikes…

2 thoughts on “Taking Requests

  1. Hey,

    I posted the message below on the Amazon EC2 forums. Haven't gotten a real response.

    Maybe you can take our real life case and educate me and the readers, where I'm wrong and maybe even take us throught the process of dreaming someting up that would work for us.

    The product's called Transact and we love to show people how we're bootstrapping and still doing this, so this would be a great way to combine that with your knowledge of this technology that we'd love to work with.

    Link to the diagram:
    http://developer.amazonwebservices.com/connect/se

    ——

    Hi guys,

    I'm trying my best to fully comprehend the limitations of EC2 from the different discussions on the forum to decide if we should choose EC2 as our hosting platform to launch our new web app.

    So I would love your input on our case:

    The Case

    I've designed a new CRM/ERP app, that is currently being built on the Ruby-on-Rails platform. Obviously this app and the databases need to be hosted and backed-up well, because of the importance of the data that is stored.

    Enter the Amazon press release: ,,We have S3 and now EC2!"

    My thoughts: This is fantastic! I can't afford to built anything close to that, let alone want to deal with the organizational implications of backup procedures, wait time for new servers etc. So this could very well be a great choice for us.

    So in technically I think I hear: 1) Persistant data backup & 2) Cheap (auto-)scalable servers with quick availability.

    But as always the devil is in the details:

    The Issues

    – I read on the forum that the EC2 drivespace is non-persistant and so it's gone when an instance crashes. The equivalent of a 'normal' dedicated server with a drive meltdown.

    Can we couter that by doing a RAID setup across 2 (or 3) instances? With the added advantage of multiple processors, so stellar performance?

    (Turning it into an economical issue if you can make that many instances work with your business model).

    – And then scale this setup if our data requirements increase to more then 160GB?

    – And for long-term data safety, we could make hourly backups to S3? That would offer a good level of datasafety on top of the RAID.

    – If this all is possible, is it feasible to put this into semi-automatic procedures, that kick into action when certain events occur? Like for example activating a replacement instance when a instance should crash.

    A setup something like I included in the diagram.

    I would greatly appreciate your input about this case and like to hear your vision about if we're on the right path with this.

    Also if this is viable, I would need someone to help us implement, so if you're interested in that, please let me know.

    Thanks,

    Danny

    ——-

Leave a Reply