Share on facebook
Share on twitter
Share on linkedin

Keeping the original promise of serverless

Forrest Brazeal
Forrest Brazeal

Welcome to “Serverless Superheroes”!
In this space, I chat with the toolmakers, innovators, and developers who are navigating the brave new world of “serverless” cloud applications.

The Serverless Superheroes Series featuring Jay and Frank

For today’s edition, I spoke with Jay V and Frank Wang, who are known for their Serverless Stack tutorials. They recently released the beta version of a new serverless deployment pipeline called Seed. The following interview has been edited and condensed for clarity.

Forrest Brazeal: So what’s the history behind Seed? How did the two of you get interested in continuous integration for serverless applications?

Jay V: Frank and I have been building products and services in AWS for over a decade. At some point it became pretty obvious that it’s hard to manage and maintain the cloud infrastructure for all those projects. So when serverless architecture came along, we kind of went: “Wow, this is what we’ve been missing.”

But as we tinkered around with it, we realized there wasn’t a good resource on how to build a serverless application end to end. You have to put many different AWS services together in the same stack, which is not the way projects were architected before.

So we wrote Serverless Stack as a comprehensive, step-by-step tutorial, covering everything from the back end all the way to hosting the front end of the application on AWS.

As that project took off, we had a lot of people come to us with questions about various aspects of life in the serverless world. And a big theme soon emerged: it seems that people struggle to manage serverless projects at the level of a team.

Our guide and a lot of other resources out there are written to help an individual developer get going. But when you’re building a serverless application as part of a team, it’s up to you to figure out that workflow and piece it together using whatever services you can find.

So we decided we wanted to put together a service that you could bring to your team on Day 1 and get everybody working together on a serverless project. And that’s how Seed got started.

I’ve definitely experienced the pain of orchestrating serverless deployments on a team of multiple developers — continuous integration is hard when there’s no build server! Can you walk me through an example of a team successfully using Seed in their workflow?

Jay: The basic workflow we support right now is a branch-based workflow. First you create a feature branch in your source control repository and do some work on it. Once you write your unit tests and the code works in your local environment, you ping your team lead or whoever and say: “Hey, we’re ready to merge these changes into staging.”

When that merge happens, Seed runs your tests and creates what we call “verified builds”, deploying your code and infrastructure into the specified AWS environment. And when the team is happy with the build in staging, you can deploy to production.

All the steps of that pipeline are configured through the Seed dashboard as opposed to just pushing code through Git. We keep track of all the verified builds in production so that you can roll back if anything goes wrong.

Frank Wang: We also support secret variables. A lot of people are concerned about checking in passwords and other sensitive config into source control. So through our dashboard, we let people encrypt their credentials with their own KMS key.

Do you provide Seed as a managed service? Or do I have to deploy it in my AWS account?

Jay: Seed is a hosted solution. Everything related to the build is done in our AWS account, and then we deploy the actual resources in your account using IAM credentials you give us.

A key benefit of this setup is that you don’t really have a dependency on our service. If you want to opt out of Seed and orchestrate your own deployments, you’re already set up to do that in your account. We’re just there to make it easier.

AWS has their own suite of CI/CD tools, including CodeBuild and CodePipeline. What makes Seed a better option for serverless workflows?

Jay: Actually, we’re built on top of CodeBuild internally. And then we expose the CI workflow to you — right now we support that branch-based workflow I mentioned.

Like a lot of AWS services, the Code* services handle maybe 80% of the deployment pipeline for you, and then the 20% is up to you to figure out. So we are targeting a team-based workflow for serverless products that works out of the box for the majority of users.

I definitely agree that AWS’s code pipeline services have their share of gaps. But other products, like Jenkins and GitLab CI, are well established ways to do continuous integration and delivery, both in and out of AWS. Why is Seed different?

