We spend a lot of time focused on DevOps for Devs in the industry. A lot has been written about how we can make life better for developers through automation, Lean, Agile, Kanban, etc. etc. but it seems like there isn’t a ton of information out there written from the Operations perspective, or maybe I have just been incurious about it until recently. DevOps for a team or a tribe is pretty straightforward, there are a lot of resources available to help out from tooling to knowledge sharing, patterns for consumption and what have you. And that is true for both the developer and operations side of the equation. Certainly structured platforms like Cloud Foundry and Open Shift and container technologies are starting to make things better for operations as well, but they are really helpful again at the team or tribe level. Adopting DevOps at scale is really a horse of a different color.
I have been working on enabling DevOps at scale for a large Bank for the last two years and have learned a lot. Working with Pivotal has been really eye opening, but they are really focused on the developers, and I guess that is to be expected, they’re kind of a “by devs for devs” sort of company. I have started to take some of what they are teaching our developers and utilizing it for our platform operators to start. Our platform operations team is pairing and that has been a revelation. The amount of collaboration, focus, and innovation has greatly increased. The team is really energized and just walking through the area where the cloud team sits makes you want to grab a keyboard and build something. We are going to take this concept and start applying it to more of our operations team. This really helps bring people up to speed on our environment, how we do things, what our expectations are, and gets folks into a sharing mindset. Watching the platform operators engaging in problem solving, moving as a pair from the whiteboard to their keyboards and seeing the output has been really inspiring.
The cloud team is located in two offices with a good amount of home working as well. I wish I could get them all colocated but I think that is going to be increasingly unlikely for large organizations to do as we move forward. We are accelerating our rollout of Microsoft Teams to increase our collab-fu. ChatOps here we come. It is becoming readily apparent how important ubiquitous video capability is and we will fast track our Office 365 roll out to facilitate that. Ready access to big screens, whiteboards, and sticky notes has also greatly improved collaboration for the team. We have also annexed more desks adjacent to the cloud area so that the development teams we are onboarding to the platform, or engineering teams working on new capabilities, are able to colocate with us. This offers more opportunities for pairing as well.
The team is demonstrating how we expect people to work moving forward and is living the values we have focused on: Humble, Hungry, and Smart (with apologies to Patrick Lencioni). We are trying to turn the team and the area and the platform into a gravity well for the enterprise, attracting people to what we are doing rather than trying to force things from the top down – although we have strong executive support and the appropriate corporate policies in place to promote “Cloud First”. We have very consciously been developer driven in terms of the capabilities we are exposing in our IaaS and PaaS offerings as I have been burned too many times by the Field of Dreams approach. Smart dev teams are appreciative of this approach, other teams who are not as switched on are disappointed that not everything is there and available out of the box. We are trying to make this a big tent approach, inviting everyone in to come on the journey with us.
The progress on DevOps for Ops is coming along, we have got better tooling, a platform, better ways of working, more automation, more collaboration, improved mindsets, etc. That is all great, but it is exposing some areas where a lot more work is needed. I have written before about how Big Data is the problem statement, that is especially true for cloud operations. We are building lots of information radiators, but there is something overarching that is missing. I truly believe it is important for each application team to define their pipeline, and for each operations team to do the same. These pipelines need to be automated, auditable, and flexible. That compounds our big data problem. We give teams patterns on how they can integrate their pipelines with source code and artifact repositories, testing tools, service management, and enable them with new collaboration tools, communications, ChatOps, wikis, and corporate social media. We are implementing Communities of Practice and Centers of Excellence to improve collaboration and development and sharing of policies, standards, and processes. We are automating our infrastructure and platforms, making them self-documenting, generating a ton of measurement and machine data.
More and more data every where. That’s great . . . right? We did a study that showed we have 30+ collaboration and knowledge management tools in the enterprise. The challenge is getting the data in the right place and making it searchable so it can turn into information. This has to be a part of DevOps for Ops if our job is to enable the organization to move fast and learn fast. We are bringing the teams together, automating, removing handoffs, simplifying processes and all kinds of IT and service management goodness . . . I fear that we are creating IT data silos. We focus a lot on operational data stores for customer centric data, we have got to take a similar approach to IT data. I have seen this done really well at the team and tribe level, I have yet to see something done at scale. This will be my next area of focus and I would love to learn from anyone who has hacks, tips, and lessons learned in the area.