Down on DevOps: What do you do when software deployment systems get in the way? That and more from the week in software engineering

You are reading "Compiler," a software engineering newsletter from LinkedIn covering the industry's top news, trends and interesting players. If you like what you see here, make sure to subscribe!

'When seeing broad angst against an implementation detail, it’s usually a symptom of a broader problem'

The software deployment trend of bringing enterprise developer teams and operations teams closer together (called DevOps) isn't always as enjoyable to work in as advertised. See, studies have shown that DevOps done properly can bring results, meaning any company worth its weight in cloud space is hopping on the train. But when not done properly, DevOps can be a developer hindrance.

I spoke to a few veteran DevOps developers about what they like and don't like about the various systems they've worked in and what changes a dev can make when stuck in a system that isn't working well.

The Q & A below has been edited for brevity and clarity.

Can you explain the best application of DevOps you've worked in? What were its largest benefits?

• Stephen G. Pope, lead software engineer at Navvy Education: I tend not to have favorites because I just want to solve the problem, and each one is different and requires different tooling, however Github/Bitbucket, Jira, Jenkins, TravisCI, Docker and orchestration platform like Rancher and Kubernetes (as well as Google and AWS) [are some picks]. I also like Digital Ocean. It really comes down to so many factors. 
• Nathaniel Avery, solutions architect at SES Corporation: My general recommendation is to use an all-in one system instead of stitching together a “best-of-breed” solution unless it’s something you feel really good about integrating, and/or the tools are just that much better.
• Only H., software engineer at Google: I like the rolling-update, and AWS is a pretty good platform to do that. You can standardize the process and reduce the side effects humans introduce.
• Daniel Kirkdorffer, senior software developer at Nortal US: I’d have to place Jenkins at the top of the list of DevOps tools because it can be used in so many ways, to manage builds, automate tests and develop build and deployment pipelines. The plugin ecosystem is diverse and vibrant, and most organizations I’ve worked at have used Jenkins. Also never underestimate the power of a UI, even in a command line-heavy world, and Jenkins would do well to maintain a user-friendly UI and not fall victim to complexity as can happen in a Jenkinsfile world. 

How about the opposite: Is there a system you've been a part of that you thought was ineffective or more trouble than it was worth? What were its pain points?

