Is not it paradoxical when we are saying against cloud computing is bad but publishing guides on how to install, configure server softwares on cloud server? No. Public Cloud is Deceptive From Sysadmin’s Point of View When Usage of RAM is More. Here Are Top Reasons Why Cloud Server Sucks Your Bucks.
Cloud Server Sucks Your Bucks Because You Use Some Swap as Physical RAM, Virtual CPU
100% Physical RAM is never actually allocated to any cloud server instance. Suppose of 32 GB dedicated server on which the cloud software/virtualization software is installed even if have one dozen of 2GB RAM cloud server instances. To run the main physical server’s major processes, it is whole system which pushes some swap. This becomes fully transparent cheating in case of OpenVZ virtualization (we talked about how to catch that thing for OpenVZ virtualization). It will be astonishing if you can use even 10% of original physical server’s CPU. It is far lower.
Cloud Server Sucks Your Bucks Because You Use Over Promoted Companies
We had a historical comparison of Rackspace vs Amazon EC2 vs Linode vs DigitalOcean vs SoftLayer. Basically all of them are bad.
Cloud Server is practical at 1 Euro/mo for 1 GB VMware instance or $7/mo for 6 GB OpenVZ instance. There are many such providers which you can seek at LowEndBox, WebHostingTalk like websites and forums. If 6GB RAM’s 25% is physical, 2 GB at $7 Per Month not fully bad for OpenVZ. OpenVZ virtualization has advantage of near “direct” resource allocation. Most of the OpenVZ virtualization server providers will kick out you if your Load Average becomes very high for longer period.
Cloud Server Sucks Your Bucks Because You Pay For Underpowered DNS, Tutorials, Beautiful Dashboard
Basically DNS should be either a separate service from standard providers like Dyn DNS, Hurricane Electric DNS etc or self hosted DNS. You are actually paying for many useless services like Underpowered DNS, Tutorials, Beautiful Dashboard, Support staffs etc. Those examples of 1 Euro/mo to $7/mo instance providers lacks those stuffs. It does not matter because you can always use free Hurricane Electric DNS or any paid DNS, even some domain registerer has such service for free of cost. Not really you always use those graphically great looking stuffs like graphing. Graphing typically lacks the analysis of log. Most of the tutorials of the web hosts are of inferior quality and sometime target to sell more instances. These polished services actually would remain same for very polished dedicated servers.
Cloud Server Sucks Your Bucks Because Cloud Server is Never Scalable
It is dedicated server which is scalable because we can add physical RAM, hard disk even when the servers are running (hot swap). For most of the “real virtualization”, you can not exactly increase the RAM of a running Cloud Server instance. It is possible in some types of container virtualizations.
Cloud Server Sucks Your Bucks Because You Never Know About Networking Card
A server’s most important aspect is networking, the things we talked about in easy language like sswitch, hub, router are not even offered as virtual options. HP Cloud had such virtual router and subnet settings which actually makes IPTables more powerful.
We are not going to the topics like ISP. Cost of good quality bandwidth is not exactly cheap, that will become more clear if you use colocation servers.
Cloud Server Sucks Your Bucks Because You Can Not Tweak BIOS, Lacks Privacy, Complicated SLA Etc
VM BIOS (virtual machine basic input/output system) is the lollipop to fool the booting process of a virtual machine. On dedicated server, BIOS really tweaks the hardware. We are not going towards the topic like lack of privacy of an instance. Cloud almost always has complicated Service Level Agreement. There is old good 5 Year Rule for On-Premise servers which is not applicable to the dedicated servers.
Cloud Server Sucks Your Bucks Because Cheap Dedicated Servers Availble
That is the reason why why we talked around preferring dedicated servers over public cloud/cloud server. We are not selling anything.
Follow the Author of this article :