"Cloud" as an alternative to traditional hosting

At the last REEF, I talked about the “cloud” as an alternative to the traditional hosting (for example, Amazon).



Since then, several months have passed. During this time, I have repeatedly debated both with ardent opponents of the "cloud" and with no less active supporters.



The last such dispute happened a couple of days ago directly with hosters. And ended (on their part) with the following conclusion: “Now the cloud in hosting is a marketing evil that only confuses people.”

')

The topic, as it seems to me, is not just popular and interesting, but also very important. Therefore, I would like to summarize my own experience (I have several personal sites on a virtual shared hosting, periodically I look after one Dedik, and all work projects are located in the Amazon cloud) and try to understand all the pros and cons cloud hosting compared to the traditional.



Speaking in general about traditional hosting, I will mean any placement of web projects - more often VPS, colo or dedicated and slightly less shared hosting.



Under the “cloud”, I will generally refer to IaaS (Infrastructure as a Service) - “providing computer infrastructure (usually in the form of virtualization) as a service based on the concept of cloud computing” ( Wikipedia ).



(In general, I promise to use less “... aaS” in the text less often :) “Cloud” sounds more positive, and for end users at least an appearance of clarity of what is being said is created. Although this term is already “littered.”)



For the consumer, the "cloud" is any computational structure that is provided as a service upon request or automatically.



From the point of view of the provider, this is:

• Hardware resources (servers, network equipment, data storage systems, communication channels, etc.)
• System software (virtualization)
• Management software (billing, API, etc.)

Perhaps the most frequent and most actively used message for switching to “clouds” in general (and IaaS in particular) is cost reduction and economy .



And this, as it seems to me, is a very big and serious mistake of "cloud" marketers.



Let's try to figure out whether this is the most savings, and what it is.



The label below is a comparison of some typical VPS configuration of “traditional” hosters and virtual machines in the cloud: approximately 800 Mhz CPU, 512 Mb RAM. (We don’t take the usual shared hosting in this case, as we will not be able to estimate the allocated resources. No matter how many hosters limit these or other resources, the usual hosting is still a hostel: whoever first got up - that and sneakers.)







Prices - in cu (similar to dollars :)).



Comparison is not ideal, it should not be used as a serious guideline when choosing a provider. For example, some hosters do not have strictly the configuration that we compare, so - choose the closest one.



The purpose of the plate is to show only the price ratio. "Cloud" on average a half to two times cheaper.



If we take for comparison more “adult” configurations, for example, rented physical servers and virtual machines with similar power, we will get an approximately similar ratio.



It seems to be cheaper, but ...



We start working in the cloud and face such (not the most obvious at first glance) difficulties:

• Almost always the cost of traffic is calculated separately.
• We (perhaps for the first time in our life) are starting to deal with such a concept as “consumption calculations”: if our virtual machine is not with a fixed fixed price, then we pay for the consumed processor time, used memory; in any case, we are faced with such a concept as IOPS (Input-Output Operations Per Second) - and we pay for it.
• When you pay "on consumption" with a sharp increase in load (DDoS, "habraeffekt", errors in development), significant costs are possible (many times more than planned).

Where are the real savings?



In fact, we do not directly reduce current expenses, but we optimize several other processes.



No installation fees



For large projects - when it comes to buying your own equipment - you no longer need to allocate significant funds from the budget.



Another important advantage of the “cloud” automatically follows from this point:



Minimal financial risks at the start of a new project



If you are launching a new startup, you cannot be guaranteed to know in advance whether it will take off or not. The project "went" - excellent, all investments (including infrastructure) will be paid off.



And if not? And while you have already spent on servers, software, paid wages to those employees who were engaged in deploying the entire infrastructure?



In the “cloud” you risk only a monthly fee for the period during which your virtual infrastructure was serviced.



Losses in case of failure are not so great (and often - generally minimal). And they will not discourage your desire to implement new ideas and launch new startups. :)



Human resources for system maintenance



If we are talking about a large car park (tens to hundreds or thousands), then in a virtual environment it is much easier to maintain them. Microsoft talked about its own experience: one system administrator can service in the "cloud" ten (or more) times more machines than real physical servers.



Time saving



Any service work (adding disks to servers, adding new machines, etc.) in the “cloud” will be performed faster.



* * *



And now let's try to figure out if the “cloud” has other (perhaps even more obvious) advantages?



Must have any truly good project - regular load tests (both before launch and during work - on the stands). Load testing allows you to determine the limit of the performance of the created project on the selected equipment and gives an approximate estimate when scaling of certain resources is required.



And sometimes scaling is necessary suddenly! :)



For example, a website dedicated to chess lives on the Internet. And it comes to 1-2 thousand people a day. And then “suddenly” and unpredictably happens chess tournament. Attendance grows many times, and the administrator is not ready for such a load.



