Over the summer months, we'd like to share a few stories from startups around the world: what are they working on and how they are using the cloud to get things done. Today, we're profiling Yottaa from Cambridge, MA!

I first met Coach Wei, CEO and founder of Yottaa, last year, as a finalist in the AWS Start-up Challenge. With a name like “Coach” and a deep passion for speed and web performance, he sounded like he was the perfect guy to run a startup like Yottaa.

Anybody can visit www.yottaa.com, enter a URL and learn about its performance and user experience over time, and across multiple geographies. The Yottaa free monitoring tool, Yottaa Insight, also enables users to link their Google Analytics account to provide deeper insight into the correlation between site performance and business objectives. Their paid product, Yottaa Optimizer, is a web performance optimization service that aims to double the speed of your website within a few clicks, without code changes, software installs or hardware purchases.

Q&A with Coach Wei:

Creating a Free Product Offering

AWS is a big reason that we are able to provide Yottaa Insight, a premium web performance monitoring service, for free. We run hundreds of machines at any single moment, but the system dynamically scales up and down at many different geographic locations in response to the workload demands.

Growing and Solving the Data Management Problem with AWS

The amount of performance monitoring data we collect for our users have grown over many terabytes. How to manage the large amount of data is a common challenge for startups with data-centric web applications. Like most web startups, we started by storing all the data in our database initially. It quickly outgrew what a database can handle. Luckily we have quite a few options with AWS. One of the recent actions we took is to move most of the historical data onto Amazon S3 and only keep the recent data in our database cluster. This design essentially makes our data storage almost infinitely scalable. Another action that we took is to implement data replication to another geographic location, which gives us redundancy and disaster recovery protections.

AWS Start-up Challenge Impact on Yottaa: Confidence & Validation

In our particular situation, the biggest difference AWS contest made for us is "confidence" or "bragging rights" : it gives us a certain level of confidence that we are onto something. Yottaa is taking a new approach to solve some difficult problems by leveraging the AWS cloud. A large part of the unknowns came from whether it was feasible to do wire-speed optimization of web pages, both technically and financially. To our knowledge, no one had solved those issues before. After the contest (and in particular, after talking to the AWS Startup Contest judges, the folks who helped created the entire cloud computing movement), we can confidently say that we were not crazy to attempt this. :-)

Sharing the Wisdom with other Asia-Pacific Start-ups:

SaaS and Cloud start-ups are blazing new trails with innovative approaches, architectures, and delivery models. Amazon Web Services provides a fantastic foundation to build on. Our advice for start-ups is to embrace the cloud and design your application’s architecture to leverage multiple AWS services. For example, Yottaa architected the system to leverage Spot Instances and multiple AWS regions and Availability Zones. Decisions like these create both a robust platform and the ability to scale infrastructure and costs as your startup begins to get traction.

Another quick thought is the "audacity of dreaming". Dream big. Cloud provides a cost-effective way to figure out the validity and viability of your dream..

The AWS Startup ChallengeWe're getting ready to launch this year's edition of our own annual contest, the AWS Startup Challenge. You can sign up to get notified when we launch it, or you can follow @AWSStartups on Twitter.

We've made some important updates to EC2's Auto Scaling feature. You now have additional control of the auto scaling process, and you can receive additional information about scaling operations.

Here's a summary:

You can now elect to receive notification from Amazon SNS when Auto Scaling launches or terminates EC2 instances.

You can now set up recurrent scaling operations.

You can control the process of adding new launched EC2 instances to your Elastic Load Balancer group.

You can now delete an entire Auto Scaling group with a single call to the Auto Scaling API.

Auto Scaling instances are now tagged with the name of their Autos Scaling group.

NotificationsThe Amazon Simple Notification Service (SNS) allows you to create topics and to publish notifications to them. SNS can deliver the notifications as HTTP or HTTPS POSTs, email (SMTP, either plain-text or in JSON format), or as a message posted to an SQS queue.

