Is your application architecture effectively making use of cloud?

I have seen a lot of application products (web products or mobile apps) claiming that they are based on cloud architecture. But, when we dig more into the architecture, we can see that the products are just hosted on cloud server and sometimes utilizing cloud storage (file, DB etc.).

Let’s debunk the myth first!

Lot of IT folks are under the impression that if their application is hosted on cloud servers, then their solution can be called as cloud based architecture. Is it so? Can we call it as a cloud based architecture? I leave this question to be answered by readers after reading this blog post.

Only if an application makes use of the following four principles, can we call it as a cloud based architecture.

1. Elasticity
2. Pay-By-Use
3. Self Service
4. Programmatically

So, how is the web hosting different from cloud computing? Following table lists the differences.

If an application satisfies the above four principles, technically it can be said that it is based on cloud architecture. But is that enough? The answer is ‘No’.

So, what does it take to make effective use of Cloud?

There are many other things to do if we want our application architecture effectively make use of cloud and thus minimize the load on web server, minimize the utilization of different resources and ultimately reduce operating cost.

Let us take a simple example of how file transfer can happen in any web based product or mobile app. Following diagram shows a typical way of sending files from end user machine/device to cloud storage. I have seen this happening in many of the customer products.

This can be called as a traditional way and following are the steps in this process.

• The end user initiates the process of uploading a file to server using web page or mobile app.
• The file will get uploaded to web server and sits in the web server’s local file storage. Usually it will be server’s local hard disk or some network file storage.
• Once web server ensures that the file upload is done by end user, it will indicate the backend service (can be a regular windows service or cloud service or a daemon process) to initiate the file transfer from its local file storage to cloud storage (can be Amazon’s S3 or Microsoft’s Azure). This would be usually asynchronous process. The indication to backend service can be direct way or by just updating DB records so that the backend service which keeps on polling DB will get to trigger with that change.

If the file gets bigger in size, the uploading process from end user’s machine/device to web server as well as the transfer from webserver file storage to cloud storage will take more time.

When too many users try to upload files to servers, more web servers have to be deployed (using auto-scaling feature or manual) to balance the load on web server.

Gosh. What a wastage of CPU time, resources and also the cost!  Also the end user will not get a clear picture about when the file will be available for his/her use from cloud storage(of course through web server or mobile app) as the backend service works asynchronously.

How Cloud Helps?

Let us see how the time and resources can be minimized when the application architecture effectively make use of cloud!

In this architecture, we’ll make use of cloud storage provided functionality called ‘Shared Access Signature‘. Also we will effectively make use of unlimited bandwidth (Unlike auto scaling, this is unlimited) of cloud storages. Here cloud storage can be

• Amazon S3 or
• Azure Blob

Both these cloud providers offer ‘Shared Access Signature’ feature. This concept allows any file/directory stored in cloud storage to be shared with anyone with read only/write/full access for a limited time. We can make use of this feature to make the end user directly upload file(programmatically) from his/her machine/device to cloud storage.

Let us see the steps about how file gets uploaded directly to cloud storage without any backend service or the webserver’s local storage usage.

1. End user will initiate the upload file functionality on the webserver provided page or using mobile app.
2. Webserver creates some temporary place on cloud storage (Blob or S3) and generates write access signature which is valid for some short time (say 60 minutes-this can change depending on the need).
3. Webserver passes access signature to client browser or mobile app. Note that it is just a signature and not any credentials related to cloud.
4. Client browser will use that signature and uploads the file directly to cloud storage.
5. Once the file upload process completes, browser or mobile app will indicate that to webserver.
6. Webserver will take care of moving the file to appropriate location within the cloud storage (cloud storage will take negligible amount of time to move a file from one place to another within it). Also takes care of removing shared access opened on the file.

Note that

• There is no backend process involved in this flow at all
• No usage of web server’s local storage
• Web server’s time in getting a file from end user’s machine is totally saved. Thus, lot of reduction in the web server’s load.
• Once the user uploads a file, it will be there in final destination within negligible time and webserver can use that for user’s other operations.

So, what’s your thought?

Surprised? There are many other tricks which can be used to make application architecture effectively making use of cloud. Let us see those in coming blog posts.

Feel free to share any such tricks at sales@trigent.com