Original reporting via devops.com. Original post date: July 26, 2019.
Stackery Brings AWS Lambda Development to the Local IDE
Stackery announced a plug-in capability designed to let developers build and debug AWS Lambda functions directly from a local integrated development environment (IDE), without requiring a live connection to the AWS cloud for every change. The announcement targeted DevOps teams looking to incorporate serverless computing more smoothly into their existing CI/CD workflows.
How the Plug-In Works
According to Stackery CTO Chase Douglas, the tooling can be added to any IDE either through the Stackery VS Code Serverless Tools Plug-In—which automates the installation process—or through a manual installation path. The plug-in is language-agnostic, meaning it is not limited to a specific runtime such as Node.js or Python.
Key capabilities announced at the time included:
- Local build and debug: Developers can iterate on Lambda function code from their laptops without pushing every change to AWS.
- No Stackery account required: The local tooling is available without creating a Stackery cloud account, lowering the barrier to entry.
- AWS CloudFormation compatibility: The Stackery toolset can invoke resources compatible with AWS CloudFormation—86 resource types were cited at the time of the announcement.
Reducing YAML Complexity for Serverless Infrastructure
A core part of Stackery’s value proposition is abstracting away the YAML authoring typically required to define serverless infrastructure as code. Stackery provides visual tooling that lets developers configure Lambda functions and related AWS resources without writing raw CloudFormation or SAM (Serverless Application Model) templates by hand. The local IDE plug-in extends this approach to offline development, allowing teams to work without a constant internet connection to AWS.
Why Serverless Adoption Adds Complexity for DevOps
Serverless computing frameworks such as AWS Lambda are increasingly popular because they allow developers to trigger additional compute resources in response to events—such as invoking an analytics pipeline when a specific application event fires—without embedding that infrastructure logic in core application code. Serverless workloads are typically short-lived and stateless, complementing rather than replacing containers and virtual machines used for longer-running processes.
However, for DevOps practitioners, serverless introduces an additional abstraction layer that must be integrated into existing CI/CD pipelines. Teams already managing container and VM-based deployment workflows face a real challenge absorbing yet another compute paradigm with its own tooling, IAM permission models, deployment packaging, and observability requirements.
Tooling that brings serverless development closer to familiar local workflows—like an IDE plug-in with offline debugging—directly addresses this friction.
Looking Beyond AWS
At the time of the announcement, Stackery’s tooling was focused exclusively on AWS environments. The company indicated plans to eventually extend support to other serverless computing platforms, though no specific timeline or platforms were named. The broader goal, as stated by Douglas, was to make serverless frameworks more accessible to both development and IT operations teams regardless of which cloud provider they use.
The Road to Serverless Automation in DevOps
The longer-term vision for serverless in DevOps is full automation: developers focus purely on business logic while infrastructure provisioning, scaling, and teardown are handled transparently by the platform. Achieving that vision across multiple serverless frameworks running on different cloud providers remains a significant challenge as of this writing. However, tooling improvements—such as local development environments that reduce the feedback loop for Lambda development—represent meaningful steps toward mainstream DevOps adoption of serverless architectures.
For DevOps teams evaluating serverless tooling for AWS Lambda, the ability to develop and test functions locally before deploying to the cloud can meaningfully accelerate iteration cycles and reduce unnecessary AWS invocations during development.