To be (a DevOps) or not to be?

October 26th, 2020 8 min |

gsoft-blog-DevOps-hero-202010-1840x1040

Share
this article

Author

With the rapid development of Cloud computing over the past few years, we’ve gone from hosting individual virtual machines to entire virtual servers, along with the infrastructure dedicated to software development and client-facing services. As a result, developers are looking to better understand (and even help design) the infrastructure environment in which their software operates, while IT operates and deploys infrastructure in ways that borrow heavily from software development pipelines.

As the cross-over between software development and IT operations increases, so has the importance of some best practices, known collectively as DevOps.

Share this article

Who becomes a DevOps specialist?

It’s telling that neither Pierre-Antoine nor Yohan Belval, DevOps lead and full-stack developer over at ShareGate, considers their role to be centred around DevOps itself. Unlike many agile systems that provide a complete framework for their methodology, there is no defined set of DevOps principles. Yohan doesn’t even like using the term if he can avoid it. To him, each practice needs to be investigated individually, to determine if it can really aid his team or if it will just increase the complexity of their development cycle.

GSoft-DevOps-Pierre-Antoine-Deshaies
large-quotes-left

I consider myself a Cloud specialist, not a DevOps specialist. For us, DevOps is a mentality rather than a defined role. We ensure our teams work in DevOps mode, going beyond the tools we put in place to the methods in which we work and iterate.

dash-bar
Pierre-Antoine Deshaies

CloudOps Developer at Officevibe, GSoft

large-quotes-right

So, what are we left with? At its core, integrating DevOps is simply a search for faster, more reliable tools with which to develop and support your product. It can be tackled as a radical overhaul of your entire operation, as was the case for Pierre-Antoine’s Officevibe team. They went from a traditional release train every two weeks to a cycle of continuous deployment — in which rapid iteration, micro-optimizations and experimentation, and feature switches allowed them to deploy code within minutes of it being integrated into the master branch, without sacrificing stability or security.

But it can also be done with a more conservative, methodical approach, as with Yohan’s ShareGate Apricot, where the focus was on automation and monitoring capabilities that support a more standard development cycle.

Who becomes a DevOps specialist?

If you’ve been following along, then by definition: nobody. But that’s not a very interesting answer, is it? Though we believe DevOps needs to be integrated on a team basis, there is still room for folks to lead the crossover from Dev to Ops, or vice versa. (Here at GSoft, we’re more of a software shop, so our experience has mostly been with devs learning IT magic.)

It won’t be a specialist, though. If anything, it’s the jack-of-all-trades generalist that Yohan calls to mind when thinking of the ideal candidate. That’s because they’ll need to juggle development, deployment, configuration and monitoring duties as the need arises.

Yohan’s 3 tips for aspiring DevOps leads

  • 1

    You need to be driven by an interest in infrastructure. Distance yourself from the devs who want to focus on a specialty, algorithms or best dev practices, and don’t really care where or how it gets deployed.

  • 2

    Choose a platform. For GSoft, the answer was Microsoft Azure, but make sure to get comfortable with your organization’s platform of choice.

  • 3

    Once you know your way around, it’s time to develop everything but software: the infrastructure, configs and web/security protocols that keep your product running efficiently and securely.

His own path first took him from electrical engineering to software design. He became GSoft’s expert on Microsoft SharePoint, which paired perfectly with his natural curiosity about IT infrastructure. When he made the formal move to DevOps lead after eight years at the company, he was more than ready for the role!

As for Pierre-Antoine, his team at Officevibe had been hunting for a candidate to fill a senior Cloud operations position for over a year when, as a young recruit, he took a chance, presented a plan to management on how he could evolve into the role, and has since rewarded that faith by being instrumental in leading Officevibe’s DevOps overhaul.

While they’ve come at the task from very different backgrounds, the key to their success has been making sure that the practices they integrate are perfectly suited to the needs of their team, rather than making change for change’s sake.

When is DevOps the right choice for your team?

“The boat was sinking, and it was all hands on deck to bail ourselves out of it. We survived, though, and from there we put in place the practices to ensure we’d never have to go through that again,” confides Pierre-Antoine.

They called it the Perfect Storm. Officevibe had reached a point of no return: performance was atrocious, development was slowing down, and even GSoft’s founders were coming by to share their concerns. Then, an ultimatum from our biggest client: if the performance issues weren’t fixed yesterday, they were out.

While we don’t recommend trying it at home, this Perfect Storm was also a perfect time for re-evaluation and overhaul. Our two-week release schedule was causing bottlenecks for both testing and development, so we moved towards continuous delivery. To ensure resilient code and minimize impacts on our clients, we instituted a series of feature switches, so that we could deploy releases into progressively larger testing environments. (And yes, we do eat our own dog food here at GSoft!) Automated monitoring alerts us of any performance issues within five minutes of a service going live. The list of examples could go on, but suffice it to say that, for Officevibe, this radical restructuring allowed us to navigate away from future situations like the Perfect Storm while also improving development speed and security.

But the transition towards a DevOps mentality doesn’t have to be so all-or-nothing. The project that would become ShareGate Apricot was launched with a more traditional model, and even today Yohan’s team schedules their design, development and deployment process in two-week increments.

GSoft-DevOps-Yohan-Belval
large-quotes-left

In general, I believe it’s a mistake to ‘over-engineer’ software too early in its lifecycle. We started simple, built a client base that saw potential in our product, and from there we’ve had the resources to invest in expanding operations.

dash-bar
Yohan Belval

DevOps Lead and Full-Stack Developer at ShareGate, GSoft

large-quotes-right

It’s not that they’re unaware of or uninterested in DevOps practices; far from it, in fact. This is a team that relies on much of the same performance telemetry as Officevibe, to avoid falling into their old trap. It’s a team that’s automating infrastructure creation, relying on coded configurations instead of manual inputs, which saves countless hours of work when something breaks or is lost.

Still, just because a new practice exists doesn’t mean it will automatically pay dividends. For example, Yohan does eventually want to move towards smaller, more specialized teams that will be better suited to continuous development and other practices. But it will happen along a timeline that makes sense for his team’s reality, to ensure that when it does happen they’ll actually see a benefit.

When all is said and done, why bother with DevOps?

If our teams are any example, there is no magic answer for how and when DevOps practices are right for a given team. But whether there are storm clouds on the horizon or there’s smooth sailing ahead, there is always room for improvement, productivity and reliability.

_20_31_GSoft_blogtbontb_760px X --

And we’re learning more every day. For Pierre-Antoine, seeing developers working with more knowledge of the environment in which their applications live has resulted in a better understanding of performance and stability requirements, cutting down on time spent optimizing and bug fixing.

For Yohan, more software in the Cloud means more APIs means better integration between applications, allowing one organization’s product to highlight the strengths of another, as well as providing the data to convince clients of the proposition.

And for you, we wish you the best in discovering how to leverage this new space between development and operations in ways that will most benefit your team. If this is something you’ve developed a passion for, why not reach out? We’re always looking for new collaborators.

Share this

Curious to join our dev teams?