Cloud Providers in China

The cloud business is slowly but surely picking up in China as it has in the West. Out of the major multinational providers, only Microsoft Azure offers comprehensive service in China. Amazon in 2014 has introduced a closed limited program for region in Beijing, but this service excludes common services such as Elastic Beanstalk. China, however, has its own homegrown cloud services, principally SinaCloud and AliYun from Sina and Alibaba respectively. Baidu offers a PaaS service but not a full fledged IaaS. Unlike US cloud services, most Chinese cloud services are pay by the month instead of pay by the hour. This arrangement is quite limiting since one would be unable to scale down costs below the monthly unit. This truly adds up when one is talking about thousands of instances.

Understanding Cloud Host Pricing, Part 2

In the past few years, there has been a movement to standardize cloud compute resource measurements in order to make way for public trading of compute resources. The idea is simple, but execution may be complicated: each company can run something like OpenStack and rent off underutilized compute resources and these resources can be further trading on public exchanges to enable companies to hedge for price spikes. Along these lines, Amazon was quite early in introducing the Reserved Instance Marketplace. A public trading of standardized compute units will enable smaller organizations to monetize underutilized assets. This model is not without its challenges. Compute resources have many aspects that distinguish them. Performance may vary dramatically. In this post, I investigate some of the smaller cloud hosts and their prices.

Provider	Minimum Unit ($/hr)	Memory (GB)	Instance Storage (GB)	Persistent Block Storage ($/GB/mo)
HP Helion	0.03	1	10	0.10
IBM SoftLayer	0.04	1	25	0.10
Oracle Cloud		1.8
CloudSigma	0.0319	1	1	0.14 SSD
GoGrid	0.02-0.03	0.5	25	-
DreamHost DreamCompute	0.0264	2	25	-
Internap	0.04	1	20 SSD	0.30

Top 5 Gotchas When Running Docker on a Mac

Running Docker on Mac is meant to be a convenience but the fact that Docker on Mac is a 2nd class citizen shows up every now and then. Since Docker is based on Linux cgroups, it cannot and does not run natively on MacOS X. Instead, Docker runs on Macs by using boot2docker, a shim that boots up a whole VirtualBox VM on which one will actually run Docker. Running Docker inside of a VM on Macs complicates things quite a bit.

Understanding Cloud Host Pricing, Part 1

The pricing schemes of the top cloud infrastructure-as-a-service (IaaS) providers are rather complicated. They cannot be compared directly since their performance characteristics vary. Moreover, the differences in costs of instances, storage, and bandwidth may offset each other. For example, one provider A's storage costs may be greater than provider B but B's instance costs may be greater. Some providers bill for instances by the minute (Azure and Google Computer Engine) whereas others bill by hour (rounded up), such as AWS. Some providers charge for storage by the TB (Azure) whereas others charge by GB/month or sometimes GB/hour (Rackspace). Consequently, what constitutes to the best deal in terms of cloud hosting depends on your specific workloads and storage needs. In this series, we will investigate the various aspects of cloud host pricing from the major providers: Amazon AWS, Microsoft Azure, Google Compute Engine, DigitalOcean, and Rackspace.

Apache Mesos and Hadoop YARN Scheduling

Mesos and YARN are two powerful cluster managers that can play host to a variety of distributed programming frameworks (Hadoop Map-Reduce, Dryad, Spark, and Storm) as well as multiple instance of the same framework (e.g., different versions of Hadoop). Both are concerned about optimizing utilization of cluster resources especially in terms of data locality of data distributed around the cluster. Google's paper on Omega, their own cluster scheduling system, dubs Mesos a two-level scheduler, which provide some flexibility by having a single resource manager offer resources to multiple parallel, independent schedulers. YARN is considered a monolithic scheduler since independent Application Masters are only responsible for job management and not scheduling. Scheduling is the essence of efficient Big Data processing. However, where do these two systems differ?

Alternatives to Docker: LXD and Rocket

Two recently announced alternatives to the Docker Linux container runtime LXD and Rocket aim to offer some interesting value propositions. Before I get to the details, let's first identify what use cases and aspects of the Docker container runtime of interest here. Docker identifies a few major categories of use cases: continuous integration, continuous delivery, scaling distributed applications, and Platform-as-a-Service. The former two are DevOps use cases. At this point, Docker pretty much has a lock on DevOps use cases. Moreover, neither of the would-be competitors truly target DevOps. It becomes obvious when you consider that LXD was intended to run on OpenStack Server environments and Rocket on CoreOS/fleet (though it is not necessarily tied to CoreOS). Docker runs on workstation environments and even on top of VirtualBox via boot2docker to support DevOps functionality on MacOS X. The more competitive aspect is the cloud infrastructure one. Here, Docker is competing with a wider range of technologies to support scaling on the cloud and providing PaaS functionality. This is the market where LXD and Rocket would operate. This is also the area where hypervisors have reigned.

