In the previous post, AWS Config was introduced. We talked about how it can be used to obtain continuous compliance with your AWS account. In this post, we’ll implement a working example solution.
In the previous post, AWS Config was introduced. We talked about how it can be used to obtain continuous compliance with your AWS account. In this post, we’ll implement a working example solution.
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. 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 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.
subscribe to Blog via RSS