Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Cloud service api design rules presentation

999 views

Published on

This presentation covers key factors for API design and adoption for the new class of enterprise application services. Topics include funding, design rules, usage, management and governance.

Published in: Technology, Business
  • Be the first to comment

Cloud service api design rules presentation

  1. 1. © 2013 Cloud Technology Partners, Inc. / Confidential1
  2. 2. © 2013 Cloud Technology Partners, Inc. / Confidential2Erik.Sebesta@cloudtp.com / Chief Architect and Technology Officer (CATO) / June 12, 2013API Design for the New Class ofCloud Enterprise Applications
  3. 3. © 2013 Cloud Technology Partners, Inc. / Confidential3{“Introduction” : “Enterprise Application Maturity Model”,“Funding” : “Business Case”,“Design” : “14 API Best Practices”,“Usage” : “Facilitating Adoption”,“Management” : “Governance”,“Audience” : “Questions?”}Get Http://cloudtp.com/agenda/06-12-2013
  4. 4. © 2013 Cloud Technology Partners, Inc. / Confidential4Four Stages of Line of Business Application Service Maturity“Introduction” : “The Enterprise Application Maturity Model”Current applicationspaghetti to cloud spaghetti.No code changes④ External Shared ServicesDeliver and leverage externalshared services(Advanced PaaS)③ Portfolio Refactoring② Application Refactoring① VirtualizationRefactor individual applicationsinto cloud services. Remediateknown violations in currentcode and platformConsolidate portfolio to takeadvantage of internal sharedbusiness and technical cloudservices (Basic PaaS)
  5. 5. © 2013 Cloud Technology Partners, Inc. / Confidential5“Funding” : “Business Case”“IT projects are born ifthe pain today or in the futureis greater thanthe perceived pain of transition”Chris PerrettaCIO, State Street Bank
  6. 6. © 2013 Cloud Technology Partners, Inc. / Confidential6• High cost, tightly coupled, heterogeneous systems• Redundant functionality• Lack of agility to innovate• Slow time to market• Rising maintenance costs• Rising regulatory and compliance costs, multiplied by– heterogeneous systems– geographic expansion / local laws• Falling IT budgetsThe Pain Today
  7. 7. © 2013 Cloud Technology Partners, Inc. / Confidential7Industry-Specific Core and Cross-Business Commodity Shared ServicesThe FutureTo get appropriate attention and funding, successful API programs startwith creating customer or partner focused external shared services.April 30, 2013Source: John Musser, Programmable Webhttp://blog.programmableweb.com/2012/05/23/which-apis-are-handling-billions-of-requests-per-day/
  8. 8. © 2013 Cloud Technology Partners, Inc. / Confidential8• Be a pessimist – assume everything fails and design backwards.Love your chaos monkey.• Put your eggs in multiple baskets – leverage multipleproviders, geographic regions and availability zones toaccommodate for local availability issues. Design for portability.• Think efficiency - inefficient designs will not scale. Efficientdesigns become cheaper as they scale.• Be paranoid – design for defense in depth and zero tolerance bybuilding in security at every level and between every component.Trust no one.• But not too paranoid – not every application needs theplatinum solution. Architect for different SLA’s, service tiers andsecurity levels“Design” : “14 API Best Practices” Part 1/3
  9. 9. © 2013 Cloud Technology Partners, Inc. / Confidential9• Divide and conquer - pursue data partitioning andparallelization wherever possible. Make components as smalland portable as possible including multiple small databaseinstantiations per services package. Use load balancingbetween layers• Think elasticity - increasing resources should result in aproportional increase in performance and scalability.Decreasing resources should have the same effect.• Hands Off - leverage automation to increaseconsistency, quality and reduce response times• Be dynamic - enable dynamic configuration changes likeautoscaling, failure recovery and resource discovery to adapt tochanging environments, faults and workload volumes“Design” : “14 API Best Practices” Part 2/3
  10. 10. © 2013 Cloud Technology Partners, Inc. / Confidential10• Stay close – reduce latency by moving highly interactivecomponents and data near each other.• Don’t talk too much – design service granularity tominimize chatty network traffic• Keep it loose - loose coupling, service interfaces, separationof concerns, abstraction and well defined API’s deliverflexibility• Dress for success – separate UI services from functionalservices. Provide custom look and feel for popular devicedisplays• Be cost aware – autoscaling, data transmission, virtualsoftware licenses, reserved instances, etc. can rapidly increaseyour monthly charges. Monitor your usage closely.“Design” : “14 API Best Practices” Part 3/3
  11. 11. © 2013 Cloud Technology Partners, Inc. / Confidential11Patterns in Successful APIs and API Programs“Usage” : “Facilitating Adoption”• Clear API ownership and strong internal evangelism• Early and consistent vision, strategy, business cases and metrics• Usage and security policies designed up front. I.e. Content level authorization• Compelling differentiated API• Dedicated transformational support staff– APIs designed for adoption. Easily found by developer community– Frequent engagement with the developer community– Clear API documentation to facilitate proper use, avoid misuse– Easy process to receive feedback to iterate quickly– Full cloud service development lifecycle (Cloud SDLC) operational support• Dynamically scalable underlying PaaS and IaaSIncludes some content from: Apigeehttp://www.slideshare.net/apigee/10-patterns-in-successful-api-programs-2-8081076
  12. 12. © 2013 Cloud Technology Partners, Inc. / Confidential12Provide Great Developer Experience (DX)Source: John Musser, Programmable Webhttp://www.slideshare.net/jmusser/what-makes-a-great-open-api?from_search=2Plus proactive marketing to potential early adopters, SLAs for servicepackages and product-level engineering support
  13. 13. © 2013 Cloud Technology Partners, Inc. / Confidential13“Management” : “Governance”Source: John Musser, Programmable Web http://www.slideshare.net/jmusser/what-makes-a-great-open-api?from_search=2
  14. 14. © 2013 Cloud Technology Partners, Inc. / Confidential14Governance must also recognize and reward“Management” : “Governance”Internal teams and partners who create highly valuable shared services• Public praise• Compensation commensurate with value createdInternal teams, customers, and partners who reuse shared services• Praise for adoption by internal business units• Incentives for adoption by internal business units• Incentives for adoption by customers and partners
  15. 15. © 2013 Cloud Technology Partners, Inc. / Confidential15“Audience” : “Questions?”Erik.Sebesta@cloudtp.com / Chief Architect and Technology Officer (CATO) / June 12, 2013
  16. 16. © 2013 Cloud Technology Partners, Inc. / Confidential16Appendix
  17. 17. © 2013 Cloud Technology Partners, Inc. / Confidential17Netflix Bloghttp://techblog.netflix.com/What Makes a Great Open API; John Musser, Programmable Webhttp://www.slideshare.net/jmusser/what-makes-a-great-open-api?from_search=2Designing Beautiful REST and JSON APIs; Les Hazlewood, StormPathhttp://www.slideshare.net/stormpath/rest-jsonapis?from_search=12Developer Support Handbook; Pamela Fox, Googlehttp://developer-support-handbook.appspot.com/intro.htmlSuggested Resources for More DetailsGreat APIs to Emulate list from: Apigeehttp://www.slideshare.net/apigee/10-patterns-in-successful-api-programs-2-8081076
  18. 18. © 2013 Cloud Technology Partners, Inc. / Confidential18API ProtocolsREST vs. SOAPREST is easier to understand and code against. Less plumbing. Fasterinnovation. Http protocol is more portable. SOAP hosted over TCP or pipesprotocols may not translate well between vendor stacks.
  19. 19. © 2013 Cloud Technology Partners, Inc. / Confidential19XML= Red, JSON= BlueXML vs. JSONData from Google Trends, June 4, 2013, Internet and Telecom category
  20. 20. © 2013 Cloud Technology Partners, Inc. / Confidential20

×