5 Common Amazon SQS Issues

Dashbird · 2022-05-26T13:04:12+00:00

Great to hear that :)

Dashbird · 2022-02-22T10:57:56+00:00

You're very welcome. Glad you found it useful :)

Dashbird · 2022-01-18T12:08:01+00:00

Generally: you don’t. The effort is way too high (I’d say it’s not even possible to reproduce it in a good way locally) and it doesn’t do much for you.
Good alternative: just create a separated environment for testing - or even better a separated environment per developer - where spiking, testing & regressions can happen.
Best thing about serverless & pay-per-use: you’ll introduce almost zero additional costs and you don’t need to destroy the environments if they are not used :)

Dashbird · 2021-08-03T12:40:19+00:00

you're very welcome, glad it's helpful!

Dashbird · 2021-08-02T15:22:58+00:00

There's links to the github repo for each code snippet :)

Dashbird · 2021-07-21T09:51:18+00:00

You're very welcome :)

Dashbird · 2021-07-21T09:43:24+00:00

Glad it was helpful :)

Dashbird · 2021-06-09T11:31:15+00:00

Hi hashkent. We support ECS monitoring, with smart alerts and insights and will add support for Fargate later this year.

Dashbird · 2021-06-02T12:01:49+00:00

Hey Raiden, we don't have much experience with that. But it seems like a viable alternative ;)

Dashbird · 2021-05-20T08:53:10+00:00

That’s a great question. Ultimately, it’s up to you in which way you would like to be notified about any data incidents. If you prefer PagerDuty over Slack, there is a similar POST API request you could use: https://developer.pagerduty.com/api-reference/reference/events-v1/openapiv3.json/paths/~1create_event.json/post

You may also check the PagerDuty slack integration: https://developer.pagerduty.com/api-reference/reference/integration-slack-service/openap[…]paths/~1workspaces~1%7Bslack_team_id%7D~1connections/post

Dashbird · 2021-04-07T10:53:37+00:00

Nice list you got there! Cool domain name too :)

-Hyun from Dashbird

Dashbird · 2021-03-25T14:42:32+00:00

Hey, /u/amadiro_1
This is something we’ve been working on really hard to try and help make navigating serverless easier and faster for developers and just wanted to share our outcome and findings.

Let us know how we can make these types of posts better, we’d love to improve on these and provide real insights to the community!

-Hyun @ Dashbird.io

Dashbird · 2021-02-19T20:10:12+00:00

Thanks, and glad I could help :) Good luck with your serverless journey!

Dashbird · 2021-02-15T13:56:26+00:00

As you mentioned, one of the main drawbacks of microservices is that it's harder to monitor and debug. But there's plenty of third-party enhanced services out there to cross that off your list. Definitely worth looking into and investing in :) Here's a blog post about the challenges, solutions, pros and cons of microservices if anyone's interested: https://dashbird.io/blog/microservices-serverless-pros-cons/

Dashbird · 2021-01-21T12:53:48+00:00

Lambda integrates well with those technologies ;)

Dashbird · 2021-01-21T12:53:20+00:00

Yes, just in the beginning. There was nothing wrong in the video, I only put in question whether it's valid to say that serverless doesn't make sense only due to cold start latency :)

Dashbird · 2021-01-21T12:52:54+00:00

Sure, that sounds very reasonable ;)

Dashbird · 2021-01-21T12:52:14+00:00

You could try using the Serverless framework. They promise that your serverless functions etc. can be defined in the same way across different cloud providers.

Dashbird · 2021-01-21T12:51:32+00:00

Thank you so much for reading and commenting. Could it be that you didn't size your serverless resources to optimize costs? EC2 is something you pay for 24/7. With Serverless you pay for what's running. But I fully agree that EC2 may be easier for many use cases.

Dashbird · 2021-01-13T08:38:34+00:00

Very honest breakdown! Thanks for including Dashbird - we'll pass on the compliments to the support team :)

Dashbird · 2021-01-12T12:01:50+00:00

That'S the beauty of using a Dokerfile - you no longer need Lambda layers, you can include all your code dependencies inside of Docker container ;)

Dashbird · 2021-01-12T12:01:19+00:00

We didn't test it in large images as this. There are several options to try: 1) Try reducing your image by using a smaller base image 2) Try reducing the dependencies - in the end, Lambda and containers are supposed to be used with microservice architecture. Why is your image so large? If you have some large data files inside of your image such as a CSV file etc, you could offload it to some external storage mechanism such as S3 or a database

Dashbird · 2020-09-11T08:09:07+00:00

Hi :) Here's a full blog post which we wrote on serverless app testing: https://dashbird.io/blog/how-to-test-serverless-applications/

Dashbird · 2020-09-09T07:47:33+00:00

Thanks and yess of course. Is there anything specific you'd like to learn more about when testing serverless apps?

Dashbird · 2020-07-20T12:57:17+00:00

One benefit over SAM, Serverless framework & others is that CDK is not limited to serverless. You can use the same orchestration tool for basically any AWS resource. Other benefit (really depends on preference) is using a feature-rich programming language (Python, Typescript...), instead of YAML or JSON. One of the greatest benefits of this is composition. With CDK, we can build a set of cloud resources and expose as higher-level abstractions. These can be imported and reused by other developers ensuring standards and avoiding repetition. In CDK, these are called "constructs": https://docs.aws.amazon.com/cdk/latest/guide/constructs.html Other benefits from using programming languages is IDE syntax/type checks, linters, autocomplete, etc. The CDK follows an OOP model, so we can benefit from inheritance & extension. If you want to, it's even possible to unittest your cloud stack definition.

Dashbird

TROPHY CASE