This post aims to present the stack I’m currently using for my various projects and consulting clients, as well as the state of my products and services.
I’m still an avid Ruby and Rails user. In my opinion 90% of all applications are (currently) better off using the “old” server-side rendering model instead of going for single-page apps. It’s just plain easier, is not necessarily slower when architected correctly, and you will never run out of programmers to build that kind of app.
It seems to me that a lot of apps go the JS framework route because they couldn’t think of a way to do it elegantly with the tools available in Rails, and/or they want to try the new shiny. That being said, today I would probably use EmberJS if I had a strong use-case for it. I also really like the React way, but the landscape is just changing too quickly for me.
As an aside, my development environment is hosted on a remote server. I currently use tmux + vim to write code and launch commands. All my projects are using either Vagrant VMs or docker-compose to easily launch the dev environment. I find the remote server option quite nice:
- great bandwidth (especially useful with all those docker images)
- accessible from any computer/tablet with an SSH client
- very easy to test OAuth-like callbacks or share work with clients
- I get access to a lot of (cheap) power, even if one of my own machine is a (not so fast) Macbook.
- if I need more power, I can just switch to a larger server overnight, and not hesitate for ages between the configurations offered by Apple & cie.
I’ve been a Docker user since it was published about 4 years ago. I used Docker extensively in production for Packager.io to run isolated builds for packaging old-school DEB/RPM packages. In those days it would have been a folly to try to run “real” apps with Docker, but nowadays I operate multiple platforms for clients that all run of top on Amazon ECS + Docker.
In production with a lot of different apps I tend to rely on Empire to operate an on-premise PaaS on top of ECS. I currently manage 3 platforms for 3 different clients, but in the future I think Convox will be my choice. It just offers more features and saner defaults, plus it comes with commercial support.
For simpler apps I’m just happy to either use Heroku, deploy everything as a CloudFormation stack, or just
apt-get install the thing after a DEB package has been generated by Packager.io.
I used to rely a lot on Puppet to provision the servers, but deploying on top of Amazon ECS with Docker containers means that I just don’t have any use for it anymore. Everything is managed through Empire or the CloudFormation template, using the base Amazon hardened AMIs.
Did I say I really like CloudFormation? For managing stacks I tend to use
cfn-config. It’s great. I might start using Terraform at some point, but for now I’m not in any way put off by directly writing the bare CloudFormation JSON templates.
The AWS services that I use extensively are the following: VPC (obviously), S3, EC2+ELB, RDS, ElasticCache, Route53, Certificate Manager (really nice), Elastic File System, CloudWatch (logs + metrics), and CloudFormation.
Misc: I had a lot of fun recently using Traefik proxy + Let’s Encrypt to act as the main proxy in front of multiple apps deployed on ECS. Since v1.2 Traefik has a ECS connector which means your services get automagically registered with the proxy when they launch, and deregistered when they stop. Plus you get free and automated SSL management with the Let’s Encrypt integration.
Packager.io, the DEB/RPM packaging service for Ruby/Go/NodeJS/Python/PHP apps, is still humming along, although I haven’t dedicated as much time as I wanted. It’s now 4 years old in April 2017, and it seems like people still have a need for old-school packaging after all!
Chunk.io has been up since October 2012, all on a free Heroku dyno. It has seen a few clones emerge over the years, but I still like its simplicity. Plus it has a streaming feature that no one else has (I think).
PullPreview.com is a new service I launched last December, to help a client run preview environments on-demand for any branch, tag, or pull request of a GitHub repository. It took just a few days to build, since it delegates most of the hard tasks to Amazon ECS. I don’t have a strong urge to market it yet (hence the bare landing page and absence of pricing page), but that might change.
Buildcurl.com is an HTTP API to compile and retrieve binaries. I use it extensively to fetch precompiled versions of Ruby (any version) for use on Linux distributions. It has also recipes to compile recent versions of useful tools that your distribution’s package management tool may not have (e.g. aws-cli). It is using Docker containers under the hood. In the future it will likely be replaced with Barebuild instead (see next).
Barebuild.com is an experiment in running commands over SSH, that provide useful little services that I had running elsewhere. It was inspired by Gliderlabs cmd.io service, and you can find more details about the supported services in the wiki, or by running: