Adobe Presents Internal Service Delivery Platform at Velocity 13 Santa Clara

69.610 visualizações

Publicada em

Srinivas Peri (Adobe) and Alex Honor (SimplifyOps) presenting at Velocity 2013.

Publicada em: Tecnologia, Negócios
1 comentário
5 gostaram
Sem downloads
Visualizações totais
No SlideShare
A partir de incorporações
Número de incorporações
Incorporações 0
Nenhuma incorporação

Nenhuma nota no slide
  • 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 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 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
  • Alex’s slides…
  • 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 …
  • Adobe Presents Internal Service Delivery Platform at Velocity 13 Santa Clara

    1. 1. Retooling Adobe – Devops Journey Srinivas Peri | Adobe , Alex Honor | SimplyOps
    2. 2. WARNING There is nothing on GitHub to download at the end of this talk We ll talk about tools but that isn t the main point This presentation is about the journey and the lessons we learned along the way
    3. 3. Srinivas Peri - Adobe First time public speaker 3rd Velocity 11 Years @ Adobe Engineering Manager( Devops Evangelist) Main Focus - fostering Devops @ Adobe
    4. 4. Alex Honor- SimplifyOps Founder SimplifyOPs, DTO Solutions Project lead Rundeck 20 years experience architecture, administration, management Main focus: Making operations simple, easy and fun
    5. 5. Adobe s Big Switch Old Business Model New Business Model ?
    6. 6. My group s value proposition Turn this... Time spent creating value Time spent dealing with everything else Into this... Time spent creating value Time spent dealing with everything else
    7. 7. What’s our relevance in the cloud ? Old Business Model New Business Model CoreTech Tools and Infrastructure ? “We make enabling tools to deliver reusable software components ” March 2010
    8. 8. How did I get here? "10+ Deploys Per Day: Dev and Ops Cooperation at Flickr” Velocity 2013!! CDOT Team Lots of work Typekit , acquired by Adobe
    9. 9. Adobe Shifted to Cloud Subscription Model Old Business Model New Business Model Adobe® Creative Cloud™ Adobe® Marketing Cloud™ June 2013
    10. 10. We just do it differently Old Business Model CoreTech Tools and Infrastructure “We make enabling tools” New Business Model CoreTech Solution Engineering “We make enabling services”
    11. 11. Major realization “We are no longer toolsmiths... we are now a SERVICE PROVIDER”
    12. 12. What s the first problem we can solve?
    13. 13. What s the first problem we can solve? Business Service A Business Service B Business Service C Business Service D Business Service E Business Service F
    14. 14. Give them a clear and automated path to Production CDOT: “Connecting the dots”
    15. 15. CDOT – 30k View Service Architecture Service Architecture Cloud Providers CDOT AWS Java stack Application Code CDOT UI Python stack Client Custom UI Rackspace CDOT API Application Configuration Ruby stack Private Cloud CDOT CDOT Service Verification Code PHP stack Datacenters Operations Code ... ... CDOT Integration layer Open Source Tools Jenkins Rundeck Chef Zabbix Splunk
    16. 16. CDOT Toolchain Workflow Build Deployment Pipeline Perforce/ Github 4 CD PK/Jenkins 1 7 Pull Recipes Chef Server Rundeck Server 5 Instance Chef Directed Instance Chef Instance C.client Orchestration CI ModDav/ Nexus 2 Promote Pkgs 8 S3 Pull Pkgs "Fry" "Bake" 3 Provisioning AMI Tool CI - Continuous Integration CD - Continuous Deployment AMI Repo 6
    17. 17. CDOT Enhances the full service delivery lifecycle 4a 3a S3 Master Branch AWS Support S3 4b 3b 2 CD Dev 1 Feature Branchs ... Non-Prod Prod Dev 3 1 Devops Engineering SRE 24/7 SRE CSO Support
    18. 18. CDOT capabilities •  •  1-click automated deployment anywhere Self-service deployment •  •  Deploy consistently across environments Greater predictability and efficiency •  RESTful API and Custom GUI •  Released as an internal SaaS
    19. 19. video
    20. 20. How to be a service provider Step #1: Build a service Step #2: Create a great user experience Step #3: Marketing and sales!
    21. 21. Internal sales is still sales §  It s not about explaining technology, it s about understanding people! §  People are busy... save them time §  People have frustrations and headaches... alleviate those §  People play politics... understand their motivations §  People have fears... listen to and address
    22. 22. Bring backup like any salesperson §  §  §  §  §  §  Testimonials! Data! Website Presentations Collateral / Whitepapers Organize events §  §  §  Internal DevOps conference Lunch/breakfast tech talks Videos
    23. 23. Build support “Get out of your cube and go talk to people”
    24. 24. Think like a salesperson Dev Guys 1Get “users” onboard Business Guys 2 Get “buyer” onboard Ops Guys 3 Get “partners and suppliers” onboard
    25. 25. The user conversation Srinivas Peri Engineering Manager
    26. 26. The buyer conversation Srinivas Peri Business Manager
    27. 27. The partner conversation Srinivas Peri Ops Manager
    28. 28. Onboarding 3 Weeks Total ?? Days Total
    29. 29. Onboarding is critical customer experience