emrahsamdan

Yes depending on which connector you chose to connect. There could be a new PR on GitHub, a rollback in CircleCI or a feature flag switch on LaunchDarkly. All waits for a human to chime in by default.

These are all becoming tablestakes, imo for any AI SRE. The real moat is to build the data layer in an efficient manner so that the investigation (and mitigation) is fast and cost-efficient. The models are making it easier for any company at the same time.

Running the test takes around 5-6 hours per vendor depending on how much wrestle it requires (not every system is ideal for ai agents - including ourselves) but the actual work was to come up with the real world scenarios and what would be the expected RCA and remediation for this. Our own SRE team worked for 1.5 weeks for that.

how does it compare to AWS' Application composer?

Serverless Inc. makes a similar attempt for this: https://www.serverless.com/cloud

There are thousands, if not millions, of developers, now using serverless to build real-life customer-facing applications. As in the whole new tech, it gets adopted for non mission critical apps first between 2016-2018. Starting with 2019, more and more companies adopted the technology and the Cloud providers, especially AWS, invested heavily to improve the integrations and remove the roadblockers. See how Lego has moved the whole e-commerce app into serverless. https://medium.com/lego-engineering/accelerating-with-server...

I also strongly believe that severless is an overloaded term and everyone understands something different from it. Some people consider this only as a FaaS but I think that it's any cloud service, that can auto-scale to infinity, scales to zero, pay-per-use and managed. I frankly believe Serverless should be regarded as a paradigm rather than a technology advancement. here's a very nice blog about it: https://ben11kehoe.medium.com/serverless-is-a-state-of-mind-...

Serverless as a term mixed up with FaaS. In 2022, Serverless is more general as it can be defined anything that autoscales to infinity and scales to zero when not used and pay per use. Amazon DynamoDB is also serverless in that sense for example.

I don't know what would be the use case for a HTTP endpoint that return 59 minutes later but this seems interesting.

Congrats Or Weis! I have been following Permit.io for a while it's no surprise that your efforts just paid off. Way to go!

Not sure if it's what you really want to see but there's a new solution called Serverless Cloud that lets you write only code in JS/TS. This platform handles the infra management itself. It has frontend sync, global CDN, secret management, event-driven design possibilities. https://www.serverless.com/cloud/

Not working for me (Turkey)

The next AWS will be built on AWS, a wise man said one day.

A very nicely curated list. If you're still in search of dealing with cold starts, Thundra also provides a warm-up plugin that helps you keep your serverless functions warm. https://github.com/thundra-io/thundra-lambda-warmup

Hey! We have made our first webinar! It includes a demo showing solving a real life problem in Java with RDS.

You can watch it here: https://www.youtube.com/watch?v=bmAw24uquK0

You are right about lack of observability tools for AWS Lambda. Thundra was born because of same maddening at our side. You have very solid questions that we are enthusiastic to tell more and more:

1) Automatic instrumentation is what creates no code change. Once you add Thundra to your environment variables, you can change the monitoring settings with annotation or additional environment variables with no code change for Java. For Node.js and Go, You simply wrap your functions with our agents. With manual instrumentation on the other hand, you can also add code blocks to inspect your variables.

You can check our codes here: https://github.com/thundra-io. We are open to share more, if you want any further questions.

2) Zero overhead is one of other strong points of us. You need to switch to async. monitoring for this. This means you need to add "our" lambda to your environment variables (Please check for it: https://github.com/thundra-io/serverless-plugin-thundra-moni...). Then this lambda sends logs of your function to us. Overhead of sending and retrying for failed logs will not happen. Only overhead can occur because of make your code to gather more logs for our lambda to read. But this is truly negligible.

Sorry for make you sad but Thundra is a bird. Inspired by Thundra (a.k.a queen of rainforest :)) in Aladdin: http://disney.wikia.com/wiki/Thundra.

Thanks for giving a try! We are here to continuously improve our product with your feedbacks. What specifically can you recommend to improve our UI?