Practical Technology

for practical people.

April 8, 2014
by sjvn01
0 comments

Why Containers Instead of Hypervisors?

Our cloud-based IT world is founded on hypervisors. It doesn’t have to be that way – and, some say, it shouldn’t be. Containers can deliver more services using the same hardware you’re now using for virtual machines, said one speaker at the Linux Collaboration Summit, and that spells more profits for both data centers and cloud services.

I confess that I’ve long been a little confused about the differences between virtual machine (VM) hypervisors and containers. But at the Linux Collaboration Summit in March 2014, James Bottomley, Parallels‘ CTO of server virtualization and a leading Linux kernel developer, finally set me straight.

Before I go farther I should dispel a misconception you might have. Yes, Parallels is best known for Parallels Desktop for Mac; it enables you to run Windows VMs on Macs and yes, that is a hypervisor-based system. But where Parallels makes its real money is with its Linux server oriented container business. Windows on Macs is sexier, so it gets the headlines.

So why should you care about hypervisors vs. containers? Bottomley explains that hypervisors, such as Hyper-V, KVM, and Xen, all have one thing in common: “They’re based on emulating virtual hardware.” That means they’re fat in terms of system requirements.

Bottomley also sees hypervisors as ungainly and not terribly efficient. He compares them to a Dalek from Dr. Who. Yes, they’re good at “EXTERMINATE,” but earlier models could be flummoxed by a simple set of stairs and include way too much extra gear.

Containers, on the other hand, are based on shared operating systems. They are much skinner and more efficient than hypervisors. Instead of virtualizing hardware, containers rest on top of a single Linux instance. This means you can “leave behind the useless 99.9% VM junk, leaving you with a small, neat capsule containing your application,” says Bottomley.

That has implications for application density. According to Bottomley, using a totally tuned-up container system, you should expect to see four-to-six times as many server instances as you can using Xen or KVM VMs. Even without making extra effort, he asserts, you can run approximately twice as many instances on the same hardware. Impressive!

Lest you think this sounds like science fiction compared to the hypervisors you’ve been using for years, Bottomley reminds us that “Google invested in containers early on. Anything you do on Google today is done in a container—whether it’s Search, Gmail, Google Docs—you get a container of your own for each service.”

To use containers in Linux you use the LXC userspace tools. With this, applications can run in their own container. As far as the program is concerned, it has its own file system, storage, CPU, RAM, and so on.

So far that sounds remarkably how a VM looks to an application. The key difference is that while the hypervisor abstracts an entire device, containers just abstract the operating system kernel.

LXC’s entire point is to “create an environment as close as possible as a standard Linux installation but without the need for a separate kernel,” says Bottomley. To do this it uses these Linux kernel features:

  • Kernel namespaces (ipc, uts, mount, pid, network, and user)
  • AppArmor and SELinux profiles
  • Seccomp policies
  • Chroots (using pivot_root)
  • Kernel capabilities
  • Control groups (cgroups)

The one thing that hypervisors can do that containers can’t, according to Bottomley, is to use different operating systems or kernels. For example, you can use VMware vSphere to run instances of Linux and Windows at the same time. With LXC, all containers must use the same operating system and kernel. In short, you can’t mix and match containers the way you can VMs.

That said, except for testing purposes, how often in a production environment do you really want to run multiple operating system VMs on a server? I’d say “Not very damn often.”

You might think that this all sounds nice, but some developers and devops believe that there are way too many different kinds of containers to mess. Bottomley insists that this is not the case. “All containers have the same code at bottom. It only looks like there are lots of containers.” He adds that Google (which used cgroups for its containers) and Parallels (which uses “bean-counters” in OpenVZ) have merged their codebases so there’s no practical differences between them.

Programs such as Docker are built on top of LXC. In Docker’s case, its advantage is that its open-source engine can be used to pack, ship, and run any application as a lightweight, portable, self sufficient LXC container that runs virtually anywhere. It’s a packaging system for applications.

The big win here for application developers, Bottomley notes, is that programs such as Docker enable you to create a containerized app on your laptop and deploy it to the cloud. “Containers gives you instant application portability,” he says. “In theory, you can do this with hypervisors, but in reality there’s a lot of time spend getting VMs right. If you’re an application developer and use containers you can leave worrying about all the crap to others.”

Bottomley thinks “We’re only beginning to touch what this new virtualization and packing paradigm can mean to us. Eventually, it will make it easier to create true cloud-only applications and server programs that can fit on only almost any device.” Indeed, he believes containers will let us move our programs from any platform to any other platform in time and space… sort of like Dr. Who’s TARDIS.

A version of this story was first published in SmartBear.

April 2, 2014
by sjvn01
0 comments

GOTO Still Has a Place in Modern Programming. No! Really!

Mea culpa! Sometimes, the experts agree, GOTO can be very useful.

When I wrote a few weeks about Apple’s SSL GOTO security fiasco, I put the blame on GOTO. I quoted no less a seer than programming guru Edsger W. Dijkstra who wrote way back in 1968 that the goto statement should be abolished from all “higher level” programming languages.

