X-Ray tracing for Kotlin Ktor client
Thursday, 09 March 2023, 13:04
Just yesterday I wrote about X-Ray integration for Rust SDK. Tracing is very important in serverless microservice architecture - if you have tens or hundreds of AWS Lambda functions behind API Gateway communicating via SQS queues looking into logs in single place will not be enough - with the main issue very often being lack of that place to look for in the first place. When working with Kotlin and distributed microservices, usually default choice is Ktor (for client). It's possible to track external communication (non-AWS services) with X-Ray, but of course it needs to be recorded. I've build an extension (called feature in Ktor) that saves each external HTTP call as X-Ray trace.
X-Ray tracing for AWS Rust SDK in Lambda runtime
Thursday, 09 March 2023, 01:20
Rust becomes more and more widely used in many places and AWS cloud is no exception. With AWS SDK for Rust (currently in preview) and Rust runtime for Lambda it's possible to build regular Lambda functions. Rust gives those serverless components safety and runtime speed but it's still quite new and ecosystem around Rust for AWS Lambda does not cover all features from other SDKs. One of such missing features is good X-Ray integration. There is no fully-flagged instrumentation for Rust SDK and if you search for solutions how to include such tracing in Rust projects using SDK… you will find planty of different solutions and there is high chance that none of them is what you are looking for.
CloudFormation custom resource providers - with any runtime, any toolchain, any deployment pipeline
Thursday, 27 May 2021, 22:05
Yes, CloudFormation again. It may seems funny how many trouble case-studies and troubleshooting guides I can write for a tool I claim is best IaaC solution for AWS cloud… but I bet this is how it works for most of popular tools - you always have some edge cases and new features that require stabilization, yet if the tool is flexible enough you can overcome the downsides. In CloudFormation you can do so by using macros, modules, custom resources ("old way") or - subject of this post - resource providers. Resource providers allow for extending CloudFormation capabilities to handle custom resources in a standardized approach. You can think of it as a superior replacement for AWS::CloudFormation::CustomResource. Custom resources had a lot of limitations: you had to manage permissions for each instance - in resource providers it's the provider that defines required permissions; resource handler execution time was limited to single Lambda execution time (in fact you could count it times three thanks for handling retries) which was up to 45 minutes in current setup - resource providers allow you to report progress and integrate stabilization flow to extend this time to tens of hours. Resource providers are more integrated with CloudFormation service itself - in fact huge part of natively-supported resources is released open-source by AWS as resource providers. As always there is also some but and here I will try to describe my little experiment lifting the boundaries of resource providers to cover scenarios and needs that AWS claims are not "supported" right now.
Tags: AWS, Cloud, Code, Lambda, CloudFormation
Blue-green deployments with Terraform
Thursday, 24 December 2020, 13:29
Blue-green deployments are not always easy, but cloud environments and tools that manage them make it much easier. One of the leading tools in the DevOps world designed to help you manage your resources in infrastructure-as-code manner is Terraform. This tool is just brilliant and at the same time easy to use. Still, when working exclusively with AWS cloud, I use CloudFormation considering it to be just better choice (for various reasons), and when it comes to serverless architecture I hardly can find anything simpler. But yes, this time I will use Terraform and the solution, even though using AWS resources for exemplar cases, should be portable to any infrastructure provider you would like to use. In most guides and articles on the web, which I've found infrastructure code was used to orchestrate entire landscape as one codebase - meaning you would need to modify your code reflect current stage of deployment process. This however doesn't play well with another aspect of dev-ops, which is automation usually done via CI/CD pipeline. I tried to describe blue-green deployment more like a process that allows you to decouple each step and place it within your pipeline.
Tags: AWS, Cloud, Continuous Delivery, Terraform
Variables namespaces in CodePipeline for multi-stage deployment pipelines
Thursday, 16 July 2020, 22:26
In November 2019 AWS CodePipeline introduced variables namespaces to allow passing outcomes of one pipeline action into another. Previously passing values between stages was very tricky and required involving of additional services (eg. S3 or DynamoDB). Things worked however little different if you were provisioning your pipeline with CloudFormation - since your pipeline definition was wrapped in a template you had a chance to inject deployment-time values into it via templating functions. To make things even more usable, but also complex, if you were defining CloudFormation step in CodePipeline you had an option to use Fn::GetParam function (which you couldn't use anywhere else, it was it's sole purpose). Now, with variables namespaces in CodePipeline and support for this feature in CloudFormation building more dynamic pipelines that manage your AWS resources in infrastructure-as-a-code approach and vice-versa became much simpler and robust!
Tags: AWS, Cloud, CodePipeline, CodeBuild, Continuous Delivery, CloudFormation
Provisioning AWS Athena queries with Lambda and StepFunctions
Saturday, 30 May 2020, 23:21
Amazon Athena is a brilliant tool for data processing and analytics in AWS cloud. Under the hood it utilizes Presto engine to query and process data in your S3 storage using standard SQL notation. The concept behind it is truely simple - run SQL queries against your data in S3 and pay only for the resurces consumed by the query. No cluster to manage - everything fully serverless and managed by Amazon; no need to learn new technology - you query data using SQL that most likely is known among your team; no need for additional storage or fees - you store data directly in S3. Did I mention a keyword serverless? Yes, it runs completely via API SDK, no need to manage any resource on your own (and cold startup in Athena is super low). It integrates tightly with Glue. When we say serverless in AWS we mainly think Lambda. And for sure, sooner or later you will want to integrate your query into some more complex workflow.
Monitoring Lambda memory usage - X-Ray aware version
Tuesday, 30 July 2019, 07:17
In serverless architecture on AWS Lambda is a basic computing service. AWS provides some basic metrics related to it, like execution time, invocations count etc. but one important metric is missing - memory consumption. Knowing how much memory your functions use allows you to optimize resources and reduce costs (or increase to avoid failures). It can be very simply generated out of logs (since Lambda logs execution report after each invocation) with CloudWatch metric filter feature. And this approach has been described plenty of times around the web, including ready solutions. So I will not elaborate that much on the concept, as has already been done. But there is one trick - if you use X-Ray this solutions will not work. At least - not out of the box.
Tags: AWS, Cloud, Lambda, CloudFormation, X-Ray, CloudWatch, Monitoring
Deploying Lambda@Edge with pl.wrzasq.lambda
Thursday, 22 November 2018, 13:12
When working with cloud, one of the most efficient approaches you can leverage is serverless architecture. This concept allows you to define your entire application as set of interacting resources, without worrying about underlying infrastructure. Serverless applications can scale virtually to infinity, are cost-effective, lower maintenance costs (forget about patching kernels, installing system packages, defining upgrade paths etc.). Per-se, serverless it is a general pattern, but I will focus on AWS as this is my area of expertise - here, the main computing unit in serverless world is Lambda. It is a FaaS component that allows you to run your piece of code "in the cloud", which means decoupled form any computing hardware. Such code pieces can be triggered by you to perform some computation, but can also act as a handlers for various events across the platform (like SNS message processors, API Gateway authorization handlers and many many more). One of such integration ways is Lambda@Edge, which allows for handling CloudFront request events.
Tags: AWS, Cloud, Lambda, Web, CloudFormation, Open Source
Bootstrapping AWS account with CloudFormation and CodePipeline
Saturday, 09 June 2018, 08:45
Yes, I love CloudFormation when working with AWS. With all of it's limitations and quirks, it's a really simple and extensible tool, that allows you fully manage your resources in an automated Infrastructure-as-a-code approach. If you create a project from scratch you probably want to automate as much as possible - if you decide on CloudFormation you probably want to figure out how to provision as much as possible from your AWS cloud with it? The thing is: you can manage everything - by using just a single command it's possible to bootstrap your account in a fully automated manner.
Tags: AWS, Cloud, CodePipeline, Continuous Delivery, CloudFormation
Multiple Amazon API Gateway stages
Sunday, 03 December 2017, 23:08
Short time ago I described CI/CD pipeline design, that allows for handling multiple environment deployments replicated from same CloudFormation template. Process is usually quite easy if you have some EC2-based deployment, per-environment ECS cluster or Lambda functions that you can deploy freely however you like. Things get complicated when you integrate API Gateway. The easiest way would be to deploy separate APIs for each of your environments. But it seems so wrong, isn't it? API Gateway has a feature of stages, that seems to be perfect for such cases.
Tags: AWS, Cloud, Lambda, API Gateway, CloudFormation