I was fortunate enough to attend the recent OWASP AppSec 2017 conference in Belfast. One of the attendees came by our booth and after we’d chatted a little he told me that he’d asked each of the speakers the same question: “What’s your definition of DevOps and how does it apply to containers?” He set me up to fail by saying that none of the answers he’d heard so far were very compelling.
Nevertheless, I had to give it a shot…
What is DevOps?
DevOps is the joining of development teams with application operations. That’s important.
The less of a platform that you have or the less abstracted that platform the more of an operational footprint or stack is needed for application operations.
If your application is a traditional, 3 tiered, virtual machine based, shared Oracle database backed with some middleware then your new DevOps teams (off the top of my head) have to touch:
- The application, its development, its requisite software and development
- Load-balancers and networking
- Operating Systems (if you’re lucky then it’s one standard one – which also constrains your development)
- Data management and database management
- middleware, messaging
- Application clustering (e.g Websphere)
- Perhaps clustering at a different layer, OS for example
- Storage (presentation and consumption … filesystems alone can be painful enough)
My point? each of these areas listed above is a specialization in its own right. If you’re not careful then you run the danger of creating a “DevOps team” who are really just providing glue (and probably doing a good job trying to automate things) for all these silos. Perhaps worse would be a ham-fisted attempt to create separate DevOps teams.
Development groups (scrum teams if that’s your thing) that expand out to have individuals from every field. The size of the team, the levels of cross training, the error prone accidental damage from learners (all of this set against a background of changing technology and technology standards/best practices) makes organizations and individuals look amateurish – which can drive away your talent.
I’m not here to espouse the benefits of DevOps – I believe they are self-evident and detractors have probably only experienced the bad, previously described scenarios. But, how can we avoid these pitfalls? How do we do it better?
Well, that brings us back to…
My Definition of DevOps and How to Get Started
DevOps is about developing and operationally managing something. Be that an application or a service or even a platform (all of which could probably be described as services, but I get paid by the word). This is different from trying to shoehorn the full stack of infrastructure services into a development group. It’s also different from saying that highly specialized operational teams need to give up and go learn Go.
By providing a common platform for your development groups that abstracts as much of the stacks as possible you empower your development teams. Operational management of the application becomes:
- The application and its code
- How to interface with the platform
- Standards and best practice
Your development teams are empowered to be operational and, crucially, your operational teams are empowered to develop. Abstracting the platform means that the platform can be managed independently of the applications!
No one is going to say it’s simple to rollout a successful DevOps approach, but containers provide a means to rapidly progress to this – certainly faster than trying to force this change onto change-averse teams or business units. Actually, containers make a lot of things easier (Docker will tell you all about it!) and there are some big players creating platforms you can deploy to streamline even further (Think: Kubernetes, Swarm, and OpenShift).
Using containers and pushing control to the layer closest to the business means we can push decisions to where it matters. Using common platforms or services we can push information and give clarity to those decisions.
Take our field – Security, for example.
Vulnerability management can now appear at the beginning of the software development lifecycle. The security posture of the IT estate can be set and published to development groups up front. These new DevOps teams can set the operational requirements of their platform and also their security requirements! One of the DevOps goals of improved software through operational accountability also give us improved security!
Highly skilled security engineers, who in our post-devops-apocalyptic world were to be merged & retrained in multidiscipline teams (or just ignored) are now providing a service to the teams. They can use the same security platform to monitor, report and ensure compliance as their DevOps teams use.
In addition to this the SecDevOps team must develop their platform. Their ‘data’ must be accurate and evolve (CVE feeds, false positives, compliance, malware, zero day, etc.), their ‘code’ must be developed (dashboards, APIs, availability), and their services must progress as well (CI/CD plugins, automated intent based security, registry scanning, runtime scanning and auto defense, active threat protection).
Your organization’s appetite for risk, willingness to have these as core functions to maintain & develop, and regulatory requirements will dictate whether you roll your own using Open Source tooling, custom code, modified traditional security and manually managed inputs, or use the market leading container security software.
To Summarize: Done well, DevOps increases IT’s value to the business. Done poorly, it’s a dangerous risk – but in a world of digital disrupters it’s something that is unavoidable. It’s your choice on how that happens in your organization.
Oh and as for the innocent questioner at the booth? He claimed that my answer was the best of the day! He may have just been trying to escape though…
Follow us on Twitter
Follow us on Twitter for real time updates on the cloud native ecosystem, Twistlock product, and cloud native security threats.