DevOps Realms – Own your Destiny in the Cloud

In this first episode of ‘Own your Destiny in the Cloud,’ Marc Paré, Chief Commercial Officer at CloudOps, discussed DevOps realms with Jesse Hurkens, VP of Consulting and Transformation Services at CloudOps. They spoke about how DevOps impacts business value and how it can be found in three different realms of a technology stack.

Transcript

MP – We hear a lot today about DevOps adoption in the industry, and its value is being understood both by technical teams and business executives. To start off with, how would you define DevOps at the business level?

JH – DevOps can ultimately be defined (and measured) by the improved business value it brings an organization. If properly implemented, it will allow you to more quickly interact with customer feedback and will drive revenue for your business. If you’re not seeing those results, it’s a clear sign that you’re not properly implementing DevOps.

MP – We often hear a lot about DevOps tools, and there’s so much focus on the marketing and selling of DevOps solutions and tools. But is DevOps more about changing the way people work or giving them a new tool?

JH – There is definitely a misconception in many organizations that DevOps relates purely to technical toolings. In reality, it’s also a cultural change. I would say that 80% of DevOps is cultural.

Many organizations have siloes, which can be massive roadblocks to DevOps implementation. Siloes impact continuous integration and continuous delivery (CI/CD) initiatives because they prevent teams from having optimal mechanisms for communication and collaboration. This will impact an organization’s ability to deliver value faster to customers.

MP – If we define DevOps as “the combination of cultural philosophies, practices, and tools that help increase an organization’s ability to deliver applications and services at high velocity,” we can see that the benefits are fairly evident. DevOps has been shown to return higher value to shareholders, and, B2B leaders in particular, have seen better economic growth when taking DevOps approaches. Do you have any thoughts on the science behind DevOps?

JH – There’s actually this book called Accelerate: The Science of Lean Software and DevOps by Gene Kim, Jez Humble, and Nicole Forsgren that does a great job demonstrating the science behind DevOps. It determines the main cultural points that have an impact on the actual business value. In the end, it’s a combination of lean and agile principles that optimize pipelines in end-to-end DevOps practices.

MP – Jesse, how do these end-to-end DevOps pipelines exist in the realms in which it’s being applied? I’ve found different groups of people in our customer base often view DevOps differently. There’s one group who are often developing an application for business logic, like an e-commerce application, and they’re focusing on which DevOps approach and tooling is best for them. Another group is very involved in, as examples, Spinnaker, CI/CD, Docker, and Kubernetes. They’re focused not just on how to use these tools, but actually on building and maintaining that application platform side. There’s a third group that could be more infrastructure focused. We could take one of our customers, cloud.ca as an example. They’re taking a DevOps approach to delivering the machine services or Infrastructure-as-a-Service that they offer. What are the parallels and differences across these areas?

JH – What’s most important is not to siloe your tools. No single team should decide the actual tools to select or use as that will result in tools that do not consider the needs of all parties. It has to be a common initiative, involving breaking silos and putting the right culture in place. That means the development team, the operations team, all teams must be part of your tool selection.

MP – We recently came back from KubeCon, which was a great event. We ran a workshop on infrastructure, networking, and Kubernetes, and we also had a booth presence. All three areas were in some way represented at KubeCon, and all areas seemed to be very impacted by the others.

In the conversations with teams out there, there were a fair amount of people who were really in the application platform world and were focused on the toolings around Docker, Kubernetes, Jenkins, CI/CD. There seemed to be a consensus amongst such people that the application developers using the application platform need to understand more about the roles and responsibilities in DevOps.

There were also a lot of application platform teams who were using GCP, Azure, or AWS, but there was also a subset who actually had their own infrastructure that they wanted to make available as APIs for another platform team.

If you were to carve out this into three different realms – one being the infrastructure tier that takes hardware and converts into APIs someone can consume, another being the application platform tier that delivers those hardware, infrastructure APIs as a platform service that application developers can write on. Can you give us a little bit of insight on how those three different realms would work together in order to deliver and how DevOps impacts them?

JH – Those three layers – the infrastructure, the application platform, and the application development – are all customers of each other. The infrastructure team is providing a service for the application platform team, which is providing a service for the application development team. Those teams have to work together to select tooling and consider each of their needs. The Application development team should be aware of features in the application platform, and the application platform team should be aware of features in the infrastructure. They can then all work together with seamless integration to deploy features to customers.

MP – For organizations that have all three layers, where would you recommend they start?

JH – You typically always start at the application development layer. You must make sure application developers instrument their code in ways that will enable all the operations, logging, etc. to continuously deploy releases when required by the business. The inception of DevOps transformation is in application development, and that’s where I’d start.

The second phase is to go down into the application platform. You’ll want to enable the continuous testing, staging, deployment, monitoring, and also the production of the software to give valuable feedback to the application development team so they can continue their iterations.

Infrastructure would come last. More and more teams are relying on existing cloud providers, like AWS, GCP, Azure, cloud.ca, etc. Some are maintaining their own infrastructure or are using a hybrid cloud infrastructure. In that case, the infrastructure team becomes key to enable that ability to scale up, scale down, or do partial deployments. This is an integral part of your DevOps chain, which becomes increasingly abstracted.

MP – We commonly see the application platform as being where DevOps started. Because of the popularity of technologies like Docker and Kubernetes there’s been a focus on building the app platform. Is that something that you would recommend doing in parallel or should it be more serialized, doing one before another?