You can now instruct Auto Scaling to send a notification when it launches or terminates an EC2 instance. There are actually four separate notifications: EC2_INSTANCE_LAUNCH, EC2_INSTANCE_LAUNCH_ ERROR, EC2_INSTANCE_TERMINATE, and EC2_INSTANCE_TERMINATE_ERROR. You can use these notifications to track the size of each of your Auto Scaling groups, or you can use them to initiate other types of application processing or bookkeeping.

Recurrent Scaling OperationsScheduled scaling actions for an Auto Scaling group can now include a recurrence, specified as a Cron string. If your Auto Scaling group manages a fleet of web services, you can scale it up and down to reflect expected traffic. For example, if you send out a newsletter each Monday afternoon and expect a flood of click-throughs, you can use a recurrent scaling event to ensure that you have enough servers running to handle the traffic. Or, you can use this feature to launch one or more servers to run batch processes on a periodic basis, such as processing log files each morning.

Instance Addition ControlThe Auto Scaling service executes a number of processes to manage each Auto Scaling group. These processes include instance launching and termination, and health checks (a full list of the processes and a complete description of each one can be found here).

The SuspendProcesses and ResumeProcesses APIs give you the ability to suspend and later resume each type of process for a particular Auto Scaling group. In some applications, suspending certain Auto Scaling processes allows for better coordination with other aspects of the application.

With this release, you now have control of an additional process, AddToLoadBalancer. This can be particularly handy when newly launches EC2 instances must be initialized or verified in some way before they are ready to accept traffic.

Hassle-Free Group DeletionYou can now vanquish an entire Auto Scaling group to oblivion with a single call to DeleteAutoScalingGroup. You'll need to set the new ForceDelete parameter to true in order to do this. Before ForceDelete you had to wait until all instances in an Auto Scaling group were terminated before you were allowed to delete the Auto Scaling group. Auto Scaling will terminate all running instances in the group and obviates the waiting.

Easier IdentificationInstances launched by Auto Scaling are now tagged with the name of their Auto Scaling group so that you can find and manage them more easily. The Auto Scaling group tag is immutable and doesn’t count towards the EC2 limit of 10 tags per instance. Here is how the EC2 console would show an instance of the Auto Scaling group SpeedTest:

Over the summer months, we'd like to share a few stories from startups around the world: what are they working on and how they are using the cloud to get things done. Today, we're profiling Mediology Software from India!

Mediology Software is currently a one-year old start-up based out of India and employing 35 people. Mediology DigitalEdition, their main product, is a SaaS platform that enables print publishers to digitize their content, add interactivity, create workflows, and then distribute the content via web, mobile and e-reading platforms. The system achieves its massive scale for content digitization and delivery using event-centric cloud computing services from AWS.

As an example of the type of work Mediology does, I encourage you to take a look at the case study we recently published, describing how AWS and Mediology teamed up to help CozyCot.com, a website geared to East Asian and South Asian women on a wide range of topics including family, health, beauty, etc. In addition to offering CozyCot a better website hosting and scaling solution through the AWS infrastructure, Mediology has helped them distribute and promote their content through a wide variety of platforms, increasing CozyCot’s bottom line.

From the FoundersI caught up with Manish Dhingra and Gaurav Bhatnagar, Co-Founders at Mediology Software, a few days ago, as I was checking on how they’re doing almost a year after being named finalists in the AWS Start-up Challenge.

Since January 2011, we have had some high-profile launches on our DigitalEdition platform. Naturally, the usage of AWS, not just in terms of the instance volume, but across the set of AWS services has enabled us to create a very scalable, yet cost-effective architecture. We're 100% build and reliant on AWS. For instance, we use EC2, Cloudfront, S3, SES, SimpleDB, RDS, SNS, CloudWatch and IAM, all orchestrated together to enable our SaaS platform, Mediology DigitalEdition.

How Has the AWS Start-up Challenge Helped Mediology?I asked Manish to tell me how the AWS Start-up Challenge has helped their business. Here's what he told me:

