LambdaWrap, a Ruby GEM for AWS Lambda

Author: Markus Thurner
Reblogged from:

We’ve released LambdaWrap, a Ruby gem to simplify deployment to a serverless application based on AWS Lambda. This blog post talks about the motivation behind this Ruby gem, and technical details of LambdaWrap.

Where did we start?

There was a lot of talk among my team regarding the benefits of AWS Lambda, an offering from Amazon Web Services to run code without provisioning or managing servers. So, while we were skeptical of how that would work out, we gave it a try for a simple RESTful service.

Since our service was very simple, we didn’t want to start with a framework like serverless. Instead, we simply had some basic unit tests, uploaded our scripts manually and tested everything online.

As our thoughts evolved on how to support this service in a production environment, we weren’t satisfied with our manual approach. We turned to AWS CloudFormation, but quickly realized that it didn’t support versioning of Lambda functions nor setup of API Gateway. So we decided to create a rakefile and leverage the AWS SDK for Ruby. We started simple by just supporting uploading of the Lamba functions, but then added a wrapper for aws-apigateway-importer, and since we were using AWS DynamoDB, also included a simple wrapper for DynamoDB table creation.

What does LambdaWrap do?

LambdaWrap allows one to create a build pipeline for an AWS Lambda-based RESTful service within less than an hour, so that you can immediately start focusing on creating value, namely, writing your service code. LambdaWrap is easy to get into, since it focuses on the deployment pipeline only.

Let’s look at a basic example: a RESTful service that exposes a PUT and a GET method on a resource, and uses AWS DynamoDB to store data. With a documentation-first approach, go to, document the two endpoints, and save the swagger.json locally. Then, create your rakefile and have a deploy task like the following:

That’s it. A few lines of ruby code and your deployment is fully automated, including supporting short-lived environments such as those for developers or pull request builds. (Yes, we recommend creating a full environment during a pull request to ensure the deployment pipeline works, and also to run some service level tests against it.) Once you start doing that, you probably also want to be able to destroy all those short-lived environments to avoid unnecessary expenses caused by unused resources.

How did this help Cimpress?

We’re still in the early stages of our service’s lifecycle. But so far, deploying new versions of a service has been a smooth experience. Unifying this into a Ruby gem already benefited our small team by not duplicating the same deployment script over and over again, or worse – diverging over time. So while it took a little effort to bundle everything into a reusable library, the return on investment was almost immediate. So we believe the creation of LambdaWrap is a good story in moving a small team forward while showing what can be achieved with simple, generic script and by sharing our AWS Lamba experience in order to lower the entry hurdle for other teams.

What’s next?

We believe LambdaWrap allows others to learn from our experience of creating a deployment pipeline for services based on AWS Lambda. It’s so simple (in terms of just a few Ruby files) that it can easily be copied for more specific use cases, extended with additional, generic features, or both. Yes, we would appreciate your feedback and contributions. With that, we do not have a long-term roadmap for LambdaWrap, although we’ll continuously extend it. We will certainly continue to focus on deployment, not local execution or other alternatives. Other larger frameworks such as serverless already do that job particularly well.

Cloud First: Azure

Hello everyone! As promised this is a follow up post to this one and is a high level overview of the Microsoft Azure cloud service.

I’ve been using Azure for a couple of years now and and if I was to summarize I would say it’s a good service with great and rich interface, with rather poor organized SDK and quite expensive I might add but let’s get into it, shall we?

First things first, you can register for a free trial right here and you’ll get an amazing 200 USD that you can spend on Azure services right away and I encourage you to do so. Afterwards you can dig into the Azure portal which has been recently redesigned and it looks great and the performance is also slightly better but let’s get into more details.



They do have data centers scattered across the globe(Europe, Asia, Americas, Australia) so it shouldn’t be a problem for you to get where you’re customers are.



As with every Microsoft product we all know that interface is usually good and this one is no exception. I mean it’s beautifully done from the dashboard which can be customized by simply using drag and drop to the organization of information so that you don’t get confused. Don’t underestimate this because there is quite a bit of information going on and I can easily see how some could get this wrong but they did a great job and I love it.


