Saturday, April 21, 2018

The Use Cases of the Cloud

Intro

A few days ago, I engaged in a discussion on whether we should use cloud computing to deploy the software we will develop in the scope of a research project. As a result of this discussion, I felt the need to clearly identify the cases where the cloud is useful. Please note that the discussion that follows is sort of one-sided: I don't discuss the cases where the cloud is not useful, although these are to some extent implicit, if they do not fit in the favorable cases.

I would like to thank my colleague Paulo Rupino for providing me useful comments on this discussion.


Discussion


An important discussion that often takes place is when to run software on the cloud, instead of doing it on premises. As I see this, we have basically three situations where going to the cloud might be advantageous, depending on the specific cases:

1) The cloud has technology that is not available on premises. For example, consider two clusters of application servers in different regions served by a DNS + local load balancer scheme. Achieving the same level of availability and response times using privately owned hardware and software would certainly be too complicated for the standard user. Big data provides us another example, as Amazon, Google or Microsoft might leverage their huge volumes of data, to provide machine learning services that are simply not available on premises. This could be the case of Amazon AWS Rekognition, for example.

Some other cases are less clear, as solutions may actually exist on premises, but one does not know if they actually perform on the same level as cloud-based solutions. But, even when performance is comparable (or even better on premises), this takes us to the second point.

2) It is much easier to deploy on the cloud. Deploying on premises and maintaining a running solution on premises may be too complicated. A standard scheme with a cluster of application servers in a single region serves as example here. Maybe we could find the appropriate hardware, application server, database, fault-tolerant load balancer and so on, but a scenario like this might be set up and running in minutes in Amazon, with Elastic Beanstalk, for example, but would certainly take a long time to deploy, if we were going to do this privately. This may motivate companies to deploy on the cloud, to reduce their workforce, thus leading us to the next point.

3) The economics favors the cloud. Then, even if you dare to install the hardware and software on premises, this might not be worth it. Consider the following cases: 
A site with a very low demand year-round that has some short-lived peaks, e.g., due to some sort of periodic event. In this case over-provisioning for the events only would be too costly.
AWS Step and Lambda functions provide us the other case: if most of the time our application is not running, we may want to pay per use instead of paying per time.
The company may desire to exchange capex by opex.

9 comments:

  1. This comment has been removed by a blog administrator.

    ReplyDelete
  2. This comment has been removed by a blog administrator.

    ReplyDelete
  3. This comment has been removed by a blog administrator.

    ReplyDelete
  4. This comment has been removed by a blog administrator.

    ReplyDelete
  5. This comment has been removed by a blog administrator.

    ReplyDelete
  6. This comment has been removed by a blog administrator.

    ReplyDelete
  7. This comment has been removed by a blog administrator.

    ReplyDelete
  8. This comment has been removed by a blog administrator.

    ReplyDelete
  9. This comment has been removed by a blog administrator.

    ReplyDelete