Jay: Granted, we have a bit more work to do as we really differentiate ourselves. But the context is a little bit different. With those other products, you have to manage a server to run your tests and orchestrate your builds. With Seed, the build happens serverlessly — no need to worry about server management, scaling, or idle cost.

But the bigger issue, specifically with AWS, is that deployments are about infrastructure as well as code. We want to be sure you’re not making small unintended changes to your stack — changes that wouldn’t show up in, say, GitLab CI.

A good example of this is a CloudFormation template. You might get rid of a resource and not realize it, which would be a major problem at deployment time. So we will soon be able to prepare changesets and show you what you’re about to change, even at the infrastructure level.

Frank: I’ve definitely seen blog posts on how to integrate, like, TravisCI with serverless. On the simple side, when you’re just running a “serverless deploy” command, this works okay. But it doesn’t help you manage secret variables. It doesn’t keep track of your CloudFormation updates — what if I just changed some code but didn’t make any updates to my CloudFormation stack?

As an upcoming feature, Seed will figure that out and skips the CloudFormation update step in your workflow to save you time. These optimizations take effort and are not well documented elsewhere. Seed is designed to fill that gap.

That sounds pretty interesting! What other optimizations are you making to the serverless deployment process?

Jay: Well, we’ve identified a lot of things. We’re in beta right now, reaching out to the community so they can help us prioritize the things that are the biggest pain points. One thing a lot of people like is the idea of supporting “stages” out of the box.

A question that repeatedly came out of the Serverless Stack tutorial is: “How do I set up multiple stages and hook them into my build system?” We handle that easily. When you create a new branch, that becomes your stage. And keep in mind that because we are deployed on serverless ourselves, the cost to run these builds is really low — much less than other services that charge you for server time.

As a serverless developer myself, I know that the niche attracts a lot of early adopters and toolmakers — the kind of people who enjoy filling in the gaps in existing services. What would you say to an engineer, or manager of engineers, that says — “Hey, we could hack together something like Seed pretty quickly ourselves. Why should we outsource our CI/CD pipeline to you?”

Jay: What initially attracted us to serverless applications is that they’re so easy to build and deploy. But when you start building them with your team, you wind up — as you said — hacking something together in order to have a deployment workflow.

Almost everybody we’ve talked to has some sort of twist — whether it’s branch-based, pull-request based, AWS blue green deployment, whatever — on the same basic workflow model, something they came up with independently.

So we see a lot of teams spending a lot of engineering hours building a bespoke solution that just reinvents the wheel. Why not use something that works out of the box, is more well tested, and is written in code that you don’t have to maintain?

With Seed, we are keeping the original promise of serverless: you just worry about your code and everything else is taken care of.

What are the larger philosophical goals behind your work with serverless CI? Do you see your project becoming a one-stop shop for serverless deployment, maybe even extending to multiple clouds?

Jay (laughs): That’s a good philosophical question. A big goal for us — not just with Seed, but with our previous work on the Serverless Stack tutorial — from Day 1 has been a focus on practicality.

There are a bunch of engineers out there — and we have certainly been in this position ourselves — who just want to get work done, not to spend a lot of time ramping up. So whether it’s a guide, documentation or tooling, we want to make those engineers’ lives easier. Right now, for us that means focusing on Serverless in the context of AWS.

We always get feedback about how detailed our tutorial is, but here’s one thing that really stands out: people tell us they are excited that they have actually been able build something real. That’s the sense of accomplishment and purpose we want to tap into with all of our projects.


Get the skills you need for a better career.

Master modern tech skills, get certified, and level up your career. Whether you’re starting out or a seasoned pro, you can learn by doing and advance your career in cloud with ACG.


Jay and Frank are looking for community feedback on the beta release of Seed. Check it out at seed.run, and check back soon for another edition of Serverless Superheroes!

Recommended

Get more insights, news, and assorted awesomeness around all things cloud learning.

Sign In
Welcome Back!

Psst…this one if you’ve been moved to ACG!

Get Started
Who’s going to be learning?