6 ms·

> A lambda publishes a message to SNS, another one picks it up and writes something to DynamoDB, the third one takes that new record and sends an email… Or, yo

> A lambda publishes a message to SNS, another one picks it up and writes something to DynamoDB, the third one takes that new record and sends an email… Or, you know, just do related functionality in the same AWS Lambda function. While I would probably do the sending of an e-mail asynchronously as well (as AWS Lambda function triggered by a DynamoDB stream), the indirection over SNS to write something to DynamoDB seems overly complex. Why would you do something asynchronously with a Serverless architecture you'd do synchronously with Ruby on Rails? > […] and random hardcoded configs in AWS console. Just don't do that. A Serverless application will always be a pita if it relies on manual configuration. Ensure all relevant configuration is part of Infrastructure as Code (e.g. CloudFormation or Terraform). > Impossible to replicate production environment If the project is set up properly with Infrastructure as Code replicating the production environment is as easy as it can possibly get. And because it's Serverless, if an environment isn't used, it usually doesn't even incur notable costs. There is no silver bullet and I believe Serverless as well as other approaches have their place, but what I miss are similar posts about great experiences with Serverless applications. I for myself wouldn't want to go back and I'm really happy with the problems Serverless applications solve.

alerighi 6y ago
The impossible to replicate the production environment I think was referred to impossible to replicate locally, on your machine. At my job I use AWS serverless services and I get a lot of frustration not being able to test and debug code offline. Having each time to upload some code to debug it is time consuming. Also you have to rely only on logs to debug, you obviously cannot use a debugger, and thus the solution is to insert a ton of print statements in the code and remove them, which is not a problem to me (I usually do that even in code that I debug locally) but the service to read these logs (ColoudWatch) is not great at all, you don't even have all your logs in one place, it's a mess. I think serverless is overrated, sure it maybe the right tool for a simple project, but when the complexity grows it's best to use other more classical solutions.
- k__ 6y ago
  Thundra offers online and offline debugging. Also, AWS SAM CLI allows to run things locally.
- rualca 6y ago
  > At my job I use AWS serverless services and I get a lot of frustration not being able to test and debug code offline. AWS's Serverless Application Model explicitly supports local testing. https://docs.aws.amazon.com/serverless-application-model/latest/developerguide/serverless-sam-cli-using-debugging.html https://docs.aws.amazon.com/serverless-application-model/lat... Which problems did you experienced?
  - vp8989 6y ago
    "AWS's Serverless Application Model explicitly supports local testing." It doesn't provide any additional capability that was already there. Ie, I could already run my arbitrary function from the CLI by building a simple wrapper that reads a JSON file and sends it in. Or wrap it in a simple HTTP server. The debugging story using that tool is worse than how I would already do it pre-SAM and they don't even have documentation for every runtime they officially support: https://docs.aws.amazon.com/serverless-application-model/latest/developerguide/serverless-sam-cli-using-debugging.html https://docs.aws.amazon.com/serverless-application-model/lat... It doesn't allow you to test any of the interesting bits, which is what the blog post was alluding to. - What happens if I have an SQS Lambda with 100 concurrency and a few of the containers get into a bad state? Do the other ones keep going or does the whole thing grind to a halt? - What happens if I have a Lambda that consumes from 50 Kinesis shards and some of the containers get into a bad state? - What happens if my Lambda throws an exception, what happens to my SQS message or Kinesis record? If you outsource the plumbing you can't actually test the system locally you can only test "units" of it and in a lot of cases you either have to do remote tests with print debugging to figure out what's going on or what is more common is blindly assume the plumbing works how you intend, ship it to Prod and then fix problems as they occur.
    - rualca 6y ago
