Comment by Dunedan | Hacker News Reader

Comment by Dunedan | Hacker News Reader

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

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.

Thundra offers online and offline debugging.

Also, AWS SAM CLI allows to run things locally.

> 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/lat...

Which problems did you experienced?

"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/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.

> It doesn't allow you to run all the other services like DynamoDB, SNS, S3, etc. locally.

Sounds like you're mixing up how a test pyramid works.

AWS SAM supports running unit tests locally. Your remarks refer to integration tests. Integration tests are expected to be performed on environments that mimic either subsets of the production environment, or the whole production environment.

https://docs.aws.amazon.com/whitepapers/latest/serverless-ar...

What about manual tests? You know, just running the app on your machine and check if it works/how it works.

You're forced to either share the aws resources with other devs or provision separate resources for each dev which is a big PITA.

As long as you use terraform/cloudformation/sam, it should be fairly simple. You deploy everything with your name as a suffix. Most of the resources will be billed on usage only as well, so you don't even pay more than a few cents for testing like that.

It’s only an “integration” test because you split things up too much. In a monolith, it would all be unit tests against a mock DB.

SAM is able to run AWS Lambda functions locally and to emulate some API Gateway behavior. It doesn't allow you to run all the other services like DynamoDB, SNS, S3, etc. locally. As Serverless applications often rely on such additional AWS services, the ability of SAM to run AWS Lambda functions locally doesn't really help for running such applications locally.

You guys don't even take the time to do a simple search... https://docs.aws.amazon.com/amazondynamodb/latest/developerg...

You can have pretty much all the services locally if you want you can even have a step function locally

DynamoDB and AWS Step Functions are notable exceptions to the fact that AWS services are usually not available locally. The vast majority of AWS services isn't available outside of AWS.

I have a local tool for every AWS service just tell what are you looking for, for example I use https://github.com/softwaremill/elasticmq to emulate SQS locally

There's also https://github.com/localstack/localstack for the heavier services.

I agree. Iteration speed and the ability to debug applications are the biggest downsides for me as well when developing Serverless applications.

To make debugging at least a bit easier, I prefer doing structured logging (e.g. by utilizing AWS Lambda Powertools [1]) to get the ability to query the logs efficiently with CloudWatch Insights [2]. Also AWS X-Ray [3] is really valuable to understand how a Serverless application behaves.

[1]: https://github.com/awslabs/aws-lambda-powertools-python

[2]: https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/Ana...

[3]: https://aws.amazon.com/xray/

> At my job I use AWS serverless services and I get a lot of frustration not being able to test and debug code offline.

For my purposes debugging is as simple as crafting a payload and feeding it through the handler locally. I match credentials locally with what my lambda runs as. Since it’s a monolith function it behaves basically the same way, including the usage of a debugger.

To make life a little easier any time there’s an exception it persists that ordinal payload so I can just replay it locally.

But I agree that serverless is mostly overrated for most use cases.

Ugh, I rewrote my serverless service for exactly these reasons. It felt magical the first time where you can deploy a service without spinning up a server so I put up with all these annoyances. But then docker gains popularity and suddenly there is no practical advantage in using serverless anymore, at least for me. I rewrote the service in django, packaged it as a docker image, then run it on any platform that can run docker.

On the other hand, I use cloudflare worker on a bunch of my projects. Unlike aws serverless, cloudflare worker is actually useful because it can do many things that can't be done by traditional backend, such as running and intercepting requests on the edge servers that sit between your server and your visitors.

What you do with CloudFlare Workers can be done on AWS with Lambda@Edge [1].

[1]: https://docs.aws.amazon.com/lambda/latest/dg/lambda-edge.htm...

I can't comment on lambda@edge as it wasn't available when I was still using aws lambda a few years ago. My current use case is probably supported on lambda@edge if I were still on aws as I'm mostly only use them to implement smart caching and routing.

I think you never heard about SAM/Serverless Framework, this is why you suffer.

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.

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.

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.

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.

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.

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.

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

[2]: https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGui...

[3]: https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGui...

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.

> 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

Going from something like Puppet with a few VPSes to CloudFormation with serverless is a huge jump in complexity and boilerplate.

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

Totally, cloudformation is terrible and verbose. [Cloud Development Kit](https://aws.amazon.com/cdk/) however, is superb.

Reply on news.ycombinator.com