Retooling Adobe: A DevOps Journey from Packaged Software to Service Provider
Srinivas Peri, Adobe and Alex Honor, SimplifyOPS/DTO
Adobe needed to move from desktop, packaged software to a cloud services model and needed a DevOps transformation as well.
Srini’s CoreTech Tools/Infrastructure group tries to transform wasted time to value time (enabling tools).
So they started talking SaaS and Srini went around talking to them about tooling.
Dan Neff came to Adobe from Facebook as operations guru from Facebook. He said “let’s stop talking about tools.” He showed him the 10+ deploys a day at Flickr preso. Time to go to Velocity! And he met Alex and Damon of DTO and learned about loosely coupled toolchains.
They generated CDOT, a service delivery platform. Some teams started using it, then they bought Typekit and Paul Hammond thought it was just lovely.
And now all Adobe software is coming through the cloud. They are not the CoreTech Solution Engineering team – who makes enabling services.
Do something next week! And don’t reinvent the wheel.
How To Do It
First problem to solve. There are islands of tools – CM, package, build, orchestration, package repos, source repos. Different teams, different philosophies.
And actually, probably in each business unit, you have another instantiation of all of the above.
CDOT – their service delivery platform, the 30k foot view
Many different app architectures and many data center providers (cloud and trad). CDOT bridges the gap.
CDOT has a UI and API service atop an integration layer It uses jenkins, rundeck, chef, zabbix, splunk under the covers.
On the code side – what is that? App code, app config, and verification code. But also operations code! It is part of YOUR product. It’s an input to CDOT.
So build (CI). Takes from perforce/github to pk/jenkins, into moddav/nexus, for cloud stuff bake to an AMI, promote packages to S3 and AMIs to an AMI repo.
For deploy (CD), jenkins calls rundeck and chef server. Rundeck instantiates the cloudformation or whatever and does high level orchestration, the AMis pull chef recipes and packages from S3, and chef does the local orchestration. Is it pull or push? Both/either. You can bake and you can fry.
So feature branches – some people don’t need to CD to prod, but they sure do to somewhere. So devs can mess with feature branches on dev boxes, but then all master checkins CD to a CD environment. You can choose how often to go to prod.
Have a cool “devops workbench” UI with the deployment pipeline and state. So everyone has one-click self service deployment with no manual steps, with high confidence.
Now, CDOT video! It’s not really for us, it’s their internal marketing video to get teams to uptake CDOT. Getting people on board is most of the effort!
What’s the value prop?
- Save people time
- Alleviate their headaches
- Understand their motivations (for when they play politics)
- Listen to and address their fears
Bring testimonials, data, presentations, do events, videos! Sell it!
“Get out of your cube and go talk to people”
Think like a salesperson. Get users (devs/PMs) on board, then the buyers (managers/budget folks), partners and suppliers (other ops guys).
the agile admin 