Ce diaporama a bien été signalé.
Le téléchargement de votre SlideShare est en cours. ×

Non solo Microservizi: API, Prodotti e Piattaforme

Non solo Microservizi: API, Prodotti e Piattaforme

Télécharger pour lire hors ligne

Il trend dei Microservizi coesiste e si confonde con
quello delle API. Le API moderne però non sono più quelle
delle prime Internet Companies: molto è cambiato, e
molto sta accadendo. Proviamo a esaminare un altro punto di vista.

Il trend dei Microservizi coesiste e si confonde con
quello delle API. Le API moderne però non sono più quelle
delle prime Internet Companies: molto è cambiato, e
molto sta accadendo. Proviamo a esaminare un altro punto di vista.

Plus De Contenu Connexe

Livres associés

Gratuit avec un essai de 30 jours de Scribd

Tout voir

Non solo Microservizi: API, Prodotti e Piattaforme

  1. 1. ...non solo Microservizi: API, Prodotti e Piattaforme!... Marzo 2021 STEFANO FAGO
  2. 2. Se dicessi API…
  3. 3. … Pensate a...
  4. 4. ...O forse pensate a...
  5. 5. ...O forse pensate a...
  6. 6. Cosa sono le API? API è l'acronimo di Application Programming Interface, cioè un intermediario software che consente a due applicazioni di dialogare tra loro. Un'API è un insieme di funzioni che consente di creare applicazioni che accedono alle funzionalità o ai dati di un'altra applicazione o servizio.
  7. 7. API Oggi... API è una chiave d’accesso ad un universo di concetti, strumenti, architetture ed in generale un Ecosistema che raccoglie sforzi ed iniziative sempre più avanzate!
  8. 8. Internet Companies & API
  9. 9. Internet Companies & API Il Bezos Mandate è considerato la chiave del successo di Amazon! E’ stato innescato dall'aumento dei costi dei team all'interno di Amazon (mancanza di modi coerenti e ben gestiti di scambiare dati e capacità tra loro) e dal conseguente rallentamento delle pianificazioni di business di Bezos. Il Bezos Mandate ci ricorda dei concetti cardine:  Connubio tra Business & IT  Esposizione di Dati e Funzionalità  Fondarsi sulla comunicazione tramite interfacce e standardizzare le interazioni dei dati  Essere agnostici dal punto di visto delle Tecnologie usate  Progettare per “l’Esterno” come Paradigma https://www.cio.com/article/3218667/have-you-had-your-bezos-moment-what-you-can-learn-fr om-amazon.html
  10. 10. API & Business << ...Le API sono passate dall’iniziale stato di tecnica di sviluppo ad un driver del modello di business. Le risorse principali di un'organizzazione possono essere riutilizzate, condivise, e monetizzate tramite API che possono estendere la portata dei servizi esistenti o fornire nuovi flussi di entrate. Le API dovrebbero essere gestite come un prodotto, costruito su una tecnica complessa improntata ad includere sistemi e dati legacy e di terze parti… >> [ Deloitte Consulting ]
  11. 11. Definizione di Prodotto Cos'è un prodotto? • etichettato • confezionato • facile da usare • documentato • supportato da un business
  12. 12. Time-To-Market, Prodotto e MVP Un prodotto per essere considerato efficace deve posizionarsi opportunamente sul mercato e questo significa considerarne le evoluzioni. La rapidità delle odierne evoluzioni di mercato porta alla visione di Minimum Viable Product. MVP è una versione di un prodotto con caratteristiche appena sufficienti per essere utilizzabile dai primi clienti che possono quindi fornire feedback per lo sviluppo futuro del prodotto. Concentrarsi sul rilascio di un MVP significa che gli sviluppatori potenzialmente evitano il lavoro lungo e non necessario.
  13. 13. API as Product e VPI Le API che divengono prodotti portano al concetto di VPI: Value Proposition Interface La Value Proposition è la proposta di valore che un’azienda fa al mercato, espressa in termini di vantaggi percepiti, tangibili o meno, che i consumatori possono ottenere dall’acquisto della soluzione proposta sul mercato. Le API non sono più orientate all’applicativo ma vengono progettate insieme al business per offrire un prodotto che esprima la Value Proposition aziendale. API Product Management : https://www.youtube.com/watch?v=G0xASUzunaQ
  14. 14. API & API Economy API Economy: Interazioni di mercato create con alla base una connessione API API Economy si riferisce, dunque, al modo in cui le API possono positivamente influire sulla redditività di un'azienda, consentendo di scalare rapidamente grazie all’accesso a dati e servizi di terze parti o trasformare i propri servizi e dati in una piattaforma che attrae partner su cui costruire nuovi servizi e che porta nuovi clienti.
  15. 15. Macro e Micro Economy Nell’ambito API Economy si parla di Macro-Economy riferendosi alle transazione tra Aziende mentre si parla di Micro-Economy nel caso di interazioni interne ad una data azienda tramite API. E’ possibile distinguere tre tipologie di API in base al ruolo che giocano all’interno o all’esterno dell’ecosistema aziendale. Partner API Private API Public API
  16. 16. API: Internal vs External http://dret.net/lectures/oreilly-sa-ca-2019/
  17. 17. API Economy & Market Place L’idea dell’API Economy si basa sui fattori di business che le API possono supportare sia internamente all’azienda che nel rapporto con clienti finali e partner. Il concetto di Market Place è collegto a quello di API Economy: l’offerta di valore aggiunto di un’azienda prende forma in un’offerta differenziata e componibile di funzionalità acquisibili separatamente
  18. 18. Monetizzazione delle API << ...la monetizzazione delle API è il processo attraverso il quale le aziende creano entrate dalle loro API... sono la pietra angolare di quella che è ampiamente considerata come la prossima iterazione dello sviluppo aziendale, dove avere API ben sviluppate stabilisce e mantiene relazioni in un'economia digitale… >> [ https://www.redhat.com/en/topics/api/what-is-api-monetization ] [ https://www.rdegges.com/2020/the-only-type-of-api-services-ill-use/ ]
  19. 19. API Platform Un provider di API è un'organizzazione che espone dati e/o funzionalità tramite un servizio consumabile a livello di codice con una o più Application Programming Interface. Questa organizzazione è più di un fornitore e diventata una piattaforma quando le sue API:  Consentono l'accesso alla value-proposition fondamentale dell'organizzazione  Sono scalabili sia tecnicamente che sul business  Consentono ai consumatori di creare valore condiviso  Sono determinanti per garantire la posizione dell'organizzazione come leader di mercato  Sono viste dal top management come critiche per l'azienda https://www.apiscene.io/lifecycle/federated-apis-across-ecosystems/
  20. 20. API Platform & Cycles
  21. 21. API Management API REGISTRY ...un inventario delle API di un'organizzazione che consente ai consumatori di interrogare sulle caratteristiche delle API disponibili. Il registry aiuterà anche un'organizzazione a gestire il ciclo di vita di una API, catalogando le versioni supportate e la loro promozione o il ritiro da l'inventario delle API dell'organizzazione…
  22. 22. API Management API GATEWAY ...è il componente responsabile dell'esposizione e dell'organizzazione delle API ai diversi consumatori. Lo API Gateway copre le seguenti aree fondamentali:  Pubblicazione  Sicurezza  Standardizzazione  Controllo dell’Erogazione  Logging & Data Capture
  23. 23. API Management DEVELOPER PORTAL ...Il Developer Portal fornisce l'interfaccia umana alle API di un'organizzazione, fornisce un'esperienza utente di qualità (sia all’interno che per le terze parti), strumenti e risorse utili per la creazione di applicazioni che utilizzano le API. Inoltre, il portale fornisce le strutture agli sviluppatori per gestire il loro coinvolgimento con l'organizzazione (documentazione, notifiche, metriche)...
  24. 24. Developer Experience Lo Sviluppatore diventa principale consumatore di API: è per questo motivo che si parla di DX (Developer Experience) https://css-tricks.com/what-is-developer-experience-dx/
  25. 25. API Management (Books)  https://www.amazon.it/Continuous-API-Management-Decisions-Landscape/dp/1492043559  https://www.amazon.it/Enterprise-Management-Luis-Augusto-Weir/dp/1787284433  https://www.amazon.it/API-Management-Architects-Developing-Organization-ebook/dp/B06XRTNZNN
  26. 26. API vs Microservices La recente proposizione dell’architettura a Microservizi può portare all’identificazione delle API con i Microservizi: questo però non corrisponde alla realtà e può essere controproducente. Un microservizio nasce da un approccio architetturale che separa porzioni o interi monoliti applicativi in servizi di ridotte dimensioni e auto- contenuti Un’API è un contratto che fornisce la guida verso un Consumatore di quelle API al fine di interagire con il Servizio sottostante.
  27. 27. API vs Microservices L’obiettivo di un’API non è mostrare le capacità tecniche del microservizio ma esporre il suo valore aggiunto ed il migliore contratto per interfacciarsi con i clienti di cui deve soddisfare le richieste. UI Layer Orchest. Layer Atom. Services Layer
  28. 28. API, Gateway, BFF  https://samnewman.io/patterns/architectural/bff/  https://www.quora.com/What-is-backend-for-frontend-pattern  https://www.slideshare.net/GiulioRoggero/come-i-microservizi-favoriscono-il-la voro-dei-feature-teams
  29. 29. API, BFF, GraphQL  https://speakerdeck.com/timakin/go-backends-for-frontends-with- graphql-and-grpc  https://medium.com/tech-tajawal/backend-for-frontend-using-gra phql-under-microservices-5b63bbfcd7d9  https://www.infoq.com/presentations/graphql-bff/  Good fit for complex systems  Fetching data with a single API call  No over- and under- fetching problems  Tailoring requests to your needs  Validation and type checking out-of-the-box. ...  Auto-generating API documentation.  API evolution without versioning.  Code-sharing.
  30. 30. API, Gateway, Service Mesh https://betterprogramming.pub/the-roles-of-service -mesh-and-api-gateways-in-microservice-architect ure-f6e7dfd61043
  31. 31. API,Gateway,Micro Gateway,Service Mesh
  32. 32. Microservice Design Canvas Questo Canvas è uno strumento che aiuta a catturare gli attributi iniziali più importanti di un servizio prima di crearlo. Il Canvas ha un approccio sintetico che si presta a riportare le relazioni tra l'interfaccia e implementazione del servizio stesso. https://apiacademy.co/2017/08/the-micro service-design-canvas/ https://solusoftsl.github.io/microservices- design-canvas-editor/
  33. 33. API, Microservices, Modellazione Cosa significa Micro? Qual è la corretta dimensione di un servizio? Come la dimensione e, quindi, le funzionalità possibili condizionano la modellazione di una API?
  34. 34. API, Microservices: Books  https://www.oreilly.com/library/view/securing-microservice-apis/9781492027140/  https://www.amazon.it/Microservice-Architecture-Aligning-Principles-Practices/dp/1491956259  https://www.amazon.it/Monolith-Microservices-Evolutionary-Patterns-Transform/dp/1492047848/
  35. 35. API Ciclo di vita La definizione di un ciclo di vita delle API segue la stessa visione di un prodotto portando ad un’evoluzione continua al fine di adeguare e accrescere il marketplace e la value proposition aziendale DEFINE OPERATE DEPRECATE DISMISS LIFECYCLE OPERATIONS BUSINESS
  36. 36. HTTP Support: Deprecation La dismissione di una API dev’essere preceduta da un periodo in cui la stessa viene notificata agli utilizzatori come Deprecated. L’azione di Deprecation è attuabile: • su canali email, rss (syndication), chat per la notifica ad operatori umani • grazie ad apposito HTTP Header in termini di REST API Esempi: Deprecato nel passato: Deprecation: Sun, 11 Nov 2018 23:59:59 GMT Deprecato nel futuro: Deprecation: Sun, 20 Oct 2022 23:59:59 GMT Definitivamente deprecato: Deprecation: true
  37. 37. HTTP Support: Deprecation Lo HTTP Header della risposta Deprecation consente a un server di comunicare ad un client che la risorsa nel contesto del messaggio è o sarà deprecata. [ https://greenbytes.de/tech/webdav/draft-ietf-httpapi-deprecation-header-01.html ] L’ambito della deprecation è definito dall’API: ∙ Lo Header dedicato può apparire ovunque o solo su una specifica risorsa ∙ Possono essere fornite ulteriori informazioni con lo header Link Deprecato con informazioni aggiuntive: Deprecation: Sun, 11 Nov 2018 23:59:59 GMT Link: <https://developer.example.com/deprecation>; rel="deprecation"; type="text/ html"
  38. 38. HTTP Support: Sunsetting Il fornitore di risorse quando desidera comunicare all'applicazione client che si prevede che una risorsa obsoleta non risponda da un momento specifico in avanti, è possibile usare lo HTTP Header Sunset [ https://tools.ietf.org/html/rfc8594 ] The timestamp fornito nello Header Sunset deve essere successivo o lo stesso di quello presente nello Header Deprecation. Deprecation: Sun, 11 Nov 2018 23:59:59 GMT Sunset: Wed, 11 Nov 2020 23:59:59 GMT Prima che lo Header Sunset appaia per la prima volta è possibile che per la risorsa venga pubblicata la politica di dismissione utilizzando un Header di tipo Link verso informazioni specifiche: Link: <http://example.net/sunset>;rel="sunset";type="text/html"
  39. 39. HTTP Support: Gestione degli Errori In passato, i codici di stato erano sufficienti ad esprimere la condizione di una data invocazione. Le evoluzioni delle API hanno reso necessario avere una semantica più ricca. La conseguenza è stata il proliferare di soluzioni e formati per rappresentare le condizioni di errore nei vari ecosistemi di API delle Internet Companies.
  40. 40. HTTP Support: Gestione degli Errori I differenti approcci utilizzati hanno creato difficoltà nello sviluppo di API e la crescente necessità di avere uno standard di riferimento
  41. 41. HTTP Support: Gestione degli Errori La specifica Problem Details for HTTP APIs [ https://tools.ietf.org/html/rfc7807 ] si pone come standard capace di accogliere le differenti esigenze di gestione degli errori nell’ambito delle API • Flessibilità di formato grazie al supporto di differenti MIME Type nell’ambito della content negotiation HTTP • Supporto ad informazioni aggiuntive • Estendibilità delle informazioni ospitate • Supporto ad errori multipli sulla stessa risposta • Costruito su alcune considerazioni di sicurezza
  42. 42. HTTP Support: Gestione degli Errori La specifica supporta principalmente due tipologie di Content Type previsti come standard IANA: • application/problem+json • application/problem+xml Il formato prevede I seguenti campi: • Type: (obbligatorio) un URI che identifica il tipo di errore. Il caricamento dell'URI in un browser dovrebbe portare alla documentazione dell'errore, ma non è strettamente necessario. Questo campo può essere utilizzato per riconoscere le classi di errore • Title: un breve riassunto human-readable dell'errore.Iclient devono usare il Type come metodo principale per riconoscere i tipi di errore • Detail: spiegazione estesa e human-readable dell’errore • Status: il codice HTTP dello stato originario dell’errore • Instance: un URI che identifica questa specifica istanza di errore. Questo può fungere da ID per questa occorrenza dell'errore e / o un collegamento a maggiori dettagli sull'errore specifico
  43. 43. HTTP Support: Gestione degli Errori { "type": "https://example.com/probs/out-of-credit", "title": "You do not have enough credit.", "detail": "Your current balance is 30, but that costs 50.", “status”:400 "instance": "/account/12345/transactions/abc" } <?xml version="1.0" encoding="UTF-8"?> <problem xmlns="urn:ietf:rfc:7807"> <type>https://example.com/probs/out-of-credit</type> <title>You do not have enough credit.</title> <detail>Your current balance is 30, but that costs 50.</detail> <status>400</status> <instance>/account/12345/transactions/abc</instance> </problem>
  44. 44. HTTP Support :Gestione dei Warning La gestione degli errori non può coprire le situazioni dove un’esecuzione positiva della API implica comunque delle conseguenze negative o di cui il Client deve essere avvisato La specifica è al link: [ https://datatracker.ietf.org/doc/draft-cedik-http-warning/ ] La specifica fornisce un pattern per rappresentare il concetto di warning nelle HTTP API La specifica offre la possibilità di un formato unico in cui è racchiuso il warning grazie ad una rappresentazione JSON La specifica prevede uno specifico Header (Content-Warning) per indicare la presenza di un warning nel contesto della data risposta, offrendo in questo un'unica modalità espressa dal valore standard: embedded-warning
  45. 45. HTTP Support :Gestione dei Warning POST /example HTTP/1.1 Host: example.com Accept: application/json HTTP/1.1 200 OK Content-Type: application/json Content-Warning: "embedded-warning"; 1590190500 { ... "warnings": [ { "detail": "Street name was too long. It has been shortened ...", "instance": "https://example.com/shipments/3a186c51/msgs/c94d", "status": "200", "title": "Street name too long. It has been shortened.", "type": "https://example.com/errors/shortened_entry" }, ... ], "id": "3a186c51d4281acb", "carrier_tracking_no": "84168117830018", "price": 3.4, ... }
  46. 46. HTTP Support: Versioning L’adozione di una politica di versionamento delle API può sembrare un argomento banale ma in realtà nasconde differenti difficoltà dato che differenti sono le conseguenze rispetto alla strategia scelta. Quando affrontato nei termini stessi della definizione delle API, sono utilizzabili tre differenti approcci:  URI Versioning Es. http://host/v1/users  Query String Versioning Es. http://host/users?api-version=1  Header/Media Versioning Es. Accept: application/vnd.myname.v1+json Avere un indicatore di versione diventa necessario specie in ambienti basati su container ma non necessariamente sono da definirsi nelle API dato che è possibile affidarsi ad API Registry e alle versioni, generalmente derivanti dal Semantic Versioning, relativo a sorgenti o specifiche sottese alle API.
  47. 47. HTTP Support: Versioning Viene considerato a volte molto più pragmatico evitare il versionamento e differenti aziende hanno sperimentato soluzioni alternative: Continuous Versioning: Badoo - https://www.slideshare.net/BadooDev/versioning-strategy-for-a-complex-internal-api API Versioning for Zero Downtime ING - https://www.youtube.com/watch?v=RvcDs_JLc0Y
  48. 48. Versioning? Io uso GraphQL... E se invece...
  49. 49. Versioning? Io uso GraphQL... E se invece...
  50. 50. HTTP Support: Rate Limiting E’ una buona pratica considerare delle limitazioni (quota) di servizio per le differenti API e nel rispetto delle classificazioni delle differenti tipologie di possibili consumatori. Questo tipo di strategie vengono comunque richieste in presenza di prodotti dedicati alla gestione delle API E’ possibile notificare il Client dello stato dei limiti di servizio di una data API tramite apposito Header HTTP [ https://tools.ietf.org/id/draft-polli-ratelimit-headers-02.html ] In passato un meccanismo analogo era svolto con un altro identificativo per lo Header che prevede un prefisso “X-”. Questa prassi che interessa anche altri Header è stata deprecata anche se I vecchi Header devono essere supportati. HTTP/1.1 200 Ok Content-Type: application/json RateLimit-Limit: 100 RateLimit-Remaining: 20 HTTP/1.1 429 Too Many Requests Content-Type: application/json Date: Mon, 05 Aug 2019 09:27:00 GMT Retry-After: Mon, 05 Aug 2019 09:27:05 GMT RateLimit-Reset: 5 RateLimit-Limit: 100 Ratelimit-Remaining: 0
  51. 51. REST API : Books  https://www.amazon.it/REST-Design-Rulebook-Mark-Masse/dp/1449310508/  https://www.manning.com/books/the-design-of-web-apis  https://www.amazon.it/Hands-RESTful-Design-Patterns-Practices/dp/1788992660
  52. 52. Open Source Licensing Sono emersi nuovi tipi di licenza in risposta a Cloud Provider come Amazon che attuano packaging, rebranding e profitti da progetti open source distribuiti sulla loro piattaforma cloud. Esempi popolari includono la Redis’Source Available License (RSAL), la Server Side Public License (SSPL) di MongoDB, la Cockroach Community License (CCL) o le licenze a cui è stata aggiunta la clausola Commons.
  53. 53. O.S. Licensing: Amazon Problem? << ...In practice, Amazon isn’t going to share source code for AWS, or even its AWS-ified version of Elasticsearch. They’re a closed platform people use to run a lot of open software, not an open source platform. So the license in effect said “hands off” to AWS, not by saying they couldn’t use the code, but by saying that if they did, they’d have to share alike. Which they won’t. Why? Because releasing that code ain’t in Amazon’s business model... >> https://writing.kemitchell.com/2021/01/20/Righteous- Expedient-Wrong.html
  54. 54. API & Licensing Comparing Open-Source Software Licenses https://www.youtube.com/watch?v=DDx6gjwU0K8
  55. 55. API & Licensing ( Risorse ) https://www.apilicens.se/en/ https://opendefinition.org/licenses/api/ https://wiki.p2pfoundation.net/Open_A PI_License https://matija.suklje.name/popular-lice nses-in-openapi Legal Challenges: https://nordicapis.com/challenges-the-api-industry-faces- in-2021/
  56. 56. ...ma c’è altro...
  57. 57. ...ma c’è altro...
  58. 58. ...ma c’è altro...
  59. 59. Grazie a Tutti!

×