Gateways to Gateways: API Development in the Cloud

•

0 gostou•86 visualizações

Treating APIs as a product can be the business case you need to push your application to the cloud. The Big Four can stand up legacy and new API implementations with low friction. This talk will show how to build APIs in the Cloud, how it ties into IaaS, and the infamous Netflix API Gateway Model.

Tecnologia

Gateways to
Gateways: API
Development in
the Cloud
nerdypaws /in/amycodes
Amy Arambulo Negrette
Cloud Software Engineer Lead
Cloudreach

2
Who am I?
Amy Negrette
I build a lot of APIs a lot
of different ways for a
lot of different people.
nerdypaws /in/amycodes

3
Let’s Talk
APIs
nerdypaws /in/amycodes

APIs and Where to Get Them
4
nerdypaws /in/amycodes

5
Decisions,
decisions!
nerdypaws /in/amycodes

6
Source: Docker.com | What is a Container?
Containers are like small, streamlined
virtual machines. Except where a virtual
machine is an entire system, OS and all, a
Container will only have an application
and its dependencies, using the OS and
Kernel of the machine it lives on.
For APIs housed in containers, an API, its
framework, and a webserver can live in
the container, while its required
infrastructure, such as a Linux or
Windows machine, remain outside.
Containers
nerdypaws /in/amycodes

7
Source: Docker.com | What is a Container?
Pros:
➢ Can move from machine to
machine
➢ No need to upskill API
developers*
➢ More Runtime Control
Containers
Cons:
➢ High overhead on Container
Maintenance
➢ One bad container... nerdypaws /in/amycodes

8
Serverless architecture uses Cloud
Native services to create an
infrastructure that does not need to be
managed by the Developer. It most often
uses a combination of a Cloud Provided
API Gateway and Functions as a Service
or Containers.
For developing APIs, the Cloud Provider
will create a collection of endpoints that
connect to a Cloud Compute Service
triggered by Events such as HTTP
Requests or Event Queues.
Serverless
nerdypaws /in/amycodes

9
Serverless
Pros:
➢ Lightweight
➢ Pay-as-you-go
➢ Cloud Native, Cloud
Optimized
Cons:
➢ A very different
Programming Paradigm
➢ Vendor Lock
➢ Developers touch more
Infrastructure
nerdypaws /in/amycodes

11
Lift & Shift
Pros:
➢ Least Code Changes
➢ Fastest to Live
➢ No Upskilling
Cons:
➢ Pay Per Hour
➢ Lose Optimization
nerdypaws /in/amycodes

12
Modernize
Pros:
➢ Optimized
➢ Future Proof
Cons:
➢ Slow to Market
➢ Requires overhaul of
infrastructure and software
➢ Language Specific
nerdypaws /in/amycodes

14
Zuul, Netflix’s Edge Gateway, allows
multiple video clients such as a Roku,
SmartTV, Smart Phone, Laptop, etc. to
connect to Netflix User and Streaming
Services using a single API Gateway to
connect to a Service layer which,
depending on the source and version,
returns the right data.
This works because the workflow for all
clients is the same. It looks for the same
things and returns data from the same
sources allowing Front End
optimization.
What it is
nerdypaws /in/amycodes

15
Even though Zuul is a multi-client API, it
is not a magic bullet. One cannot send
any number of different requests at a
single endpoint and infer where it should
go depending on the content without
previous development for that logic.
Design Requirements for a single
product API are the same for even Large
Service Gateways. Purpose and
Frequency will dictate how they are built.
What it isn’t
nerdypaws /in/amycodes

16
➢ Frequency and Size of Request are
still Important
➢ How similar are the Requests?
➢ How many end points will you have?
➢ How is this better than different
APIs?
Things to consider...
nerdypaws /in/amycodes

Summary
➔ Many ways into the
Cloud
➔ Containers vs
Serverless
➔ Modernization vs
Migration
➔ APIs have Limits
➔ Netflix’s API is
Case Specific
➔ APIs can do a lot,
but they shouldn’t
do everything
17
nerdypaws /in/amycodes