Both of these projects, the “spherical ideal website,” and our chess server unite one thing: any scaling will take time to allocate new resources, transfer the project to more powerful equipment, etc. During these works (if the move is sudden) the site is likely to be unavailable to visitors. And all this is the money of the project owner.



Next moment. Sooner or later we run into the ceiling: we cannot increase the server’s capacity indefinitely. In addition, with the growth of server capacity, its value grows in proportion. And here we move to horizontal scaling (if it supports the project architecture) - we are not increasing the capacity of one server, but adding new machines.



And finally, the last crucial point is reverse scaling, so that resources do not run idle, and so that we don’t think about where to go to unused servers. Chess tournament is not all year round. After some time, the resources allocated to peak attendance are unclaimed (until the next equally significant event).



Scaling in the “cloud” is a simple, clear and extremely easy operation!

• An increase in virtual machine resources is available instantly.
• Equally immediately available is not only vertical, but also horizontal scaling (you can get almost any number of virtual machines of the desired configuration).
• Once there is no need for a large amount of resources, we simply refuse them and stop paying for them.

Instant availability of any resources is generally one of the most important advantages of the “cloud”.



A living example that I somehow had to face in practice is an urgent need to transfer a large “heavy” project (which lived on a separate dedicated physical server) to another data center on January 7th.



In our country, the New Year is celebrated on a grand scale. And only those projects that are fortunate enough not to run into problems during the period when the whole country drinks and walks work during the New Year holidays.



The result of the phone call is a half dozen Russian hosters, which offer dedicated / colocation services: you can place your project only on a typical standard configuration, which is already in the price list. And then - just an acquaintance. And at best - during the day. And something non-standard and even more quickly - will not work ...: (



The result - the project is transferred to the "cloud" of Amazon.



Finally, I want to talk a little about the reliability of placing projects in the "cloud".



Often I hear such a thesis: the cloud is more reliable.



In my opinion, it misleads users and as a result works only against.



Not a “cloud safer”, but a “cloud” gives much more opportunities to build a reliable infrastructure .



1. Almost all serious "cloud" providers own several data centers, which allows them to reserve (at their level) almost all resources. For end users, this makes it possible to place your web project not on a single virtual server, but on a web cluster consisting of several servers that reserve each other and are located in different data centers.



If there is no possibility (for example, expensive) to constantly keep a complete copy of the project, you can use a much weaker machine, for example, under data backup and databases (for example, MySQL slave). In the event of a crash, the project on the backup server is quickly put into operation, and the server itself is scaled to the required number of available resources (memory, CPU, etc.)



2. Many cloud providers offer specialized cloud storage for static content (for example, Amazon S3).



They are in fact reliable, so their whole architecture is such that already directly in it the redundancy at the data center level is incorporated.



Transferring static content to such a storage allows minimizing the size and time of creating backups. Accordingly - to minimize the time of their deployment in the event of any accident.



3. The same backups - can be stored in the same cloud storage.



First of all, such storage facilities are cheap. This allows you to create backups often and keep them long enough. Secondly, the storage, which does not depend on the virtual machines themselves, ensures availability of backups even in the case of the most serious accidents and unbelievable cases - even if lightning hits the data center .



If the project is located in one data center on one or several physical servers, then in case of an accident (the data center is de-energized):

• The owner does not have access to the data. At all. It remains only to wait for the accident to be eliminated.
• If there is no possibility to wait (availability of the service is extremely critical) - you need to take data from the backup. From which? How and where to do it? In another datacenter?
• A separate question - which other data center to move during an accident. Finding the server of the desired configuration (as we already discussed above) is not the most trivial task. Time consuming.
• Moved It is necessary to change the DNS. It is time again. In the case of using the "cloud", which has several data centers, you can simply "outweigh" the old IP on a new machine.

* * *



Let's recap.



Cons "clouds":

• Not an alternative to hosting for 200-300 rubles per month.
• Costs (time) for training employees in the specifics of a particular service
• Infrastructure limitations (hardware, software specific)
• The complexity of the calculations "by consumption"

Pluses "clouds":

• Savings due to scheduling capabilities
• Savings and lack of risk associated with infrastructure investments
• Instant vertical and horizontal scaling
• Ease of administration
• Time saving
• additional services

By the way, it is additional services that are often one of the factors by which the “cloud” provider is finally selected.



Ability to place in different data centers, many ready-made images of operating systems, SLA accessibility, flexible disk configurations, cloud databases, cloud data cache, firewall configuration via a web interface for machine groups, creation of copies of virtual machines, etc. d. etc.



There are plenty of opportunities for cloud providers to compete and attract customers. :)



* * *



I’ll finish my post with a quote from Bret Taylor, now a technical director of Facebook, and a little earlier, co-founder of FriendFeed: “When we started work on a startup (FriendFeed), we had to decide whether to buy our own servers or choose one of the cloud hosting services. Providers - such as Amazon (AWS). We chose the first - we decided to purchase our own servers. Looking back, I think it was a big mistake. ”