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.
Quando un software è di qualità? - Agile Venture Milano 2020Thomas Rossetto
Leggendo il titolo cosa ti viene in mente?
Probabilmente concetti astratti e noiosi, come ad esempio le sigle delle normative ISO9000. Oppure, mettendoti nei panni di chi ad esempio compra un prodotto o un servizio, a qualcosa di bello, appagante e sicuro.
Il problema è che la sensazione che si ha dopo aver udito la parola ‘qualità’ non è così chiara e condivisa, e se ci avviciniamo la parola ‘software’, che per sua natura è intangibile e di difficile comprensione, le cose si complicano.
In questo talk cercheremo di mettere più a fuoco questa sensazione, attraverso il racconto di come trasformiamo le idee del nostro cliente in prodotti che possano essere definiti, per tutti, di qualità.
L’eccellenza tecnica è uno dei principi cardine dell’agilità e come tale favorisce la creazione di valore mantenendo le architetture semplici e i processi snelli. I sistemi legacy sono però un ostacolo per la ricerca dell’eccellenza tecnica. Di fatto il debito tecnico che si stratifica negli anni non aiuta la continua innovazione e la business agility.
Le nuove tecnologie, come Cloud e Big Data, sono degli abilitatori per creare applicazioni semplici e mantenibili nel futuro. Ma da soli non bastano.
Il problema è che ogni tecnologia ha le sue complessità e spesso queste sono indipendenti dalle logiche applicative. Può succedere che il team spenda più tempo a mettere in piedi l’infrastruttura e la connessione a tutti i servizi Cloud, che a scrivere le parti applicative. E questo tempo spesso si replica N-volte quanti sono gli N-progetti sviluppati da diversi team.
Manca un concetto comune di infrastruttura e piattaforma.
In questo talk vedremo come l’ “infrastruttura invisibile” possa semplificare il lavoro dei team favorendo l’eccellenza tecnica e la business agility.
Piccola anticipazione. L’infrastruttura invisibile é come le rotaie per un viaggiatore in treno: si gode il viaggio sorseggiando la sua bevanda preferita senza preoccuparsi della complessità che letteralmente viaggia sotto i suoi piedi.
Come i Microservizi favoriscono il lavoro dei Feature TeamsGiulio Roggero
In un contesto Agile i Feature Teams sono una delle strutture organizzative più efficaci per sviluppare un ecosistema complesso in modo rapido, mantenendo alta la qualità e basso il TCO (total cost of ownership). Spesso questi team sono però vincolati da architetture monolitiche, o a lasagna/spaghetti, che non consentono di operare end-to-end sulle feature, creando dipendenze tra team, colli di bottiglia e frustrazione. Lo stile architetturale a Microservizi (sì, è uno stile e non un pattern e quindi va interpretato a seconda dei casi) da una mano a questi team ad essere più indipendenti tra loro e li aiuta a lavorare tutti con lo stesso scopo: generare valore per gli utenti finali in modo continuo. In questo talk vedremo come organizzare più team che lavorano su uno stesso prodotto e come lo stile architetturale a Microservizi supporti questa organizzazione evolvendo con l'evolversi dei team.
La multicanalità è il contesto del Cliente digitale di oggi e le spaghetti API stanno prendendo il sopravvento. Il Business e l'IT sono in prima linea a garantire time-to-market e qualità mettendo sotto stress la struttura organizzativa e le tecnologie. Organizzarsi in modo agile non basta, serve anche una strategia chiara di piattaforma!
La presentazione introduce il problema che oggi le aziende hanno a livello IT: tante applicazioni sparse che accedono ai sistemi core in modo non organico (spaghetti API). Questo comporta: rallentamento del time-to-market, attriti nelle relazioni e prodotti poco coerenti tra di loro. Durante una trasformazione digitale si pensa in primo luogo a riorganizzare persone in modo da snellire i processi. Questo è di sicuro aiuto ma da solo non è sufficiente: se i sistemi sui quali lavorano i team non evolvono i team possono essere agili quanto vogliono ma non riescono a tenere il passo con il mercato. La zavorra del debito tecnico di codice e API a spaghetti non è facilmente ripagabile. E’ necessario cambiare le strategie architetturali e creare un sistema che si possa rifare a pezzi e far evolvere. Vedremo come una strategia di Piattaforma Digitale possa essere a supporto per la trasformazione Agile.
Il software che oggi produce valore è stato scritto parecchi anni fa. Il costo di manutenzione ed evoluzione sta diventando sempre più alto.
Parallelamente stiamo vivendo una forte accelerazione sul digitale: omnicanalità, self-service e ubiquità sono fattori che stanno influenzando i comportamenti delle persone. Alle aziende si chiede sempre più innovazione e semplicità dei servizi offerti.
In questa presentazione guarderemo avanti nel futuro, sui software che produrranno valore nei prossimi 10 anni e che stiamo costruendo ora.
Proveremo a dare una possibile risposta a questa domanda:
“come possiamo evitare di accumulare un debito tecnico difficilmente ripagabile e nel contempo seguire l’accelerazione che il mercato ci sta chiedendo senza impattare sul business esistente?”
Agile è entrato nel gergo comune di molte aziende che hanno a che fare con progetti IT. Questa è una buona cosa: il termine è conosciuto e accettato come una buona prassi, le persone sono ben disposte ad adottare metodi e pratiche che consentono di migliorare la gestione del ciclo di vita di un prodotto software e sono favorevoli al cambiamento.
Quando però si parte veramente mi sono trovato in diverse situazioni dove Agile si limitava alla parte “persone” e “organizzazione” ma non entrava nel merito di come si sviluppa il codice!
La provocazione “Stop Meeting, Start Coding” vuol ridurre all’essenziale i momenti di confronto e concentrarsi a scrivere buon codice, insieme!
In questo talk presenterò alcune buone pratiche di coding che favoriscono anche l’efficacia organizzativa.
Il modo di lavorare è cambiato, che ci piaccia o no. Emerasoft, Lynx Group, ha identificato temi e tecnologie che non possiamo più fare a meno di considerare: dalla Software Supply Chain al Value Stream Management, alla Digital Onboarding. Ecco alcuni consigli per lavorare meglio, con più efficienza e produttività
Quando un software è di qualità? - Agile Venture Milano 2020Thomas Rossetto
Leggendo il titolo cosa ti viene in mente?
Probabilmente concetti astratti e noiosi, come ad esempio le sigle delle normative ISO9000. Oppure, mettendoti nei panni di chi ad esempio compra un prodotto o un servizio, a qualcosa di bello, appagante e sicuro.
Il problema è che la sensazione che si ha dopo aver udito la parola ‘qualità’ non è così chiara e condivisa, e se ci avviciniamo la parola ‘software’, che per sua natura è intangibile e di difficile comprensione, le cose si complicano.
In questo talk cercheremo di mettere più a fuoco questa sensazione, attraverso il racconto di come trasformiamo le idee del nostro cliente in prodotti che possano essere definiti, per tutti, di qualità.
L’eccellenza tecnica è uno dei principi cardine dell’agilità e come tale favorisce la creazione di valore mantenendo le architetture semplici e i processi snelli. I sistemi legacy sono però un ostacolo per la ricerca dell’eccellenza tecnica. Di fatto il debito tecnico che si stratifica negli anni non aiuta la continua innovazione e la business agility.
Le nuove tecnologie, come Cloud e Big Data, sono degli abilitatori per creare applicazioni semplici e mantenibili nel futuro. Ma da soli non bastano.
Il problema è che ogni tecnologia ha le sue complessità e spesso queste sono indipendenti dalle logiche applicative. Può succedere che il team spenda più tempo a mettere in piedi l’infrastruttura e la connessione a tutti i servizi Cloud, che a scrivere le parti applicative. E questo tempo spesso si replica N-volte quanti sono gli N-progetti sviluppati da diversi team.
Manca un concetto comune di infrastruttura e piattaforma.
In questo talk vedremo come l’ “infrastruttura invisibile” possa semplificare il lavoro dei team favorendo l’eccellenza tecnica e la business agility.
Piccola anticipazione. L’infrastruttura invisibile é come le rotaie per un viaggiatore in treno: si gode il viaggio sorseggiando la sua bevanda preferita senza preoccuparsi della complessità che letteralmente viaggia sotto i suoi piedi.
Come i Microservizi favoriscono il lavoro dei Feature TeamsGiulio Roggero
In un contesto Agile i Feature Teams sono una delle strutture organizzative più efficaci per sviluppare un ecosistema complesso in modo rapido, mantenendo alta la qualità e basso il TCO (total cost of ownership). Spesso questi team sono però vincolati da architetture monolitiche, o a lasagna/spaghetti, che non consentono di operare end-to-end sulle feature, creando dipendenze tra team, colli di bottiglia e frustrazione. Lo stile architetturale a Microservizi (sì, è uno stile e non un pattern e quindi va interpretato a seconda dei casi) da una mano a questi team ad essere più indipendenti tra loro e li aiuta a lavorare tutti con lo stesso scopo: generare valore per gli utenti finali in modo continuo. In questo talk vedremo come organizzare più team che lavorano su uno stesso prodotto e come lo stile architetturale a Microservizi supporti questa organizzazione evolvendo con l'evolversi dei team.
La multicanalità è il contesto del Cliente digitale di oggi e le spaghetti API stanno prendendo il sopravvento. Il Business e l'IT sono in prima linea a garantire time-to-market e qualità mettendo sotto stress la struttura organizzativa e le tecnologie. Organizzarsi in modo agile non basta, serve anche una strategia chiara di piattaforma!
La presentazione introduce il problema che oggi le aziende hanno a livello IT: tante applicazioni sparse che accedono ai sistemi core in modo non organico (spaghetti API). Questo comporta: rallentamento del time-to-market, attriti nelle relazioni e prodotti poco coerenti tra di loro. Durante una trasformazione digitale si pensa in primo luogo a riorganizzare persone in modo da snellire i processi. Questo è di sicuro aiuto ma da solo non è sufficiente: se i sistemi sui quali lavorano i team non evolvono i team possono essere agili quanto vogliono ma non riescono a tenere il passo con il mercato. La zavorra del debito tecnico di codice e API a spaghetti non è facilmente ripagabile. E’ necessario cambiare le strategie architetturali e creare un sistema che si possa rifare a pezzi e far evolvere. Vedremo come una strategia di Piattaforma Digitale possa essere a supporto per la trasformazione Agile.
Il software che oggi produce valore è stato scritto parecchi anni fa. Il costo di manutenzione ed evoluzione sta diventando sempre più alto.
Parallelamente stiamo vivendo una forte accelerazione sul digitale: omnicanalità, self-service e ubiquità sono fattori che stanno influenzando i comportamenti delle persone. Alle aziende si chiede sempre più innovazione e semplicità dei servizi offerti.
In questa presentazione guarderemo avanti nel futuro, sui software che produrranno valore nei prossimi 10 anni e che stiamo costruendo ora.
Proveremo a dare una possibile risposta a questa domanda:
“come possiamo evitare di accumulare un debito tecnico difficilmente ripagabile e nel contempo seguire l’accelerazione che il mercato ci sta chiedendo senza impattare sul business esistente?”
Agile è entrato nel gergo comune di molte aziende che hanno a che fare con progetti IT. Questa è una buona cosa: il termine è conosciuto e accettato come una buona prassi, le persone sono ben disposte ad adottare metodi e pratiche che consentono di migliorare la gestione del ciclo di vita di un prodotto software e sono favorevoli al cambiamento.
Quando però si parte veramente mi sono trovato in diverse situazioni dove Agile si limitava alla parte “persone” e “organizzazione” ma non entrava nel merito di come si sviluppa il codice!
La provocazione “Stop Meeting, Start Coding” vuol ridurre all’essenziale i momenti di confronto e concentrarsi a scrivere buon codice, insieme!
In questo talk presenterò alcune buone pratiche di coding che favoriscono anche l’efficacia organizzativa.
Il modo di lavorare è cambiato, che ci piaccia o no. Emerasoft, Lynx Group, ha identificato temi e tecnologie che non possiamo più fare a meno di considerare: dalla Software Supply Chain al Value Stream Management, alla Digital Onboarding. Ecco alcuni consigli per lavorare meglio, con più efficienza e produttività
Anche voi siete in piena "APIFICATION"? Riccardo ci svela tutti i segreti per rilasciare API di successo. #apistrategy
Per ulteriori informazioni scrivi a wso2.sales@profesia.it
Vibecode è un framework di business che consente la realizzazione veloce di applicazioni evolute fornendo strumenti per risolvere comlpessità tecnologiche.
API Conf 2017 - Allineare il business e la tecnologia grazie alle apiGiulio Roggero
Spesso i termini usati dal business non si ritrovano nell'architettura informatica sottostante. E questo alla lunga genera incomprensioni e problemi. In questi 10' vedremo come, in 3 semplici passi, sia possibile allineare i termini usati dal business e dai tecnici. Per facilitare la spiegazione vedremo due brevi esempi di casi reali: Trenord e Foorban.
API Management/Economy are the latest trends in Enterprise Application Integration. This presentation has been used during a workshop made for Intesa Vita with a focus on Microsoft Azure API Management.
Tech trend 2018: dai sistemi distribuiti alla sicurezza informatica passando ...Purple Network
Il 2017 è stato l'anno che ha consacrato la customer care automation, l'anno dei chatbot e dei nuovi contenuti in Realtà Aumentata. Il mondo ha scoperto le cryptovalute e quanto è davvero smart l'intelligenza artificiale. Cosa ci aspetta nel 2018? Backend as a Service, la sfida alle App Native lanciata dalle PWA e soprattutto Blockchain.
Qui trovi tutti i Tech trend da tenere d'occhio nel 2018: Digital Intelligence, Machine Learning, AI, Voice Driven application, Customer Care automation, Immersive Experience, Sistemi distribuiti, Performance e sicurezza.
Xamarin: Shared Library and Portable Class Library - Aristide Di Francesco - ...Codemotion
A key component of the creation of cross-platform applications to be able to share code among several specific projects and platform dependent. Each different platform can only use the class libraries that have been developed for that specific platform. In Xamarin there are two main approaches to the sharing code: Using Shared Asset Projects (Shared Library) and the Portable Class Library (PCL) Projects. In this session we will see how and when to use the shared library, or the PCL library and we will try to answer the question: Shared or PCL?
Francesco Arcieri - La monetizzazione delle API - Codemotion Milan 2017Codemotion
L’API Economy ha permesso ad aziende e startup di fornire i propri servizi attraverso nuovi canali. La nascita di ecosistemi digitali interaziendali ha spinto ulteriormente molte aziende ad inserire nel loro piano di Digital Transformation programmi di sviluppo ed esposizione di API interne ed esterne per aumentare l'integrazione aziendale e abilitare nuovi modelli di business con terze parti. Ma esporre delle API non è sufficiente. Nell'API Economy diventa fondamentale sviluppare una strategia di commercializzazione delle API e un'architettura in grado di abilitare transazioni commerciali.
Twinergy Solution:Agenti+ soluzione SAP per la gestione agentiTwinergy
Agenti+ è una Twinergy Solution realizzata per gestire il calcolo e la liquidazione delle provvigioni agli agenti. È una soluzione completa e totalmente integrata con SAP® ERP. Sviluppato con gli strumenti dell’ABAP Workbench, può essere installato su qualunque installazione SAP® preesistente, senza impatto e integrandosi con esso. Agenti+ è integrato con i componenti Sales & Distribution, Finance, Controlling.
Anche voi siete in piena "APIFICATION"? Riccardo ci svela tutti i segreti per rilasciare API di successo. #apistrategy
Per ulteriori informazioni scrivi a wso2.sales@profesia.it
Vibecode è un framework di business che consente la realizzazione veloce di applicazioni evolute fornendo strumenti per risolvere comlpessità tecnologiche.
API Conf 2017 - Allineare il business e la tecnologia grazie alle apiGiulio Roggero
Spesso i termini usati dal business non si ritrovano nell'architettura informatica sottostante. E questo alla lunga genera incomprensioni e problemi. In questi 10' vedremo come, in 3 semplici passi, sia possibile allineare i termini usati dal business e dai tecnici. Per facilitare la spiegazione vedremo due brevi esempi di casi reali: Trenord e Foorban.
API Management/Economy are the latest trends in Enterprise Application Integration. This presentation has been used during a workshop made for Intesa Vita with a focus on Microsoft Azure API Management.
Tech trend 2018: dai sistemi distribuiti alla sicurezza informatica passando ...Purple Network
Il 2017 è stato l'anno che ha consacrato la customer care automation, l'anno dei chatbot e dei nuovi contenuti in Realtà Aumentata. Il mondo ha scoperto le cryptovalute e quanto è davvero smart l'intelligenza artificiale. Cosa ci aspetta nel 2018? Backend as a Service, la sfida alle App Native lanciata dalle PWA e soprattutto Blockchain.
Qui trovi tutti i Tech trend da tenere d'occhio nel 2018: Digital Intelligence, Machine Learning, AI, Voice Driven application, Customer Care automation, Immersive Experience, Sistemi distribuiti, Performance e sicurezza.
Xamarin: Shared Library and Portable Class Library - Aristide Di Francesco - ...Codemotion
A key component of the creation of cross-platform applications to be able to share code among several specific projects and platform dependent. Each different platform can only use the class libraries that have been developed for that specific platform. In Xamarin there are two main approaches to the sharing code: Using Shared Asset Projects (Shared Library) and the Portable Class Library (PCL) Projects. In this session we will see how and when to use the shared library, or the PCL library and we will try to answer the question: Shared or PCL?
Francesco Arcieri - La monetizzazione delle API - Codemotion Milan 2017Codemotion
L’API Economy ha permesso ad aziende e startup di fornire i propri servizi attraverso nuovi canali. La nascita di ecosistemi digitali interaziendali ha spinto ulteriormente molte aziende ad inserire nel loro piano di Digital Transformation programmi di sviluppo ed esposizione di API interne ed esterne per aumentare l'integrazione aziendale e abilitare nuovi modelli di business con terze parti. Ma esporre delle API non è sufficiente. Nell'API Economy diventa fondamentale sviluppare una strategia di commercializzazione delle API e un'architettura in grado di abilitare transazioni commerciali.
Twinergy Solution:Agenti+ soluzione SAP per la gestione agentiTwinergy
Agenti+ è una Twinergy Solution realizzata per gestire il calcolo e la liquidazione delle provvigioni agli agenti. È una soluzione completa e totalmente integrata con SAP® ERP. Sviluppato con gli strumenti dell’ABAP Workbench, può essere installato su qualunque installazione SAP® preesistente, senza impatto e integrandosi con esso. Agenti+ è integrato con i componenti Sales & Distribution, Finance, Controlling.
Power Apps Introduction (Eduard Capanu).pptxEduardCapanu
This slide are made for an event with Fabio Biondi where we are explaining the basics of the Power Platform services.
Event link: https://www.youtube.com/watch?v=y2PGikFu96g&t=3s
Il mercato del nuovo millennio chiede capacità di costruire la propria solidità in una situazione di grandi perturbazioni. Ogni azienda è chiamata ad interpretare le costanti sfide accogliendo ogni istanza proposta dal mercato, avendo la capacità di re-immaginarsi, rispondendo a stimoli costanti e spesso disparati.
Oggi la grande sfida e’ interpretare la cosiddetta società della conoscenza. Entrare e costruire valore a partire dalla grande opportunità rappresentata dalla rete. L’informazione produce valore, la corretta gestione delle informazioni migliora la qualità della vita e del lavoro, consente di ridurre gli sprechi e di aggredire i mercati in modo competitivo.
In tale contesto Insiel si sta misurando, ad esempio con il FLOSS, impegnata ad aprire interlocuzioni con la comunità, con le istituzioni internazionali, con gli operatori e con gli utenti stessi. L’obiettivo e’ interpretare questo innovativo modello di business sia all’interno dell’azienda che mettendo a sistema la solidità e la forza di Insiel nella partecipazione a diversi progetti nazionali e internazionali in ambito Open Source.
Nell’intervento verranno presentate esperienze e criticità maturate in ambito OS, sia per la conduzione di progetti di collaborazione e sviluppo che per l’adozione di strumenti all’interno dell’azienda.
Qui puoi trovare informazioni sulla nostra azienda, che opera nel settore IT.
Usiamo un approccio consulenziale, basato sull'ascolto dei bisogni del cliente, la comprensione dei problemi, l'analisi dei requisiti e la scelta degli obbiettivi.
La nostra sede è a Bologna, Italia.
Comunicazione tecnica e competitività aziendaleKEA s.r.l.
In questa presentazione vedremo i molti modi in cui la comunicazione tecnica e di prodotto può contribuire a rendere l'azienda competitiva, raggiungendo obiettivi di efficienza, riduzione dei rischi, efficacia, miglioramento incrementale e innovazione.
In particolare, presenteremo proposte di applicazioni software in grado di rispondere a esigenze e attese informative, formative e operative di persone, interne ed esterne all'azienda, e di software dell’azienda e di parti terze.
Obiettivo è comunicare "ad attrito zero" fra azienda, clienti attuali e potenziali, partner, fornitori, dando valore alle risorse dell'azienda: Argo CMS, altre fonti dati e software; contenuti, documenti e output; sollecitazioni dei molteplici interlocutori.
Contattateci per approfondire le nostre proposte o per condividere con noi le vostre esigenze!
A digital company based in Italy (Milan and Venice) strong in digital transformation. We design and develop innovative mobile and IoT app, web application and e-commerce.
ESI è l'infrastruttura di integrazione per realizzare applicazioni multicanale integrate con sistemi ERP
E' una service-platform nata per realizzare in modo semplice ed efficace l’integrazione di applicazioni desktop, web e/o 'mobile' principalmente con sistemi ERP (il primo su cui è stato implementato ESI è SAP) ma anche con sistemi di Business Intelligence, Enterprise Content Management, ecc.
e-Business, e-Marketing And Social Media 2008 Course Ge Ma Business School ...Salvatore Larosa
Module 1/13 of a series of slides I wrote down in order to introduce a small class of post-graduate students to e-Business and e-marketing, at "Gestioni & Management" Business School in Rome.
My goal was NOT just to discuss or introduce the Internet, the Web or the basic concepts online user experience and online advertising. Instead, I focused on the idea that e-marketing management is more and more a relevant aspect of "plain and simple" marketing management and I tried to give future marketing managers some methodological tool in order to address e-marketing projects in a "right", formal and structured way.
ICARO: soluzioni e strumenti smart per avere maggiore flessibilità sul Cloud; adattare soluzioni software alle nuove esigenze cloud-based; produrre e gestire servizi a consumo: Business Process as a Service.
ICARO: Tramite modelli, strumenti e algoritmi per la gestione della configurazione e del deploy dei servizi e processi cloud; Il middleware e l’astrazione dei servizi sul cloud; l’ottimizzazione dei costi per le PMI e per la gestione del cloud.
ICARO permette: automatizzare il processo di pubblicazione e vendita delle applicazioni a consumo su cloud; automatizzare il processo di monitoraggio di basso ed alto livello e l'impostazione di strategie di smart cloud; automatizzare il controllo sulle SLA (service level agreement) in modo da associare ad evetuali disfuzioni azioni di scaling, riconfigurazione, etc.
ICARO ha sviluppato: modello descrittivo per servizi e applicazioni;
sistema automatico di configurazione;
motore di intelligence per il cloud e reasoner che prendere decisioni su configurazioni: consistenza e completezza (sulla base din un ontologia Cloud per lo Smart Cloud);
soluzione di produzione del business, config automatica;
algoritmi per il monitoraggio del comportamento di servizi e applicazioni: IaaS, PaaS, SaaS,…;
soluzione PaaS di tipo evoluto; algoritmi per la valutazione di modelli di costo e di business;
adeguamento dell’architettura su alcune applicazioni; algoritmi di ottimizzazione della gestione del cloud.
video: https://www.youtube.com/watch?v=hf-8mlY5o-o
Che tu sia uno sviluppatore, un architetto software, un manager IT, uno studente di informatica o un professionista interessato all'evoluzione del software, questo talk è per te!
Faremo un viaggio nel tempo in cui attraverseremo i paradigmi API che hanno dominato il panorama negli anni, da CORBA a SOAP, fino a REST e OpenAPI. Analizzeremo i vantaggi e gli svantaggi di ogni paradigma e le loro implicazioni per l'architettura software. Esploreremo inoltre l'hype cycle di Gartner e la teoria dei corsi e ricorsi di Vico per comprendere meglio i cicli di adozione e sviluppo delle varie tecnologie.
Infine, ci concentreremo sull'API-first design, una metodologia emergente che pone l'API al centro del processo di sviluppo software. Discuteremo i benefici dell'API-first design e come può aiutare le aziende a creare software più flessibile, scalabile e riutilizzabile.
Similar to Non solo Microservizi: API, Prodotti e Piattaforme (20)
Gamification - Introduzione e Idee di un NON GIOCATOREStefano Fago
Ritorno a parlare di Gamification, una industry che ha anche in Italia diversi casi di successo ed i propri champions
https://designagame.eu/pietro-polsinelli/
http://www.gameifications.com/autore/
e tante aziende...
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. 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!
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. 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. Definizione di Prodotto
Cos'è un prodotto?
• etichettato
• confezionato
• facile da usare
• documentato
• supportato da un business
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. 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. 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. 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. API: Internal vs External
http://dret.net/lectures/oreilly-sa-ca-2019/
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. 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. 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/
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. 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. 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. 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/
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. 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
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. 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?
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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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
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
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. 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