4 ms·

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

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.

signalnine 9y ago
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.
- lotyrin 9y ago
  So like, CI uses Terraform populates all of your functions + other resources in a temporary environment and runs whole-system integration tests?
agranias 9y ago
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.
- illumin8 9y ago
  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
shoo 9y ago
Some ideas here re automated testing, CI and deployment: https://hackernoon.com/yubls-road-to-serverless-part-2-testing-and-ci-cd-72b2e583fe64 https://hackernoon.com/yubls-road-to-serverless-part-2-testi...
smoll 9y ago
I've been using Zappa https://github.com/Miserlou/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 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
WaxProlix 9y ago
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.
chrisweekly 9y ago
You lost me at "pre-VCS". Seriously.
- lotyrin 9y ago
  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).
ewindisch 9y ago
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).

signalnine 9y ago

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.

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

agranias 9y ago

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.

illumin8 9y ago
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

shoo 9y ago

Some ideas here re automated testing, CI and deployment: https://hackernoon.com/yubls-road-to-serverless-part-2-testing-and-ci-cd-72b2e583fe64 https://hackernoon.com/yubls-road-to-serverless-part-2-testi...

smoll 9y ago

I've been using Zappa https://github.com/Miserlou/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 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

WaxProlix 9y ago

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.

chrisweekly 9y ago

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

lotyrin 9y ago
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).

ewindisch 9y ago

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).