Aucune remarque pour cette diapositive
Even though we are going to be talking about and showing some tools... that is not the point of this talk
I am Srinivas Peri from Adobe and main focus @ Adobe is to foster Devops best practices across various groups and organizations. Today along with Alex , I am going to share my journey past 3 years
I am Alex from Simplyfops.com and I am here because I learned something new..
Last few years Adobe has been transitioning from a traditional software business model to subscription based software and cloud services . This shift enables Adobe to “put innovation in our customers hands at much faster pace “, unlike before where you have to wait for several months for new version. This means… gone are the days ..team takes months to plan,develp,test and release ;
Our group "Coretech Tools and infrastructure " group was in the business of providing productivity tools , that means .. In nutshell we take this and convert to this.
So what does that mean when we transition to cloud ……We started our journey in March 2010..
Engineering manager and Devops Evangelist @ Adobe ... got thrust in the world of online services... talked to Dan Neff... Pointed me to velocity 2009 ... talk by paul hammond and john allspaw... went to devops days... met Alex and Damon brought first DTO Solutions then SimplifyOps into Adobe.... we all did a lot of work... Developed a service delivery platform, called CDOT .. Used by several groups @ aodbe .. … I always wanted to give back to the community... but nobody at Velocity knew who I was… Meanwhile turns out that Paul Hammond is part of Adobe as a part of Typekit Acqusition .. and some of the work we are doing with CDOT had benefited Paul ’ s typekit group...... He gave John Allspaw the endorsement and here I am today at Velocity 2013
3 Years from then … Adobe now completely shifted to cloud based delivery
And my group has transformed from “Tools and Infrastructure” Solution Engineering
We saw that there were suddenly islands of tools, scripts, processes, etc..
Different teams make different choices and use different technologies and tools all over the organization
I can ’ t tell everyone to use Chef. I can ’ t tell everyone to use Rundeck. But I can help you connect it all together... I can connect the dotsWhat is CDOT.... transportation system connecting islands of automation
Lets take a look at the cdot architecture … Adobe services teams has many different service architecture stacks .. And they get deployed to different cloud providers ; while most recent ones are in AWS , we have few services in rackspace , and many still in the data centers , and some services like entitlement , need to deployed in Adobe private DC. CDOT is a service delivery platform (aka transportation system) , which can reliably move code to destination. CDOT is built on top of some of the standard best open source tools , with integration layer . This layer abstract the tool details , tools can be easily swapped with others when needed. CDOT providers well defined API for most of the common day-day operation activities like Creating a new Env , Deploying a new packg , Running tests ; and also informational API like which build is deployment to which environment , by whom and when. It comes with workbench UI , which can be customized as per team needs CDOT also enables a very good workflow for the development of operations code, Operations code like Application code , will be designed , implemented, tested , and reviewed
Lets take a deep look at how the tool that we choose work together Step1 is CI – Code gets continually built , pkg and stored in repository Now you have decision to make.. Bake or Fry .. Step2 –promote this packages to appropriate location, which can be used @ runtime .. In case of AWS its S3 , but could be repository in each datacenter . This step is very important , and involves workflow around hand-off to other teams Step 3 Then comes the process of generating AMI… you can bake bare minimum stuff @ generation time , and get rest @ runtime. Thi is useful in most of the cases…But there are usecases where baking all make sense Now we are ready to hook CI with CD .. We use Jenkins Rundeck plugin , and initiate the “client run” or launch cloudformation . Rundeck also set the chef server with right packages. Instances then pull recipes and from chef server , and pkgs from S3 , and completes the local orchestration Key thing to remember here is architecture supports both Push and Pull
Focus on the last bullet .. Released as service … This is a new kind of business service just like .. Other entilement , provisioning Adobe is a global enterprose , product team all over the world How do you get the word out.. U cannot got travel and visit the every person So it takes a little bit of sales and marketing .. I want to play her ethe video that we use internally…
As a service provider I need to think like a salesperson.... start with the customer (if you don ’ t have users you don ’ t have a service) and work your way backward to the buyer (if someone isn ’ t going to pay for it you don ’ t have a business) then to your partners and suppliers (if you can ’ t deliver to your users or buyer your business will fail... but if you don ’ t have users or a buyer then your partners won ’ t listen to you). In my case, I was building a service where the primary user is a developer, the buyer was the business manager for that line of business, and my critical partner was the ops manager.
Always working to improve
What is the onboarding experience... just as important to a customer as features... must keep the cost of switching low for your customers! Part of onbaording checklist …