From Amazon Web Services to Digital Ocean
Amazon, I quit.
I tried, Amazon. I really did. For the last few months I tried to make it work with an EC2 instance for Gastropoda. I tried two main methods of deployment, both of which worked sporadically at various points:
- Elastic Beanstalk. Main Problem: Alongside seemingly miscellaneous issues causing EB to terminate and re-spin-up EC2 instances, it would also spin up these new instances in wrong availability zones, causing instances to not be deployed in the right zone to utilize by reserved instance.
- CodeDepoy. Main Problem: CodeDeploy was my preferred solution. It worked great. Push to GitHub and it would start a deployment. This was a bit more nitty-gritty to set up than Elastic Beanstalk, but also provided more control. However, one day my EC2 instance just couldn’t be connected to…by anything…
I ran into various problems with the EC2 instance itself regardless of deployment method. The last straw was my EC2 instance suddenly going down one day when nothing was being deployed or changed at all. Or rather, it said it was up, but nothing could connect. I tried a few different solutions and configurations, tried cloning the instance, setting up a new one, etc. Finally I got sick of it. I’ve heard great things about Digital Ocean from many sides, including the Laravel community. During this latest bout of EC2 problems @lauhakari and @niklasmodess recommended Digital Ocean again and finally I caved.
I set up a $5 droplet on DO and was fully operational by the next day. It still gives me plenty of flexibility and control, but somehow it’s just not as fiddly. I decided to try out dploy.io for autodeployment. After a pain free setup everything seems good knocking all the wood.
“We want to help”
The funny thing is that the Amazon twitter account has a couple of times told me they want to “help” when I mentioned having EC2 problems on Twitter. They recommended I post my issue on the AWS forums. While the social media response is admirable, the offer of assistance rings hollow. I have made threads on the forums and have seen others make threads - usually after one fairly speedy response from Amazon, which tends to not solve much, further communication in the thread is dropped and no more support is extended. Usually you end up solving the problem yourself or it magically resolves itself a few weeks later (which is actually what happened in the case of the last thread I created about Amazon’s GitHub autodeployment instructions failing).
I should note that I am still using S3 for this blog. But as for EC2…I think I’m done.
Gastropoda has been chugging along slowly but surely. I’m focusing on fixing bugs in the brain and the snails’ environment detection. I need to move on to racing functionality soon, but I don’t want to do that until I make sure that the main brain stuff is working as it should.
I have also added item rot. Some items (usually consumables) will rot and disappear from the jar if left in there too long. Some snails will later also be more picky about the kinds of food they eat based on its rot stage (keep in mind snails tend to actually prefer slightly rotten food).
One interesting bug I ran into recently was a weird error message about eggs not being able to hatch. They couldn’t find the jar they were meant to hatch into! After some digging it looks like the doe snail actually somehow died mid-mating, resulting in the eggs being laid in jar ‘0’ (basically the death or unassigned jar). Then when hatching the snail eggs were trying to get some jar attributes, but since it didn’t exist everything just failed miserably. I did have a check for this implemented on snail death (if a snail dies all of its unlaid eggs are meant to be deleted), but I guess there was some sort of timing issue there. I added a second check during actual hatching just in case.