The “cloud” has been a hot term for a while. Regardless of the fact that the concept has been around for about 10 years, its superstar status produces many delusions and misconceptions.
There are still misunderstandings even about what cloud is. Technologies that have nothing to do with the cloud are given the buzzword name, and cloud hosting is marketed as a solution to every problem a business owner might have.
Therefore, before we talk about advantages and disadvantages of cloud computing, it is important to understand what the term "cloud service" really means. The main characteristics of the cloud are:
- Scalable and measurable
To be more specific, when using the cloud, service users should be able to choose the type and amount of the resources at any time and only pay for that amount. Why am I going into detail about this? Because these are the features that determine the main advantages of cloud technologies, namely:
- Full access to easy-to-use control panels and API, enabling fast fine-tuning without intermediaries such as specialists of ticketing and support systems;
- Reduced costs of administration and support of the working system;
- Practically unlimited scaling opportunities to efficiently cover growth spouts and peaks, as well as sharp declines;
- Easily achievable high availability of apps and products.
Despite these obvious advantages, it is vital to remember that this does not at all mean that any application migrated to the cloud will a) work faster or b) cost less. In fact, if you simply move a website from a physical server to a virtual one, having purchased infrastructure as a service from one of the cloud service providers, most likely it will only increase the cost of hosting.
"How come?” you may ask. “Aren’t cloud services supposed to be more cost-effective?” The answer to that is yes, but only if they are utilised in a way that allows them to be cost-effective. Let me explain; if you buy a much more powerful Toyota Tundra in place of an old unimpressive Volkswagen Golf, and yet continue to drive on the same roads and carry the same loads, you'll end up having to pay more for gas without receiving any additional benefits (except for driving a newer, larger car, which is not your goal to begin with). To gain an economic advantage through cloud computing, you should try to use it to the maximum and always prioritise effectiveness.
With this in mind, let us return to the example with the website. If the site has a permanent audience that is not scared off easily by a temporary unavailability of the resource as a result of hardware failure, it makes no sense to change anything and it’s best to keep using physical servers. However, as soon as future plans include an advertising campaign to attract new users, it’s wise to start thinking about cloud migration. Otherwise, it will be difficult to effectively deal with the growing number of users.
Another question that is often raised when talking about migrating to the cloud is security. Many organisations don’t want to allow their information to be stored somewhere outside the office. However, cloud service usage is quite comparable to storing money in a bank. Definitely, there are some risks involved, but it’s typically safer to keep money in a bank than to store it under the mattress.
The same is true for cloud providers since the level of security in their data centers is higher than most organisations can afford. The risk of insider threat, which is usually extremely difficult to secure protection from, is also minimised.
Project infrastructure in the cloud: An example
A company began work on a large system. It needed product management software (defect tracking, source control, continuous integration and requirements management). In the end, they chose to use a Microsoft Team Foundation Server hosted on a virtual machine.
The reasons for this choice were as follows:
- An already obtained license for Team Foundation Server (TFS) under the MSDN subscription;
- The company did not want to invest in its own infrastructure (and did not want to fill or create the position of system administrator);
- Developers could easily install the system themselves.
Did it work? Not really. After spending a lot of the developer team’s time and effort, project leaders started thinking about trying Visual Studio Online after all.
So what went wrong?
1) TFS administration. Even after successful installation, the TFS still required administrating procedures. When the TFS database began to grow rapidly, one of the developers had to work on it, abandoning his previous projects, in order to change settings and schedule regular cleanup tasks.
2) The cost of resources. A number of virtual machines were selected, but it turned out that more resources were needed in order for builds to be delivered faster and for the growing team to effectively work with source control. Automatically scaling virtual machines was not a viable option either, as this operation was quite time-consuming, and delaying the already lengthy builds further had to be avoided.
What resulted was that, even though project infrastructure was migrated into the cloud, benefiting from the main advantages of the cloud was impossible since it functioned almost as a normal server, wasting money as a result.
In similar scenarios, it’s best to choose from two options: placing the software on dedicated physical servers or SaaS solutions such as Visual Studio Online. Let’s look at both options in detail.
Dedicated physical servers
- Low cost of resources (much cheaper than cloud hosting). However, the salary of a system administrator should be added to the equation;
- Full control over the hardware.
- Time delays (searching for system administrators, knowledge transfer, system setup, etc.);
- Requires an administrator;
- Constant availability of the system is not guaranteed (although it is acceptable, even a 24-hour unavailability is not critical for business);
- In the event the project decreases in scale, investments may not pay off.
- Save time (a working system is immediately available);
- No need for additional specialists;
- A 99.9 per cent uptime is guaranteed in an official Service Level Agreement (which is not critical, but is still a winning point);
- The cost depends only on the number of users and time spent by the build agent.
- High costs.
As can be seen, the self-hosting approach using Infrastructure as a Service (IaaS) was not the best option. It is better to try to use the cloud to its maximum capacity (SaaS) or move in the opposite direction of dedicated servers configured in-house.
Testing outside the cloud
In another example, the main goal was to save money on test environments. The main system was hosted using Azure Cloud Services (PaaS), and traditional virtual servers were used for testing. These steps were carried out in order to:
- Save money (conventional virtual machines are both cheaper and require fewer machines, since the availability of the system for testing is not as critical as in the case of business-critical applications).
- Avoid being tied to a single provider (testing in this way confirmed that it could be done without Azure).
A year later, it was decided to fully transfer testing to Azure Cloud Services, as well as use Azure more actively. The following are the factors that contributed to changing the strategy:
- Testing missed certain Azure-specific features, which could be found at a much earlier stage of the process;
- Alternative non-Azure solutions required a lot of time to develop and test, and they were made more like a stub (no one considered them seriously as production-ready solutions) and gave a false sense of independence from a specific service provider.
Saving money on test environments may seem like a good idea at first, but another aspect of the process is far more important: the test environment should be as similar to the production environment as possible. Otherwise, many vital issues may be missed. And there are other ways to decrease costs –turning the test environment off at night or reducing the number and/or size of cloud service virtual machines (VMs).
Too close for comfort – Being tied to providers
As for being tied to a PaaS provider, here are some considerations to keep in mind:
- Providers like Azure, Google and Amazon have more or less proven their reliability (a few high profile cases when their client websites went down vs. many years of successful reliable operations);
- Solutions offered by providers at such levels were tested with a large number of users and in different situations and scenarios; therefore, they are much more reliable than freshly developed, in-house solutions;
- Supporting two alternatives should involve an equal amount of testing for each of them, which doubles the cost of testing and is usually simply unacceptable;
- Failure to go the provider-specific way in favor of “neutral” methods, such as storing files on a local disk instead of Azure blob, leads to having the most optimised approaches being ignored (and therefore the potential of the provided technologies not being maximised.)
The lesson here is it is best not to complicate your life and use all the available tools offered by providers. Of course, ensuring flexibility on the level of architecture to easily switch from one solution to another is always a great idea.
Another useful move is implementing a stub for the local development environment in order to simplify settings and improve productivity. The stub created by the developer does not form an illusion of independence but is only a development tool. However, when it is used as a QA testing tool, a conclusion can be drawn that, for proper functioning, Azure may not be necessary at all.
Despite the myths and misconceptions that surround the cloud, there is a growing niche where it should be used, but it is important to know in which situations cloud works best and where traditional hosting can be more effective.
The use of cloud technology is economically feasible in the vast majority of cases. But it is necessary to understand how to use the provided opportunities in the most effective way.
Often it means using a higher level SaaS or PaaS solutions rather than the basic IaaS.
Mihail Karpuk, senior software developer, Itransition