New Pricing & Free Tier

Today, I’m thrilled to announce our new free tier and pricing model for teams adopting modern serverless application development. I believe cloud-side development is the future and I want everyone to experience it at their own pace. We also now offer a model that can scale with either teams or workflows depending on how aggressively you decide to adopt cloud-side development.

How Software Development in the Cloud Has Changed

While we’ve been at this for a while, it’s worth reviewing where development workflows came from and what’s changing.

When "the cloud" first emerged, the prevailing development pattern was to spin up a generic (EC2) server and install software on it to customize its behavior. These customized behaviors might include event streams, data stores, database tables, APIs, or whatever else an application requires. That software, however, is now offered by the cloud providers as a pay-per-use capability that can be configured and requested with infrastructure-as-code (IaC).

Cloud providers have released hundreds of new services which, at their core, are purpose-built, use-case-driven, software-managed services. It's no longer necessary to spin up a cluster of servers to stand up Kafka if you need a message streaming service, because it's much faster and arguably cheaper (in terms of people, overhead and maintenance) to simply pull a streaming service like Kinesis or a managed Kafka service off the shelf of the Amazon Web Services menu.

You Can’t Replicate AWS on Your Laptop

The rise of these managed cloud services has fundamentally changed the model for modern application development.

The rise of these managed cloud services has fundamentally changed the model for modern application development.

Of course, the core advantage of this model is that it has become easy to architect at-scale systems in the cloud with very little operational overhead. The consequence of this change, however, is that the software development lifecycle has fundamentally changed. No longer can your laptop act as a development server (localhost). This was a great tool for replicating and testing server-like behavior in local development when the fundamental infrastructural underpinning everything was a server. But now, rather than raw servers, applications are composed of a collection of managed cloud services. Localhost has become a poor representation of the production environment, as it is impossible to replicate all of the functionality of AWS locally on a laptop.

This is driving a shift toward cloud-side development. This doesn't mean you need to write code through a web browser; your favorite IDE will still work for your application code. But to test and iterate on the full application stack through the development cycle, you must now stand up development instances of the managed services you're using to compose an application. Crucially, cloud-side development is about service composition: composing your application architecture from off-the-shelf services to accelerate at-scale application development and rapidly iterating on a cloud-native implementation of your application.

What does this tell us? Cloud-side development isn’t just the future, it’s now and it’s big. How big? At re:Invent 2018, AWS executives proclaimed hundreds of thousands of developers are actively developing with AWS’s menu of managed cloud services and Lambda. That’s big.

What tooling does cloud-side development require?

Here is the good news, your IDE, code repository, and CI/CD systems don’t change. What changes? How you manage stacks in the cloud and how you build and iterate stacks with your team.

Stackery now offers easy to consume tooling and environment management capabilities to every organization trying to deliver faster. To build Stackery, we’ve thought about, experienced, and built safeguards around the ways teams could get into trouble composing applications out of managed cloud services. All while keeping every output in standard CloudFormation in case you decide to go back to doing things the hard way.

Managing Active Stacks in the Cloud

Cloud-side development tools must automate and accelerate the iterative nature of development work on top of cloud managed services. This includes rapidly configuring, deploying, sandboxing, namespacing, and managing individual instances of cloud services for each developer involved in the development. At Stackery, we call these active stacks. Cloud-side tools will include automation around packaging and building your code, version controlling your IaC, managing developer environments, instrumentation, governance, and automating the release process across multiple environments and cloud accounts.

Building Stacks

Until recently, cloud-side development of complex applications using managed cloud services was limited to engineers dedicated to cloud innovation (and YAML.) That human investment is still useful but should be applied to setting patterns instead of troubleshooting misplaced characters. Infrastructure as code is the new assembly language. It is machine-readable and unforgiving, which means tooling needs to help developers do things like attaching a handler to a resource in seconds while properly setting all the correct permissions and more. Speaking of resources...

New! Amazon Aurora Serverless and Amazon Cognito

We owe a lot of kudos to our earliest customers who pushed us to add the most popular services needed to visually compose modern applications. Most recently, Amazon Aurora Serverless Database and Amazon Amazon Cognito(user authentication) (user authentication). We’ve also just added the “Anything Resource” that enables our users to add any AWS CloudFormation service beyond the (now 20!!) resource types currently available in the Stackery resource pallet. We like to say it takes a serverless team to keep up with a serverless team.

The Stackery Developer & Teams Plans

And now, with the introduction of our free Developer plan, we’re excited to unleash the possibilities of cloud-side development to everyone who wants to experience the power of the cloud. The Stackery Developer plan includes 6 free active stacks, which is plenty to get a side-project or proof of concept up and running. After you consume the first six stacks or if you want more support or collaborators in the account, additional active stacks can be added for $10 a month per stack. More details here.

Bring your own IDE, Git repository (blank or existing AWS SAM or serverless.yml files), AWS account, and your CI/CD system if you like - Stackery will accelerate you into cloud-development. It’s time to go build.

Further Reading On Cloud-Side Development:

__The Anatomy of a Serverless App__

We call an application deployed into a cloud service provider an active stack. This stack has three primary components - the functions where the business logic resides, the managed cloud services that serve as the building blocks of the application and then the environmental elements that define the specific dependencies and credentials of for a particular instance of the first two components. This anatomy of a serverless application post goes into the full detail of what serverless teams will build and manage.

Our friends at Lumigo on the need to test cloud-side (and some slower and manual non-Stackery methods for doing so).

Corey Quinn of Last Week in AWS (sign up for the snark, stay for the news, pay for the bill reduction) sparked this conversation on twitter.

While I appreciate AWS's support for the local development model, I can't shake the feeling that it's the wrong approach to Serverless development. Can we talk about that?

— Corey Quinn (@QuinnyPig) February 5, 2019

Likewise, this “[localhost is dead to me](https://twitter.com/mweagle/status/1093590457278390272)” rant by Matt Weagle, organizer of the Seattle Serverless Days, won him a shiny new Stackery account. This thread also garnered some helpful nuance and commentary from Amazon engineers James Hood, Preston Tamkin, and iRobot's Ben Kehoe.

1/ Twead incoming...

— Matt Weagle (@mweagle) February 7, 2019

I think we need to distinguish between local execution of user code & local emulation of managed services. I don't think anyone's against the ability to run a function locally. But if it calls a DynamoDB table, local code should call a real table, put there via a CFN deploy

— Ben Kehoe (@ben11kehoe) February 8, 2019