Container Virtualization Options

photo by sioda	via PhotoRee

Looks like the container virtualization space is becoming a little more interesting this week. Previously, Docker was the only more or complete standard container implementation (with definition of image, image creation, and container start/stop management). There was Canonical's LXD, it didn't seem to be garnering nearly as much attention and support since it was only announced a month ago. However, with the Docker and CoreOS organizations starting to encroach on each other's territory, the CoreOS community has released an early version of their own container runtime, Rocket. On the balance, Docker has moved into the container cluster orchestration and management space with Docker Swarm and Docker Compose, the latter being still in the design stage.

Containers versus Virtual Machines

Containers-based systems (e.g., Docker, LXC, cgroups) and virtual machines (VMWare, Xen) both seek to bring the benefits of virtualization to the data center and developer workflow. They have considerable overlap in benefits. Although both do some kind of virtualization to enable better utilization of physical hardware, there are also some key differences. Containers do virtualization at the OS kernel-level. Hence isolation is limited to what the kernel can enforce. Containers do a lot of sharing of layers of file systems, courtesy of AuFS, which potentially makes better use of disk space and image space than virtual machines which commit the entire contents of a VM's disk to the disk image.

Security in Containerization Technology

One lingering worry with containerization is security. Previously, with conventional type 0 and type 1 (native, bare-metal) hypervisor technology, we greatly limited our trusted based to small hypervisors (e.g., Xen is < 150kloc). Some were so small (seL4 core was 7.5kloc) that they were amenable to mechanized formal verification. OSes supporting containers, in contrast, are much larger. Even CoreOS, intended as a slimmed down version of the Chrome OS Linux kernel that just supports modern bare-metal architectures for containers, that is fundamentally more challenging to vet, not to mention verify, than a simple hypervisor. Etcd and fleet alone add up to 44k sloc of Go. So for all the great inroads we were making in verification, the move towards containerization in the data center brings new challenges and potentially resets some of the progress the community has made in mechanically verifying security and functional correctness of the lowest layers of software systems and infrastructure.

ClusterHQ Flocker

Flocker does multi-host orchestration for Docker containers. It is intended mainly as a means for containerizing and orchestration distributed data stores and databases although in principle it can deploy any app. Unlike some of the other solutions out it, Flocker aims to support checkpointing of stateful and stateless containers to support migration of (running) containers across nodes. This seems like a great feature if one wanted to do work stealing rescheduling of containers as the execution profile changes and other nodes become available. Flocker provides its own NAT layer for mediating communication between containers across nodes. It also supports ZFS persistent volumes to maintain state. Flocker itself does not aim to do any particularly sophisticated scheduling (c.f. Kubernetes) but instead relies on the user to supply scheduling.

Top 5 Container Cluster Managers: Containers and Cloud Management

photo by OneEighteen	via PhotoRee

The rapid ascent of containers is nothing less than breathtaking. In the space of a year and a half, Docker has went from initial release to being adopted by every major IaaS cloud host (Google, Amazon, Microsoft, Rackspace's On-Metal CoreOS), VM software vendor, and a few toolchain developers. As a point of reference, VMWare ESX took over 5 years before ever getting near such market penetration. It is interesting to consider at this point what the management tool options are for containers and clusters/networks of containers. There are two main categories of use cases for Docker: devops (e.g., continuous integration) and virtualization infrastructure (e.g., improve utilization of server resources using lightweight containers in place of hypervisor-based virtualization).

This is a series of evaluations of container cluster managers: Part 2 (Kubernetes and Decking) and Part 3 (Flocker).

Can free tiers be tear free?

Many of the cloud computing services offer some kind of free tier these days. Most of them are time-limited (e.g., Amazon's free tier lasts for 1 year, Microsoft's 90 days), but some are not including Google. How do they stack up?

Server Infrastructure, Part 2

Following post on Oscigen's benchmark, I was curious how much does increased memory usage due to Ruby and Python-based web app stacks affect the bottom line. Plotting Amazon EC2 instance cost against instance memory shows that costs scale roughly linearly with the memory allowance. The least squares fit is y(x) = 0.028*x + 0.079. Linear scaling means that when Ruby/Rails take 10x the memory (roughly the difference between OCaml/Oscigen and Ruby/Rails) then it costs 10x as much in the long run (and after scaling up). For smaller instances, the difference is probably less. Of course, this doesn't take into account the productivity difference. However, although Ruby and Rails are clearly more productive than C/CGI, it is not clear that it is more productive than other high-level languages with better memory use and performance characteristics.