Let’s Talk!
18
nerdypaws
/in/amycodes
Amy Arambulo Negrette
Cloud Software Engineer
Cloudreach

Mais conteúdo relacionado

Mais de Pronovix

API docs frequently fail to address developers’ needs by omitting common usage scenarios and use cases. Let’s take a look at good and bad practices for documenting API use cases, and take steps to ensure that developers get from our API and docs what they really want. You wrote an API specification, documented your endpoints, and published SDKs. Here’s a question, though: Does your API actually solve your users’ problems? API providers often fail to address common use cases to solve users’ needs, or their assumptions don’t match the reality. This may end up in frustration and loss of users. In this talk, we will take a peek into developers’ mindset. I will show how to better understand the developers’ needs by researching the usage patterns, existing libraries and 3rd party experience layers, provide examples of good and bad practices, and suggest actionable steps to improve developer experience for your API.

Why your API doesn’t solve my problem: A use case-driven API design

Pronovix

unREST among the docs

Pronovix

Nobody likes ambiguity—especially when it comes to the stability of APIs and the expectations for availability long term. Avoid common pitfalls and explore a critical area where trust is built with developers through thoughtful policy and the development of best-in-class documentation. A good deprecation policy involves a lot of forward thinking and an awareness of how developers or end users are currently leveraging your capabilities, and how a given API or feature deprecation could affect them in the future. The hard-earned trust that you’ve built and maintained with these individuals is at risk with any type of policy or documentation that is unclear. The road to developing a clear, trustworthy deprecation policy is a multi-faceted initiative with input from product, engineering, customer success and other cross-functional teams, as well as external market awareness. Knowing which voices to have in the room, what the industry standards are, and formulating appropriate communication timelines will ensure a world class policy is developed and documented before it’s needed. Join us as we dive into the nuances of this process and how to avoid the common pitfalls that come from lacking a strategic, thoughtful approach to documenting a deprecation policy for your APIs.

Developing a best-in-class deprecation policy for your APIs

Pronovix

At MongoDB, we now generate REST API references for MongoDB Atlas from annotations in the product’s source. Our team’s writers proposed, planned, led, and implemented this project–and learned a lot along the way. We’ll share how we got buy-in from engineering and product stakeholders, coordinated the project across teams, implemented swagger-core annotations in Java, and drove positive change to benefit our team, the company, and our users.

Annotate, Automate & Educate: Driving generated OpenAPI docs to benefit everyone

Pronovix

It turns out there is no single answer. Developers may have unique goals, motivations, constraints, and challenges, and all of these influence how they approach the problem in front of them. However, more than a decade ago, three development styles were identified - systematic, pragmatic, and opportunistic - and the academic literature suggests that these still exist today. Two of the three approaches, the systematic and the opportunistic pattern, can be considered as opposite extremes, while the pragmatic approach is situated in between and is similar to both. It is not a personality trait - people may approach a situation one way or another depending on their circumstances, goals, and motivations (however, they may also have a preferred approach, which is usually their characteristic). Understanding the differences between these patterns (and the different needs) helps us to design in a way that serves most of the users, and even helps them to get into a state of flow by providing the optimal level of challenge to solve their problem.

What do developers do when it comes to understanding and using APIs?

Pronovix

It's time to take the bias out of code, UI, docs, configurations, or our everyday language by ensuring we choose our words carefully to avoid harmful subtext or exclusion. We can do our part and take steps by examining assets from code to config files to API specifications to standards. Heard of suss? You can suss out more information or you can find someone's information to be suss. "Suss" shows the flexibility of language. It’s an ongoing process to change how we use certain words. It's important to choose words carefully to convey the correct meaning and avoid harmful subtext or exclusion. Let's explore some of the tools and triage methods that it takes from an engineering viewpoint to make bias-free choices. How can you ensure that biased words do not sneak into code, UI, docs, configurations, or our everyday language? First, let's walk through how to take an inventory of assets from code to config files to API specifications to standards. Next, by placing those findings into categories, prioritize the work to substitute with inclusive alternatives. Let's examine some examples using both API and code assets. Next is a demonstration of how to automate analyzing your source code or documentation with a linter, looking for patterns based on rules that are fed into the tool. What's in the future for these efforts? Inclusive language should expand beyond English and North America efforts. To do so, let's organize the work with automation tooling, as engineers do.

