Hacker News Reader

Comment by lotyrin | Hacker News Reader

This claims that on close-to-breakeven applications that moving to serverless might reduce dev costs or accelerate dev work... Serverless proponents: how does that work in theory?

In practice, all the serverless guys I've seen have a pre-CI pre-VCS pre-UAT kind of workflow using the AWS console where there's no change control or ability to collaborate.

View on HN

I've been using Zappa https://github.com/Miserlou/Zappa for a few side projects and even at work, and you can definitely set up a robust version-controlled, CI + UAT + CD pipeline if you have the discipline.

* Dev: develop inside Docker container identical to Lambda environment https://github.com/lambci/docker-lambda

* CI: test via Jenkins/GoCD/Travis/CircleCI, inside docker

* Staging: deploy to staging host on merge

* UAT: against staging env, break build if any user-facing tests fail

* Prod: deploy exact same package we deployed to Staging

CI/CD is pretty easy. Another commenter mentioned Jenkins+Terraform. A year or so ago, I did a great project using just Jenkins+CloudFormation for Lambda deployments, too. Took a bit of initial investment but after that it was maybe the best development experience I've had, despite the tooling being lackluster and best practices still sort of emerging. We used TypeScript to build microservices in the backend with API Gateway talking to a proxy tier, Angular 2 in the frontend. All super enjoyable to use.

Of course it depends on the use case, but for smaller functions it definitely reduces dev work. For AWS, Lambdas can be versioned and aliased. Blue green deployments are trivial since you can switch Lambda versions on the fly. Rolling back and invoking dev versions are similar.

You can now even do canary deployments where you switch a small amount of traffic to a new version of your Lambda. The FaaS (function as a service) ecosystem is rapidly reaching parity with traditional software.

Disclaimer: I work for AWS

Some ideas here re automated testing, CI and deployment:

https://hackernoon.com/yubls-road-to-serverless-part-2-testi...

My team uses the Serverless Framework (serverless.com), git-with-github, and automate deployments from CI/CD.

AWS also offers some of these pieces fully integrated via CodeDeploy (which we do not ourselves use).

We've got a CI pipeline that deploys Lambda functions via Terraform and Jenkins. There are some slightly tricky bits but it's not really that hard to do.

So like, CI uses Terraform populates all of your functions + other resources in a temporary environment and runs whole-system integration tests?

You lost me at "pre-VCS". Seriously.

Yeah... I tend to end up on "We're kind-of like a start-up inside of the Enterprise" teams which frequently fail to see the benefit of change control or release engineering, they're edit-on-production PHP cowboys or Java devs that are used to feeling like operations and integrating their code changes are someone else's problem, but who have no such support.

Teams that have (only fairly recently) discovered AWS lets them escape the snail's pace of getting something into production within Enterprise IT, their little walled garden that IT has siloed them into (for their own good). They just absolutely love Node + Lambda because servers are scary (they tend not to have CLI skills to even CD / LS around the VFS) and it lets them get things done -- which is all their superiors value.

Places where IT doesn't value time to market, and nobody values maintenance or costs (we regularly have products owned by failing to apply patches to products using OSS, we rack up AWS bills by leaving manually created test resources around for months or ramping up products like Lambda to the moon for a batch job then forgetting to turn it back down once it finishes).

Reply on news.ycombinator.com