Accelerating API Development With OpenAPI and Serverless
•Als PPTX, PDF herunterladen•
0 gefällt mir•272 views
Learn how OpenAPI and Serverless can help your team deliver APIs faster with Keshav Vasudevan, Product Marketing Manager at SmartBear.
Empfohlen
Empfohlen
Weitere ähnliche Inhalte
Was ist angesagt?
Was ist angesagt? (20)
Ähnlich wie Accelerating API Development With OpenAPI and Serverless
Ähnlich wie Accelerating API Development With OpenAPI and Serverless (20)
Mehr von SmartBear
Mehr von SmartBear (20)
Kürzlich hochgeladen
Kürzlich hochgeladen (20)
Accelerating API Development With OpenAPI and Serverless
- 1. Accelerating API Development With OpenAPI And Serverless Keshav Vasudevan @keshinpoint
- 2. Page Proprietary & Confidential 2 Twitter: @keshinpoint Traditional API Development Plan Develop Test Deploy Documentation? Business objectives? Sustainability?
- 3. Page Proprietary & Confidential 3 Twitter: @keshinpoint But APIs can no longer just be data driven,but MUST focus on sustainabilityand self service Growth and monetizationopportunities Speedto market
- 4. Page Proprietary & Confidential 4 Twitter: @keshinpoint Growth and Monetization
- 5. Page Proprietary & Confidential 5 Twitter: @keshinpoint Trend1: Platforms Drive The Internet’s GDP The internet drives over 1.2 trillion Euros in sales Platform ecosystems are a major driver of this growth Source:Stripe
- 6. Page Proprietary & Confidential 6 @keshinpoint Life in a monolith Implementation API Backend Developers Frontend Developers Client A Client B Client C … Database
- 7. Page Proprietary & Confidential@keshinpoint Life In a Monolithic Dependency Stakeholders Build Application Code Check in to Repo Deploy Happy customers Test 7
- 8. Page Proprietary & Confidential@keshinpoint A Monolithic Dependency Codebase 1 Codebase 2 Check in to repo Deploy Check in to repo Deploy Codebase 3 Deploy 8
- 9. Page Proprietary & Confidential@keshinpoint A Nightmare of Failures Codebase 1 Codebase 2 Check in to repo Deploy Check in to repo Deploy Codebase 3 Deploy Check in to repo Code failure 9
- 10. Page Proprietary & Confidential 10 Twitter: @keshinpoint Moving faster with better services decoupling Model Companies
- 11. Page Proprietary & Confidential 11 @keshinpoint The Jeff Bezos Mandate This was issued in 2002!
- 12. Page Proprietary & Confidential 12 Twitter: @keshinpoint To remain competitive and move faster today .. • The ModernAPI is no longer datadriven, but consumer driven • The ModernAPI is staged for self service development and consumption • The ModernAPI is built for speed of updating and maintenance • The ModernAPI has a common vocabulary Reusable interfacesbased on HTTP standards that allow for reuse of data and functions, built for consumer demand and self-service
- 13. Page Proprietary & Confidential 13 @keshinpoint An API First Approach Backend Developers Frontend Developers Client A Database Implementation Implementation Implementation Mock Mock Mock API interface API interface API interface Client B Client C
- 14. Page Proprietary & Confidential 14 Twitter: @keshinpoint Conceptualizing service interface Designing with a definition forces you to think about - Identify organization’s business taxanomy - Map APItoorganization’s taxanomy Tangibleoutcometointernalprocesses Tangibleoutcometobusiness Tangibleoutcometocustomer
- 15. Page Proprietary & Confidential 15 Twitter: @keshinpoint The OpenAPI Specification • AdefinitionisaframeworkfordescribingAPIs • MachineANDhumanreadable • Languageagnostic The OpenAPI Specification (OAS)is the world’s standard for defining RESTful API
- 16. Page Proprietary & Confidential 16 OpenAPI example API Info API Request API Response Twitter: @keshinpoint
- 17. Page Proprietary & Confidential A common vocabulary Call the API (request) Obtain data (response) Restful Interface Technical Writer Developer Tester Architect Keeps in Sync 17 Twitter: @keshinpoint
- 18. Page Proprietary & Confidential 18 Twitter: @keshinpoint OAS opens up a world of possibilities
- 19. Page Proprietary & Confidential 19 @keshinpoint An API First approach Backend Developers Frontend Developers Client A Database Implementation Implementation Implementation Mock Mock Mock API interface API interface API interface Client B Client C
- 20. Page Proprietary & Confidential 20 Twitter: @keshinpoint Developers have to be aware of servers
- 21. Page Proprietary & Confidential 21 Twitter: @keshinpoint The Evolution of software development Datacenter Deployment - Deploy in months - Live for years Virtualized Cloud Deployment - Deploy in minutes - Live for weeks Container Deployment - Deploy in seconds - Live for minutes/hrs ?
- 22. Page Proprietary & Confidential 22 Twitter: @keshinpoint Enter Serverless • AnoverarchingideaofservicesbeingbackedwithoutYOUmanagingtheservers • Scalesondemand • Costperinvocation
- 23. Page Proprietary & Confidential 23 Twitter: @keshinpoint Take an example Scott wants to buildan e-commerce applicationthat allows users to buy pets Search Buy Authentication
- 24. Page Proprietary & Confidential 24 Building the API that supports this app through FaaS API Gateway Purchase (Lambda Function) Client (browser) HTTP request Search (Lambda Function) Result Result Query HTTP response Query Database Throttling Auth
- 25. Page Proprietary & Confidential 25 Twitter: @keshinpoint Petstore function Focus on the business logic function only No development of the server framework to support the business logic
- 26. API First With OAS And Serverless Twitter: @keshinpoint 2 6
- 27. Page Proprietary & Confidential 27 @keshinpoint API First adoption guidelines 1. Planning for the Shift 2. Designing the Service 3. Developing the Service 4. Deploying and Consuming the Service
- 28. Page Proprietary & Confidential 28 @keshinpoint Planning the shift Proposal Align Review Design DevelopVerify Deploy Used by
- 29. Page Proprietary & Confidential 29 @keshinpoint Designing the service: business objective of services APIsExistFor a Reason • Identify your organization’s business taxonomy– outer bounds of business capabilities • Conceptualize APIs that exist within these bounds DeterminingWhy API Exists • What tangible outcome can service bring to overall business? • What tangible outcome can service bring to customer? • What tangible outcome can service bring to internal processes?
- 30. Page Proprietary & Confidential 30 @keshinpoint Conceptualizing the Service: The Top Down Approach
- 31. Page Proprietary & Confidential 31 @keshinpoint Conceptualizing the Service: Design theAPI Tools todesign APIs SwaggerHubSwagger Editor
- 35. Page Proprietary & Confidential 35 Twitter: @keshinpoint Code-Generation From The Definition The OAS definition allows you togenerate serverstubs and clientSDKs directlyfrom the definition Codegeneration Developer Consumer
- 39. Page Proprietary & Confidential 39 @keshinpoint Deploying the Service: Catalog Services WhyCatalog? • Maybethemost importantpieceofinfrastructureneeded • Needtoconsolidatediscovery,documentation,SDKs,andoverall engagement • Criticalpiecefor internalcommunication • Centralsourceoftruthalsohelpsenforceotherdevstofollowandintegrate withAPIs CatalogMVP • InventoryofAPIswithownershipinformation • ShowsallrelevantversionsofanAPI • Supportscollaborationandaccesscontrol • Documentationhosting • SupportsSDKs • CommunicationandFeedback
- 40. Page Proprietary & Confidential@keshinpoint API First using OAS and Lambda Design First Communication and Collaboration Governance and Guidelines Serverless implementation Cataloging and Discovery
Hinweis der Redaktion
- 30% of world’s companies are trying to build a digital ecosystem Platforms account for a majority of the internet’s revenue APIs are the centerfold to Platform and API Economy APIs driving strategic business goals with unique business models
- Too many interdependencies Time consuming to add new features or fix bugs Decrease go-to-market
- API-first development will allow parallel development by all teams without the need to wait for changes to be released by one team or another. In the picture above, we can see the first the APIs that are created are mocks. Second, both back-end, front-end, and test teams are starting to work with the mocked APIs. Once the API is ready, all teams can switch to the production or staging API. This saves a lot of development time.
- The definition of your problem space has a big impact on how you think about solving your problem. One way to help ensure you’re always building platform capabilities and not just point solutions is to clearly define the capabilities that compose your business. These become your problem spaces. Business capabilities represent the core, reusable building blocks that your business needs to support the business processes required to function. By defining your business capability taxonomy, you establish a shared language that can be used by all domains to describe the logical relationships in any given process. This serves as a stable, business-driven (not technology-driven) context in which to discuss solutions that, hopefully, remains relatively consistent over time. Is also provides a critical link between how the Business thinks about its investments and how Technology leverages them.
- API-first development will allow parallel development by all teams without the need to wait for changes to be released by one team or another. In the picture above, we can see the first the APIs that are created are mocks. Second, both back-end, front-end, and test teams are starting to work with the mocked APIs. Once the API is ready, all teams can switch to the production or staging API. This saves a lot of development time.
- In traditional software development, the software engineer had to be acutely aware of the concept of a server. Servers are where their software runs. Servers communicate with each other. Servers have IP addresses which need to be discovered. Servers go down which must to be accounted for. Servers have local state that is not visible to other servers. Many facets of software development revolved around the first class concept of a server. Developers write code that implements business logic. Durable state needs to be externalized, local storage mechanisms are for optimization only. Business logic is addressable, not individual servers. https://auth0.com/blog/what-is-serverless/
- Serverless Computing allows me to do what I enjoy, which is write code, without having to provision and/or configure servers. Using the AWS Serverless Platform means that all the heavy lifting of server management is handled by AWS, allowing you to focus on building your application. Serverless can also mean applications where some amount of server-side logic is still written by the application developer but unlike traditional architectures is run in stateless compute containers that are event-triggered, ephemeral (may only last for one invocation), and fully managed by a 3rd party. https://aws.amazon.com/blogs/aws/build-your-first-serverless-application/
- Let’s think about a traditional 3-tier client-oriented system with server-side logic. A good example is the petstore example. Where a user can search for pets in an online store and make a purchase Traditionally the architecture will look something like this, with HTML/JS on the front end, and Java implemented on the server. With this architecture the client can be relatively unintelligent, with much of the logic in the system - authentication, page navigation, searching, transactions - implemented by the server application. If we use serverless fucntions instead, then we can “outsource” all of the server framework development to third party vendors, and our only focus would be the server logic. It gives us flexibility in the client to use the various responses given by these functions and add in their own logic to it.
- The definition of your problem space has a big impact on how you think about solving your problem. One way to help ensure you’re always building platform capabilities and not just point solutions is to clearly define the capabilities that compose your business. These become your problem spaces. Business capabilities represent the core, reusable building blocks that your business needs to support the business processes required to function. By defining your business capability taxonomy, you establish a shared language that can be used by all domains to describe the logical relationships in any given process. This serves as a stable, business-driven (not technology-driven) context in which to discuss solutions that, hopefully, remains relatively consistent over time. Is also provides a critical link between how the Business thinks about its investments and how Technology leverages them.
- This piece of infrastructure may be the most important. Given the scale of a large organization, you really need a central place to consolidate all APIs, all documentation, the engagement process, and the overall program status and progress. This ends up becoming the internal developer portal and it’s critical to communicate with and coordinate the actions of the organization. This investment hasn’t been trivial, but it’s been absolutely essential to operationalize the goals of the program.