Developing For Deterministic Deliveries

Whether you’re a developer, an operations professional, tester or an analysts, when it comes to IT - we really all want the same result. We just have different ways of getting there.

That’s what Mykel Alvis, a seasoned DevOps coach, has concluded after thousands of hours of working with all types of IT professionals. But, too often these different divisions work against each other, instead of with each other, making delivering the best product an uphill battle.

Alvis has some thoughts on how we can fix this, though - especially in a world where we 1.Cannot buy all this work.  And 2. Can’t outsource it all.

So - where do we start? At the end of course. At his 2018 All Day DevOps session, Alvis sets up where we want to end up - so that we can figure out to get there:

• Don’t promise the world and then under-deliver
• Don’t expect deterministic outcomes in complex systems
• Test rigorously
• Improve continuously

Screengrab from Alvis’s 2018 All Day DevOps presentation

In theory, you write your code, test it, version it, tag it, build it, and produce an artifact. You only use that artifact. It’s easy...except in reality, it isn’t.

From higher up, everything has a process. But that doesn’t mean everything always works the same way. Chaos is inherent, says Alvis.

With the introduction of chaos, you get to see the edges of your system.

Alvis goes on to define determinism. He defines it as “making things happen because you made certain choices previously.” But that means it’s probably complicated and error-prone, has more steps than it should, is difficult to replicate, and is too human-centric (meaning it’s not automated).

When Alvis says “deterministic,” he means “predictable.” This doesn’t mean 100% predictable—you don’t control whether or not AWS is up—but reasonably predictable is better than what many people have now.

How do we make things predictable?

There are a number of approaches we can take.

Source Control

A first step is to use source control. The idea is that there’s one copy of the source code (even in distributed VCSs) that matters, and it shouldn’t be the one on your laptop.

You need to learn to use it seriously, learn how to merge properly, and have a decent workflow. The tool you use is less important than the workflow you use. For example, not committing on the master branch is more important than whether or not you’re using GitHub or BitBucket.

Tags in source control are a great way to manage immutability. In reality, most VCSs don’t have real immutability (for example, force push in Git). But tags come close. They let you talk about specific points in time. They are a frozen moment in time.

Containers

Containers are another way of doing immutability. Alvis recommends Kubernetes to handle your container deployment.

External management systems allow you to manage the immutability of your containers. Alvis mentions systems like Cloud Formations and Atlas. He warns us that choosing such a technology is a long-term commitment.

You could roll your own, and it might work for you. But it’s difficult to maintain. Plus, it’s still a long-term commitment.

Processes

Because no one wants responsibility but the business demands accountability, Alvis recommends taking the process away from humans. Automation is key here. He calls this “robotic processes.”

This sometimes makes people angry. For example, it might build on your machine but not on the robot. This means you’ve forgotten to include something immutable.

Don’t forget—immutable doesn’t mean stagnant. If you approach it like you approach code, you can version your processes. Here’s immutability at play again. This means you can go forward to a new version but back to an older version too.

Because versioning is important, Alvis points to semantic versioning (semver.org).

Environments

Versioning environments is a little harder, Alvis admits. What this means is that you should version the thing that produces the environment.

Dependency Management

According to Alvis, dependency management is about 50–85% of your job. If you’re doing it yourself, you’re probably not doing it very well. That’s why caching-proxies were invented: Nexus, Artifactory, gem/geminabox, and the like.

Enforcement

Sometimes, all of the above must be enforced. This can be done by automation, but sometimes it means you have to speak to people and change their ways. Not always a fun job.

Alvis continues to talk about how you should try to get your workflows to be as linear as possible. This makes it easier to plug them in to existing tools, like Jenkins. So what you’re really doing is moving the process as much as possible “to the left”—in other words, putting most of it into code.

One final, but very important point, document your code and your processes!

***

Missed Mykel Alvis’s session, or want to see some other great presentations from October 17? Head over to https://www.alldaydevops.com/live and make sure you’re registered. Then, catch up on what you missed (or re-watch your favorites)!

About the author, Peter Morlion

Peter is an experienced software developer, across a range of different languages, specializing in getting legacy code back up to modern standards. Based in Belgium, he’s fluent with TDD, CQRS and other modern software development standards. Connect with Peter at @petermorlion.