Nuts and Bolts

AWS is one of the greatest things since sliced bread. It empowers engineers to get things done quickly by enabling them to take control of the steering wheel and drive. With a simple AWS account, engineers can create resources, update security groups, and deploy their applications in rapid-fire fashion. The ease and power of AWS might make it seem like a security nightmare, but it’s actually the opposite. AWS provides the tools and controls to ensure everyone is following best practices, allows to you achieve a hardened security posture, and take compliance to a level that was never even thought possible before AWS: continuously.

In this video tutorial, we cover Jets Polymorphic Support Ability. Jets allows you to write Lambda functions not just in Ruby but also in other languages like Node and Python. This can be useful if you have pre-existing Lambda code. You can re-use the code and and move on with life.

In this video, we continue the tutorials on the Jets Ruby Serverless Framework that adds Ruby support to AWS Lambda. We talk about the difference between Jets extra vs different environments. Different environments refer to development, staging, uat, production environments. Extra environments refer to instances of each of those environments. For example, development-1, development-2, development-3, etc.

Here’s the presentation I gave at the Serverless Meetup in Toronto on Jets: A Ruby Serverless Framework. We discuss how Ruby support at native speed was achieved. We learned a bit about how AWS Lambda works under the hood to understand how it works. 2 demos with a Jets application are also provide. We deploy it to Lambda with a single command.

A quick way to test a Lambda function, is to add a little portion of code at the bottom of the script that tells it to run itself when it is the main script. The if statement means that the script will only run if it is ran directly vs being required as a library.

In this video, we continue the tutorials on the Jets Ruby Serverless Framework that adds Ruby support to AWS Lambda. We talk about a Jets concept called extra environments. With one environment variable JETS_ENV_EXTRA, we can create as many additional instances of environments as we wish. This helps when multiple people are asking to use the development, staging, or uat environment but cannot because it is currently used by someone else or another feature. Usually, you end up having to wait until the environment free. With this Jets concept you can create as many environments as required.

In this video, we continue the tutorials on the Jets Ruby Serverless Framework that adds Ruby support to AWS Lambda. We’ll demonstrate how to customize the properties associated with the Lambda functions that Jets creates. There are 3 ways to set function properties with Jets: at the function level, class level or application level. We’ll also explore the AWS Lambda console and shows how the Lambda function properties connect with Jets.

In this video, we continue the tutorials on the Jets Ruby Serverless Framework that adds Ruby support to AWS Lambda. We’ll demonstrate how to customize the IAM policies and roles associated with Jets Lambda functions. IAM policies are important because they handle securing access to your AWS resources so it’s worth learning them. Jets provides you with fine-grain control over the IAM permissions at the function, class, and application level.

In this video, we continue the tutorials on the Jets Ruby Serverless Framework that adds Ruby support to AWS Lambda. We’ll cover background jobs in this video. Using background jobs is a typical pattern that offloads processing outside of the web request-response cycle. Users will not wait for web pages to load if it takes too long, so background jobs are an excellent technique to keep slower work outside of the request cycle.

In this video, we continue the tutorials on the Jets Ruby Serverless Framework that adds Ruby support to AWS Lambda. We’ll cover something that is pretty important to know as a software developer: debugging. With Jets it’s pretty straightforward to look at the debugging logs both locally and remotely. Locally, the logs show up with the local running server. Remotely, the logs show up in CloudWatch Logs: available both on the AWS CloudWatch Logs console and the AWS Lambda console.

In this video tutorial, we continue how to get to started with the Jets Ruby Serverless Framework that adds Ruby support to AWS Lambda. We’ll explore the AWS Lambda Console and API Gateway to show how the AWS resources map back to Jets application code.

In this video tutorial, we cover how get to started with the Jets Ruby Serverless Framework that adds Ruby support to AWS Lambda. We’ll build the quintessential CRUD application, and more we’ll importantly explore and edit it to understand how it works. Here’s the link to the Live CRUD Demo.

Update 2018/12/12: Official Ruby Support was announced at AWS re:Invent 2018 on Nov 29! Jets has switched over to it: Official AWS Ruby Support for Jets 🎉. This article is now out-of-date and kept around only for posterity. AWS Lambda does not yet support Ruby. Though there are plenty of rumors that AWS is working on it. I’m pretty excited for the day when AWS releases official support for Ruby. Until that day arrives though, we must use a shim in order to add Ruby support to AWS Lambda. A shim is a function written in a natively AWS Lambda supported language that calls out to Ruby. Jets uses a node shim to add Ruby support to AWS Lambda. The neat thing is that Jets adds Ruby support to AWS Lambda at pretty much native speed.

Update 2018/12/12: Official Ruby Support was announced at AWS re:Invent 2018 on Nov 29! Jets has switched over to it: Official AWS Ruby Support for Jets 🎉. This article has been updated to reflect official Ruby support, but video in the post is out-of-date and will be updated in time. Ruby on Jets is a framework that allows you to build serverless applications in a beautiful language: Ruby. It includes everything needed to build and deploy applications to AWS Lambda. I love working with Rails, Ruby and AWS; and wanted to work with something similar in the serverless world. So I built Jets. It is key to understand AWS Lambda and API Gateway to understand Jets conceptually. Jets maps your code to Lambda functions and API Gateway resources. AWS Lambda provides Functions as a Service. It allows you to upload and run functions without worrying about the underlying infrastructure. API Gateway is the routing layer for Lambda. It is used to route REST URL endpoints to Lambda functions.

Have you ever wondered how to find the current market spot price for an EC2 instance? When people first hear that spot instances can save you up 50%-90%, they tend to react in disbelief. This is natural and understandable, it just sounds too good to be true. Fortunately, there are many ways to confirm that the 50%-90% spot price savings is real. This article tries to lists the many ways in one place.

AWS docs explain How Spot Fleet Weighting Works under the “Spot Fleet Instance Weighting” section. I’ve read through the doc a few times now, and even so, when I come back to it months later, it still requires some mental wrangling to remember how it works. Been using some “mental” rules to understand how Spot Fleet Weighting works more quickly. Hopefully, you find these notes helpful also.

One of the biggest game-changers to spot instances are spot fleets. I mentioned how you could save 50%-90% when you take advantage of spot instance pricing in: How Does Spot Pricing Work? Spot fleets is where things get even more interesting. With a normal spot instance request, you place a bid for a specific instance type in one specific AZ and hope you get it. With spot fleets, you can request a variety of different instance types that meet your requirements. Additionally, you can spread your spot fleet bet across multiple AZs to increase the likelihood of getting your instance fulfilled. It’s like playing rollette and being able to bet a single chip on multiple numbers. Insanely cool! The method dramatically increases the chances of you getting instances available at your spot bid price. Like I said, game-changer.

Spot instance pricing is a fascinating EC2 pricing model that many people have not heard of yet. It is not only interesting from the 50%-90% savings perspective, which is already huge. It is also interesting because it encourages you to think about building your system with the best practice of high availability in mind.

Just like renting or leasing a house, when you pay for servers from AWS, there are many, many different options. The plethora of options is so vast that it can be overwhelming staring at them. I’m hoping to cover the pricing options in a useful way. With the options, you get exactly the same server, but you pay a different price because of the different commitment levels from either you or from AWS.

Have you ever been asked to deploy a branch of code to the staging or uat environment but cannot because the environment is currently in used by someone else or another feature? Usually, you end up having to wait until the environment free. Ultimately, after this happens often enough a common request is to build additional environments. This can take some time though, so you still have to wait.