Cloud computing accelerates innovation by providing ubiquitous access to computing resources at a click of a button. However enterprises are weary of the costs associated with public cloud, especially as their usage grows.

At the same time, public cloud providers like AWS have created multiple cloud resource consumption models to reduce the barrier to adoption of their services. AWS users can consume compute resources on EC2 in several different ways – On-demand instances, reserved instances and spot instances. For an average customer, EC2 cost is roughly 70-80% of the total monthly AWS bill. So, EC2 spend is naturally the first place to look for savings.

Lets look at how AWS EC2 instances can be consumed:

On-demand & Reserved Instances

The most common way of consuming EC2 is by launching On-demand instances. On-demand instances provide the most flexibility and predictability but are the most expensive. On the other hand, for enterprises that have predictable, long-term compute needs, using Reserved instances can provide up to 70% in savings but there is limited flexibility in being able to change instance family and regions as well as the long-term commitment involved.

Spot Instances

With Spot instances, AWS allows customers to bid on any unused EC2 capacity in an availability zone. This model allows customers to use compute capacity with no upfront commitment at hourly rates much lower than the on-demand rate. The only caveat being that Spot Instances will be shut down with little warning when the spot price rises above the customer’s maximum bid price, or if capacity for on-demand instances within that availability zone increases. For this reason, spot instances are typically not a good choice for stateful or non-cloud aware applications which require an instance to remain available and retain state. Users interested in using spot instances have to build extensive tooling to be able to deploy their applications. As a result most users have shied away from using spot instances due to their unpredictable nature and the need to build tooling in spite of the extensive cost savings.

Using Nirmata with Spot Instances

Nirmata provides multi-cloud container services with built-in microservices tooling to deploy and operate cloud native applications. Several of our customers are moving towards microservices style applications, where applications are composed of independent services that are designed to be elastic and resilient.

These applications, along with Nirmata sophisticated scheduling and management features, are an ideal match for spot instances. Using flexible resource selection policies to group on-demand instances with spot instances (e.g. 30% on-demand & 70% spot), our users have been able to significantly cut their EC2 costs without compromising on their agility and the availability of their application.

Spot Fleet Requests

Earlier this year, Amazon launched the Spot Fleet API [1] making it even easier to provision spot instances. Now, we have added support for Spot Fleet Requests in Nirmata. With this integration, you can easily leverage spot instances to deploy any containerized application via Nirmata. And in case a spot instance goes away, Nirmata will detect spot instance termination and preemptively redeploy the containers on available instances before the spot instance is terminated, ensuring the application is always available. Note that for this to work, your application containers need to be stateless. There are ways to enable this behavior for stateful applications, perhaps a topic for a separate post.

Here are the steps for using spot instances with Nirmata:

1.    Create an AWS AMI with docker and Nirmata agent and note the AMI ID. See documentation for details:

sudo curl -sSL http://www.nirmata.io/nirmata-host-agent/setup-nirmata-agent.sh | sudo sh -s aws

2.   Create a Spot Fleet Request and use the AMI created earlier. Note, that you will need use the new spot request console, which is still in preview, to create spot fleet requests

Specify the settings for your Spot Instances including Capacity Units, Target Capacity and Bid Price and select the instance types. It is recommended to select multiple instance types to increase your chances of getting a spot instance at any time.

Next select the Allocation Strategy [2] , Network, Security Groups, Availability Zones etc and Finish the wizard to create the Spot Fleet Request.

 

 

3.    Once the Spot Fleet Request is created, log in to Nirmata and create an AWS Cloud Provider, if you don’t already have one and proceed to creating a Host Group.

On the Settings page, select ‘use Spot Fleet Request’ for Host Instances and then select the Spot Fleet Request you created earlier, in Step #2. Finish the wizard.

4.    Shortly, you will see the spot instances discovered and connected to Nirmata.

That’s it! Now your host group is available and you can deploy your application. Once your application is deployed, Nirmata will keep it running even if some spot instances go away and other spot instances get provisioned by redeploying your application containers.

Check out this five minute video to see how to use Spot Fleet Requests with Nirmata.

Use Cases

Our customers have been using Spot Instances with Nirmata for several different scenarios:

• To deploy & operate distributed, microservices style applications
• To simulate IoT/Connected devices for testing
• For testing scaling and availability of their application

I hope this was helpful. In a follow up post, I will discuss how you can use combination of Spot Instances and On-demand instances for distributed applications. Meanwhile, feel free to test drive our Spot Fleet integration and let us know if you have any questions or suggestions.

For more updates and news follow us at:    

 

References:

[1] https://aws.amazon.com/blogs/aws/amazon-ec2-spot-fleet-api-manage-thousands-of-instances-with-one-request/

[2] https://aws.amazon.com/blogs/aws/new-spot-fleet-option-distribute-your-fleet-across-multiple-capacity-pools/