claudiusd 6y ago
Completely agree. Most of the criticism I've seen comes from people who don't have a good grasp of the platform or tools, or haven't adapted their style to the "serverless mindset". There's definitely a new technique I've had to teach myself in order to build serverless systems effectively. Today I'm getting great results from the approach.
- Dunedan 6y ago
  Yes, absolutely. And to be honest to get started with it for a software developer which doesn't have any "cloud" experience is pretty rough. Suddenly that developer needs to have a understanding of AWS in general, IAM, CloudFormation and all the services which can be utilized to avoid having to write custom code. It's a steep and long learning curve.
  - s_fischer 6y ago
    Fully agree. The problem gets even worse at bigger orgs where there's a separate, security oriented, team which is responsible for setting/managing IAM roles and KMS keys. I think the AWS ecosystem can be very discouraging for younger engineers in these situations. A innovative PoC in your downtime seems a lot more daunting when you need to learn about 4-5 AWS services that are unrelated to code execution and you have make a request to devops for a new IAM role just to locally test out a prototype that you built over the weekend.
- zerubeus 6y ago
  I'm just really sad reading all this comments, knowing that some people will take the decision based on them, PLEASE DON'T, most of the commenters have no idea about what they are talking about.
sheeshkebab 6y ago
If you ever dealt with cloudformation you’d know it’s absolutely enormous PITA. There might be no “silver bullet”, but aws serverless is like rusted bucket.
- Dunedan 6y ago
  > If you ever dealt with cloudformation you’d know it’s absolutely enormous PITA. Is it? For me it's working fine. What problems are you facing when writing CloudFormation templates and what better alternative to declare infrastructure do you suggest? Most problems I see are people being not aware of the possible attributes of resources or doing indentation mistakes when it's a YAML template. Most of these problems can be avoided by using cfn-lint [1] to ensure the template is valid. [1]: https://github.com/aws-cloudformation/cfn-python-lint https://github.com/aws-cloudformation/cfn-python-lint
  - nitrogen 6y ago
    Going from something like Puppet with a few VPSes to CloudFormation with serverless is a huge jump in complexity and boilerplate.
  - dmarinus 6y ago
    CloudFormation is slow (custom resources take hours to time out), it's unpredictable (behavior is different for different services). I wish it didn't use stacks (drift happens and can only be fixed manually) and was just idempotent like ansible. It also doesn't come with sane defaults so you have to supply a load of boilerplate code (cdk fixes this using constructs).
- mxz3000 6y ago
  Totally, cloudformation is terrible and verbose. [Cloud Development Kit](https://aws.amazon.com/cdk/ https://aws.amazon.com/cdk/) however, is superb.
nitrogen 6y ago
One of AWS's major flaws is that it provides an encouraging UI that almost begs new teams to create a special snowflake manual configuration. The AWS UI should ideally be refactored to be a frontend for an infrastructure as code service like CloudFormation. One of the other problems with AWS+CF though is that it doesn't support every option from every service, e.g. populating secrets was a hassle when I used it.
- hodgesrm 6y ago
  Why wouldn't Terraform be sufficient? I use Terraform to manage real deployments, but the UI is very useful to scan the environment. This is partly because the aws-cli is so awful^h^h^h^h^h hard to use as an interactive tool.
- Dunedan 6y ago
  I like that AWS offers the management console. It can be great for quick prototyping and checking out new services where you don't know yet what to expect. An absolute no-go however is that the management console sometimes uses functionality which isn't available as an official API! One of the most prominent examples for that is probably that the management console does support U2F tokens, while the official API doesn't [1]. CloudFormation lagging behind in terms of features is mainly a matter of priorities and I agree, feature parity from day 1 on would be great. However the way they do it allows them to ship features more quickly, so that's something as well. In the past CloudFormation support was even worse as the CloudFormation team was responsible for implementing the support for new features of all services in CloudFormation. And with an ever growing list of services and features, that was something which simply didn't scale. From my understanding that changed however, so that most service teams are now responsible for CloudFormation support of their service themselves. > One of the other problems with AWS+CF though is that it doesn't support every option from every service, e.g. populating secrets was a hassle when I used it. That's because creating a secret in AWS Secrets Manager is not a control plane operation (which is what CloudFormation usually implements), but a data plane operation (which CloudFormation usually doesn't implement). However in this particular case it has been apparently painful enough, as creating secrets can be necessary to be able to deploy other resources (e.g. for authentication to the Aurora Data API), that AWS implemented this data plane operation in CloudFormation [2]. The same is true for creating parameters in the SSM Parameter Store [3], while it's still not possible to create objects in S3 or items in DynamoDB without custom CloudFormation resources. [1]: https://github.com/aws/aws-cli/issues/3607 https://github.com/aws/aws-cli/issues/3607 [2]: https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-resource-secretsmanager-secret.html https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGui... [3]: https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-resource-ssm-parameter.html https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGui...

