I’ve been talking to many friends that are involved in product development in start-ups and one issue that we frequently discuss in the huge impact Amazon AWS had over the years in product development and start up acceleration.

However, I’m frequently surprised to learn that many product managers and developers treat AWS as just a hosting provider and ignore the importance of the Amazon environment as a platform for product development and deployment – and this is a big, no, HUGE mistake.

If you are planning to use AWS as your platform, you have to think “Amazonian” and plan your product accordingly.

Here are few ways we have been using EC2 “Amazonian” to speed deployment and massively reduce operational costs (I will write another post about databases and Lambda also):

Design your backend where each server is self-sufficient as much as possible

For me, this is a major thing when designing a highly scalable system that relies on Amazon Auto Scaling. Each server has to be able to work independently and perform all its tasks without replying on another server to complete the task (and I’m not talking about databases, which is a totally different issue). The idea is to design a technology where you each task is self contained and can be independently performed on anyone of the servers involved.

Run mission critical tasks on Spot Instances

Amazingly, many experienced architects and product managers dismiss EC2 spot instances since “Amazon can take them whenever someone bids a higher price…”. While this statement is absolutely true – its also completely irrelevant, if you know how to manage it. Recently Amazon introduced a 2 minute notice that the server is about to be terminated. This allowed us to develop a watchdog that monitors the state of each server and flush the data from the server while issuing another spot request in parallel. My 2 cents – RTFM and learn the instance lifecycle.

Keep an open eye and open your mind to other server types

What we found over time is that we can use a wide variety of servers instead of focusing on the obvious ones. Most dev-ops will focus on the right server configuration for their application – which is correct in general but less so in the Spot Instance ecosystem. What we found over time is that the most important factor is spot price stability – not the price itself but selecting a server configuration. The spot pricing of highly demanded servers (like c4.large) tends to change dramatically while less demanded configurations (like r3.xLarge) tend to be stable. And amazingly the spot price differences is very small. Yet another of my 2 cents – shop around and explore larger servers and look for price stability.

Take a look at these pricing graphs over the last week.

c4.large instance pricing fluctuates between $0.0161/hour to $0.46/hour on all zones while r3.xLarge stays relatively stable at $0.0323/hour on all zones (with some spikes in us-east-1e).

 

The result is a dramatic cost saving in platform operational costs.

Happy coding.