Note: Here's another guest post from our friends at the Hybrid Group.

So you're a Ruby developer and you've heard about this cool new language called Go, but you don't know where to get started. You've read the bullet points and got a litle scared. Static typing? Compiling? Is this the 80's all over again?! Well sorta! Go gives us the power of concurrent operations with a built in GC, so we get the power of a compiled language, but the lazyness of a dynamic language. Interested yet? Let's get into the basics of the language and cut out all the uncessary exposition and look at some code.

Hello world

Here's the canonical "Hello world" in Go.

package main

import "fmt"

func main(){
  fmt.Println("Hello world!")
}

And its ruby equivalent

puts "Hello world!"

At first glance you may think "Wow that's verbose!", but if you have a c/c++/java background, this doesn't look too out of the ordinary. Now let's discect this program and firgure out what's going on.

In the previous post in this series, we explained how the shared-nothing architecture places additional constraints on cloud app developers. We also explained how embracing these constraints enables apps to have high scalability and high availability.

In this present post, we explain how to adapt an app for the cloud by removing any dependency on the file system, in order to make it compatible with a shared-nothing architecture.

Replacing the File System

If you’re deploying an existing app to the cloud, whether it’s an internal app or an off-the-shelf app, you may find that there are some points of contention.

The most common problem we have found is that apps designed for traditional hosting environments expect the file system to behave like a database. That is, they write out a file, and then expect that this file is going to exist at some point in the future.

This is a problem for languages like PHP, where many of the off-the-shelf apps have existed since long before the cloud was popular. These apps generally assume that you are only using one server, and that the master copy of your site lives on the server.

Unfortunately, this causes some problems. This model does not work when you want to scale across multiple servers, or when you want to keep the master copy of your site in a revision control system like Git.

Let’s take one example: WordPress. The default WordPress configuration requires write access to the wp-content directory on the local file system. If you log into the WordPress administration console and make some changes, WordPress may update a file on the local file system. But if you have multiple servers, none of the other servers have this updated config.

If, on the other hand, you re-deploy from Git, your configuration changes will be overwritten! You could try to use something like gitdocs to automatically propagate changes, but what happens when you have a merge conflict, or your local state becomes particularly byzantine? Your app could fail instantly, or it may even experience hidden corruption, failing later in such a way that makes it difficult to debug.

So what’s the solution?

We briefly looked at hack in part one of this series, but there is a lot more to it than type-hints.

Why Hack?

The main reason for Hack, is not to alleviate any number of small bugs that can creep into PHP code due to lack of strong typing, but instead to provide new language features and tooling to make developers lives better.

A primary goal of hack is to not [negatively] impact the developers workflow — especially the REPL; whereby we can edit code and refresh our browser to immediately see changes.

Using Hack

Note: Hack is only included with HHVM 3.0 or nightly builds after March 20th.

Out of sheer, unapologetic envy for the meetup in NYC, "Papers we love," our lead data engineer Ines Sombra started a “Papers we love too!” meetup in San Francisco. Our inaugural meetup was Wednesday evening, and the NYC organizers joined us for an excellent presentation on “Dapper, a Large Scale Distributed Systems Tracing Infrastructure,” a much loved paper chosen and presented by Yammer infrastructure engineers Ryan Kennedy and Anjali Shenoy.

--Tasha Drew, Product Manager

Engineering Updates

MySQL has been tweaked to load time zone tables by default, per customer requests in our feature request forums. Is there something you’d love to have Engine Yard add to our platform? Ask us there, and it could just happen!

We’ve done most of the work necessary to release AWS M3s, and are continuing to improve our integration with C3s. Expect more in this space shortly!

A bunch of other updates are chronicled in our regular release notes!

Social Calendar (Come say hi!)

RubyConf Philippines, March 28-29: Attendees can visit the Engine Yard table to meet members of our support team who can answer a wide range of any technical and non-technical questions you may have about Engine Yard. Also, PJ Hagerty continues his fabulous world tour, and will be giving a talk on creating active user groups in your local Ruby community.

Great Wide Open, April 2-3, Atlanta, Georgia: Engine Yard’s lead data engineer, the one and only Ines Sombra, will be doing a two hour workshop covering Databases in the Cloud (first half relational, second half non-relational). A few of us will also be tagging along so be sure to stop by our table!

Interaction 14 Redux, April 3, Dublin, Ireland: Engine Yard will be hosting Dublin’s Interaction 14 Redux, with a series of four lightning talks covering highlights and themes from the conference as well as three brand new presentations from our Irish speakers who submitted their talks for the Interaction 14.

Ancient City Ruby, April 3-4, St. Augustine, Florida: Our most excellent deployment engineer, Evan Machnic, presents on how he juggles children and rubies without missing a beat -- or dropping anyone.

Articles of Interest

Blogger highscalability examines the Facebook/Occulus acquisition and suggests that Occulus made this deal for a very sensible reason: they need help scaling, in a big way, to launch VR.

Welcome back! In Part 1 of this series we introduced you to Vagrant, a powerful tool for creating virtual environments of all flavors for development purposes. When we last left off we had configured Vagrant using the Vagrantfile and brought up our virtual environment based on an Ubuntu 12.04 image. In part two, we are going to now start automating the configuration of the virtual environment itself.

Introducing Puppet

Once a virtual environment has been created using Vagrant, in almost all cases there is going to be some configuration necessary of that environment itself before it can be useful. For example, if you are like me you'll need to install some sort of LAMP stack so you can do some PHP development. To accomplish this we will need to add a provisioning technology to our Vagrant setup which will run in the virtual environment once it is created to install any packages, etc. necessary.

Out of the box Vagrant supports a number of different provisioning technologies such as Puppet, shell scripting, Chef, and more. In this article we will be using Puppet to configure and install our packages in the virtual environment. To get started, we need to head back into our Vagrantfile to add a new configuration block to specify our Puppet provisioner as shown below:

config.vm.provision :puppet do |puppet|
    puppet.options        = "--verbose --debug"
    puppet.manifests_path = "puppet/manifests"
    puppet.module_path    = "puppet/modules"
    puppet.manifest_file  = "site.pp"
    puppet.facter         = {
        "vagrant"     => true,
    }
end

There is a lot going on here in this configuration block, but if you are familiar with Puppet already most of these configuration settings should already be familiar to you. For those of you who aren't certain what these mean, he's a quick legend for you: