DevOps is to some degree being conflated with “Digital Transformation”
What does the future of DevOps look like and how does this virus spread? How important is containerization in a DevOps context and how can containers enhance your company’s DevOps transformation? What should a first-aid DevOps toolkit contain? We talked to Dr. Daniel Bryant, Chief Scientist at SpectoLabs, about all these issues and more.
JAXenter: Some people call DevOps a cultural movement, others consider it a magic bullet. In your view, what is the essence of DevOps?
Daniel Bryant: In my opinion, the essence of DevOps is based on shared ownership and understanding throughout the business and IT functions within an organization. Although we call the movement “DevOps” (Development-Operations) it could have equally have been called “BuDevQaOps” (Business-Development-QA-Operations), because typically all of these functions need to come together to deliver software rapidly and safely in the modern business environment. However, “BuDevQaOps” doesn’t sound quite as cool as “DevOps”…
Like anything in technology, DevOps is definitely not a silver bullet, and although moving towards a DevOps way of working can drive success within a company, it also has to be part of a bigger picture, including alignment throughout the business, the correct organisational structure and accounting practices, a willingness to experiment and learn, appropriate technology choices and implementations etc.
JAXenter: What are the latest trends in DevOps? Could you describe one important trend that you are particularly interested in?
Daniel Bryant: One of the latest trends on the technological side of DevOps is immutable programmable infrastructure. Programmable infrastructure was popularized by the introduction of public cloud technology and the likes of Puppet and Chef, but the recent increase in the use of container and serverless technology is driving technology towards immutable artifacts.
I’m not going to recommend any tools per se, and instead, recommend that people read the “DevOps Handbook” (alongside its precursor “The Phoenix Project”).
Immutability of infrastructure and deployment artifacts is very beneficial, as it means environments can much easily be provisioned and maintained throughout the development, QA and production parts of the delivery lifecycle. Many times in my career I have seen mutable infrastructure and customized ‘snowflake’ servers (each with subtly different configuration) cause a lot of issues, as you cannot easily recreate production-like environments for dev and test, nor guarantee a deployment will work across all servers.
JAXenter: DevOps is more than a technology trend — some people claim that it is transforming the modern IT landscape. As more and more organizations decide to adopt DevOps, they need guidance and the right tools. In your view, what are the most suitable tools that should be part of a ready-to-use “DevOps kit”?
Daniel Bryant: DevOps is to some degree being conflated with “Digital Transformation” and traditional change management. Although this can add confusion for people trying to understand DevOps, this conflation is an inevitable part of the adoption lifecycle with any popular technology – vendors want to sell products and consultants want to package and sell services.
I’m not going to recommend any tools per se, and instead recommend that people read the “DevOps Handbook” (alongside its precursor “The Phoenix Project”) By Gene Kim et all, “Continuous Delivery” by Jez Humble and Dave Farley, “Infrastructure as Code” by Kief Morris, “The Art or Business Value” by Mark Schwartz, and “Leading Change” by John Kotter.
I always stress that the values, principles, and practices are more important than individual technology choices, and hopefully, from these books, people should be able to build their own “DevOps” kit. I would also advise starting small, experimenting rapidly, and constantly retrospecting on learning.
JAXenter: What is the role of cloud in a DevOps context? What benefits does it bring?
Daniel Bryant: The primary benefit to cloud is flexibility — you can spin up and tear down infrastructure as it suits you. This facilitates experimentation, and also helps with scaling. There is also the separation of concerns and contextualized expertise that come from scale — for example, I’m betting that AWS can run a more secure data centre than the vast majority of other IT organisations. To some degree, there can be cost savings, but this shouldn’t be the primary motivator.
I always stress that the values, principles, and practices are more important than individual technology choices.
The SaaS-based offerings of Cloud vendors also allow organisations to delegate away some of the operational responsibility of infrastructure, which can also be a real enabler. For example, not every organisation would be happy running a large-scale container management system or MySQL cluster, and so they can use GCP GKE or AWS RDS, and remove most of the operational burden. Cloud vendors like AWS, GCP and Azure are also seeking to offer even more SaaS-based services, for example, AI-based services like GCP Vision API and AWS Alexa Voice Service, which further add to the value proposition.
JAXenter: If containers are revolutionizing IT infrastructure and DevOps is transforming the modern IT landscape, would you say that they go well together?
Daniel Bryant: Yes, but you don’t have to implement it all at once (or at all). In my experience, DevOps, cloud, containers and microservices are quite complementary. However, the first action any organisation that is looking to embrace DevOps must do is to figure out their current situation, their goals, and the journey they must take in order to achieve these goals. For example, if an organisation wants to increase deploy frequency, it may be best to address issues within their architecture and invest in automating their current infrastructure, rather than jumping all-in to microservices, cloud and containers.
The primary benefit to cloud is flexibility.
JAXenter: What are the anti-patterns of DevOps?
Daniel Bryant: Broadly speaking, the primary anti-pattern is not understanding what DevOps is, or what you want to achieve from moving towards this way of working. I would also suggest that approaching DevOps from purely an organisation perspective or a technical process is also a bad idea — increasing collaboration throughout a correct organisational structure (perhaps well-aligned cross-functional teams) in combination with the implementation of a valuable continuous delivery build pipeline will clearly help. I’ll also direct you to my recent talk at JAX DevOps “The Seven (More) Deadly Sins of Microservices”, as I talk about this here, too.
DevOps, cloud, containers and microservices are quite complementary.
JAXenter: Do you have a tip on how we can eliminate obstacles to DevOps adoption?
Daniel Bryant: I believe the books I mentioned above, and also the need to be clear about your current situation and goals, will help with this. My time as an academic taught me to always “stand on the shoulders of giants”, and it is important to learn from other organisations’ successes and failures.
Thank you very much!
Take a look at our DevOps expert checklist: