2018 Madrid API Event Recap
•Télécharger en tant que PPTX, PDF•
0 j'aime•65 vues
Este documento presenta información sobre dos expertos en tecnologías Microsoft, Sergio Hernández Mancebo y Alberto Díaz Martín. Sergio es ingeniero informático y cuenta con certificaciones en SharePoint 2010 y aplicaciones web. Tiene más de 6 años de experiencia desarrollando con tecnologías Microsoft centrado en SharePoint y Azure. Alberto tiene más de 15 años de experiencia en la industria TI trabajando con tecnologías Microsoft. Es reconocido como experto en SharePoint, Office 365 y Azure.
Recommandé
Contenu connexe
Similaire à 2018 Madrid API Event Recap
Similaire à 2018 Madrid API Event Recap (20)
Plus de Alberto Diaz Martin
Plus de Alberto Diaz Martin (20)
Dernier
Dernier (20)
2018 Madrid API Event Recap
- 1. 2018 - Madrid Sponsor: Gobierno de APIs Sergio Hernandez Mancebo (@shmancebo) Alberto Diaz Martin (@adiazcan)
- 2. Sergio Hernández Mancebo shernadez@encamina.com - @shmancebo Sergio Hernández Mancebo es Ingeniero Informático por la Universidad Complutense de Madrid y certificado en MCPD en Sharepoint 2010 y MCSD en Web Aplication. Lleva desarrollando con tecnologías Microsoft más de 6 años y desde sus inicios está centrado en el desarrollo sobre SharePoint y actualmente emplea sus esfuerzos en desarrollos sobre Azure y O365. Actualmente es Principal Team Leader liderando la gestión de equipos de desarrollo en ENCAMINA una consultora informática de Valencia que se destaca por realizar soluciones basadas en Tecnología Microsoft, principalmente en SharePoint. Es colaborador de la revista CompartiMOSS y en los blogs oficiales de Encamina. Además es participa activamente en eventos presenciales y online de la comunidad .Net
- 3. Alberto Diaz Martin alberto.diaz@encamina.com - @adiazcan Alberto Diaz cuenta con más de 15 años de experiencia en la Industria IT, todos ellos trabajando con tecnologías Microsoft. Actualmente, es Chief Technology Innovation Officer en ENCAMINA, liderando el desarrollo de software con tecnología Microsoft, y miembro del equipo de Dirección. Para la comunidad, trabaja como organizador y speaker de las conferencias más relevantes del mundo Microsoft en España, en las cuales es uno de los referentes en SharePoint, Office 365 y Azure. Autor de diversos libros y artículos en revistas profesionales y blogs, en 2013 empezó a formar parte del equipo de Dirección de CompartiMOSS, una revista digital sobre tecnologías Microsoft. Desde 2011 ha sido nombrado Microsoft MVP, reconocimiento que ha renovado por séptimo año consecutivo. Se define como un geek, amante de los smartphones y desarrollador. Fundador de TenerifeDev (www.tenerifedev.com), un grupo de usuarios de .NET en Tenerife, y coordinador de SUGES (Grupo de Usuarios de SharePoint de España, www.suges.es)
- 4. APIs and API economy Cloud2-speed IT Mobile Analytics IoT Microservices
- 5. Azure API Management AZURE API MANAGEMENT
- 6. Azure API Management On-prem APIs 3rd party APIs AZURE API MANAGEMENT APIs on Azure Azure APIs
- 7. Azure API Management On-prem APIs 3rd party APIs AZURE API MANAGEMENT APIs on Azure Azure APIs API consumers
- 8. An API program is much more than just having APIs… developer registration partner access SOAP to REST XML to JSON façade layer x-domain calls publisher analytics developer analytics caching URL masking status codes IP filtering rate limiting issue tracking Branded developer portal
- 9. APP DEVELOPERS APPS API MANAGERS Hosted anywhere Developed using any technology BACKEND APIs DIRECT VPN ExpressRoute Admin portal Gateway Developer Portal
- 11. Objetivos del GOBIERNOEl objetivo es conseguir el EXITO de las Aplicaciones que nos consumen Debemos tratar el sistema como un PRODUCTO Aseguramos la ADOPCIÓN de los desarrolladores que consumen el proxy Construida basa de un ESTANDAR e INDEPENDIENTE de cualquier sistema Diseñado pensando en quien nos consume, con el objetivo de FACILITAR su uso Es un proxy no un bus, se debe pensar en SIMPLIFICAR y EVITAR la lógica de negocio Potenciamos la MONITORIZACION y el CONSUMO para asegurar el servicio, la evolución del producto en busca de mayor RENDIMIENTO y DEPRECANDO lo inservible SEGURIDAD, y más SEGURIDAD, esto es el CORE de MM CACHE, como mejor aliado del RENDIMIENTO Nuestro gobierno no lo marca nuestro estilo de liderazgo!!
- 12. Arquitectura genérica Api Proxy - Azure
- 16. API Contract
- 17. API Management Versions and Revisions
- 19. Managing Change with API Management Developer portal for advertising change OpenAPI Contract Gateway façade for hiding changes Versions and Revisions for temporal control
- 21. Modelos de despliegue y Gestión de entornos
- 23. Deployment flow
- 24. Environments
- 26. Copy paste, Swagger Export/Import Pros Easy to get started Reliable deployments? Doing the same mistakes over and over again Cons How to make sure all resources are update?? Policies on Multiple levels OAuth Backends
- 27. PowerShell / REST Pros All functions needed Flexibility What if we add something new? Cons More time spend developing the deployment process Does the scripts / Flow takes this into consideration??
- 28. GIT Pros Release and deploy in separate steps History in all changes Contains almos all resources: Missing Named Values (Properties) Cons File based Need PowerShell to edit URL’s etc Rengerate Password every 30 days*
- 29. ARM Templates Pros Standard Azure deployment Contains all resources Out of bot Support for Key Vault during deployments generate keys etc Cons Preview (export not 100% correct) Need PowerShell to “fix” template
- 30. GIT Setup
- 31. ARM Setup
- 33. Summary Gobierno de APIS Producto Definir el ciclo de vida de tus APIs
Notes de l'éditeur
- API economy makes APIs a first class concept Not just an implementation detail that only devs care about It is a contract between providers and consumer API maybe just a supporting function Driving mobile app, or 3rd party integration Or actually a product in itself Critical part of the business service
- First is APIM creates a public facade over your APIs and decouples API implementations or backends from API consumers enabling them to evolve independently. This includes hiding all APIs regardless of their location behind a single domain name and API address. Exposing only a subset of backend capabilities to API consumers. Modernizing and normalizing APIs by changing their URL structure and response formats. Optimizing APIs for specific consumers and scenarios by conditionally stripping down the responses. Dynamically routing requests to implement advanced versioning approaches Second, APIM allows API implementers to externalize and centralize common cross cutting concerns and focus on the core value, the domain related logic. Security, throttling, cross domain access and response caching are just a few horizontal capabilities you'll get from APIM. APIM supports API key, JWT token validation as well as IP based authorization. We offer a number of cross domain techniques including full support for CORS. APIM implements distributed quota and rate limiting policies that allow a great degree of flexibility and scale. It comes with built in response cache and policies that allow fine grained control over what and how gets cached Having insight into usage and health of your APIs is important and APIM captures metrics and provides key reports out of the box. For those customers who are looking to monetize their APIs we collect and offer via API data allowing them to implement a variety of subscription business models. With APIM Developer portal you can treat internal and external developers the same way from the get go and provide them with a self service on-boarding experience, AP catalog, documentation, samples, and allow them to send request to your APIs without writing a line of code. ■ Know who API users are and engage them like customers. Whether the developers programming to one’s APIs are inside the organization or outside, knowing who they are is a foundation of API success. For an API provider that charges for API use, like Twilio and SendGrid, this is of course necessary for collecting revenue, but even for free access, as with New York’s and Chicago’s transit systems’ APIs, knowing API users enables greater understanding of how APIs are used and what direction to take APIs in the future. API users, whether they pay or not, should be engaged as customers. ■ Clarify the rules of API access. For reasons of capacity management and security, access to APIs is rarely unlimited. But customers (i.e., API users in this case) don’t like surprises, so the rules for access must be clear, such as what data may be accessed and how many requests are allowed per minute or per month. is may include de nition of di erent access plans with di erent rules for di erent API users. Make it easy to use the API. rough documentation, examples, and discussion forums, it must be easy for API users to understand the API, get answers to questions, test API usage, and migrate between API versions. Although REST services are needed for mobile, other styles of services may also be part of an enterprise API strategy (e.g., SOAP, message queuing). Enforce the rules of API access. API providers must validate that incoming API requests are authorized and comply with the rules de ned by the access plan each API user is associated with. Proactively manage API success by treating it as a product. Whether API users are internal, external, or both, to optimize the business value of an API, the API provider must treat it as a product with customers and a life cycle. Whether via basic reporting or advanced analytics, API providers must understand patterns of API access, including error rates that may indicate the API is di cult to understand. New versions of the API need a smooth and managed rollout to API users. ■ Connect API access to functions and data within their technology estate. APIs deliver their value by connecting to the API provider’s data and applications. Some of these assets may be API- ready, while others may need some manner of integration connectivity to make them accessible.
- APIM is a management layer atop all of your APIs regardless of their location or technology stack. You can also use it to publish on-prem APIs, expose 1st party Azure APIs in a simplified manner directly to your partners, or expose functionality provided by 3rd party APIs.
- Three components: dev portal, gateway, admin portal … Backend hosted anywhere on any platform, As long as it is a HTTP API
- HTTP APIs are different … In order to clear make this distinction, Introduce new language
- Terms usually used interchangeably … Alternative to the semantic versioning model, because breaking changes can’t be defined. Revisions need to meet an API Providers “Change Level Agreement”
- So, how can API Mgmt help us deal with versions and revisions Developer portal is a customizable web site that provides tools and documentation to learn about API Used to advertise new versions API Contract is the interface. It’s the WHAT is changing. Changes in contract may be versions or revisions, depends on CLA Gateway acts as a façade to the API implementation isolate the backend Where revisions hide Let’s look into these three aspects a little bit more and then we will see how the product enables it
- Developer portal is about facilitating on-boarding API community has recognized this as critical to adoption Change is irrelevant if no-one is using your API Self-service sign-on support for many IdPs Monitor for reliability and performance Review reports for usage Knowing what to change is as important as how
- API Description formats define an interface. WSDL came first for SOAP -> protocol independent API WADL is XML based from the Java world OpenAPI (fka Swagger) JSON based, very popular MSFT using it in many products. Handle both revisions and versions