Inclusive, Accessible Tech: Bias-Free Language in Code and Configurations

Pronovix

How to create documentation and write code for an international audience, not just the people who speak and think like you. Make your APIs more useful for everyone on the planet. Much of the documentation supplied by both Open Source and Close Souce projects assume the community have a good understanding of the English language and often North American culture as well. This creates barriers for many solution providers, who are the gateway to potentially huge markets for your project. This talk discusses some of the cultural differences, particularly for people from Asia, in using English language API documentation. It suggests some strategies to help diverse audiences understand you APIs and create solutions using them. The talk will cover not only differences in language but also other cultural differences that are often not obvious. For example: Different expectations about publication formats, release processes, levels of support during the development process Meeting and communications styles Software development workflows, processes, and tools Supporting people who are visually impaired will also be briefly discussed. As well as discussing these issues, specific suggestions will be provided to make API docs accessible for as many people as possible. This talk is based on Alec's work with customers in Europe, North America, Middle East, Asia, and Australasia. The last five have been spent as a developer evangelist working with PaperCut partners in China, Japan, Korea, US and Europe.

Creating API documentation for international communities

Pronovix

APIs in a modern enterprise are rarely uniform or all of the same type. The multitude of API types can be due to organic growth, mergers and acquisitions, or any number of other reasons. Regardless of their origin, APIs of all types need to be fully documented to facilitate a developer’s journey as they interact with your API ecosystem in order to develop useful applications. In this talk I will show examples of how we have augmented developer portals to document APIs that are not of the REST variety, such as AsyncAPI, GraphQL, SOAP, gRPC, and more, such that all API documentation can seamlessly live side-by-side.

One Developer Portal to Document Them All

Pronovix

We are a software engineering team creating API docs. Docs are authored using Instructional Design principles to narrate use-cases and practical API implementations. This talk shares why & how we've applied software development practices to evolve our document tooling, creation, & delivery methods. Our APIs describe asynchronous protocols used for embedded software (firmware) components in a digital 2-way radio communications system. The API is protocol data unit (PDU) based and its definition is described in a proprietary format; consequently, well-known API formats, such as Swagger/OpenAPI, or tools, such as doxygen, are not used. Our product training and technical writing teams are very experienced in Instructional Design methods, but these teams have only written documentation for an end-user audience. Understanding software development processes is equally important as understanding two-way radio networks in order to successfully integrate with the APIs. This is the rationale for having a software engineering team develop the skillsets to write API documentation for a developer audience. With a solid foundation of API documentation in place, regular examination of engineering efficiency and developer experience is appropriate. Repeated actions can be replaced by automation. Content can be modular and re-usable. Formats can be streamlined for easier consumption. Docs can be made portable and lightweight for faster delivery.

Docs-as-Code: Evolving the API Documentation Experience

Pronovix

Ever wonder how some products are just lovable and easy to use while other are not? The good products have optimized onboarding into their ecosystem where you get the information served at the right time. That’s thanks to developer journey and we will teach you how to get it right! We will go through the basics such as how to analyze existing and non-existing developer touchpoints, set metrics and optimize them to increase the conversion.

Developer journey - make it easy for devs to love your product

Pronovix

Deliberate Complexity Conferences - 19 JULY 2022 Alicia Juarrero - Complexity is not complicatedness Professor Alicia Juarrero, a leading complexity theory philosopher and academic, as well as the founder and president of VectorAnalytica, a technology company that specializes in large scale scientific data capture and real time analysis tools. Alicia's work in complexity theory is widely quoted by thought leaders in the technology space and referenced in many recent complexity-informed approaches for managing highly dynamic systems, as well as in knowledge management.