alerighi 6y ago

The impossible to replicate the production environment I think was referred to impossible to replicate locally, on your machine. At my job I use AWS serverless services and I get a lot of frustration not being able to test and debug code offline. Having each time to upload some code to debug it is time consuming. Also you have to rely only on logs to debug, you obviously cannot use a debugger, and thus the solution is to insert a ton of print statements in the code and remove them, which is not a problem to me (I usually do that even in code that I debug locally) but the service to read these logs (ColoudWatch) is not great at all, you don't even have all your logs in one place, it's a mess. I think serverless is overrated, sure it maybe the right tool for a simple project, but when the complexity grows it's best to use other more classical solutions.

k__ 6y ago
Thundra offers online and offline debugging. Also, AWS SAM CLI allows to run things locally.
rualca 6y ago
> At my job I use AWS serverless services and I get a lot of frustration not being able to test and debug code offline. AWS's Serverless Application Model explicitly supports local testing. https://docs.aws.amazon.com/serverless-application-model/latest/developerguide/serverless-sam-cli-using-debugging.html https://docs.aws.amazon.com/serverless-application-model/lat... Which problems did you experienced?
- vp8989 6y ago
  "AWS's Serverless Application Model explicitly supports local testing." It doesn't provide any additional capability that was already there. Ie, I could already run my arbitrary function from the CLI by building a simple wrapper that reads a JSON file and sends it in. Or wrap it in a simple HTTP server. The debugging story using that tool is worse than how I would already do it pre-SAM and they don't even have documentation for every runtime they officially support: https://docs.aws.amazon.com/serverless-application-model/latest/developerguide/serverless-sam-cli-using-debugging.html https://docs.aws.amazon.com/serverless-application-model/lat... It doesn't allow you to test any of the interesting bits, which is what the blog post was alluding to. - What happens if I have an SQS Lambda with 100 concurrency and a few of the containers get into a bad state? Do the other ones keep going or does the whole thing grind to a halt? - What happens if I have a Lambda that consumes from 50 Kinesis shards and some of the containers get into a bad state? - What happens if my Lambda throws an exception, what happens to my SQS message or Kinesis record? If you outsource the plumbing you can't actually test the system locally you can only test "units" of it and in a lot of cases you either have to do remote tests with print debugging to figure out what's going on or what is more common is blindly assume the plumbing works how you intend, ship it to Prod and then fix problems as they occur.
  - rualca 6y ago

claudiusd 6y ago

Completely agree. Most of the criticism I've seen comes from people who don't have a good grasp of the platform or tools, or haven't adapted their style to the "serverless mindset". There's definitely a new technique I've had to teach myself in order to build serverless systems effectively. Today I'm getting great results from the approach.

Dunedan 6y ago
Yes, absolutely. And to be honest to get started with it for a software developer which doesn't have any "cloud" experience is pretty rough. Suddenly that developer needs to have a understanding of AWS in general, IAM, CloudFormation and all the services which can be utilized to avoid having to write custom code. It's a steep and long learning curve.
- s_fischer 6y ago
  Fully agree. The problem gets even worse at bigger orgs where there's a separate, security oriented, team which is responsible for setting/managing IAM roles and KMS keys. I think the AWS ecosystem can be very discouraging for younger engineers in these situations. A innovative PoC in your downtime seems a lot more daunting when you need to learn about 4-5 AWS services that are unrelated to code execution and you have make a request to devops for a new IAM role just to locally test out a prototype that you built over the weekend.
zerubeus 6y ago
I'm just really sad reading all this comments, knowing that some people will take the decision based on them, PLEASE DON'T, most of the commenters have no idea about what they are talking about.

sheeshkebab 6y ago

If you ever dealt with cloudformation you’d know it’s absolutely enormous PITA. There might be no “silver bullet”, but aws serverless is like rusted bucket.

Dunedan 6y ago
> If you ever dealt with cloudformation you’d know it’s absolutely enormous PITA. Is it? For me it's working fine. What problems are you facing when writing CloudFormation templates and what better alternative to declare infrastructure do you suggest? Most problems I see are people being not aware of the possible attributes of resources or doing indentation mistakes when it's a YAML template. Most of these problems can be avoided by using cfn-lint [1] to ensure the template is valid. [1]: https://github.com/aws-cloudformation/cfn-python-lint https://github.com/aws-cloudformation/cfn-python-lint
- nitrogen 6y ago
  Going from something like Puppet with a few VPSes to CloudFormation with serverless is a huge jump in complexity and boilerplate.
- dmarinus 6y ago
  CloudFormation is slow (custom resources take hours to time out), it's unpredictable (behavior is different for different services). I wish it didn't use stacks (drift happens and can only be fixed manually) and was just idempotent like ansible. It also doesn't come with sane defaults so you have to supply a load of boilerplate code (cdk fixes this using constructs).
mxz3000 6y ago
Totally, cloudformation is terrible and verbose. [Cloud Development Kit](https://aws.amazon.com/cdk/ https://aws.amazon.com/cdk/) however, is superb.

nitrogen 6y ago

One of AWS's major flaws is that it provides an encouraging UI that almost begs new teams to create a special snowflake manual configuration. The AWS UI should ideally be refactored to be a frontend for an infrastructure as code service like CloudFormation. One of the other problems with AWS+CF though is that it doesn't support every option from every service, e.g. populating secrets was a hassle when I used it.

hodgesrm 6y ago
Why wouldn't Terraform be sufficient? I use Terraform to manage real deployments, but the UI is very useful to scan the environment. This is partly because the aws-cli is so awful^h^h^h^h^h hard to use as an interactive tool.
Dunedan 6y ago
I like that AWS offers the management console. It can be great for quick prototyping and checking out new services where you don't know yet what to expect. An absolute no-go however is that the management console sometimes uses functionality which isn't available as an official API! One of the most prominent examples for that is probably that the management console does support U2F tokens, while the official API doesn't [1]. CloudFormation lagging behind in terms of features is mainly a matter of priorities and I agree, feature parity from day 1 on would be great. However the way they do it allows them to ship features more quickly, so that's something as well. In the past CloudFormation support was even worse as the CloudFormation team was responsible for implementing the support for new features of all services in CloudFormation. And with an ever growing list of services and features, that was something which simply didn't scale. From my understanding that changed however, so that most service teams are now responsible for CloudFormation support of their service themselves. > One of the other problems with AWS+CF though is that it doesn't support every option from every service, e.g. populating secrets was a hassle when I used it. That's because creating a secret in AWS Secrets Manager is not a control plane operation (which is what CloudFormation usually implements), but a data plane operation (which CloudFormation usually doesn't implement). However in this particular case it has been apparently painful enough, as creating secrets can be necessary to be able to deploy other resources (e.g. for authentication to the Aurora Data API), that AWS implemented this data plane operation in CloudFormation [2]. The same is true for creating parameters in the SSM Parameter Store [3], while it's still not possible to create objects in S3 or items in DynamoDB without custom CloudFormation resources. [1]: https://github.com/aws/aws-cli/issues/3607 https://github.com/aws/aws-cli/issues/3607 [2]: https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-resource-secretsmanager-secret.html https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGui... [3]: https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-resource-ssm-parameter.html https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGui...