In the world of DevOps – where the unlikely team of developers and operators form one unit – nothing is more important than collaboration.
We – by which I mean myself and Microsoft Technical Fellow John Shewchuk – picked Boulder, Colorado to discuss the world of DevOps because the city embodies the true spirit of a cooperative community.
After all, what is DevOps if not an exercise in cooperation and collaboration? The industry brings together developers and operators in a high-pressured environment that often results in heat and friction.
We had the opportunity to interview Gabe Monroy, CTO of Deis, about collaboration, creativity, and the future of development for an episode of Decoded. Gabe is an entrepreneur and systems architect with 20 years of experience and he’s the creator of leading open-source PaaS Deis, which has over 12 million downloads.
Here are some of the things we learned.
Keep Experts in their Fields
At the end of the day, it’s about how we can best collaborate while allowing people to do what they are best at.
If you have a team of physicists, why would you try and get them to work as biologists? There are similar rules for developers and operators. Sure, they might work together, but that’s where the similarities end.
“The most important principle of DevOps,” explained Boulder local Gabe Monroy, “is to allow developers to do what they do best, which is write code, and for operations to do what they do best, which is manage things like deployments, monitor stuff like that.”
It’s about allowing people to prioritize and focus on their strongest skills. Essentially, keep developers in development, and operation managers in operations. Allow them both to flex their skills – albeit in a collaborative way – and you’ll be sure to see better results than any attempt at trying to form a hybrid.
Efficiency is Key
The back and forth nature of DevOps means that things can take time and, under pressure, can result in frayed tempers and damaged working relationships. Things like test automation, centralized configuration management, proactive monitoring and many other practices means that processes are protected and kept moving.
Gabe explained that, until recently, delivery for software application was built on the ideas of developers writing the code before moving the software over to quality assurance (QA) before operations teams ran further tests. “The way the process worked it took forever people asked why it was taking so long,” Gabe said. “A lot of teams frankly hated each other, yelling and screaming – everything you could imagine.”
Keeping things efficient and moving smoothly is not just good for business, it’s good for team morale. Companies that play together, stay together, and the same goes for DevOps teams around the world. Reducing friction – both between teams and processes – just makes good sense all round.
Chat Ops Help
ChatOps are what DevOps people call the use of chat clients, chat bots and real-time communication tools – such as Slack, for example – to make it easier to communicate software development and operation tasks as they are being performed. Performing DevOps tasks within chat tools is an important way that developers and operators can help speed up the whole process.
“We refer to this in the industry as ‘ChatOps,” says Gabe. “Chat and chat systems like slack are where developers and operations folks tend to live, so having the notifications come to you is a lot more effective than having to go them.”
As Gabe explained to us, chat tools and systems are actually where developers and operators spend most of their time, at least in a professional sense. Chat ops have been around for a while, and the term was widely credited to the GitHub community. From a wide viewpoint, Chat Ops basically allows for real-time collaboration with less friction, meaning processes work more efficiently to the benefit of everyone.
… As does Container Technology
If ChatOps help speed up the process of actually developing software in the building process, container technology makes it easier for applications to be packaged. This in turn makes it easier to ‘transport’ source code from platform to platform, making it easier to test and ensuring a greater guarantee that, if the code worked in once place, it will almost certainly work in another.
Container technology has been around for a while but what makes it so good is that containers do not need to bundle a full operating system, just the libraries and settings required to make the software work are needed.
One particularly useful container technology application is Docker. Like similar products, Docker allows for DevOps teams to build, ship and run their applications from any location, making it easier – and more scalable – to test these products. Scalability is a big question for DevOps teams because, in most instances, apps are created for the masses. App creators hope that millions of people will download and use their new applications, so this is a must.
The Future of DevOps is Unrelenting Innovation
For Gabe and the rest of the Deis team – as well as many other DevOps teams in Boulder – the future of DevOps is one of constant innovation.
Gabe told us, “As I think about the future I think it makes sense to consider the possibility of what a ‘fly by wire’ infrastructure might look like, where developers are committing code, and testing and deployment of that code is completely automated. I’m really hoping that the tooling and automation [of DevOps] get advanced so that developers don’t have to think about anything other than writing code – they can innovate at the speed of thought.”
This would be an extraordinary step towards the future of DevOps operations, all over the world. Reducing the friction of operations – even that in chat ops, would make for a richer, more robust experience for software companies. Combined with a defined API, harmonization of developers and operators, streamlining the development process and increasing scalability will be a boon for future technological advances.
If nothing else, this proved how important collaboration between departments, programs and workers ranked in importance above all else. Now, if we can just make total collaboration a reality, the potential for developing new apps and bots could be unlimited.
This post is part of our contributor series. It is written and published independently of TNW.