In case it is unclear, @apc_lee @DBJDEV @cloudcollider @seantcarroll and I created the platform as a product operating model at Allstate before it got that name from a certain software vendor.
We literally started by saying that the developer should have to do the least amount of work possible to deploy to the platform.
We started by moving the team to the cafeteria because there was not a collaborative space for us to work. We started pairing on ops, which at the time was not very common.
We went as far as creating our own infra stack so that we could control (I.e. automate) every aspect of the platform.
We were pressured to just use existing tech such as Splunk or HP Open View, but we refused because we wanted to be able to provision everything the developer needed when they came on to the platform. No hand offs.
We went as far to file firewall rules for the developers which later led to is hiring a firewall engineer and building software so that we could push rules more frequently.
We literally took everything that was terrible out of developers hands. We controlled RTO at the platform level by getting opinionated about how traffic was managed and routed. We also tried to take care of as much compliance and security stuff off of their hands as we could.
Because of the way we built the architecture we were literally able to unplug an entire foundation with all of its hardware and move it with zero impact to teams in the middle of the day.
We broke all the rules. We made sure the architecture supported deploying in the middle of the day. We also enforced patterns through deployadactyl that ensures availability.
This made sure that our software engineers could just push from the CI tool without worrying about change tickets, security scanning, or approvals because it all happened through automation.
A major reason to live into this model is that it is the ultimate form of empathy for the software teams. It brings the pain of interacting with infra forward to the platform team so they can solve those problems.
Platform as a product is more than stand ups and pairing. It is literally having a platform product manager that gets feedback from customers (dev teams) and makes it as easy as possible for them to do the right thing on the platform.
There should be a mission and vision and KPI just like any other product. We tracked things like compliance, RTO, change velocity. One big challenge we had was other teams did not have that discipline so getting a baseline for comparison was near impossible.
I also showed how to do multi cloud deployments at a CF meetup in Denver through deployadactyl. @kennybastani was blown away. It was the first time I know of someone had shown the bulkhead pattern with the GSLB our front. That pattern is now in a white paper.
If you require more than CF push for your platform ops then there is opportunity to improve. Operational readiness, compliance, logging, monitoring, paging and notifications, etc should all be automatic. They should have to do nothing except communicate in their own language.
Anywhere that there are coordination teams or forms to fill out there is an opportunity to improve the developer experience.
Developers want to focus on delivering value as much as anyone else in the company. Get them out of administrivia. I assure you that they will buy into an opinionated pattern if it means more time solvin problems for customers.
We also got scolded because we had so many change that were rolled back without impact. The reason was that we made the release process opinionated so developers didn’t have to worry about a lot of the basic configuration failures.
They would just deploy and see what happened because they didn’t have to worry about impact. This was AWESOME and is what you want. But it made some leaders uncomfortable. Last year we pushed over 10,000 prod deploys.
We would not have been able to do this if we had not isolated ourselves and been uncompromising in the customer experience. We got a lot of push back a long the way, but at the end of the day I think our developers were very pleased with the experience.
Our goal was to provide our developers with tools and capabilities that they would miss if they went and worked elsewhere. I consider us successful in that endeavor.
I mean we loved our devs so much we build them an elastic search cluster and managed it with BOSH. For anyone who has managed elastic or BOSH you know that is not something for the faint of heart.
We also took on the maintinence scripts for the pairing stations. We were not desktop support prosper but I am trying to demonstrate the degree you have to live into the voice of the customer.
On the topic of accelerating learning, when we built the docs site, we refused to use share point because the rule was no friction to see the content. We made sure search worked well. Then we created a rule that support requests in slack had to be answered with a docs page.