Consumer and Customer confidence in our solution has definitely taken a giant leap, since we returned from Palo Alto in December 2010. Although the same has also led to higher expectations, our grasp of AWS has enabled us to meet the customer expectations quite easily.

Sharing the Wisdom with other Asia-Pacific Start-ups:

AWS gives you the ability to enable application or solution heavy-lifting. We believe Asia is a growth market and many new age concepts around value-based computing, value-added services (specifically around mobile, which works on the core tenets of SaaS and SOA) will find great traction here.

The key is to not get fazed during the stealth and growth stages of your start-up. Think of AWS as something that gives the wings to your creativity and enables very effective working-capital utilization. In fact, if the pricing benefits are passed on to the consumers, then there is a great chance of leveling the playing field and being the best at what you do, without compromising on the bottom line.

The AWS Startup ChallengeWe're getting ready to launch this year's edition of our own annual contest, the AWS Startup Challenge. You can sign up to get notified when we launch it, or you can follow @AWSStartups on Twitter.

I spent yesterday morning working in a coffee shop while waiting to have an informal discussion with a candidate for an open position. From my vantage point in the corner I was able to watch the shop's "processing pipeline" in action. There were three queues and three types of processing!

The customers were waiting to place an order, waiting to pay, or waiting for their coffee.

The employees functioned as order takers, cashiers, or baristas.

It was fascinating to watch this dynamically scaled system in action. Traffic ebbed and flowed over the course of the three hours that I spent in my cozy little corner. The line of people waiting to place an order grew from one person to twenty people in just a few minutes. When things got busy, the order taker advanced through the line, taking orders so that the barista(s) could get a head start. The number of baristas varied from one to three. I'm not sure what was happening behind the scenes, but it was clear that they could scale up, scale down, and reallocate processing resources (employees) in response to changing conditions.

You could implement a system like this using the Amazon Simple Queue Service. However, until now, there was no way to scale the amount of processing power up and down as the number of items in the queue varied.

We've added some additional Amazon CloudWatch metrics to make it easier to handle this particular case. The following metrics are now available for each SQS queue (all at 5 minute intervals):

NumberOfMessagesSent

SentMessageSize

NumberOfMessagesReceived

NumberOfEmptyReceives

NumberOfMessagesDeleted

ApproximateNumberOfMessagesVisible

ApproximateNumberOfMessagesNotVisible

We have also added the following metrics for each Amazon SNS topic, also at 5 minute intervals:

NumberOfMessagesPublished

NumberOfNotificationsDelivered

NumberOfNotificationsFailed

PublishSize

You can create alarms on any of these metrics using the AWS Management Console and you can use them to drive Auto Scaling actions. You can scale up when ApproximateNumberOfMessagesVisible starts to grow too large for one of your SQS queues, and scale down once it returns to a more reasonable value. You can also watch NumberOfEmptyReceives to make sure that your application isn't spending too much of its time polling for new messages. A rapid increase in the value of ApproximateNumberOfMessagesNotVisible could indicate possible bug in your code. Depending on your application, you could also watch NumberOfMessagesSent (SQS) or NumberOfMessagesPublished (SNS) to make sure that the application is still healthy. Here is how all of the pieces (An SQS queue, its metrics, CloudWatch, Auto Scaling, and so forth) fit together:

Next week (July 27th to be precise) I will be speaking at a special event in Hollywood, California.

Titled Enabling Content Workflows in the Cloud, the event is sponsored by AWS and Aspera. I'll be presenting, as willl Michelle Munson (President, CEO, and co-founder of Aspera).

If you work in media, digital media, or entertainment an an IT Executive, Manager, or Architect, you should find the content to be of immediate, practical value to you and your organization. Michelle and I will talk about AWS, with a focus on Amazon EC2, S3 and CloudFront from me and on Aspera On-Demand from her. We'll talk about media storage and processing success stories from Netflix and others.

The formal event runs from 4:00 to 6:00PM, followed by two hours of networking and a cocktail reception.

