Cloud First: AWS

AWS (Amazon Web Services) is one of the biggest cloud providers along with Microsoft Azure with data centers across the globe. They provide a mixture of IaaS (infrastructure as a service) and PaaS (platform as a service). Their offerings include a large number of services that can easily replace most of the infrastructure you would have in a traditional datacenter and perhaps even more.

AWS regions

As you can see they cover most of the world, except Africa and some parts of Asia and Middle East. So if most of your users are located in Europe, the US, most of Asia or Australia + New Zeeland then you’re probably okay using AWS. So one of the important factors are in using AWS is which locations are important for you and your users.

That being said, AWS has an extensive IaaS offering including but not limited to:

  • computing: EC2, ELB
  • storage: S3, Glacier
  • database: RDS, Dynamodb
  • Networking: VPC, R53

They also have started making PaaS offerings, with the notable mentions of EB (Elastic Beanstalk) and Lambda. EB combines multiple IaaS such as EC2, load balancers, networking capabilities, database into a platform which is managed by itself and the user only has to deploy the application to EB which will in turn take care of the rest. For Lambda, there is no infrastructure at all, you just deploy your application to it and it will run on certain triggers with no underlying visible infrastructure.

Scalability is one of the main drivers for AWS, compared to traditional infrastructure. With AWS you don’t necessarily have to plan in advance your infrastructure, unless you are really cost centric, because AWS is able to scale up and down as needed and even automatically if a PaaS is chosen. I remember there were times when you’d have to plan in advance, months or perhaps years the buildup of a datacenter, the requirements and the tremendous costs associated with it. With AWS you can just spin off as many machines you want or storage capability and you’ll just pay for it. And once you no longer need it, you can terminate it and everything will be fine. If we are to think about reliability and security I could easily say that AWS is more reliable and probably more secure than most traditional data centers out there, not to say that they are perfect but they rarely have incidents and when they do they alert their users and usually tend to have quick fixes.

I think one of the main disadvantages for using AWS is the learning curve, especially if we are talking about regular software developers which are the most users of AWS. The amount of details and configurations in AWS is extensive and getting to know each and every option will take time, plenty of time. Now luckily, AWS has decent documentation and they have a CLI you can interact with so you don’t necessarily have to remember all the UIs. And once you have learned it, it will be hard to give up on it, because the learning curve is high and some of the concepts and technology is proprietary. So, for instance you start using lambda, you’ll start writing your code in a certain way so that it fits in the lambda model. So, if one day you’d like to switch from AWS to some other cloud provider, that might not be as straightforward as you’d hope.

I think there are many things to say about AWS, from the individual services in the AWS offering to advanced infrastructure designing. Personally, I really like AWS Elastic Beanstalk and CloudFormation. The first one is a PaaS solution that will take care about VMs, monitoring, scaling, alerting, deployments, logging and many other things while CloudFormation allows you to design the infrastructure that you need in a very friendly way, finally having as an output a JSON file you can export and use it as a script to later create physical infrastructure. CloudFormation really turns infrastructure into code which is something developers have always liked.

Maybe some people are concerned about CD/CI pipelines while working in AWS, but there is little reason to be concerned about because AWS fully adheres and complies with those principles. AWS is really good in providing SDKs and CLI to interact with their services in a variety of languages which helps a lot in terms of development and scripting.

Obviously most of these services would require a dedicated post for each of them but to keep this one short I won’t go into the details now. I will definitely have separate posts for Elastic Beanstalk and CloudFormation soon.

AWS 5 Pillars

Finally I can really recommend you the AWS Well Architected Framework, which is a set of principles and guidelines set by AWS separated into pillars that will help you design and maintain the infrastructure you need for your services.

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.

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