Love DevOps? We're hiring!

FP Complete's DevOps Homepage

DevOps is a broad term covering many different topics, including tooling, team structure, and even project management. There is certainly some debate in the world as to what constitutes "real DevOps." At its core, DevOps is about one core goal: knocking down the wall between software development and systems operation.

Why DevOps?

You've been working on a new network service for the past six months. It uses a database, stores some files uploaded by users, and makes some external requests. It's accessible over HTTP. You've tested it extensively, both with a full integration test suite and manual testing with your Quality Assurance team. The big launch date is approaching. You tag a commit in your team's Git repository, and notify your operations (ops) team that it's ready to ship.

Then, as is wont to happen, all hell breaks loose.

Ops can't build the software. You spend the weekend answering Slack questions about which build tools to install, system level dependencies, etc. After a week of misery, there's a production-ready executable. Frustrated with each other, the ops and dev teams silently agree to skip repeating the process for the test suite.

Ops deploys to a production cluster... and the app doesn't work. Dev has to come in to help debug, but they don't know how to access the log files. So there's a lot of late-night requests for the ops team to grab logs and send them over. Two days later, the dev team realizes that the database has been misconfigured.

After fixing the database, someone discovers that the HTML isn't rendering correctly. That's because it's pulling down CSS and Javascript assets over HTTP and HTTPS. But the ops team deployed with HTTPS, and the browser security model is preventing the insecure mixed content. A few tweaks to the codebase, and those are fixed. And now ops gets to spend another painful four hours rebuilding the app.

The next two months are spent fixing minor issues that should have been caught by the test suite, and only appear in production due to minor differences in the dev versus production environment.

The next release ends up pushed back by two months due to all the unanticipated work. And then this process starts all over again.

How to fix it?

If this story sounds all too familiar to you, you're not alone. This is how much of the software development world has operated historically, and many continue in these practices today. The DevOps methodology is about systematically addressing the root causes to this with better tooling and better processes.

The first step to adopting DevOps and escaping this mess is: knock down the walls between dev and ops. The ops team should not be a separate team called in at the last minute. Instead, DevOps engineers have a deep understanding of both software development and operations, and should be intimately involved from the beginning of a project with:

By taking these steps at the beginning of your development cycle, you avoid nasty surprises from popping up when you're ready to deploy. You make it easier and faster to make changes. And while it may slow down the initial start to a project by a bit, those costs are quickly amortized out with the productivity gains felt by your entire team.

Tooling

The DevOps world is relatively young, and its tooling continues to evolve quickly. FP Complete provides an online DevOps syllabus and offers commercial training services to get you and your team up to speed quickly.

For a deeper dive into individual tooling topics, please see some related pages:

Who DevOps is for?

DevOps is a language-agonistic methodology. It works for compiled and interpreted languages, functional and imperative, statically and dynamically typed. We use DevOps extensively as part of our Haskell and Rust work within FP Complete. But those same practices and tools have transferred to clients working with languages like Javascript, Go, Ruby, Python, Java, and C#.

Further reading

Love DevOps? We're hiring!