Shipping serverless applications feels good. And it should! Serverless lets us focus on our software and ignore the tedium of managing servers. You download a framework, write a little code, and deploy your first Lambda function. Congrats! You're a serverless developer!

But, as you run through that first "Hello, world" serverless tutorial, you might notice that you're cutting a few corners that you can't really cut in a professional setting. Security? Permissions? Secrets management? Dev environments? Testing? CI/CD? Version control? And the other two hundred little details that matter when you're doing professional software development with a team.

On the one hand, these are solvable problems. On the other hand, though, if you have to re-invent the wheel for the development and operations cycle, maybe you won't get to focus on the code as much as you thought...

Successful Serverless Teams

Successful serverless teams use software tools to solve these challenges. They deliver projects on time and reliably by automating the manual, error-prone parts of serverless development. While we could write a book on all of the best team ergonomics for serverless, let's focus on the big three areas where you'll want a tool: configuration, release automation, and visibility.

Configuration

Regardless of which framework you choose, once you get past your first "Hello, World" function, you're going to have to start writing configuration code. Congrats! You're a serverless YAML developer!

You (and everyone else on your team) will need to learn to configure every single cloud resource you want to use down to the smallest details. Event streams, VPCs, API gateways, datastores, etc, etc. And I mean really down in the weeds here -- like, the be ready to map your IP Routing Tables kind-of-in-the-weeds...

The right tooling can automate this configuration for you and let you pull pre-configured resources off the shelf and into your framework automatically. That's trickier than it sounds! Most "resources" are actually a collection of services. It's not enough just to say "I need an API," you'll be configuring IAM roles as part of the assembly process, unless you have professional tooling.

Oh, and um, this is awkward... everyone on your team is going to have their own configuration file. Each developer will need to sandbox their own resource instances with scoped IAM roles and namespace their resources so you don't overwrite each other with collisions. Even with master-level git-fu, this is really hard. That's coming from me, and I came to Stackery from GitHub.

Release Automation

For serverless release automation, we’re going to need to figure out how to solve a few specific challenges: defining deployment stages, managing permissions, and integrating into a central CI/CD pipeline.

Once you've got your application built and your infrastructure configured, you're ready to deploy. For your first app, that probably meant giving your framework God-like privileges in your personal AWS account. Yeah, ok, no, we're not going to do that at work, in production. Right?

For serverless release automation, we're going to need to figure out how to solve a few specific challenges: defining deployment stages, managing permissions, and integrating into a central CI/CD pipeline.

Managing deployment stages is a very similar problem to juggling your multiple configuration files. In fact, you could just define each stage in that one file... except that now when you make a configuration change, you have to remember to make it in every environment. I'm not pointing fingers here, but it'll probably get messed up by someone at some point. And that will suck. Plus, these environments each have their own secrets and environment parameters which you'll want to keep out of version control (and out of your config file) but available to the newly provisioned resources.

We'll also want to create limited access roles for provisioning which, unfortunately, some frameworks just don't support. This is why Stackery's CLI leverages your existing user roles to enforce your access policy, rather than requiring admin rights to your AWS account like other tools.

Finally, while you could write your own scripts, scripting up serverless deployments can be tricky and brittle. With the right CLI tool, you can simply drop it into your CI/CD pipeline and have it automatically support your deployment stages and environment parameters.

Serverless Visibility

When you're developing an application to run on static infrastructure (you know, the old way with servers), it's pretty easy to visualize the architecture in your head. There's an app; it's on a server. If someone makes a change, the architecture remains stable. If there's an error, it'll show up in the server logs. Need metrics? Dropping a library or agent in one place will do the trick. Pretty straightforward.

With serverless, visibility suddenly becomes way more important. The dynamic architecture changes as your team builds more functions. Errors and performance bottlenecks can get distributed to other services. Logs and metrics collection need to be in place in advance -- once that function instance dies, it and its data are gone forever.

It may not be obvious in advance, but the day will come when having a place to quickly glance and see a real-time view of your application architecture and performance will save you. Plan accordingly.

Get Back to Development

While we focused on three big challenges, the truth is that there are a lot. Centralized build process, dependency management, standardized instrumentation, error monitoring, and on and on. Pioneering teams have solved most of the above, for the rest of you, we're making sure you can do all of the above without having to build it yourself.

The leading serverless teams today spent the last two or three years solving these challenges. Again, they are solvable. But if you're trying to deliver your application and meet your deadlines (and not create a bunch of extra risk for your organization in the process), you have three choices:

1. Give up the velocity advantages of serverless and go back to legacy software development.
2. Delay the velocity advantages of serverless and spend the next several sprints trying to invent your own patterns (and then the subsequent ones refining them and training everyone on how to do it your way) and roll your own tooling scripts.
3. Embrace the velocity advantages of serverless and plug in a software tool to manage these challenges and get back to development.

And really, that's a pretty easy choice. Smart companies will always stand on the shoulders of giants and focus their efforts on building problems unique to their business. Try Stackery today and get back to development.