Complexity is not complicatedness

Pronovix

How cognitive biases and ranking can foster an ineffective architecture and d...

Pronovix

APIs: Semi-permeable, osmotic interfaces

Pronovix

How to develop an API ecosystem in the fintech industry from the ground up

Pronovix

Open sourcing Adyen’s API explorer

Pronovix

Creating Interactive Docs with Postman

Pronovix

Technical writing is rarely taught in code schools or listed among the qualifications for an engineering job. Yet developers rely heavily on documentation to use the tools they need to use. Not only that, decisions about which tool to use often take into account the availability of quality documentation. It’s important not to leave the task of writing docs to technical writers who may not fully understand the underlying technology or use cases. This talk will teach you the basics of technical writing–from tutorials and API reference guides to pull requests, release notes, and even code comments - so you can increase adoption of your software and keep the developers using it happy.

The Joy of Docs, or, Technical Writing for Developers and Engineers

Pronovix

I’d like to share how technical writers can pair up with product and development teams to measure and improve API references usability with additional content: use cases and best practices. We’ll take a closer look at the API design challenges and practical solutions. We’ll touch on the importance of spotting development and product biases when designing and developing the APIs, especially if technical writers were not involved in the process early on. I’ll share examples of how I work with multiple teams and manage dependencies, the tools we use, and the organizational methods we rely on to collaborate effectively. I will guide everyone through an API reference review example and discuss how writers can use API reviews as a way to get everyone, from design to development, on the same page.

Measure and improve API references with use cases: challenges and best practice

Pronovix

This talk describes the development of ABN AMRO’s API handbook, the single-source of truth for the development and management of internal and external API products. Our company is moving towards an API-First culture and mentality. Streamlining the development process is key to enabling this. In the beginning, API development knowledge was not documented or centralized in one location. Accurate information was not available for developer teams and they were not aware of what exactly the process entailed. My colleague and I began by making agreements on how the overall process works, describing it in an intuitive way, and then by making it open and accessible company-wide. This involved setting up and hosting face-to-face meetings or MS Teams calls with specialists to find out what was required This talk describes our approach to gathering content from experts, defining and refining processes, obtaining feedback from readers, and redesigning the content in a more user-centric format.

Blood, sweat, and creating an API handbook

Pronovix

Leveraging API Docs and Tools at Mercedes-Benz /developers

Pronovix

Mais de Pronovix (20)

Why your API doesn’t solve my problem: A use case-driven API design

unREST among the docs

Developing a best-in-class deprecation policy for your APIs

Annotate, Automate & Educate: Driving generated OpenAPI docs to benefit everyone

What do developers do when it comes to understanding and using APIs?

Inclusive, Accessible Tech: Bias-Free Language in Code and Configurations

Creating API documentation for international communities

One Developer Portal to Document Them All

Docs-as-Code: Evolving the API Documentation Experience

Developer journey - make it easy for devs to love your product

Complexity is not complicatedness

How cognitive biases and ranking can foster an ineffective architecture and d...

APIs: Semi-permeable, osmotic interfaces

How to develop an API ecosystem in the fintech industry from the ground up

Open sourcing Adyen’s API explorer

Creating Interactive Docs with Postman

The Joy of Docs, or, Technical Writing for Developers and Engineers

Measure and improve API references with use cases: challenges and best practice

Blood, sweat, and creating an API handbook

Leveraging API Docs and Tools at Mercedes-Benz /developers

Último

Join our latest Connector Corner webinar to discover how UiPath Integration Service revolutionizes API-centric automation in a 'Quote to Cash' process—and how that automation empowers businesses to accelerate revenue generation. A comprehensive demo will explore connecting systems, GenAI, and people, through powerful pre-built connectors designed to speed process cycle times. Speakers: James Dickson, Senior Software Engineer Charlie Greenberg, Host, Product Marketing Manager