Since then, I’ve had it gently drilled into my head by programming experts that are sometimes — okay, many times — using GOTO not only makes perfect sense, sometimes it’s the best choice.

For example, SmartBear reader ohengel wrote, “I generally agree that many uses of the goto command are undesirable, but not all are. A good counter-example is the state machine, sometimes also used and known as a syntax machine. It works very well and with unmatched performance when you use goto commands.” State machines show when certain Boolean conditions are met.

John Stracke, a software architect for ITA Software agrees with ohengel. Stracke writes, “I hate GOTO, you hate GOTO, all Right-Thinking Modern Programmers hate GOTO. It’s a primitive, archaic construct, left over from machine languages, where primitive constructs make sense. When used, it enables bad coding practices, leads to bizarre bugs, and generally contributes to the decline of civilization. But, there is one case where GOTO is The Right Thing: finite state machines.”

Stracke explains, “Think about it. The states of a finite state machine basically correspond to the program counter of a CPU. In this view, state transitions are GOTOs, right? So you can either build your code to store your FSM’s state in some sort of variable (in which case assignments to that variable are GOTOs in disguise), or you can be honest with yourself and write GOTO-based code.” Okay, so that’s one example, but how often do you use state machines?

Well, it turns out GOTOs are still alive, well, and doing useful work in more than just this one example.

Indeed, GOTOs perform essential work in the Linux kernel. No less a figure than Dirk Hohndel, Intel’s Chief Linux and Open Source Technologist, set me straight. He writes, “The Linux kernel is full of GOTOs. So are most other well-maintained C programs. GOTO used in the right circumstances makes for easier-to-read, easier-to-maintain code.”

“For example?” I ask.

Hohndel replies, “It’s quite simple. If you write a function that tests lots of conditions but needs to clean up when exiting, you can either do this with lots and lots of identical code repeated all over the code, or with nested IF statements that get way too many levels of indentation – or you can have a clearly marked exit point and jump to it.”

Of course, you can’t use GOTO indiscriminately. Hohndel gave a few simple rules for the correct use of GOTO:

  • Only jump forward, never backward.
  • Only jump to the end of a block. (It doesn’t have to be the end of the function, but usually is.)
  • Use good names for the label (e.g. goto error_cleanup;).
  • Use it consistently.

For a sample of when it’s done right, Hohndel points to When To Use Goto When Programming in C.

As for Apple’s fiasco, Hohndel opines, “The problem with Apple’s code is a lack of review, not the use of GOTO.”

Hohndel’s not the only top programmer who sees positive good coming from correct GOTO use. Jeff Law and Jason Merrill, Red Hat engineers and, oh by the way, both members of the GCC (GNU Compiler Collection) steering committee, believe that GOTO can sometimes help with code clarity. In the case of the Apple SSL error, Merrill told Dr. Dobbs, it appears GOTO was used to make the code easier to read. Using GOTO to micro-optimize your code, however, is still a bad idea. “Clarity trumps micro-optimization most of the time,” says Merrill.

Last, but by no means least, no less a figure than Linux’s creator, Linus Torvalds defended GOTO in the LKML (Linux Kernel Mailing List) back in 2003. Torvalds wrote:

I think GOTOs are fine, and they are often more readable than large amounts of indentation. That’s especially true if the code flow isn’t actually naturally indented (in this case it is, so I don’t think using GOTO is in any way clearer than not, but in general GOTOs can be quite good for readability).

. . .

[S]ometimes structure is bad, and gets into the way, and using a  GOTO is just much clearer. For example, it is quite common to have conditionals THAT DO NOT NEST.

In which case you have two possibilities

– use GOTO, and be happy, since it doesn’t enforce nesting

This makes the code more readable, since the code just does what the algorithm says it should do.

– duplicate the code, and rewrite it in a nesting form so that you can use the structured jumps.

This often makes the code much less readable, harder to maintain, and bigger.

Okay! I surrender. I’m at best a mediocre programmer, but if Torvalds, other programmers, and three top Linux developers, who work with C every day of the year, agree that GOTO can be extremely useful – who am I to argue?

So, go forth! Use GOTO! Just make darn sure you’re using it correctly is all I ask of you.

A version of this story was first published in Smart Bear.

March 31, 2014
by sjvn01
0 comments

The Spam Battle Report 2014

Let’s start with the good news: According to Kaspersky, in 2013, the proportion of spam in email flows was 70%, which is 2.5 percentage points lower than in 2012. The bad news is that spam that does get through is far more dangerous. According to John Levine, chairman of the Internet Research Task Force’s Anti-Spam Research Group (ASRG) and president of the Coalition Against Unsolicited Commercial E-mail, “The ongoing threat is that spam is now essentially 100% criminal, and it’s as likely to try to plant bank-account-stealing malware either directly or via links to compromised websites as to sell you something.” Ow!

The Spam Battle Report 2014. More>