Costs associated with developing cloud applications

A natural question to ask when developing web applications is – how much does the cloud costs when application is still being developed? This question is important as it sheds light on the cloud expenditure that is not going to provide immediate returns. The gains associated with the cloud are going to come only after the application has been developed and is running in production on the cloud, not when it is still being developed.

Recently, we did a small study to answer this question. We present our findings in this blog post.

Let’s take an example of a web application which uses a relational database and drill into the costs associated with developing such an application.

Broadly, there are two kinds of costs associated with cloud application development.

  1. Cloud learning: Let’s say you have chosen AWS. You will have to learn what relational data services are available on AWS. You will come across options of RDS and Aurora, from which you will have to pick one. Once that is done, you will have to figure out how to provision an instance, which database flavor is available in your region of choice, how to use the DB instance in your application, how to ensure that the DB instance is accessible only to your application, and so on. You will also have to figure out what tools are available for deploying your application on AWS. You will realize that there are options such as Elastic Beanstalk and Amazon container service. When picking appropriate tool, you will have to consider trade-offs such as whether you want automatic scaling of application instances, ease of access to application’s runtime logs, access to application’s deployment and runtime artifacts, and so on. Note that the costs associated with cloud learning are one time costs.
  2. Application development: Application development involves two aspects. Development and testing of the application locally and deployment and testing it on the chosen cloud. When developing locally, you will have to figure out things such as how to build and run application locally, how to use a local relational database such as MySQL service, how to setup the database, and so on. To help with your local development, you might use tools such as Vagrant, Docker, and Docker compose. Once local development is done, you might want to deploy the application on the Cloud and test it with the Cloud’s relational database instance such as RDS. For this, you would want to spin up a RDS instance, deploy your application to cloud, and connect the application to the RDS instance.

In our study we used three applications. Two of the applications needed relational database, while the third was stateless application. Between January and April 2017, we were continuously developing these applications and deploying them on AWS and Google clouds as part of our development. In total, we consumed 759 hours of Cloud database services (across both clouds).

Following tables presents cloud expenditure and cloud performance as related to our experiment.

Cloud Expenditure
Service Rate ($/hour) Experiment period (Months) Total usage (Hours) Total charge ($)
 AWS – RDS (m1.medium)     0.11      Jan – Feb 2017           585      67.28
Google – Cloud     SQL (n1-standard)    0.09         April 2017           174        17
Cloud performance
Cloud Service provisioning time in Minutes (approx.) Application deployment time in Minutes (approx.)
AWS                          8-10 (RDS) 6-7 (container deployment on Elastic Beanstalk)
Google                           4-5 (Cloud SQL) 3-4 (using Google App Engine)

You can use these experimental results in estimating the costs associated with your specific cloud application development scenario. If you are developing cloud applications for the first time, you will have to factor in the time required to learn different cloud constructs. Moreover, if the cloud platform is not already chosen for you and you have the option of picking a platform, then you will also have to factor in the time required to study multiple platforms and choose the best one for your needs.

Apart from the measured costs, we gained following key insights from our experiment:

  1. During application development you will use following app-testing workflows:
    • all-local: A workflow that will deploy application locally and connect it with locally provisioned DB instance (such as local MySQL service)
    • local-and-cloud: This is a workflow in which locally deployed application is connected with DB instance in the cloud (such as a RDS instance)
    • all-cloud: In this workflow, application is deployed to cloud and it is connected with DB instance also in the cloud.
  2. It is important to work closely with your DevOps/Ops team to know what database flavor to use during your development and testing.
  3. It is important to consider the region in which your application needs to be deployed eventually. This factor will affect the database flavor that you can use when provisioning DB instance in the cloud. In developing one of our applications, we had initially chosen “t1.micro” database flavor for AWS. But it is not available on all AWS regions. We realized this when we tried to deploy the application on every AWS region. We then changed the database flavor to “m1.medium”, which is available in all the regions.
  4. Knowing how to control access to your DB instances is essential. Both, AWS and Google allow controlling access to DB instance — on AWS, only applications that are in the same VPC (virtual private cloud) as that of the instance, and which have the same security group are allowed to access the instance; on Google only applications that belong to the same Google Cloud project are allowed to access the instance. You will need this understanding as part of configuring app-testing workflows.
  5. Knowing how to delete a provisioned DB instance is probably the most important action you need to learn. Otherwise, there will be lot of stray forgotten instances, costing you money.

Comments are closed.