• Save
Cloud service api design rules presentation

Like this? Share it with your network

Share

Cloud service api design rules presentation

  • 517 views
Uploaded 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.

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.

More in: Technology , Business
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Be the first to comment
No Downloads

Views

Total Views
517
On Slideshare
504
From Embeds
13
Number of Embeds
3

Actions

Shares
Downloads
0
Comments
0
Likes
3

Embeds 13

http://mysoaone.blogspot.com.au 8
https://twitter.com 3
http://mysoaone.blogspot.com 2

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
    No notes for slide
  • 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.)

Transcript

  • 1. © 2013 Cloud Technology Partners, Inc. / Confidential1
  • 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. © 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. © 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. © 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. © 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. © 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. © 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. © 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. © 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. © 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. © 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. © 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. © 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. © 2013 Cloud Technology Partners, Inc. / Confidential15“Audience” : “Questions?”Erik.Sebesta@cloudtp.com / Chief Architect and Technology Officer (CATO) / June 12, 2013
  • 16. © 2013 Cloud Technology Partners, Inc. / Confidential16Appendix
  • 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. © 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. © 2013 Cloud Technology Partners, Inc. / Confidential19XML= Red, JSON= BlueXML vs. JSONData from Google Trends, June 4, 2013, Internet and Telecom category
  • 20. © 2013 Cloud Technology Partners, Inc. / Confidential20