Linux In The Cloud: Windows Azure vs. Amazon Web Services

http://tuts.pinehead.tv/2013/01/07/linux-in-the-cloud-windows-azure-vs-amazon-web-services


Until recently, the most viable cloud option for Linux virtual servers has been Amazon Web Services. But in mid 2012, Microsoft launched Linux Virtual Servers on Windows Azure. If you don’t know already, Windows Azure is a cloud platform for hosting back-end content for apps and traditional Windows Server, SQL Server, and now Linux and other open source database servers. Microsoft has come a long way with its support for open source and Linux. Given that, I set out on a mission to review and compare these services to Amazon. I’ll be honest up-front–when I set out on this mission I was completely biased towards Amazon, and I was surprised by what I found.

What I’m Comparing

I think it’s important to detail what services I’m comparing, as of now Amazon Web Servers has many other cloud services that Windows Azure does not. My primary focus will be on Linux virtual servers, the hardware specs, Azure interface, and other aspects of running Linux Virtual Severs in the cloud.

Where Azure Beats Amazon

Microsoft is clearly trying to mimic the new “m” (metro) design that comes with the new Windows 8. From a usability standpoint, parts of it are very slick. The entire interface is very “ajaxy”–from building a new server to viewing options, it loads lightning fast and presents the data in column fashion. I can’t be more thrilled with the quick launch menu and how fast you can launch a basic Linux server.
It takes me three clicks to build a Linux VPS assuming I’m selecting one of the “quick launch” images, which include CentOS, Suse, and Ubuntu servers. I guess I’m lucky I’m a CentOS guy.
When I think Linux VPS in the cloud, I think of starting on the smallest possible server I can and then scaling when capacity is required. The Azure VPS “micro” server comes with more memory and a significant more disk space than Amazon Web Services “micro” instance. The root partitions are also larger in size by default. However, Azure does not allow you to resize your partition like Amazon does.

Options For Security

When you build your first Linux server on Amazon, you’re required to use a .pem key file for security. The file is intended to give you root access to your servers, securely  However, if you need to build a server fast, on the fly, and don’t have time to run the putty ppk conversion or have a UNIX machine handy, then you’re just out of luck. That first step towards getting started on Amazon has tripped up many first time Linux users as they dive into the cloud. However, Microsoft gives you two options while building your first image. You can either chose to use a security key file or you can use a root username and password. The username and password method is less secure but if you have other plans for security for your network and servers, bypassing the mandatory pem file will save you a lot of time and hassle in the end. Bottom line, secure or not secure, I love that Microsoft gives you the option.

Basic Benchmark Test

I performed some basic benchmark tests on an Amazon “micro” instance and an Azure “extra small” instance. What I found from random “time” benchmarking tests is the Amazon micro instance and Windows Azure are pretty consistent even through those basic benchmark tests. A lot of the differences are due to Azure by default providing larger disk space on the system which causes increased time when performing disk commands.

Here Is Where Azure Can Improve

Charging for stopped instances is a deal breaker. If you build a virtual server, whether the server is running or not running, you are charged for CPU/hours. Amazon does not charge for instances that are stopped but only for running instances. I have come to find it very advantageous to be able to have stopped servers that I can go back to months down the road and work on. Having to pay for those on Azure would cost too much.
I can’t control the instance by right clicking on the instance. After working with Azure for a decent time period I was consistently annoyed that in order to stop, start or delete my instance I had to first click on the instance name then browse the bottom of my screen for navigation options. Working with Amazon web services or VMware for so long, it’s become intuitive for me to find the options for my instance by a right navigation menu. Of course, I still prefer a start menu as well…
With simplicity comes complexity and the Azure interface has some. When working on Amazon, I’m presented with a dashboard for my servers and everything I could possible want to do including configuring a firewall, load balancing, changing IP addresses, configuring volumes and more. However, while Azure proves they have a simple user interface when it comes to launching servers, managing complex operations in the interface seems elusive. In fact, it seems downright impossible. For instance, if there is a firewall or load balancing management, I can’t find it. I’m not saying they don’t exist–I’m saying that I was unable to find those options from my “portal.” If they don’t exist, they are must haves for running servers in the cloud and Azure needs them. If they do either it’s not available under my “free tier” or they need to be made more readily available and intuitive for the user.

Conclusion

Out of the box I’m impressed with what Microsoft has created at Azure. They’ve created a simple to use basic environment, which makes it extremely simple to build Linux servers in the cloud. A little leeway for Azure’s shortcomings can be given based on the age of the service (for Linux) but Azure will be a great cloud solution whether you’re hosting small scale web apps or large apps that need scaling.

TERIMA KASIH ATAS KUNJUNGAN SAUDARA
Semoga artikel ini bermanfaat bagi saudara. Jika ingin mengutip, baik itu sebagian atau keseluruhan dari isi artikel ini harap menyertakan link dofollow ke https://androidblackberries.blogspot.com/2013/01/linux-in-cloud-windows-azure-vs-amazon.html. Terima kasih sudah singgah membaca artikel ini.