• Pope: At times some of the Docker orchestration platforms can be way overly complex for what you actually need, like Kubernetes. With simple apps you can deploy them on something like Heroku very quick and easily without a lot of headache. With something like Kubernetes, you’ll need to manage many additional pieces that you otherwise would not, and the learning curve can be steep.
• Art Lee, software engineer: [I've found] there are no entire systems that are bad, but some components choices have some bad sides. Like DataPower vs Apigee or Jenkins vs Kubeflow.
• Kirkdorffer: I would perhaps say the worst tools are often those that are roll-your-own in-house attempts to create a better tool. Typically these are buggy, have rudimentary UIs and have been developed by folks who soon leave the company for new challenges, leaving behind poorly maintained and quickly limited tools that need replacing. There is a great benefit in using actively used, well-known and supported systems that other companies are also using.
• Michael Bilberry, cloud DevOps manager at Oracle: I've seen a continuous integration pipeline setup with Chef. It worked as a quick implementation of automation but introduced limitations that made continuous delivery difficult. Things like branch and environment management/integrations meant that the simple fix needed external pieces and a lot of code to implement. At that point, a simple system such as just Jenkins would have been more flexible and allowed much more flexibility to developers and release management.

What's more important in a DevOps system: the workflow and tools associated with it, or the people on the DevOps team running it?

• Rithesh BP, DevOps technical manager at Avis Budget Group: In DevOps, people and process are more critical than tools. If people don’t follow strict processes and tools, then there is no meaning for DevOps. It will just be a regular deployment. People following processes and automating whatever is possible makes DevOps more robust. Its continuous learning and adopting and automating make DevOps more successful.
• Jordan Sissel, infosec at Elastic: When seeing broad angst against an implementation detail (Kubernetes, systemd, Docker, Ansible, etc), it’s usually a symptom of a broader problem: Are ops folks having burdens and they aren’t able to talk about them? If they talk about them, will concerns be addressed? Etc.

What would be your advice to a developer who is stuck in the middle of a DevOps system that they feel isn't working for them? How can a developer know when it's necessary to make personal changes to adapt and when it's obvious that changes to the DevOps team and system – or a change to a new job all together – are needed?

• Avery: There may be cases where the individual teams cannot pick their own tools for whatever reason. That’s a tough spot to be in and can be a productivity killer. ... It might be necessary for someone to make an argument based on facts and it would have to be more than “tool x is bad.” Velocity is a big measurement of team performance in Agile teams. If the velocity numbers are poor, that can support the point that there are technical limitations on innovation. In a more ideal setting, an organization would pre-approve a variety of tools and allow developers to pick which ones they use. Maybe the code repo (and possibly the artifact repository) has to be shared by all teams, but other tools could be swapped.
• Bilberry: Developers shouldn't have to change their entire workflow because DevOps implemented a system with no feedback. Furthermore DevOps shouldn't have to implement an overly complicated system because developers refuse to make small changes. Scoping the workflow and requirements of the project and then having all three stakeholders sign off on it should solve that problem in a way that allows harmony in the cross team environment.
• Pope: I think taking personal responsibility and a productive attitude is key here. As a developer, sometimes you do need to push yourself, understand the new tools and fully explore them so that you can take advantage of the benefits. You need to push yourself honestly to ensure you do all that you can to improve your situation.
• Kirkdorffer: If DevOps is the problem, then make the case for why a situation should be changed. Help educate teammates about the benefits of a solution, advocate a business case for automation where steps are too manual. Help people understand when a special process is worth introducing and when it becomes a hindrance, perhaps because it over-complicates a system or makes it harder to maintain. Beware of the lead developer who’s more interested in personal challenges and resume-building rather than listening to the ideas from his/her team.

Are you a software developers with some DevOps tips or opinions of your own? Leave them in a comment below.

Tech updates...

• Fedora 31 was released
• WSO2 API Manager 3.0 was released
• React Concurrent Mode was released in preview
• Windows Terminal 1910 (v0.6) preview was released

More from this week...

Do you care if your developer tools services are tracking you? Weeks after GitLab announced it would begin using telemetry products to track developers/customers and learn from the way they use its services, the company is backing out of that plan (for now), citing a negative response from its user community. "To make GitLab better faster, we need more data on how users are using GitLab," the company explained in a blog. "GitLab has a lot of features, and a lot of users, and it is time that we use telemetry to get the data we need for our product managers to improve the experience."

What do you think of telemetry products being baked into services like GitLab? Do the prospects of improving your favorite tools outweigh the downside of less privacy? Share your thoughts in a comment below.

The dream of the smart home is under attack. Can security experts save it? Over recent weeks, we've seen a rash of well-publicized and creepy hacks of popular internet of things devices. The most stirring trend among them had strangers speaking to babies through Nest cam remote takeovers. It's not great press for the growing promise of the "smart home," and it has me wondering this week about the solutions those working in the IoT software space are (hopefully) drumming up. Should two-factor authentication be mandatory for IoT accounts? How about rethinking API security to limit penetration? What other ideas are out there?

If you're a software security expert with thoughts on this, share them in a comment below.

PSA: If you haven't already removed Flash from your web development, now is the time. Google announced this week that it will stop indexing and surfacing Flash web content in its search in the coming weeks. Since the once-popular animation and interactive web browser protocol has essentially been replaced by HTML5, and Adobe said it would end support of Flash by the end of 2020, Google's move here shouldn't have a ton of impact. (Unless, for some offbeat reason, you are still developing in Flash. And if that's the case, please explain yourself in a comment below.) Mostly, I'd like to take this opportunity to ask web devs to post in a comment below the best Flash content you've ever created. Let's see 'em!

What was the most interesting thing to you this week in software engineering? Please join the conversation in the comments below. See you next week!