Hacker News Reader

Comment by msoad | Hacker News Reader

Can we stop using YAML for configuration and instead use a real programming language with possibly a type interface and a compiler? So much time wasted looking up possible configurations and worse, learning that some configuration will conflict with another.

View on HN

Done! This project can be deployed with YAML or programmatically w/ Javascript.

Here is an example of a full Chat Application that demonstrates how you can provision and extend this Serverless Realtime Application Component programmatically, very much like a React Component.

https://github.com/serverless-components/ChatApp/blob/master...

The purpose of CloudFormstion is not to tell AWS how to do something it’s to tell it the end state. How do you propose using a programming language where you can just change a resource and let the system figure out current state -> desired state and decide what needs to be created, updated, deleted, replaced?

But there are CloudFormation Linters.

https://marketplace.visualstudio.com/itemdetails?itemName=kd...

And there is also the CF editor for Visual Studio.

https://docs.aws.amazon.com/toolkit-for-visual-studio/latest...

CloudFormation YAML being terrible is well known, to the point that AWS did precisely what that person suggested.

https://github.com/awslabs/aws-cdk

They are in the process of releasing a kit to define your infrastructure programmatically, and let them deal with the mess of CloudFormation as a compiled IR they send to their backend when you deploy.

That’s not what CDK does:

You’re still defining your resources declaratively - just with type checking - at least if you’re using a statically typed language. If not, you’re still just getting runtime errors when you run your program. It might catch some things before you run your template - but so will a linter.

Neither will catch issues like using a subnet that doesn’t exist or using an AMI that doesn’t exist.

> Neither will catch issues like using a subnet that doesn’t exist [...]

The CDK does: you’re either explicitly bypassing the safety checks, are explicitly importing a value (which necessarily is validated at runtime), or have to provide a subnet definition to instantiate the relevant object.

You then use these programming language constructs to implement higher level ideas like applications, fully in a programming language.

Serverless Components keep track of all the resources it creates/updates and their properties locally in the .serverless directory. It also keeps it synced with the actual state of the resource on the provider (in case you've changed them in the console for example)

So if you change the configuration, the component will be able to figure things out.

Does Serverless handle all of the AWS resource types that you may need for your lambda?

You can write your own component that handles whatever service you need and share it with the community. The more components that are built, the easier it'll be to write higher level components that use those.

As of today, those are the available components:

https://github.com/serverless-components

I’ll be the first to admit that most of the missing resources would be useless for lambda. There are a few missing ones that might matter.

https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGui...

@scarface74 Let us know what you need. We have about a dozen more coming out within the next week.

@scarface74 We have three projects. Here's how they may be helpful to you:

1) Serverless Framework

The Serverless Framework enables you to provision serverless applications in a Function + Events pattern. Using this, you can accomplish the patterns you're describing, and hundreds of thousands of people are doing this already with the Framework.

https://github.com/serverless/serverless

2) Serverless Framework Enterprise

SFE works with the Serverless Framework to give you more than development and deployment convenience. SFE focuses on other phases of the serverless application lifecycle, like monitoring, alerting, security, collaboration, secrets and much more. It's a powerful solution for teams and orgs investing more in serverless application development.

https://serverless.com/enterprise

3) Serverless Components

This is a new take on serverless application development. We've learned the serverless community and teams are looking for ways to deploy and share composable architectural pieces (features, use-cases), more than infra. So we're building a new type of provisioning system to enable this. The Realtime Application Component is an example of this.

https://github.com/serverless-components/RealtimeApp

Most of the lambda related things I do are backend ETL and message processing.

Is Serverless just for API use cases or does it support other event triggers like SNS and SQS or one of the patterns we use is

S3 Event -> SNS -> SQS -> lambda and all of the related permissions and subscriptions.

But then again, isn’t the whole purpose of using Serverless instead of SAM to be cloud vendor neutral? Once you add AWS specific resources doesn’t that go against the whole ideal of using Serverless?

I heard a good reason why we shouldn't use a programming language for configuration as it can lead to incredibly custom setups that can be crazy difficult to upgrade or for new developers to understand what's going on.

this could be used programmatically as well via Serverless Components. However, if your configuration is simple, that's what YAML is made for.

That exists for AWS:

https://github.com/awslabs/aws-cdk

Reply on news.ycombinator.com