Recommended
Recommended
More Related Content
What's hot
What's hot (20)
Viewers also liked
Viewers also liked (9)
Similar to Cloud service api design rules presentation
Similar to Cloud service api design rules presentation (20)
Recently uploaded
Recently uploaded (20)
Cloud service api design rules presentation
- 1. © 2013 Cloud Technology Partners, Inc. / Confidential 1
- 2. © 2013 Cloud Technology Partners, Inc. / Confidential 2 Erik.Sebesta@cloudtp.com / Chief Architect and Technology Officer (CATO) / June 12, 2013 API Design for the New Class of Cloud Enterprise Applications
- 3. © 2013 Cloud Technology Partners, Inc. / Confidential 3 { “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. © 2013 Cloud Technology Partners, Inc. / Confidential 4 Four Stages of Line of Business Application Service Maturity “Introduction” : “The Enterprise Application Maturity Model” Current application spaghetti to cloud spaghetti. No code changes ④ External Shared Services Deliver and leverage external shared services (Advanced PaaS) ③ Portfolio Refactoring② Application Refactoring① Virtualization Refactor individual applications into cloud services. Remediate known violations in current code and platform Consolidate portfolio to take advantage of internal shared business and technical cloud services (Basic PaaS)
- 5. © 2013 Cloud Technology Partners, Inc. / Confidential 5 “Funding” : “Business Case” “IT projects are born if the pain today or in the future is greater than the perceived pain of transition” Chris Perretta CIO, State Street Bank
- 6. © 2013 Cloud Technology Partners, Inc. / Confidential 6 • 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 budgets The Pain Today
- 7. © 2013 Cloud Technology Partners, Inc. / Confidential 7 Industry-Specific Core and Cross-Business Commodity Shared Services The Future To get appropriate attention and funding, successful API programs start with creating customer or partner focused external shared services. April 30, 2013 Source: John Musser, Programmable Web http://blog.programmableweb.com/2012/05/23/which- apis-are-handling-billions-of-requests-per-day/
- 8. © 2013 Cloud Technology Partners, Inc. / Confidential 8 • Be a pessimist – assume everything fails and design backwards. Love your chaos monkey. • Put your eggs in multiple baskets – leverage multiple providers, geographic regions and availability zones to accommodate for local availability issues. Design for portability. • Think efficiency - inefficient designs will not scale. Efficient designs become cheaper as they scale. • Be paranoid – design for defense in depth and zero tolerance by building in security at every level and between every component. Trust no one. • But not too paranoid – not every application needs the platinum solution. Architect for different SLA’s, service tiers and security levels “Design” : “14 API Best Practices” Part 1/3
- 9. © 2013 Cloud Technology Partners, Inc. / Confidential 9 • Divide and conquer - pursue data partitioning and parallelization wherever possible. Make components as small and portable as possible including multiple small database instantiations per services package. Use load balancing between layers • Think elasticity - increasing resources should result in a proportional increase in performance and scalability. Decreasing resources should have the same effect. • Hands Off - leverage automation to increase consistency, quality and reduce response times • Be dynamic - enable dynamic configuration changes like autoscaling, failure recovery and resource discovery to adapt to changing environments, faults and workload volumes “Design” : “14 API Best Practices” Part 2/3
- 10. © 2013 Cloud Technology Partners, Inc. / Confidential 10 • Stay close – reduce latency by moving highly interactive components and data near each other. • Don’t talk too much – design service granularity to minimize chatty network traffic • Keep it loose - loose coupling, service interfaces, separation of concerns, abstraction and well defined API’s deliver flexibility • Dress for success – separate UI services from functional services. Provide custom look and feel for popular device displays • Be cost aware – autoscaling, data transmission, virtual software licenses, reserved instances, etc. can rapidly increase your monthly charges. Monitor your usage closely. “Design” : “14 API Best Practices” Part 3/3
- 11. © 2013 Cloud Technology Partners, Inc. / Confidential 11 Patterns 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 IaaS Includes some content from: Apigee http://www.slideshare.net/apigee/10-patterns-in-successful-api-programs-2-8081076
- 12. © 2013 Cloud Technology Partners, Inc. / Confidential 12 Provide Great Developer Experience (DX) Source: John Musser, Programmable Web http://www.slideshare.net/jmusser/what-makes-a-great-open-api?from_search=2 Plus proactive marketing to potential early adopters, SLAs for service packages and product-level engineering support
- 13. © 2013 Cloud Technology Partners, Inc. / Confidential 13 “Management” : “Governance” Source: John Musser, Programmable Web http://www.slideshare.net/jmusser/what-makes-a-great-open-api?from_search=2
- 14. © 2013 Cloud Technology Partners, Inc. / Confidential 14 Governance must also recognize and reward “Management” : “Governance” Internal teams and partners who create highly valuable shared services • Public praise • Compensation commensurate with value created Internal 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. © 2013 Cloud Technology Partners, Inc. / Confidential 15 “Audience” : “Questions?” Erik.Sebesta@cloudtp.com / Chief Architect and Technology Officer (CATO) / June 12, 2013
- 16. © 2013 Cloud Technology Partners, Inc. / Confidential 16 Appendix
- 17. © 2013 Cloud Technology Partners, Inc. / Confidential 17 Netflix Blog http://techblog.netflix.com/ What Makes a Great Open API; John Musser, Programmable Web http://www.slideshare.net/jmusser/what-makes-a-great-open-api?from_search=2 Designing Beautiful REST and JSON APIs; Les Hazlewood, StormPath http://www.slideshare.net/stormpath/rest-jsonapis?from_search=12 Developer Support Handbook; Pamela Fox, Google http://developer-support-handbook.appspot.com/intro.html Suggested Resources for More Details Great APIs to Emulate list from: Apigee http://www.slideshare.net/apigee/10-patterns-in-successful-api-programs-2-8081076
- 18. © 2013 Cloud Technology Partners, Inc. / Confidential 18 API Protocols REST vs. SOAP REST is easier to understand and code against. Less plumbing. Faster innovation. Http protocol is more portable. SOAP hosted over TCP or pipes protocols may not translate well between vendor stacks.
- 19. © 2013 Cloud Technology Partners, Inc. / Confidential 19 XML= Red, JSON= Blue XML vs. JSON Data from Google Trends, June 4, 2013, Internet and Telecom category
- 20. © 2013 Cloud Technology Partners, Inc. / Confidential 20
Editor's Notes
- Be a pessimist – assume everything fails and design backwards. Love your chaos monkey Graceful error handling and retry logic is a must! Make your applications/APIs robust! (sorry for the rhyme.)Expect and handle scenarios like “what if this disk my application is writing to suddenly wasn’t there?”… or is writing to disk even necessary? Maybe a form of cloud storage is a better option.Put your eggs in multiple baskets – leverage multiple providers, geographic regions and availability zones to accommodate for local availability issues. Design for portabilityFor portability between clouds, design your apps/APIs to be loosely coupled. At a minimum, interactions with proprietary cloud APIs implementations should be wrapped and injected. As a developer this is necessary so when your boss wants you to migrate an API to a different platform (or support multiple cloud providers) you can actually pull it off.“What’s that? I need to migrate my service’s caching layer to use a different distributed cache? No problem! I properly decoupled the layers of my application so I can easily swap in an implementation that makes use of the new platform’s cache API.”Think efficiency - inefficient designs will not scale. Efficient designs become cheaper as they scale. Also, inefficient designs cost more money to run in the cloud because they consume more resources, and are therefore more likely to force elastic scale out to occur sooner. It is more important than ever for developers to pay attention to following best-practice with regards to memory and resource management in code.But not too paranoid – not every application needs the platinum solution. Architect for different SLA’s, service tiers and security levels(The above point ties back to your slides regarding maturity model: Ideally, as an organization, your first foray into cloud application development should not be with an application that requires a “platinum solution”. Walk before you run.)
- Divide and conquer - pursue data partitioning and parallelization wherever possible. Make components as small and portable as possible including multiple small database instantiations per services package. Use load balancing between layersSmall portable components can help get better utilization of instance resources because you can more densefaster startup times when scaling out new component instancesThink elasticity - increasing resources should result in a proportional increase in performance and scalability. Decreasing resources should have the same effect. Stateless services are important here. Stateless services scale easier, and applications not originally developed with cloud in mind can have trouble effectively maintaining state across elastically scaling instances/environments.
- Keep it loose - loose coupling, service interfaces, separation of concerns, abstraction and well defined API’s deliver flexibilityFrom a developers perspective, this may be the most key point. SOA may be turning into a four letter word nowadays, but following these good practices will reap benefits in the cloud. For devs, this is still where a lot of the magic happens. It helps enable many of the other bullet points in this list.
- Discuss Service Bus & Service Registries
- why REST is winning the battle for API supremacy:Easy to understand and code against Faster innovate, and faster to market. Less time with plumbing.Http protocol No proprietary protocols means more portable(Although SOAP service stacks support Http, SOAP services are also often hosted over TCP or pipes protocols that don’t always translate well between vendor stacks. HTTP is well known to all.)