How DevOps is forcing developers to take on more responsibilites
Whether developers like it or not, DevOps is here to stay. At the DevOpsCon in Berlin, we spoke to DevOps consultant Andreas Schmidt about why the initial hurdles are worth the switch to a DevOps approach.
Between the enthusiasm and the excitement surrounding DevOps, there are still concerns that need to be addressed for the individual developer. Concerns that could be felt in the questions after sessions at the DevOpsCon in Berlin. What are the implications for developers forced to take on more Ops responsibilities? Does a DevOps approach mean even more work for programmers? Andreas Schmidt was there to console any disgruntled developers.
JAXenter: Is the broadening of responsibilities an obstacle that all enterprise programmers faced with a new DevOps will need to overcome?
Andreas Schmidt: I’m afraid so, yes. When I remember the time when I was a developer, around ten years ago, I didn’t have much knowledge about network security and all that stuff. And it never bothered me. I wanted to code and produce software and not think about how to run this. But in the end it’s not about the software. It’s about the running system. And if developers don’t care about this, then in later stages someone else has to take care of this. It’s the same with software development. A bug you can detect during the requirements phase is easier to fix that when detected during the production phase. It costs a lot more to fix a bug when it’s already in production.
And it’s the same with a network issue. If you don’t consider it during the build phase and are just throwing containers or software over the wall, someone else later on will notice “Hmm, that doesn’t work” and then you need to start over. And that makes things cost more and take longer.
So that’s the idea – to take care of these issues as early as possible. And maybe the developer should not be deciding what IP networks and what kinds of overlays are needed, but maybe they can differentiate between a web network, a front-end network and a back-end network. These are three kinds of components I want to code. And I tell my NetOps or DevOps guys we need three networks. And whether at a later stage in production this is a VXLan or a custom solution – it doesn’t matter.
So would you ultimately say developers need to come to terms with the fact that their spectrum of responsibility is widening?
I think they do, yes. I know it’s hard and that maybe not all developers want to learn that kind of stuff. And I can definitely understand that. Because developing software in a good way is hard enough and you don’t want to take the extra burden.
But I think if you’re doing DevOps and your scrum team has a DevOps person that can do this kind of work, then it’s ok. Then not every developer need to know about networking details but this one person. And they take this stuff into production.
How much do DevOps, Containers, Continuous Delivery and MicroServices all belong together? Do companies need to be adopting all of these together, or can they ever be separated?
Well, that’s an organisational issue. Of course, you can do continuous delivery without DevOps. But it’s harder. You have separated silos, a lot more formal communication and DevOps is the solution there to make things easier. You can definitely do microservices without containers. But using containers makes it a lot easier to deploy microservices. So I really think all of it belongs together.
You could do individual things, say like if I want microservices but no DevOps and nothing else…but it doesn’t get you very far. Take a look at smaller companies and startups. They don’t think about whether to do DevOps or not. They just do it. They adapt their technology really quickly, they use Docker and they use microservices. And typically these companies move faster. And this shows us that the combination of all these things makes a positive difference.
In your session here at the DevOps Conference in Berlin, you were explaining the challenges of building network infrastructures for container-based systems. What would you say are the most common obstacles here?
Networks are typically built on physical typologies and are hard-wired and applications are becoming much more dynamic. In fact, the dynamics has changed so much that the network cannot adapt to this. You cannot run in your datacentre and be plugging and replugging and so on. So it changes into configuring your network virtualisation, where you can configure virtual networks and thus you can better adapt to the changing needs of your software.
Another challenge is definitely security. We’re seeing that the classic security approach of network perimeter security is somehow not viable anymore. And this is because security is now more comprised of components on the application layer and not anymore in the network infrastructure. You’re not in control of your entire network infrastructure. Maybe you can change your network infrastructure to adapt to that, but maybe not – perhaps because you’re running in a private cloud. That’s another big aspect.
“You build it, you run it!” We’re hearing that sentence over and over in the DevOps world. But how well does that also work for firewalls?
Probably not very well! The typical firewall is a centralised one and the NetOps guys ‘own’ the firewall. I think in good companies the Ops and NetOps department has access to it and can adapt the rule base. The question is: are they fast enough? Do they keep up with the pace of their development unit? So when developers push out new components with individual communications, can the NetOps guys keep up the pace in implementing changes?
That’s one thing. And the other thing is that classic network security with a central firewall maybe no longer applies. What the NetOps guys do with a firewall – and that becomes difficult. I have some experience in automating firewall rule base generation and rolling out. But at the same time I see that it’s really hard to keep up with the development speed because modern agile organisations running scrum in two-week sprints, where something new happens every two weeks. This is an ongoing run in changing your file. And this gets tough.