Amazon Elastic Compute Cloud (Amazon EC2) is a web service that provides resizable compute capacity in the cloud. Amazon Cloud Computing is a good choice if you want to deploy a very large scale network on the cloud that requires high availability, auto scaling and load balancing features.
This article is a quick introduction on designing to achieve High Availability (HA) with your AWS infrastructure architecture. We’ll start with a simple (and vulnerable) architecture design and work our way up to a complex multi-region setup. How far you go up these steps is up to you, depending on your uptime requirements (or SLAs) and budget.
The prsentation brought you by Jared Rosoff, Director of Product Marketing and Technical Alliances at 10gen. The presentation includes an overview of MongoDB deployment on Amazon cloud service. You will also find some basic operational considerations with regards to deployment, backup and security management. Jared also published an interesting NoSQL database comparison on his blog, we strongly advice you to review.
Following Max B. post on KnowYourCloud and based on questions received at AWS Usergroup meetups I realized that there is a reasonable (but sometimes exaggerated) concern about the level of lock-in to AWS. In this article we will try to put the problem in the right perspective and explain the practical lock-in considerations for the various services of Amazon’s cloud.
What is vendor lock-in? Vendor lock-in is the situation where a business becomes overly dependent on a specific service or product provider.
Important step with cloud adoption is to manage quick cycles of learning and improvement of the cloud environment. The following presentation brought you by Amazon AWS guys contains great amount of slides including best practices and examples for Continuous Deployment, Optimization and Integration.
In this article I describe how we created a redundant PostgreSQL database on the Amazon cloud using EBS snapshots as backups to deploy a PostgreSQL DB server DR mobile application for one of our customers.
PostgreSQL 9.1 includes new capabilities for asynchronous fast replication syncing between master and slaves. The master server streams new data to the current available slave. This version includes great improvements that generated significant fast WAL (Write Ahead Log) processing, which generates replication and fast launching capabilities for the slave servers.
The following presentation describe briefly how to start with DynamoDB to support PHP sessions. Check out the full article – PHP Sessions with a DynamoDB Backend, includes why to move to DynamoDB (AWS Cloud Scalable and Consistently performing NoSql as a service) and additional important considerations.
When scaling an application, session sharing across multiple web servers is one of the first issues that need to be tackled. This issue is a bit more complex in autoscaling setups in the cloud where application servers are added or removed from the load balancer as traffic and load increases or decreases.
OpenX Source is a free, open-source ad server that allows publishers to manage their ad inventory and set up complex campaigns with sophisticated targeting rules. Unfortunately, since OpenX has been focusing on their SaaS solution, the open source version is not well supported anymore. Nevertheless, many publishers still use and maintain their OpenX installations as there is a lack of open source alternatives offering the same flexibility and functionality. Existing documentation to a great extent assumes a single server installation. For high traffic web sites delivering a large volume of advertisement impressions, there is a need for a more scalable setup. In this article we will describe the steps we have taken to implement OpenX on a multi-server, auto-scaling setup running in AWS cloud and managed via Scalr. A similar approach could, of course, be configured outside the Scalr or even AWS context. We will mention some of the alternatives.