Since AWS Lambda service release last year announcement, I wanted to try this service and I actually did it. I found it very interesting, powerful and full of possibilities, but to be honest, Node.js is not really my cup of tea. So, I kept waiting for additional languages support.

So, with the recent announcement about Java 8 support for AWS Lambda, I found an excuse to try it again and for this I decided to use JRuby and write my test functions in Ruby.

After stumbling upon and reporting an issue with JRuby releases before 1.7.21, I was finally able to write and run AWS Lambda functions in Ruby.

To test this, I took the most basic example from AWS documentation and rewrote in Ruby:

require 'java'

java_package 'example'

java_import 'com.amazonaws.services.lambda.runtime.Context'
java_import 'com.amazonaws.services.lambda.runtime.LambdaLogger'

class Hello
  java_signature 'String handler(int count, Context context)'
  def handler(count, context)
    logger = context.getLogger
    logger.log("received : #{count}")
    count.to_s
  end
end

To deploy and run that code, you must create an artifact acceptable for AWS Lambda (mostly .zip and .jar files). You can create those artifacts by using Maven as is explained in the documentation.

Your code should end in a location similar to: proj-dir/src/main/ruby/example/Hello.rb.

And you need to add some extra dependencies to use JRuby:

JRuby (use jruby-complete jar 1.7.21 or greater):

<dependency>
  <groupId>org.jruby</groupId>
  <artifactId>jruby-complete</artifactId>
  <version>1.7.21</version>
</dependency>

JRuby Maven compiler plugin:

<plugin>
  <groupId>de.saumya.mojo</groupId>
  <artifactId>jruby-maven-plugin</artifactId>
  <version>1.0.10</version>
  <executions>
    <execution>
      <phase>generate-sources</phase>
      <goals>
        <goal>compile</goal>
      </goals>
      <configuration>
        <generateJava>true</generateJava>
        <generatedJavaDirectory>${jruby.generated.sources}</generatedJavaDirectory>
      </configuration>
    </execution>
  </executions>
</plugin>

After adding these extra dependencies and running mvn package you should have a .jar file ready to be used with Lambda.

So far, I only have observed two downsides about using JRuby for Lambda functions. The first one is, jruby-complete distribution is 20 MB in size, so I found my functions a little bloated in size. Hopefully, in the future AWS will add support for more runtimes and this will not be an issue anymore.

The second detail is, the first time you run your function you will notice a very long execution time (around 10s in my case) due to the usual slow JVM start up time. If you function is executed with relative frequence you will notice AWS Lambda reuse hardware and will obtain more reasonable execution times (around 100 ms for trivial functions).

All in all, I look forward to find more uses for this service and I hope for more convenient languages (e.g. Ruby, Go, Python, etc) being supported in AWS Lambda.

PS. In an AWS event today, it was announced a new service named "API Gateway" that can be combined with AWS Lambda as backend functions to build API endpoints. It's worth checking out.

Update (2015/12/03):

Akio Katayama published a niftier way to build your Lambda functions with JRuby but using gradle instead of plain old Maven. Check it out!

Since months ago I was pondering over providing an alternative Chef hosted service.

The timing of the recent announcement by Chef, Inc. converging and releasing a single code base under Apache 2.0 license for Chef server certainly makes this initiative even more interesting for me.

So, I wanted to see if there is interest in such thing and I went ahead to setup this service.

The service is free to use and is available at api.qirtaiba.org.

The service is beta but you are more than invited to use it.

I look forward to hear comments and see what the people think about it. You can drop me a line or a tweet if you wish.

Let's hack and automate.

Wow, it looks like the last time I blogged something here was like 3 years and 7 months or so.

In that period many things had changed but the most relevant event were:

• I don't live anymore in Venezuela.

• I became a Debian Developer.

Another important things happened on my personal life but they don't belong on this blog anyway.

It feels good to write something again even if it's absolutely irrelevant in the great scheme of things.

Well, the reason why I revived this blog (again) was because I wanted to document the fact I setup what I expect to be an stable APT repo for packages prepared by myself but not ready to be included in Debian for whatever reason at the moment.

It's available at: http://people.debian.org/~nomadium/apt/.

Right now I'm working in some projects and I'm using some software that is outdated, just not available on Debian stable suite or on stable backports, e.g.:

• chef (>= 11.8)
• docker.io
• mosh

So, I decided to backport and upload those packages (and their dependencies) there. Maybe somebody else can find uses for that until they are included in the next stable release.

In my opinion you can learn a lot following the development process of Mongrel2. Mongrel2 is a redesign of Mongrel web server and it is a project that have as goal to provide an application, language, and network architecture agnostic web server.

This is probably the most interesting project that I could find right now on the web, because it is under heavy development, it is using new concepts and ideas, it is written in C (very clear and legible code if you ask me), the development process is totally in the open, and this could benefit many people if successfully achieve its goal.

Because of that, and because of the very big bold goal of this project I'm following its progress, I'm testing it and I plan to contribute with Mongrel2 if possible. By now, I'm only contributing from the distribution side of things, so I prepared some packages necessary to test Mongrel2 in Debian (despite Mr. Zed Shaw is very critic of the ``slowness'' of Linux distributions picking new software).

Anyway, below are some links to binary and source packages for Mongrel2 and a couple of dependencies, if anyone besides me is interested in testing this in Debian (or Ubuntu). I already asked for review to have those packages included officially in Debian.

• mongrel2: binary, source, git, upstream.

• python-storm (needed to use m2sh): binary, source, git, upstream.

• python-zmq (needed to run the examples included with mongrel2): binary, source, git, upstream.

Since a while ago I was aware of the possibility of hosting an ikiwiki generated website at github using github pages. This is described with great detail on tips section of ikiwiki website.

Later, it was announced the possibility of using custom domains with github pages, but unfortunately this feature was available only to paying customers. Don't get me wrong, github is fantastic and they provide a service really worth paying for (especially for private projects), but for a dollar starved guy like me, I try to avoid any expense in foreign currency.

So, it was cool to find out that the custom domain feature for github pages now is free. I decided to give a try and migrate this website hosting there. I could save a few bucks with hosting and gained the feature of updating my website using git standard tools (pretty awesome and convenient if you ask me, with one push you can publish updates or revert changes).

I'm going to investigate options about how to implement the dynamic portion of ikiwiki (ikiwiki.cgi, and maybe comments), but for now my main use case of ikiwiki is covered with github pages provided hosting.

Recently, Amazon announced support for user provided Linux kernels in Amazon EC2.

Since they provided a list of supported distributions but Debian was not included, I decided to give a try to this new feature to see if I could boot a Linux kernel provided by Debian.

Following the instructions available in EC2 documentation and the recommendations for Xen usage at Debian wiki, I could boot an AMI using linux-image-2.6.32-5-686-bigmem kernel included with upcoming Debian 6.0 (squeeze, right now at testing stage).

You just have to:

• Indicate in /boot/grub/menu.lst root=/dev/xvda1 as root device.
• Make sure /etc/fstab contains the correct device names.
• Bundle your image with linux-image-2.6.32-5-686-bigmem and grub-legacy packages installed.

In the Xen entry at Debian wiki is mentioned that domU instances can boot with a Linux image Xen flavor, but I could not boot linux-image-2.6.32-5-xen-686 in Amazon EC2. I'll investigate why that's happening.