JH – Ideally you do these two in parallel. What’s important is that your teams have outstanding communication and work in parallel. Starting your DevOps practice means breaking the silos and putting communication tools in place. If you’ve done that successfully, then those initiatives can be done in parallel. That’s why we say that 80% of a DevOps initiatives is cultural. Without cultural change, you will have a low performing pipeline.

MP – That really resonates. CloudOps’ has historically been really focused on the technology. We were one of the first 10 Kubernetes trading partners, and we’ve been offering Docker and Kubernetes workshops, Machine Learning and Kubernetes workshops, and a whole host of tooling workshops to help transfer hands-on, technical skills. We then found there was a gap between people understanding these DevOps tools and having the environment in which they could put those tools into practice to deliver the business value. That was something we were not addressing but we have since invested in.

JH – That’s something we need to address because cultural change is hard to initiate internally. You usually need external help, eyes from a third party to guide you there and give you both a cultural vision and a realistic opinion on where your organization is culturally.

MP – Some of our current customers are in the telco space and actually have infra that they’re offering as a service to external providers or sometimes external customers or departments that want to consume it. In those cases, you’ve got to start by defining the features and MVP of what you’re planning to deliver and that wants to be a productized Infrastructure as a Service.

We talked about how your app development team should be the first to focus on DevOps and that you could have the app development and the app platform implementing DevOps in parallel. Is it ever appropriate to start with the infrastructure tier?

JH – In certain cases infrastructure providers can do DevOps initiatives to standardize their practices and interface the platform and the needs of their app developers. In addition to adapting their pipelines to their own DevOps practices, they have to adapt their pipelines to the DevOps practices of their customers. That means offering standardized APIs, toolings, and communication with all customers, making sure there is a complete DevOps pipeline end-to-end. In addition to your own, you have to make sure that you enable others.

MP – If you’re a telco with a regional footprint and you’ve got an edge that you’re pushing out infrastructure to (app devs around the world are increasing looking to push workloads out to the edge as well), then you may want to start your DevOps transformation around your infrastructure services. That would mean defining standard APIs that your customer, whether internal or external, can own their destiny as they deploy their application on top of your infrastructure.

JH – Absolutely. As customers move more towards hybrid cloud environments, they will want to harmonize what’s running in different clouds. The reality is that you will sometimes have to go really regional. It’s going to inside more of a generic cloud. App platform developers must harmonize all the infrastructure services out there.

MP – If I’m looking to adopt DevOps or I’ve told my organization has adopted DevOps, what’s a litmus test for me as a manager to say whether we are DevOps gold or not?

MP – You first have to research and assess 32 areas from which you can get an improvement plan for each individual area. A complete DevOps transformation really covers all these areas. You’ll see that you’re more advanced in certain areas than others and probably have a few weak areas in your assessment that we can focus on. Some areas will also have low hanging fruit where we can rapidly improve a certain focal point of your architecture.

MP – Would you say this is a measure of maturity?

JH – Exactly. You normally have a four-level assessment that evaluates your level of maturity in each area. Once you have reached maturity in all areas, it’s important to know that you’re really close to achieving your business value. The closer you are to your business, the more mature you are and the more efficient your DevOps practice is.

MP – So if I’m not ultimately driving feature delivery faster and responding to the market faster, I haven’t adopted DevOps?

JH – There are most likely many areas of those 32 that you would score poorly on. You have to have a good score in all areas in order to optimize your pipeline as you will have problems moving faster than your weakest link. That will impact your company’s pipeline.

MP – Would benchmarking your current status before going into any type of DevOps transformation be ideal?

JH – We typically do a value stream assessment, where we evaluate your present practice and benchmark it against known metrics, like processing time, lead time, your refactor time. Those are key metrics that will then allow us to evaluate the improvement after we have actually put in place an action plan in place for improving those 32 items which are part of a complete DevOps transformation.

MP – That benchmarking and assessment of an organization’s DevOps maturity was very evident for us. We started off as being experts in the app platform, infra automation, and how those areas could be consumed efficiently by app devs. In the early days we were always working with organizations who had a high maturity at the app dev side and were pushing technology boundaries. That’s where we ended up working on AT&T’s OpenStack deployment and being introduced to Kubernetes in a really early phase of the cloud native community’s development. We’ve been such big champions of Kubernetes because we’ve seen the business value that those mature app dev teams experienced from adopting DevOps tools and practices.

We had an Application Platform Assessment, which involved looking closely at the toolings being used, their maturity and whether the right tools were in the right places. We quickly realized that while that was good for the tech heart and mind, it was not necessarily getting close to that business value delivery. We’ve therefore evolved our assessment to being a DevOps Platform and Practice Assessment (DPPA). It measures the maturity both of the toolings and of the practices.

JH – That assessment is critical to build an optimal pipeline. But you won’t optimize business value if you do your assessment without the application and without breaking down your features and requirements properly. That would result in an optimal pipeline with suboptimal business value. It’s important to evolve your practice so that it covers a complete circle and is complete. Decision-makers will base the success or failure of a DevOps initiative on the business value.

MP – Start off with measuring benchmarks and understand where you start and where you expect to finish. Be realistic about it.

Please stay tuned for more, and feel free to reach out to us at info@cloudops.com to learn more about how CloudOps can help you evaluate and improve your DevOps tools and practices. Our DevOps Transformations will modernize your skill base and evolve your organization’s ability to deliver applications and services at high velocity.