homepage VS Moto

I highly recommend, with these types of credentials, go serverless and use https://sst.dev/ with https://nextjs.org/ . Stupid simple deployment, and SST’s (reasonably priced) paid arm, https://seed.run/, for ci/cd and deployment including great stage management, and nearly free logging and error observability.

I've used seed.run with the Serverless Framework for 4-5 years. As I don't deploy to much I've stayed with the free tier and it all works perfectly. Try it out it won't disappoint.

They have, at least SST, visit seed

The backend is built with serverless.com (lambda, dynamodb, sqs, appsync). The good thing is that all the backend is stored in a file and you can deploy multiple stacks on the same account using seed.run . You don't really need EC2/Fargate when you have lambdas and you know that most of the time will be idle time. The same with cache I wouldn't think of it right now until you see the workload you are facing. Dynamodb once you understand it and have a proper design it's the fastest thing you can have. On my appsync calls I'm using Dynamodb as a cache because it's cheaper...

I run my personal project on AWS. I has been running for 4+ years now and I never had a local environment. I took the serverless route. That is appsync, lambda, dynamodb, sqs to build the stack. I'm using serverless.com to have all the resources defined in a yaml files which will deploy multiple stacks. I'm using seed.run to manage that part because it's much more simple than to do it manually.

How do you deploy your services on AWS? I'm a solo developer and have no issues with my backend. I use the Serverless framework so all services, lambdas, configurations is on a repository on git. I do all the deploys to a dev environment where I test my code and later on I deploy with a PR to my prod environment thanks to seed.run.

Your repo setup can look different, but the general concept still holds true. You have to figure out if a file change affects an individual service, or if a file change affects all the services. The advantage of this strategy is that you know upfront which services can be skipped. This allows you to skip a portion of the entire build process, thus speeding up your builds. A shameless plug here, Seed supports this and the setup outlined in this post out of the box!

I use serverless.com framework with tests and deploy with seed.run. So I don't ever touch a Lambda in production. I also have 2 environments, one for testing and the other for production.

I'd use seed.run . You can deploy multiple stacks on parallel or with dependencies. You can deploy from github ( 100% sure ) from gitlab I'm not sure. Worth checking it. I'm using the service for free and haven't had any issue.

Building on top of it requires some knowledge but for me it has been worth it. I use serverless.com to manage all the infrastructure as a CF template. This has the benefit that I can deploy multiple test environments at will. I'm also using seed.run to do all the CI/CD ( also for free ) and doing all the monitoring with lumigo.io . And I build single pages applications that use Netlify.com to handle at that part. I do it to avoid less things to manage on AWS directly when the service is free (again) and really easy to use.

> OpenMoto

I dunno if you're trying to play on "hashimoto" but https://github.com/getmoto/moto#readme would be a prime name collision for any such "OpenMoto" name

But yes, please, to adopting Vault. I don't have a horse in the race about Consul but my suspicion is such an effort would only be worthwhile if trying to adopt Nomad, too, which I gravely doubt

Unfortunately I do not believe AWS provides any "test" gateways. I do know there are mock AWS servers you can run on your own. The one I use is called Moto. It does not cover everything (unfortunately it's the most comprehensive out there AFAIK), but it's decent enough to test most standard calls via the sdk. I'm not sure if it covers authorization though...we tend to use security roles on tasks for authorization.

If using Python use Moto to mock AWS Services

You can use a library such as moto https://github.com/getmoto/moto

The Pythonic motto library mocks AWS services, removing the need to deploy your application or pay for API calls against AWS services. Other programming languages have their motto implementation.

Has anyone managed to configure moto (https://docs.getmoto.org/en/latest/) in a docker container in the similar way LocalStack does?

As for mocking, you can take a look at the moto library for mocking the AWS SDK, or for more simple cases even just use a `unittest.Mock/MagicMock` object. If you're having trouble trying to use the mocks in your code, it's a good sign your code is too highly coupled and it'd pay to re-factor, for example using dependency injection, design patterns like adapter/facade etc. (but don't over-do it)

To add on to the integration tests point, for mocking out your AWS resources you should check out moto if you don't want run your test against real AWS resources as they may cost you and is usually slower.