Some web developers avoid systems work like the plague. I can understand a developer’s reluctance to take a position that comes with systems responsibilities. Systems roles usually come with thankless maintenance work and after hours on-call duties. It’s the kind of work that gets you reprimands when services are unavailable but goes otherwise unnoticed when things are running smoothly.
So why do developers need to worry about systems? Because we’re increasing the complexity of our apps with new development platforms, single-focus software solutions, and interconnected cloud services. These new tools help us release features faster and make our applications more reliable and performant. But with every extra bit of complexity we’re adding new infrastructure demands to support our apps.
There’s a shift well underway from scaling up applications with expensive hardware to scaling out by using varied, distributed, on-demand computing and storage services. It’s no longer acceptable to expect a systems support team to setup a blind environment for deployment. And it’s not reasonable to expect someone else to work out our software configuration issues manually. Systems have to become part of our software planning process. Our applications have to be built with stock platforms in mind to make sure we can take advantage of horizontal scaling.
Automation is the oil that will keep all these interconnected pieces running smoothly. Whenever I find myself doing something twice, it’s time to consider scripting it or finding a tool that fits the need. There’s a time hit to setting up the first time but the consistency that automation adds is almost always worth the effort.
The more systems tasks that we can automate as developers, the more systems folks are freed up to innovate in their world. Less maintenance and fretting over our customizations means more time spent on performance optimizations, strengthening availability, and exploring innovative platform and service options. That’s where systems teams can add a huge amount of value to an organization.
So what can we do as developers to dig into systems?
Virtualize, now. Install a virtual machine using an unfamiliar OS on your desktop. Set up two. Get used to how they interact with each other. VirtualBox is free and rock solid. Pick a linux distro and run the installation while you code.
Setup continuous integration for yourself. Setup a deployment environment in one of your new vm’s. Get a project automatically deploying from source control. Check out Hudson, TeamCity, and Cerberus
Setup a sandbox environment that mirrors production. If your production environment is clustered, make sure you have a dev environment that is too. Feel the pain points early and capture solutions as reusable code.
Sign up for a cloud service account. Deploy a throw-away app on an unfamiliar system. Get a feel for how deployment works on different cloud systems. You’ll discover techniques you can work into your own platform. Try setting up a simple content page on Heroku, the base plan is completely free.
None of these things require permission or changes to to your workflow to start. They do take some effort and time. But the practice will make us all better equipped developers.
In the evolving world of distributed cloud services and on-demand computing, the gulf between developers and systems folks is shrinking quickly. There will always be a need for specialists on either side. But the overlap between the two worlds is expanding and that can be a huge win for everyone involved.