> You don't have to learn systemd; you don't have to know what runlevels are or whether it was groupadd or addgroup; you don't have to format a disk, or learn h

> You don't have to learn systemd; you don't have to know what runlevels are or whether it was groupadd or addgroup; you don't have to format a disk, or learn how to use ps, or, God help you, vim. All this stuff is important and useful and none of it is going away. I have a great deal of respect for sysadmins who can code-golf their way around a unix environment. But wouldn't it be great if developers could productively provision infrastructure without having to know all of this? No. At least for small applications, Unix already has functional, established, and documented mechanisms for the vast majority of how they need to be managed. (Windows does too.) At the end of the day, I think people would be far better off learning and using those, until there is a specific documented need for some feature unique to some more powerful platform. Otherwise, you're continually paying a complexity cost for features you might never use. Going back to the author's original list of 7 questions, I run a few personal apps in AWS, and here's how I answered: > How do you deploy your application? Just rsync it to the server? I scp a JAR file to a staging directory and run an install script. The install script is pretty much standard across the handful of apps I run. > What about dependencies? If you use python or ruby you're going to have to install them on the server. Do you intend to just run the commands manually? The JAR file is an uberjar, so the dependencies are included. > How are you going to run the application? Will you simply start the binary in the background and nohup it? That's probably not great, so if you go the service route, do you need to learn systemd? I learned systemd. It gives me easy service management and a standardized way to ensure the process comes up at server startup. The service script is pretty much standard across the handful of apps I run. > How will you handle running multiple applications with different domain names or http paths? (you'll probably need to setup haproxy or nginx) I installed nginx. Took about 30 minutes. > Suppose you update your application. How do you rollout the change? Stop the service, deploy the code, restart the service? Pretty much. > How do you avoid downtime? I don't. Many small apps can tolerate small downtime windows, including the ones I run, so I don't need to worry about continual operation. If I did have to worry about that, I'd have additional things to worry about in my application design. > What if you screw up the deployment? Any way to rollback? (Symlink a folder...? this simple script isn't sounding so simple anymore) Select the previous jar file, which I will have retained. Schema migrations complicate rollback, so I keep them to a minimum, test a bunch locally, and make sure I have backups of the database taken immediately before a deployment. (So that I can roll back if absolutely necessary.) > Does your application use other services like redis? How do you configure those services? Persistence handled through an embedded SQL database, and a library I've written to managed schema migrations. For nginx and git, I have source code snapshots of the configuration, but that's only needed if I rebuild the server. (Once in over five years.) Generally, for small apps, I try to keep the dependency footprint as small as possible. (Which is pretty much the entire gist of this comment, now that I think about it.)