During the discussion, the contributor persisted on knowing what would be considered and thresholds to use some kind of push-button-scaling.
Knowing his context, a unzipped install CMS with a buch of plugins I felt the urge to explain that there is not always need to get a bigger server capacity. Here is an overview of what I mean when I talk about cloud computing and continuous integration.
Let’s talk about cloud!
I mean in the web application hosting realm. Not the storage (Google Drive, Dropbox) or software as a service (Salesforce, Basecamp).
Let’s talk about a use case before and my own experience.
The use-case on my recent experience
This is a complete business management web application that manages an union who represents french speaking artists in north america (mostly residents of Canada). We built a complete web application that manages many aspects an artist needs to represent themselves and be found. A big part of it is a 140 tables worth of artist description listing details as small a hair length and types of musical instruments to voice tones. It also manages renewal, communication with agencies, portfolios, and management of contracts with managers and more.
Not to forget the very heavy databases queries we generate to search, for example: <example>An asian woman with white hair playing yuku lélé who can pilot helicopter AND ride motorcycle …</example>
Yes. Database queries get very big, very quickly. Not only in the search engine I described, but through all the features.
That, to my opinion, is heavy. Also considering that that Artist’s Union has several thousand members.
This information is on top of my head, please do not take this into real numbers, I did not look the latest deployment needs. But for the server side, it only uses a simple Virtual machine with 4Gb of RAM give or take.
That is my point about expanding hosting without optimizing stuff around.
What your web application has to consider then
Amazon and other Cloud service is about mostly about automated server deployment.
But the powerful offering of “scale tour application” with computing cubes that automatically scales requires more than just nodes.
It requires the code (here again) to support:
- multiple databases hosts and types support (Cassandra, Solr, MySQL) specialized for the type of data to store
- User upload files replication
- Database/Keystore (CouchDB, Mongo)
All spanable on multiple hosts by a mere change of one configuration file.
The code itself should:
- Be deployable by a simple phing/ant/nant task
- Hosted on a NAS mount that you could create an other machine and use when time of computing need happens
All this (for some parts) is what is called Continuous integration (Wikipedia) some deployment strategies (also here and this blog post too), and most of the time. It’s not just the continuity and automation that matters, but the underlying deployment mechanism can be provided by third parties, like Heroku and many others.