Amazon is a very convenient way for start-up companies to set their businesses up in a short amount of time. Especially with the variety of services it offers to easily scale out your business. We (Saplo) is one of such companies, taking advantage of Amazon’s Web Services and APIs here are our top six reasons why start-ups should use the cloud.
1) Elastic Cloud Computing (EC2)
We use EC2 in different ways and parts of our system. First off, it’s a really convenient way for us to run tests.
We have set up and bundled several EC2 test machines. Whenever needed, we can start an EC2 server using those bundles and have our test machines running in several seconds. It costs almost nothing, and you only pay for storing those bundles on Amazon’s S3, and for having those EC2 servers running during the test, which rounds up to a couple of cents during each test run.
Moreover, EC2 is perfect for scaling out our systems. We have bundles for different Saplo services, like the API, widget, etc, and whenever there is any load on the servers, some magic scripts automatically start up additional work servers. Of course, the perfect way to handle it would be to take use of Amazon’s Auto Scaling solutions, but in our case, the load can not really be determined by the machine load. Therefore, we have our custom scripts to manage load levels, and start up/shut down additional instances whenever necessary.
The only downside of using S3 bundled servers for this is that, if we change or update the servers, we need to re-bundle and re-store them on S3. Although the process of re-bundling is also automatized, it requires a little manual work, just to make sure everything goes as desired. In the future, we are looking forward to moving towards a “puppetized” solution, using Puppet-Lab’s awesome framework to push changes directly into the servers, and automatically setting up any dummy Amazon EC2 instance whenever we need it.
2) Simple Storage Service (S3)
Amazon has proven its S3 as a reliable service to store whatever data you want on the cloud. S3 also stands behind some other AWS services, like storing your EC2 bundles, EBS instances, snapshots, etc. Other than that, we use S3 for storing various kinds of data files that we want available at any time we need.
3) Elastic Block Storage (EBS)
Elastic Block Storage is used for more critical parts of our services. We have customized automatic snapshotting scripts for almost all of the EBS instances we run, taking daily/weekly snapshots for availability reasons. Unlike EC2 instances, EBS is more reliable and offers extended functionality, like backups, surviving service interruptions, etc. for a little extra cost :)
There is a really cool snapshotting tool by Eric Hammond called ec2-consistent-snapshot.
4) Elastic Load Balancer (ELB)
In order to easily scale out and down, we take use of Amazon’s Elastic Load Balancers. All you have to do is register an extra worker server with your load balancer, and it’s transparently added into the group of working servers behind the load balancers and your users won’t even notice a glitch.
Besides, load balancers are a perfect way of handling Amazon availability-zone blackouts. We have our instances spread out onto different availability zones behind our ELBs. Furthermore, it can automatically detect unhealthy instances and route its traffic to other healthy ones, until the damaged server comes back online or replaced.
5) Route 53
After having to struggle with loopia.se and repeating failures on their DNS services, we had to come up with a more reliable solution. And guess what we ended up with! Right, Amazon Route 53. Once you get familiar with its API, Route 53 is a really easy and simple way of handling DNS routings in the cloud. Plus, the changes you make take effect almost instantly.
Amazon CloudWatch offers great monitoring options for all the instances within Amazon. However, since we use a hybrid cloud with different machines spread on different providers, we have chosen Icinga open source monitoring service as a central monitoring point for all of our cloud servers. It’s used for monitoring servers from a single location, sending alert emails and even sms messages, automatically taking critical measures, etc. For instance, we use some custom icinga plugins to determine load on our API servers, and it automatically starts a new instance, or replaces unhealthy instances whenever necessary.
Picture: Athena’s Pix