Huh. One of the biggest 'drawbacks' of using AWS as a production platform is that making your development environment look like production is hard.
Having to deploy to test is cumbersome and having a cost associated with each test can definitely introduce some sort of 'stress' and encourage people to not test incrementally.
I wonder if this changes that.
Having services like S3, Lambda and SQS available locally sounds super interesting.
I will definitely keep an eye on this.
One other thing I would like to see is CloudFront, which can be very hard to start with due to its opaqueness.
Having to wait 20+ minutes between configuration changes is very demotivating.
Minio is awesome, I use it in production to store many TBs of data and never had any issues. The clustering functionality could use some additional work (or I just havn't understood it right) and it would be nice to be able to generate multiple keys/users.
Out of curiosity how have you found the performance of clustered Minio? I've been checking out Riak S2 but the simplicity of Minio is attractive. Thanks!
Ah. I stand corrected. I'm leery of their consistency model in that mode, but could just be that I haven't dug into it far enough to make sense out of it.
GitHub has become the defacto standard place for open source. I've heard it said that if you care about contributors or users of open source, you should publish to GitHub even if that's not where you develop it. I guess Atlassian have realised this too...
I understand what you're saying and unfortunately it's true but it's also silly because Gitlab, Bitbucket and others can use Open Auth APIs to make contribution easier. I for example use Google Auth on Gitlab but Github didn't have that back when I signed up. If they did I would have used it there too.
I guess GitHub got mindshare early and then became the entrenched option. So its less about technical merits than not, although anecdotally, while GitHub has its flaws, in many ways I prefer its UX to that of GitLab and Bitbucket. For example, Bitbucket's overview page isn't very useful to me at all and yet its the default repo page.
Am I missing the documentation somewhere? I see directions for setup and installation but nothing about what's supported for each mock. Obviously they haven't rebuilt all the service from scratch to run on my local machine, so what can I do here? If I create an S3 bucket will the API return that bucket in my next ListBuckets call? If so, is that persistent? Etc.
My concern with relying on things like these for testing is they're not supported by AWS, so behaviours can easily diverge without you realising.
I think we've got a lot of mileage in the past out of just mocking request/responses when testing AWS interactions. The only time we've ever used a pseudo-service was when testing against the dynamoDB JAR they provide with the SDK.
That is my first concern as well but testing and bug counts are not an all-or-nothing thing. If something like this can reduce bug counts in a complicated distributed system while reducing costs vs testing against "the real thing" it still may very well be worth it.
I've tried localstack once a few months ago to mock SQS and found it really slow to boot, had a pretty high memory footprint, crashed very often (was running inside their official docker container I recall), and lacked documentation.
If you just need to mock SQS, I recommend using elasticmq. I've used it for a few months now and haven't had any problems at all so far.
Looks interesting, so far we've been using elasticmq[1] (SQS) and s3rver[2] (S3) to do e2e integration testing on local and staging. We spin them up using azk[3].
This looks excellent, I used moto to do some unit testing of a Python application and was wondering if anything existed to make unit testing other codebases easier. There's always the risk of diversion from AWS resources but I think it's a small risk, generally AWS seems to stay fairly consistent for legacy when new features are introduced.
If you want to learn the ins and outs of AWS i would recommend using the real thing. You can always create a new account when you have something in production and want to take advantage of free-tier pricing.
Having to deploy to test is cumbersome and having a cost associated with each test can definitely introduce some sort of 'stress' and encourage people to not test incrementally.
I wonder if this changes that. Having services like S3, Lambda and SQS available locally sounds super interesting.
I will definitely keep an eye on this. One other thing I would like to see is CloudFront, which can be very hard to start with due to its opaqueness. Having to wait 20+ minutes between configuration changes is very demotivating.