Le origini del nostro primo prodotto

Nel 2014 iniziammo a sviluppare un prodotto open-source, allo scopo di investigare un modo più semplice e razionale di costruire applicazioni. Nacque un po’ come esperimento estivo, anche per giocare con le novità di Java 8, per diventare negli anni successivi un prodotto sempre più centrato e robusto.

Da tempo ci rendevamo conto che gli application server, diventati tanto di moda nei precedenti quindici anni, costringevano le persone ad investire più tempo nella loro configurazione e manutenzione di quello che veniva investito nella realizzazione di funzionalità applicative. Erano diventati oggetti troppo complicati e costosi da gestire, e noi non ne avevamo davvero più voglia.

L’esperienza ci insegnava inoltre che un’alta percentuale di codice veniva scritto e riscritto per fare sempre le stesse cose: lettura, scrittura, ricerche ed esposizione di dati tramite protocollo HTTP. Dati strutturati, ma spesso mescolati anche a contenuti non strutturati, documentali e multimediali, che richiedevano ben altra flessibilità rispetto a quella fornita dai tradizionali database relazionali, sia dal punto di vista dello storage che delle capacità di organizzare e ricercare informazioni che, per loro natura e dinamicità, mal si prestano ad essere inquadrate dentro schemi tabellari.

Nel frattempo l’industria stava abbandonando i Web Services basati su SOAP + XML per andare verso modelli più semplici e decisamente orientati al Web, cioè REST + JSON via protocollo HTTP. Questo fu provocato anche dal crescente successo di JavaScript per scrivere applicazioni Web “Single Page” (SPA). L’esemplare più rappresentativo e capostipite di questo modello, a dimostrazione di ciò che era possibile realizzare sul Web con un uso avanzato delle tecnologie AJAX (Asynchronous JavaScript and XML), probabilmente fu il primo Google GMail.

Il successo delle App per dispositivi mobili inoltre spostava di molto la richiesta di capacità elaborativa dai server verso i client, segnando un’inversione di rotta e rendendo in questo senso superflue alcune complessità tipiche dei vecchi application server tradizionali. Moriva dunque il concetto di SOA e nasceva quello di API.

SOA (Service Oriented Architecture) aveva infatti promesso di rivoluzionare i rapporti tra il mondo del business e quello tecnologico. La narrazione era la seguente: scomporre concettualmente il dominio applicativo in “servizi” che avessero un significato direttamente applicativo, fornendo strumenti che consentissero di orchestrare tali servizi in maniera relativamente semplice, anche ai non tecnici.

Soprattuto negli anni tra il 2000 ed il 2010 gran parte dell’industria software “pesante” pertanto tradusse l’idea in una quantità di piattaforme di EAI, ESB, BPM, SOA e orchestrazione dei Web Services. Si affermò la famiglia di specifiche WS-* ed il protocollo SOAP (Simple Object Access Protocol), che di semplice in realtà aveva ben poco. Lo XML imperversava ovunque e lo si ritrovava condito in tutte le salse, dalle configurazioni interne ai messaggi B2B.

Quasi tutte queste iniziative però collassarono sotto il loro stesso peso e SOA fu dichiarato ufficialmente morta nel 2009. Il Re era nudo.

But perhaps that’s the challenge: The acronym got in the way. People forgot what SOA stands for. They were too wrapped up in silly technology debates (e.g., “what’s the best ESB?” or “WS-* vs. REST”), and they missed the important stuff: architecture and services.

I was actually hopeful that somehow, someway SOA would transcend some of the practice issues I saw around EAI. Indeed, most enterprises are dealing with a huge mess, and it’s a good idea to begin to cleaning things up. Right? SOA was and is a great approach for doing that, but many charged with making SOA work just could not get out of their own way.

The demise of SOA is tragic for the IT industry. Organizations desperately need to make architectural improvements to their application portfolios. Service-orientation is a prerequisite for rapid integration of data and business processes; it enables situational development models, such as mashups; and it’s the foundational architecture for SaaS and cloud computing.

Prima del collasso di SOA e dei prodotti ad esso collegati, un concetto nato per risolvere problemi reali e che quindi tentava di rispondere ad esigenze concrete, si stava già rapidamente diffondendo un modello più semplice e pragmatico, quello delle cosiddette API in architettura REST, prevalentemente basate sullo scambio di messaggi JSON via HTTP, più o meno nativamente interpretabili da applicazioni Javascript su browser Web e dalle App mobili. REST (Representational State Transfer) è infatti l’essenza dell’architettura Web e funziona perfettamente in un mondo dove il Web e le tecnologie ad esso collegate sono diventati pervasivi.

Nel frattempo si consolidarono anche e soprattutto in ambito Web e App mobili, principalmente all’interno delle comunità opensource, modelli di sviluppo più pragmatici e database non relazionali basati sul paradigma NoSQL, il cui principale esponente era MongoDB, un prodotto in grado di gestire documenti JSON nativamente, molto leggero ed estremamente veloce, sebbene carente di alcune caratteristiche “Enterprise” prima ritenute indispensabili, ma che in ambito applicativo moderno non erano più considerate essenziali.

A questo si è sommato il successo del modello Cloud Computing, innescato in larga misura dalla scommessa che fece anni prima Amazon, creando prima di tutti un dipartimento dedicato a fornire servizi pubblici on demand di “commodity computing” anche a clienti esterni (Amazon Web Services), seguito dal più recente, ma altrettanto travolgente, successo di Docker e dei container, che insieme hanno rapidamente rivoluzionato tutti i modelli infrastrutturali precedenti.

Dal punto di vista dello sviluppo e della distribuzione del software, ancora più recenti e altrettanto dirompenti, sebbene non ancora così diffusi, sono stati i modelli di sviluppo applicativo più estremi che il Cloud ha abilitato, in particolare Serverless e JAMstack, che semplificano e razionalizzano ulteriormente le possibilità di sviluppo, distribuzione e fruizione delle applicazioni software, ad una frazione dei costi precedenti.

Mettendo insieme fatti ed idee, abbiamo creato e stiamo continuando a sviluppare il nostro principale prodotto RESTHeart, che risponde alle nostre esigenze di semplicità ed efficacia, è nativamente “dockerizzabile”, facilmente distribuibile in qualsiasi moderna architettura Cloud oppure on-premises, e ci sta evitando di reinventare ogni volta la ruota, permettendoci di costruire i nostri strati applicativi su solide fondamenta.

Riferimenti

• RESTHeart, the Web API Server
• Documentation
• Github repository
• mrest, Data and Content API Service for Modern Projects