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 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.
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.
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.
Have you ever wondered how to find the current market spot rate for an instance? When people first hear that spot instances can save you up 60%-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 60%-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 work 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 60%-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 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. The method obviously 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 60%-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 a little overwhelming staring at them. I’m hoping to cover the pricing options in a way that is useful. With the options, you get exactly the same server, but you pay a different price because of the different commitment level 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.
This is an introductory guide to ufo, an ECS deployment tool, with AWS Fargate. Ufo helps you deploy Docker images to AWS ECS. With Fargate, you can run docker containers without having to manage servers, for an interesting “serverless” option.
This is an introductory guide to ufo, an ECS deployment tool. Ufo helps you deploy Docker images to AWS ECS quickly. One pretty neat thing about ufo is that it provides direct access and control to the ECS Task Definition. So you can customize your ECS container options to your heart’s content. We’ll also talk about some of the resources that ufo creates.
There are some pretty big changes for ufo version 4. Here’s what’s new:
Recently upgraded ufo to add support for ECS Fargate. As part of this, I had a chance to take a look at the pricing for Fargate. Found out that ECS Fargate’s pricing is competitive to Heroku’s offering. The pricing makes a lot of sense because they offer a similar value proposition. We do not have to manage the servers.
Docker is kind of like git in a sense that there are only a few commands to learn to for it be useful. This tutorial focuses on the docker commands that I find myself most commonly use. This article assumes that you have a general idea of what docker is and have it installed and set up already. Hopefully, it serves as handy reference or cheatsheet for useful common docker commands.
Looking into AWS Step Functions. Here are some initial thoughts.
AWS Step Functions involves translating your logic into a declarative form. In this sense, it’s like CloudFormation. For some, the change in logical constructs can be a bit daunting at first. Here are some benefits and disadvantages.
If you are working with AWS heavily, you should look into a powerful tool called CloudFormation. Taking the time to learn CloudFormation is an investment that is easily returned to you in the form of powerful automation. In this guide, we’ll provide a gentle introduction to CloudFormation, and by the end, you’ll have the skills to start using it in your own AWS workflow.
The common advice to speeding up your Docker development workflow focuses on reducing your Docker image size. At the surface, the logic makes a lot of sense. By making your Docker images smaller, you win. With smaller image sizes, there are fewer bytes to pull down and push up to the registry, thus saving you a boatload of time. Smaller images = solution. What the advice does not take into account is a precious resource: developer’s time.
One way to think about Docker image layers is to think of them as git commits. While the two are technically different, this article uses this analogy to point out an interesting commonality between both of them.
subscribe to Blog via RSS