Each day, we hear about technologies relying on a fancy word which basically turned into a new trend in the IT industry: Cloud. Truth is that by now, IT community embraced so much this concept that it makes me believe if its not doing it with the closed eyes…
Commercials working in IT business are anxious to provide us with lot of brochures for their cloud based solutions, presenting their benefits; however none or very few dare to aware their customers about potential drawbacks. And after cloud services are implemented into a corporation, everybody wonders why the systems are not working as expected!
There are some important considerations to make before adopting a cloud solution in an infrastructure and because of this I believe its worth discussing them in this post, with the risk of upsetting some enthusiasts.
The benefits:
– Cloud computing relies on data hosted on a remote location. Unless we consider a private cloud, the implementation is a rented service offered by an entity specialized in delivering a professional service. The monthly fee may include agreements for data confidentiality, security, reliability for the system (failover protection, backups, traffic motorization and so on);
– Affordable for those willing to start a business with a lower initial cost, when compared with the acquisition of a personal server;
– Suited for clients that lack IT expertise in configuring servers and whish their solution to be provided as ready to use;
– No concern regarding decommissioning when life expectancy for the hardware reaches its limit, since the cloud provider assumes this responsibility.
The drawbacks:
– A cloud implementation relies on a remote system. No matter how many guarantees of reliability you will be presented from the company offering the service, these warranties worth nothing if your internet connection is down. Malfunctions with modems or routers of your ISP, or other providers on the route to the cloud datacenter, will affect the stability of your applications dependent on cloud services, no matter how reliable the system is at the other end.
– A cloud implementation relies on the global Internet speed, which is not the one your ISP provides at the very end of your router, but the fastest link between your router and the cloud datacenter, which is dictated by the slowest node on the route. Because of this, location of the cloud datacenter and the worldwide transport technologies involved affects data transfer and is crucial in providing a good QoS.
– When compared to a LAN Ethernet, the bandwidth of a cloud link is slow and will continue to remain slow for the years to come. If your application needs to handle a large amount of data, cloud implementation may not be the ideal solution.
– When considering implementing the cloud service the physical access to the remote server can be an issue. If the server stops working or the connection is lost, you will have to rely on an international telephone line or an e-mail to an operator in order to communicate the problem to the support team that provides the hosting. The reply may come within minutes or can take hours, lag which may affect your business. Having the server into your infrastructure considerably eases troubleshooting time and access to the data can be gained without relying on a network connection at all!
– On long term, an expensive service. With the money spent on a cloud solution for a year, you may purchase a server with comparable performance and reliability, with a projected lifespan of five to six years.
Where a cloud implementation can deliver expected results?
The ideal environment for a cloud solution is when individual clients access the remote server via independent routes, because the bandwidth for each individual route may suffice for the application to work in proper conditions.
In practice however, this is quite difficult to achieve if the server is located on a remote site, many of the clients will end up by sharing common portions of the route to reach the cloud server.
For instance, all clients from France share independent routes within the country, but a common external fastest route to the remote server, responsible for bandwith penalties. Similarly, all countries from Europe share independent routes within the continent, and a common portion to the cloud server outside.
Placing the server on ISP’s backbone can provide the clients with the nearest access and the guarantee of a stable bandwidth
Where cloud service is not reccomended?
The worse implementation of a cloud service is to an enterprise which has in a single site tens of hosts that will require simultaneous access to the remote server. All hosts will use the same route to reach the cloud server, and all will have to divide its bandwidth.
If the cloud server is located in a nearest location on the ISPs backbone, and if the application is designed to work well over slow links, the penalty over performance may not be as critical. However, if the cloud service is located on a remote location, not only all clients will have to share the same route to reach the data, but the bandwidth of the connection will depend on the performance of third party transport infrastructure, for which the QoS is not guaranteed by the cloud service provider, nor by the ISP. It is in this no-mans-land area of the fastest possible route, where bottlenecks will cut into the bandwidth of the cloud implementation.
Balancing bandwith resources
So where the server should be located? Truth is that if we wish to o provide good results, we face a constant battle for resource optimization and network bandwith makes no exception.
If our company has many hosts witin its LAN which require access on the server, and has branch offices with fewer hosts, then the optimal solution is to keep the server within your LAN and configure to act as a private cloud for the branches. Like so, headquarter clients (most of the hosts) will take full advantage of the internally shared gigabit ethernet links to access the data. On the other hand, for the headquarter’s site, a good upload internet speed should also be considered in order to suffice bandwith sharing among branches that will access the server.
