« Page 15 of 18 »

  1. Amazon is working on a significant new feature for the EC2 service: persistent storage. According to this pre-announcement post in the developer forums, EC2 users will be able to create storage volumes that exist separately from individual instances, but which can be attached to your instances on demand. These storage volumes will look like normal block devices to your instance, meaning you can format and combine them in any way you want.

    The persistent storage feature is still in the testing stages and is not yet available to the general public. There is more information available on the Amazon Web Services Blog and on the RightScale blog, where they have access to the trial version.

    A robust, flexible and reliable persistent storage mechanism could revolutionise the EC2 service, and will definitely simplify the process of deploying your applications to the cloud. However, I wonder whether this feature will damage the third-party providers who already offer persistence solutions for EC2.

    As Amazon continues to develop and improve their infrastructure services, they will need to be careful to avoid wiping out the third-party vendor ecosystem based on these services.

    There are comments.

  2. Amazon's Elastic Compute Cloud (EC2) service suffered a networking outage yesterday that caused instances to become inaccessible from outside Amazon's network. This meant that connections from the Internet failed to reach some instances, though these instances continued running and were accessible from other machines within EC2. The outage lasted for up to an hour, according to comments in the discussion forums.

    Amazon staff are investigating the issue and as of now there is no official word on the cause, but what is likely to be of most interest to EC2 users is whether all of the availability zones (locations) were affected. If the outage was localized to one or two zones (out of three) it would demonstrate the benefit of distributing your instances between multiple zones using the new Availability Zone feature.

    If all the zones were affected, this would demonstrate a central point of failure that partially nullifies the strategy of distributing your instances across zones. In this case, Amazon would need to modify the architecture to remove the centralized failure point.

    The forum discussion thread contains conflicting reports from users about whether the fault was localized or general. I will update this post when more information is available.

    Update

    An Amazon staff member has posted a post mortem comment stating that this networking issue did indeed affect multiple Availability Zones. It looks like this happened because the failure was caused by misconfiguration rather than by a hardware or connection failure -- basically one of those completely unexpected events for which there are no contingency plans.

    This was an embarrassing glitch, and one which cannot be repeated if developers are to believe that different availability zones give true isolation from failures.

    On the bright side, the issue was fixed quickly despite the cause being difficult to find, and the full and frank explanation from Amazon gives grounds for hope that the necessary monitoring and process improvements will be put in place to prevent a repeat.

    There are comments.

  3. Paul Graham has written a short yet striking article, How to Disagree, which could help us all improve the tone and content of debates we pursue online. He classifies comments expressing disagreement into a Disagreement Hierarchy with seven levels, from insults and ad hominem attacks at the bottom through to counterarguments and reasoned refutation of your opponent's central point at the top.

    As he points out, being aware of this hierarchy will help not only to recognise weak arguments made by others, but to make your own case more powerfully and more politely:

    [T]he greatest benefit of disagreeing well is not just that it will make conversations better, but that it will make the people who have them happier.

    There are comments.

  4. ELASTRA recently announced their ELASTRA Cloud Server product, a server application that aims to make it significantly easier to design and deploy cloud-based applications.

    The company is working to provide an application design and management system that will allow users to:

    • specify their application’s components and architecture using a declarative mark-up language
    • deploy and manage the application in their chosen cloud service provider or virtual machine environment, and
    • monitor their application and scale it on demand.

    At this stage, the server supports a number of open-source relational database components that can be deployed to Amazon's EC2 and S3 services. This makes it possible to deploy a clustered, scalable RDBMS to your EC2 instances where the data is automatically persisted to S3 to survive any instance failures.

    The product is currently only available to a limited set of users upon application, however the company intends to make it generally available in April. Pricing has not yet been announced, but it will be based on a metered system where you pay according to your usage.

    If the ELASTRA Cloud Server does indeed make it simple and economical to run a highly-scalable and reliable RDBMS in EC2, it will be a huge boon to developers who would rather spend their time building applications than hand-crafting a database system to work well within the constraints of Amazon's services.

    There are comments.

  5. Thirty

    2008-03-28

    262,992 hours.

    10,958 days.

    1,565 weeks.

    1 lifetime.

    But who's counting...

    There are comments.

« Page 15 of 18 »