The background magic of present-day software development

One of my projects at work over the past couple weeks has been deploying a local copy of some sampling software to prepare for our holiday volume. This is a lot closer to ops than I usually get, and was a fun reminder of how far ops processes and tooling have come since I started my career. Here's what I had to do:

• Write a Dockerfile for the application that builds a runnable container.
• Edit a YAML configuration (the specific schema is maintained by our DevOps team) to specify CPU, memory, repository location, and some other things. This is translated into appropriate Cloudformation files by some of the DevOps team's software.
• Use a Slack command to deploy the application.
• Application is ready to use, complete with basic graphs/dashboards.

In a happy path case, this takes an hour or two and is self-service, in the sense that a developer can do everything without any work from the DevOps team. I can use whatever language or tech stack strikes my fancy; it just has to eventually build into a Docker container. ¹

Compare this to the process (such as it was) at my first "real" job, as a system administrator in higher education ²:

• Developers talk to the sysadmin team about the software: its tech stack, availability requirements, customers, etc.
• Sysadmin team identifies the appropriate server or servers to host the application, possibly provisioning new servers as needed.
• Sysadmin team installs appropriate dependencies for the software, establishes a baseline working configuration for it, commits the result to a Puppet or Cfengine config so it can be reproduced.
• Sysadmin team typically works with developers on tuning, monitoring, etc.
• Application is eventually ready to use.

This process might have taken some weeks in a common case, and was most definitely not self-service. The difference between this and my current organization is pretty stark, and that's across about a decade; not all that much time.

There are other examples that fade into the background. While I might fault my editor for taking up too many cores or too much memory, I can't fault its ability to apply static analysis to my code and flag issues (typos in variable names, rubocop offenses, etc) immediately after I create them. The observability tool supported by the sampling software I'm deploying gives me the ability to quickly answer arbitrary what-if questions across billions of data points generated by our application. So on and so forth.

Whenever I get frustrated by the software industry or the day to day as a software engineer, I try to remember these examples.

What parts of modern software development would have seemed magical to you at the start of your career? Is there a framework, a mindset, or some other thing that makes you happy whenever you think about it?

1. There are many criticisms, good and bad, of containerization, but being able to do this is pretty cool when you think about the alternative. ↩

2. This is back when system administrator was a job that one might find in a variety of places. Modern, widespread DevOps (and associated patterns) didn't exist. The term itself did exist, but served more as an umbrella for various discussion groups, IRC channels and small conferences than a widely known set of practices.  ↩