4 ms·

I am still on the serverless high, and I don't see it going away any time soon. For the large corporation that I work for, things like soc2, patching, server ma

I am still on the serverless high, and I don't see it going away any time soon. For the large corporation that I work for, things like soc2, patching, server maintenance, etc. are a giant pain every single month. The quicker we switch as many things as possible to serverless the better. One of the services I converted over went a year and a half with absolutely no attention from our engineers. It was great seeing how old the latest deploy was. Coupling serverless with terraform and git makes everything even easier. It means doing things like adding another lambda to an API as simple as copy and paste terraform, replace phrases in terraform, write code. terraform apply and done.

luhn 6y ago
How do you use Terraform with Lambda? That's been one of the huge painpoints in my limited Lambda experience. All the CI tools (SAM, Serverless Framework, e.g.) seems to want to handle the IaaS part themselves and step on Terraform's toes. I just want to set everything up with Terraform and then have a nice simple tool to build and deploy the application.
- lovehashbrowns 6y ago
  We use terraform and terragrunt by themselves to deploy lambdas. No frameworks. It's slightly more work, I guess. But deploying and understanding how deployments happen is easier this way. Plus, getting any kind of framework approved in a corporation is annoying as heck, whereas we already use terraform and terragrunt. https://registry.terraform.io/providers/hashicorp/aws/latest/docs/resources/lambda_function https://registry.terraform.io/providers/hashicorp/aws/latest... The biggest annoyance is unit testing, although it forces certain good habits on us. So for example, since we don't use SAM, we have to do unit testing separately (our code is in Python). But because we can't exactly run a lambda via Python, we have to put most of our code in the layers that our lambdas import. So we run unit tests on the layers, and the positive is that we can essentially copy and paste the code that our lambdas would run into the unit tests. And then we can keep it DRY because almost all the code is in layers, and that incentivizes us to create generic functions that can be used across all of our lambdas. For things like unit testing DynamoDB, we use Moto which works exceptionally well. https://pypi.org/project/moto/ https://pypi.org/project/moto/ More detail: Our terraform has infrastructure code for: API Gateways Hard-coded API keys we use for testing DynamoDB tables IAM roles used by the Lambdas and Step Functions Lambdas themselves s3 buckets used for the Lambda zip files and state Step functions
- rjbwork 6y ago
  We have build our apps and create a lambda zip file and deploy it out of band of our Terraform. We just upload the zip file to S3 after deploy and if Terraform runs and makes a change to the Lambda, it deploys the most recently deployed version automatically. We did this so we could totally separate our applications and the infrastructure as code stuff since infrastructure changes at a drastically slower rate than applications.
annoyingnoob 6y ago
How does moving to 'serverless' change the need for patching and other security maintenance? You've just moved it to a server owned by someone else. Sounds more like passing the buck rather than ensuring security.
- lovehashbrowns 6y ago
  soc2 compliance for Lambdas happens through AWS https://aws.amazon.com/compliance/services-in-scope/ https://aws.amazon.com/compliance/services-in-scope/ not through our team's engineers. So for example, if we have a service deployed in an EC2 instance, we have to update the instance(s) every month by a certain date. Sometimes, we have to update early if there is a severe security issue. We also have to manage things like security software that has to run on every instance, logging for soc2 compliance, access controls, manage ssh keys, etc. etc. That's a lot for our engineers to handle every single month. A lot of context switching. It's not so bad if we only have one service to manage. But the actual issue is that we have many services to manage. So every month, our board had about 12 stories related to patching. Patch service X development. Patch service x staging. Patch service x production. Patch service Y development.... and so on. For serverless, the team responsible for SOC2 compliance gets the reports from AWS without us ever having to do anything. No patching stories, no security software that breaks on occasion, no access management, etc. All we have to worry about in terms of SOC2 compliance are the basics like principle of least privilege (i.e. lambdas do not have full access to DynamoDB), no public endpoints, we use VPCs blessed by the security team, and that's about it. Things we're used to doing everywhere else and things that we only worry about when writing the terraform. Now when I add a Lambda, I only worry about writing the Python code for the lambda and copying the terraform code. That's it. There is no patching story for this service. And yes, of course we're passing the buck. That's kinda what we pay for in the premiums that AWS gets from our massive bill every month. That's kind of the entire point for cloud-based systems, anyway. We're passing the buck on a ton of other things, like not having to manage hard disks, not having to manage network cables, not having to manage a building, not having to manage HVAC, not having to manage backup batteries, etc.
  - annoyingnoob 6y ago

luhn 6y ago

How do you use Terraform with Lambda? That's been one of the huge painpoints in my limited Lambda experience. All the CI tools (SAM, Serverless Framework, e.g.) seems to want to handle the IaaS part themselves and step on Terraform's toes. I just want to set everything up with Terraform and then have a nice simple tool to build and deploy the application.

lovehashbrowns 6y ago
We use terraform and terragrunt by themselves to deploy lambdas. No frameworks. It's slightly more work, I guess. But deploying and understanding how deployments happen is easier this way. Plus, getting any kind of framework approved in a corporation is annoying as heck, whereas we already use terraform and terragrunt. https://registry.terraform.io/providers/hashicorp/aws/latest/docs/resources/lambda_function https://registry.terraform.io/providers/hashicorp/aws/latest... The biggest annoyance is unit testing, although it forces certain good habits on us. So for example, since we don't use SAM, we have to do unit testing separately (our code is in Python). But because we can't exactly run a lambda via Python, we have to put most of our code in the layers that our lambdas import. So we run unit tests on the layers, and the positive is that we can essentially copy and paste the code that our lambdas would run into the unit tests. And then we can keep it DRY because almost all the code is in layers, and that incentivizes us to create generic functions that can be used across all of our lambdas. For things like unit testing DynamoDB, we use Moto which works exceptionally well. https://pypi.org/project/moto/ https://pypi.org/project/moto/ More detail: Our terraform has infrastructure code for: API Gateways Hard-coded API keys we use for testing DynamoDB tables IAM roles used by the Lambdas and Step Functions Lambdas themselves s3 buckets used for the Lambda zip files and state Step functions
rjbwork 6y ago
We have build our apps and create a lambda zip file and deploy it out of band of our Terraform. We just upload the zip file to S3 after deploy and if Terraform runs and makes a change to the Lambda, it deploys the most recently deployed version automatically. We did this so we could totally separate our applications and the infrastructure as code stuff since infrastructure changes at a drastically slower rate than applications.

annoyingnoob 6y ago

How does moving to 'serverless' change the need for patching and other security maintenance? You've just moved it to a server owned by someone else. Sounds more like passing the buck rather than ensuring security.

lovehashbrowns 6y ago
soc2 compliance for Lambdas happens through AWS https://aws.amazon.com/compliance/services-in-scope/ https://aws.amazon.com/compliance/services-in-scope/ not through our team's engineers. So for example, if we have a service deployed in an EC2 instance, we have to update the instance(s) every month by a certain date. Sometimes, we have to update early if there is a severe security issue. We also have to manage things like security software that has to run on every instance, logging for soc2 compliance, access controls, manage ssh keys, etc. etc. That's a lot for our engineers to handle every single month. A lot of context switching. It's not so bad if we only have one service to manage. But the actual issue is that we have many services to manage. So every month, our board had about 12 stories related to patching. Patch service X development. Patch service x staging. Patch service x production. Patch service Y development.... and so on. For serverless, the team responsible for SOC2 compliance gets the reports from AWS without us ever having to do anything. No patching stories, no security software that breaks on occasion, no access management, etc. All we have to worry about in terms of SOC2 compliance are the basics like principle of least privilege (i.e. lambdas do not have full access to DynamoDB), no public endpoints, we use VPCs blessed by the security team, and that's about it. Things we're used to doing everywhere else and things that we only worry about when writing the terraform. Now when I add a Lambda, I only worry about writing the Python code for the lambda and copying the terraform code. That's it. There is no patching story for this service. And yes, of course we're passing the buck. That's kinda what we pay for in the premiums that AWS gets from our massive bill every month. That's kind of the entire point for cloud-based systems, anyway. We're passing the buck on a ton of other things, like not having to manage hard disks, not having to manage network cables, not having to manage a building, not having to manage HVAC, not having to manage backup batteries, etc.
- annoyingnoob 6y ago