Obviously this is the most important part, right?
Well, there are a lot of things going here. From the classical VMs, to load balancers, app services, CDN(content delivery network),  Redis caching, Active Directory, VPN, machine learning services(HDInsight), storage, databases (read SQL and noSQL such as documentDB), IoT processing, schedulers just to name a few.
So there’s plenty from which you can choose and some of them are uniquely to Azure, I’ll give you a few examples in a minute. Naturally Azure has a very good integration with Visual Studio leveraging team services.
I believe one of the unique features of Azure is the Marketplace where Microsoft but also 3rd party vendors are offering cloud services. Some of those services are Auth0, load testing service, cloud-based RabbitMQ service, face recognition APIs, Logentries, speech APIs, testing service and so much more.
Furthermore there are templates for VMs and/or app/web services. You want a Sharepoint server farm, ELK + Kibana, Oracle Dbs, wordpress blog? You can literally have anything you might want in just a few minutes and people get to contribute to it.


Well you can find all of the SDKs including the CLI right here with a decent amount of supported languages such as: Java, .NET, Node.js, PHP, Python, Ruby. That being said the documentation is rather chaotically organized. While for Ruby the documentation is easy to find, where as for others is not as simple as I would like. For instance the documentation for Python is here.


They do have a pricing calculator right here but my overall impressions is that is rather expensive. Just to give you an example a quad-core 28gb of RAM VM(D12 v2) in Azure costs 317.69 USD/month at the date of this post where I could buy from OVH from instance a quad-core, 32GB of RAM dedicated server for roughly 85 EUR in any of their regions (including France, Germany, Netherlands).


It’s a great cloud service which I really recommend but one can clearly see some areas of improvement. There is more to say here and I could go through each service and describe it but it’s too much and this is just a overview of the service. If you are particularly interested in any of their services please let me know.

I totally loved that Marketplace and template based configuration services such that you could start from step 2 or 3 rather than step 0 plus the amazing variety of already done APIs/services that you can choose from.
If you can deal with the price, that is.

Welcome to the cloud!

Hello and welcome to 2016! This is the first post of the 2016 and I wanted to start with a series of posts on cloud services, because it appears to be a cool place that everyone wants to know about and there is quite a competition between the big four competitors out there: Amazon through Amazon Web Services(AWS), Microsoft through Azure, Google through Google Cloud Platform and IBM. I’ve been using Azure for years but relatively recently I started with AWS and I can talk about them from a developer perspective. I haven’t used the other two so I really can’t say.

But first let’s clear out a few concepts and explain what is this cloud thing.

PaaS – Platform as a Service
With PaaS  developers get a framework they can build upon and which makes development, testing and deployment of application quick and simple. That being said as a developer you don’t care about the OS management, virtualization software, servers, storage, network and other things, you just manage your application.

IaaS – Infrastructure as a Service
With IaaS you get a self-service where you can access, monitor and manage infrastructure that is often located across the globe. A great advantage over traditional infrastructure is that you don’t have to pay for it out front, but pay as you go and based on the actual necessities and scaling is very easy and efficient. Opposed to PaaS you have to manage servers, storage, networking and OS.

Both Azure and AWS support support IaaS and PaaS and they offer very similar services however the user experience is a bit different. If you are still wondering what are the advantage of the PaaS/IaaS over traditional infrastructure here is a summary for you:

  • It’s just there. You don’t need to manage your infrastructure, at least not entirely.
  • You can focus on your application your are building instead of infrastructure that brings no value
  • You can scale up and down as you please. You don’t have to get a ton of infrastructure that you’are only going to use during the peak season.
  • You don’t care if servers break down, all is taken care of.
  • Getting the infrastructure you need may be just a click away.
  • You can have pre-configured infrastructure for you to deploy to right away.
  • You can have the infrastructure in the geographical area you want so that the response time is as small as possible.

Because I want to cover both Azure and AWS in depth I will create separate posts for each one of them starting with Azure in the following days.

See you soon!

Simple Share Buttons