Again, this event is intended for IT folks in the media, digital media, and entertainment business. If you would like to attend, please sign up here, and I will see you next week.

There are no new "attachment" APIs. Instead, you simply use the existing SendRawEmail function to send a message that includes one or more MIME parts. Each part of the message must be of a MIME type that is supported by SES. Document and image formats are supported; executable files and archives are not. Consult the SES documentation for a complete list of supported MIME types.

Messages that include attachments incur an additional cost of $0.12 per GB of attachment data. This is in addition to the $0.10 cost for every 1000 messages and the usual cost for outbound data transfer (see the SES page for details).

I spent a few minutes putting together some PHP code to create and send a message with an attachment. I installed and configured the latest version of the AWS SDK for PHP, the Mail_Mime package, and wrote a little bit of code. Here's what I ended up with:

As you can see, this is pretty straightforward. Per the usual operating protocol for SES, you'll need to verify the email addresses that you use for testing, and you'll need to request and receive production access in order to start sending to arbitrary addresses.

Christie from Jinfonet emailed to tell me about their newest video, Cloud Reporting from Amazon EC2:

Per their recent press release, their JReport product can be installed on one or more EC2 instances with linear scaling as additional instances are added. A clustered installation of JReport can include hundreds of EC2 nodes and is able to support any number of users working on mission-critical applications simultaneously. The cluster can be scaled on the fly (read more about the JReport Architecture).

Ruby is a wonderful programming language. Optimized for 'developer joy', it is an object oriented playground for building simple domain specific languages, orchestration tools, and most famously, web applications. In many ways, the Ruby language and Amazon cloud services such as EC2 and S3 have similar goals: to help developers and businesses build innovative products without worrying about the 'muck' that can slow development down.

Today we're bringing Ruby and AWS even closer together, with the AWS SDK for Ruby.

The AWS SDK for Ruby gem

The SDK features a new Ruby gem for accessing a wealth of AWS compute, storage and middleware services whilst handling common tasks such as authentication, request retries, XML processing, error handling and more. With this release of the SDK you can access Amazon EC2, S3, SQS, SNS and the Simple Email Service and we've included an object-relational mapper for SimpleDB. Our goal is to make building applications easier for Ruby developers with an officially supported and fine tuned development experience.

Getting Started

You can install the AWS SDK for Ruby gem from the command line:

sudo gem install aws-sdk

This will give you access to to a collection of AWS specific classes, such as AWS::EC2 and AWS::S3. After specifying your security credentials, you're good to go. The best way to do this is via a simple YAML file:

access_key_id: your_access_key secret_access_key: your_secret_key

You can then load the access credentials, and start issuing requests. For example, this code snippet will create a new bucket in S3 and upload a file as an object with public read access:

The AWS SDK for Ruby also contains an ORM interface to Amazon SimpleDB, called AWS::Record. Let's see how we can use it as a data store from a Rails application. In this example, we'll build a very simple social bookmarking site.

First, we'll create a new Rails application. The AWS for Ruby documentation shows you how to set up your application by hand, but we can automate a lot of this with a simple application template:

rails new tagcloud -m http://ruby-sdk.s3.amazonaws.com/aws.rb

Add your credentials to config/aws.yml, and we can create our first model:

rails generate aws_record bookmark

Open up app/models/bookmark.rb, and we can start defining our model attributes. SimpleDB is a distributed key/attribute store and as such, doesn't require a schema or database migrations. We can simply define our model attributes in this one place, and we're ready to roll. Add the following to the class definition:

SimpleDB offers a highly available, durable data store without the overhead of managing redundancy, replication or even any servers; a popular choice for online social games or metadata indexing. The AWS SDK for Ruby makes it super simple to get up and running, model your domain and persist data without worrying about migrations, schemas or database servers.

Other language support

Native software development tools can help integrate and automate the ecosystem of AWS services, and the AWS SDK for Ruby joins our library of developer tools for Java, PHP, iOS, Android and .Net.