Connector Corner: Accelerate revenue generation using UiPath API-centric busi...

DianaGray10

Sidekick Solutions uses Bonterra Impact Management (fka Social Solutions Apricot) and automation solutions to integrate data for business workflows. We believe integration and automation are essential to user experience and the promise of efficient work through technology. Automation is the critical ingredient to realizing that full vision. We develop integration products and services for Bonterra Case Management software to support the deployment of automations for a variety of use cases. This video focuses on the deployment of external web forms using Jotform for Bonterra Impact Management. This solution can be customized to your organization’s needs and deployed to support the common use cases below: - Intake and consent - Assessments - Surveys - Applications - Program registration Interested in deploying web form automations for Bonterra Impact Management? Contact us at sales@sidekicksolutionsllc.com to discuss next steps.

Web Form Automation for Bonterra Impact Management (fka Social Solutions Apri...

Jeffrey Haguewood

Polkadot JAM Slides - Token2049 - By Dr. Gavin Wood

Juan lago vázquez

Following the popularity of “Cloud Revolution: Exploring the New Wave of Serverless Spatial Data,” we’re thrilled to announce this much-anticipated encore webinar. In this sequel, we’ll dive deeper into the Cloud-Native realm by uncovering practical applications and FME support for these new formats, including COGs, COPC, FlatGeoBuf, GeoParquet, STAC, and ZARR. Building on the foundation laid by industry leaders Michelle Roby of Radiant Earth and Chris Holmes of Planet in the first webinar, this second part offers an in-depth look at the real-world application and behind-the-scenes dynamics of these cutting-edge formats. We will spotlight specific use-cases and workflows, showcasing their efficiency and relevance in practical scenarios. Discover the vast possibilities each format holds, highlighted through detailed discussions and demonstrations. Our expert speakers will dissect the key aspects and provide critical takeaways for effective use, ensuring attendees leave with a thorough understanding of how to apply these formats in their own projects. Elevate your understanding of how FME supports these cutting-edge technologies, enhancing your ability to manage, share, and analyze spatial data. Whether you’re building on knowledge from our initial session or are new to the serverless spatial data landscape, this webinar is your gateway to mastering cloud-native formats in your workflows.

Cloud Frontiers: A Deep Dive into Serverless Spatial Data and FME

Safe Software

Elevate Developer Efficiency & build GenAI Application with Amazon Q

Bhuvaneswari Subramani

MS Copilot expands with MS Graph connectors

Nanddeep Nachan

Six Myths about Ontologies: The Basics of Formal Ontology

johnbeverley2021

ProductAnonymous-April2024-WinProductDiscovery-MelissaKlemke

Product Anonymous

Passkeys: Developing APIs to enable passwordless authentication Cody Salas, Sr Developer Advocate | Solutions Architect - Yubico Apidays New York 2024: The API Economy in the AI Era (April 30 & May 1, 2024) ------ Check out our conferences at https://www.apidays.global/ Do you want to sponsor or talk at one of our conferences? https://apidays.typeform.com/to/ILJeAaV8 Learn more on APIscene, the global media made by the community for the community: https://www.apiscene.io Explore the API ecosystem with the API Landscape: https://apilandscape.apiscene.io/

Apidays New York 2024 - Passkeys: Developing APIs to enable passwordless auth...

apidays

Retrieval augmented generation (RAG) is the most popular style of large language model application to emerge from 2023. The most basic style of RAG works by vectorizing your data and injecting it into a vector database like Milvus for retrieval to augment the text output generated by an LLM. This is just the beginning. One of the ways that we can extend RAG, and extend AI, is through multilingual use cases. Typical RAG is done in English using embedding models that are trained in English. In this talk, we’ll explore how RAG could work in languages other than English. We’ll explore French, Chinese, and Polish.

Introduction to Multilingual Retrieval Augmented Generation (RAG)

Zilliz

MINDCTI Revenue Release Quarter One 2024

MIND CTI

Whatsapp Number Escorts Call girls 8617370543 Available 24x7 Mcleodganj Call Girls Service Offer Genuine VIP Model Escorts Call Girls in Your Budget. Mcleodganj Call Girls Service Provide Real Call Girls Number. Make Your Sexual Pleasure Memorable with Our Mcleodganj Call Girls at Affordable Price. Top VIP Escorts Call Girls, High Profile Independent Escorts Call Girls, Housewife Women Escorts Call Girl, College Girls Escorts Call Girls, Russian Escorts Call girls Service in Your Budget.

Mcleodganj Call Girls 🥰 8617370543 Service Offer VIP Hot Model

Deepika Singh

Repurposing LNG terminals for Hydrogen Ammonia: Feasibility and Cost Saving

Edi Saputra

The value of a flexible API Management solution for Open Banking Steve Melan, Manager for IT Innovation and Architecture - State's and Saving's Bank of Luxembourg Apidays New York 2024: The API Economy in the AI Era (April 30 & May 1, 2024) ------ Check out our conferences at https://www.apidays.global/ Do you want to sponsor or talk at one of our conferences? https://apidays.typeform.com/to/ILJeAaV8 Learn more on APIscene, the global media made by the community for the community: https://www.apiscene.io Explore the API ecosystem with the API Landscape: https://apilandscape.apiscene.io/

Apidays New York 2024 - The value of a flexible API Management solution for O...

apidays

Dubai, known for its towering skyscrapers, luxurious lifestyle, and relentless pursuit of innovation, often finds itself in the global spotlight. However, amidst the glitz and glamour, the emirate faces its own set of challenges, including the occasional threat of flooding. In recent years, Dubai has experienced sporadic but significant floods, disrupting normalcy and posing unique challenges to its infrastructure. Among the critical nodes in this bustling metropolis is the Dubai International Airport, a vital hub connecting the world. This article delves into the intersection of Dubai flood events and the resilience demonstrated by the Dubai International Airport in the face of such challenges.

Rising Above_ Dubai Floods and the Fortitude of Dubai International Airport.pdf

Orbitshub

DBX First Quarter 2024 Investor Presentation

Dropbox

Boost Fertility New Invention Ups Success Rates.pdf

sudhanshuwaghmare1

Scaling API-first – The story of a global engineering organization Ian Reasor, Senior Computer Scientist - Adobe Radu Cotescu, Senior Computer Scientist - Adobe Apidays New York 2024: The API Economy in the AI Era (April 30 & May 1, 2024) ------ Check out our conferences at https://www.apidays.global/ Do you want to sponsor or talk at one of our conferences? https://apidays.typeform.com/to/ILJeAaV8 Learn more on APIscene, the global media made by the community for the community: https://www.apiscene.io Explore the API ecosystem with the API Landscape: https://apilandscape.apiscene.io/

Apidays New York 2024 - Scaling API-first by Ian Reasor and Radu Cotescu, Adobe

apidays

Keynote 2: APIs in 2030: The Risk of Technological Sleepwalk Paolo Malinverno, Growth Advisor - The Business of Technology Apidays New York 2024: The API Economy in the AI Era (April 30 & May 1, 2024) ------ Check out our conferences at https://www.apidays.global/ Do you want to sponsor or talk at one of our conferences? https://apidays.typeform.com/to/ILJeAaV8 Learn more on APIscene, the global media made by the community for the community: https://www.apiscene.io Explore the API ecosystem with the API Landscape: https://apilandscape.apiscene.io/

Apidays New York 2024 - APIs in 2030: The Risk of Technological Sleepwalk by ...

apidays

FWD Group - Insurer Innovation Award 2024

The Digital Insurer

Gateways to Gateways: API Development in the Cloud

1. Gateways to Gateways: API Development in the Cloud nerdypaws /in/amycodes Amy Arambulo Negrette Cloud Software Engineer Lead Cloudreach

2. 2 Who am I? Amy Negrette I build a lot of APIs a lot of different ways for a lot of different people. nerdypaws /in/amycodes

3. 3 Let’s Talk APIs nerdypaws /in/amycodes

4. APIs and Where to Get Them 4 nerdypaws /in/amycodes

5. 5 Decisions, decisions! nerdypaws /in/amycodes

6. 6 Source: Docker.com | What is a Container? Containers are like small, streamlined virtual machines. Except where a virtual machine is an entire system, OS and all, a Container will only have an application and its dependencies, using the OS and Kernel of the machine it lives on. For APIs housed in containers, an API, its framework, and a webserver can live in the container, while its required infrastructure, such as a Linux or Windows machine, remain outside. Containers nerdypaws /in/amycodes

7. 7 Source: Docker.com | What is a Container? Pros: ➢ Can move from machine to machine ➢ No need to upskill API developers* ➢ More Runtime Control Containers Cons: ➢ High overhead on Container Maintenance ➢ One bad container... nerdypaws /in/amycodes

8. 8 Serverless architecture uses Cloud Native services to create an infrastructure that does not need to be managed by the Developer. It most often uses a combination of a Cloud Provided API Gateway and Functions as a Service or Containers. For developing APIs, the Cloud Provider will create a collection of endpoints that connect to a Cloud Compute Service triggered by Events such as HTTP Requests or Event Queues. Serverless nerdypaws /in/amycodes

9. 9 Serverless Pros: ➢ Lightweight ➢ Pay-as-you-go ➢ Cloud Native, Cloud Optimized Cons: ➢ A very different Programming Paradigm ➢ Vendor Lock ➢ Developers touch more Infrastructure nerdypaws /in/amycodes

10. 10 Legacy APIs nerdypaws /in/amycodes

11. 11 Lift & Shift Pros: ➢ Least Code Changes ➢ Fastest to Live ➢ No Upskilling Cons: ➢ Pay Per Hour ➢ Lose Optimization nerdypaws /in/amycodes

12. 12 Modernize Pros: ➢ Optimized ➢ Future Proof Cons: ➢ Slow to Market ➢ Requires overhaul of infrastructure and software ➢ Language Specific nerdypaws /in/amycodes

13. 13 nerdypaws /in/amycodes

14. 14 Zuul, Netflix’s Edge Gateway, allows multiple video clients such as a Roku, SmartTV, Smart Phone, Laptop, etc. to connect to Netflix User and Streaming Services using a single API Gateway to connect to a Service layer which, depending on the source and version, returns the right data. This works because the workflow for all clients is the same. It looks for the same things and returns data from the same sources allowing Front End optimization. What it is nerdypaws /in/amycodes

15. 15 Even though Zuul is a multi-client API, it is not a magic bullet. One cannot send any number of different requests at a single endpoint and infer where it should go depending on the content without previous development for that logic. Design Requirements for a single product API are the same for even Large Service Gateways. Purpose and Frequency will dictate how they are built. What it isn’t nerdypaws /in/amycodes

16. 16 ➢ Frequency and Size of Request are still Important ➢ How similar are the Requests? ➢ How many end points will you have? ➢ How is this better than different APIs? Things to consider... nerdypaws /in/amycodes

17. Summary ➔ Many ways into the Cloud ➔ Containers vs Serverless ➔ Modernization vs Migration ➔ APIs have Limits ➔ Netflix’s API is Case Specific ➔ APIs can do a lot, but they shouldn’t do everything 17 nerdypaws /in/amycodes

18. Let’s Talk! 18 nerdypaws /in/amycodes Amy Arambulo Negrette Cloud Software Engineer Cloudreach

Gateways to Gateways: API Development in the Cloud

Recomendados

Recomendados

Mais conteúdo relacionado

Mais de Pronovix

Mais de Pronovix (20)

Último

Último (20)

Gateways to Gateways: API Development in the Cloud