• Skip to primary navigation
  • Skip to main content
  • Skip to footer

Codemotion Magazine

We code the future. Together

  • Discover
    • Events
    • Community
    • Partners
    • Become a partner
    • Hackathons
  • Magazine
    • Backend
    • Dev community
    • Carriere tech
    • Intelligenza artificiale
    • Interviste
    • Frontend
    • DevOps/Cloud
    • Linguaggi di programmazione
    • Soft Skill
  • Talent
    • Discover Talent
    • Jobs
    • Manifesto
  • Companies
  • For Business
    • EN
    • IT
    • ES
  • Sign in
ads

gabroglioMaggio 2, 2024

Cos’è l’architettura platformless?

Architettura del software
platformless
facebooktwitterlinkedinreddit

Nelle scorse settimane ho avuto il piacere di incontrare Asanka Abeysinghe (CTO di WSO2), per parlare delle evoluzioni future riguardo i prodotti WSO2.

L’incontro è stato anche il pretesto per poter approfondire un concetto che mi era già stato introdotto mesi fa dal fondatore di WSO2 Sanjiva Weerawarana.

Recommended article
Marzo 17, 2025

Gestire le code senza una coda: Scopri fastq

Puppo92

Architettura del software

Durante il nostro primo incontro, Sanjiva mi aveva parlato del concetto di Platformless, un pattern (forse solo un’idea o un’ispirazione?) il cui intento è quello di migliorare la produttività ed il tempo speso per lo sviluppo delle applicazioni.

Togliere, non per eliminare

Con il termine platformless non si intende l’assenza di un elemento, in questo caso la componente applicativa di integrazione con i sistemi centrali, si intende invece l’assenza quasi totale di tempo speso ad implementare queste componenti.

In un mondo ideale, gli sviluppatori non si occupano di risolvere singoli problemi di integrazione con ogni tipologia di piattaforma, la loro occupazione è impegnata pressoché al 100% nello sviluppo di componenti nel rispetto dei requisiti di business.

Tempo risparmiato: tempo speso meglio

L’interesse primario degli sviluppatori si può concentrare in maniera pressoché totale sullo sviluppo della componente puramente applicativa, controbilanciando in questo modo il tempo risparmiato nello sviluppo della piattaforma vera e propria.

Negli anni, l’attenzione verso l’uso di Virtual Machines in prima battuta e l’introduzione dei container successivamente, ha giocato un ruolo fondamentale nel favorire la migrazione verso questa metodologia.

L’adozione di tecnologie cloud-native, ha migliorato e semplificato l’adozione di architetture scalabili, ma è anche stata utile a creare ambienti di sviluppo coerenti con quelli di produzione, in questo modo una pipeline di CI/CD risulta più efficiente per i rilasci di quanto sviluppato negli ambienti di test e produzione.

Un approccio API first permette di definire in anticipo il modello dati desiderato per i processi di business, questo semplifica l’adozione di standard da parte degli sviluppatori che non devono quindi preoccuparsi di gestire formati dati proprietari e protocolli non standard, l’adozione di strumenti di API Management mette a disposizione degli utenti una piattaforma per il test delle API anche se queste sono ancora in fase di test.

Evoluzioni della piattaforma

Analizzando le tendenze passate possiamo immaginare che vi saranno ulteriori evoluzioni tecnologiche relative alle piattaforme, come menzionato in precedenza siamo passati da server fisici a macchine virtuali per arrivare alla definizione dei containers. Non possiamo prevedere con esattezza cosa ci riserverà il futuro, l’adozione di un architettura di tipo platformless però ci permetterà di essere più agili nell’integrare nuove tecnologie, dato che le applicazioni sono nativamente indipendenti dalla piattaforma tecnologica che le ospita.

Da dove iniziare

La creazione, l’implementazione, la gestione e l’evoluzione di tutta questa infrastruttura possono essere visti come difficili o addirittura impossibili per la maggior parte delle organizzazioni, questo può portare a discostarsi da quello che è il focus principale ossia la risoluzione dei requisiti di business, concentrandosi invece su quali debbano essere le scelte tecnologiche per risolvere nella maniera più efficiente i requisiti iniziali.

L’approccio cloud-native è riconosciuto come un metodo efficace per lo sviluppo di sistemi distribuiti moderni e che implementino i requisiti di scalabilità e sicurezza più moderni, la disponibilità di applicazioni containerizzate permette anche l’adozione di architetture multi cloud. Tuttavia, sviluppare, implementare e gestire questi sistemi richiede un investimento considerevole dal punto di vista tecnologico, occorre quindi innanzitutto investire il tempo necessario alla definizione del modello operativo.

Domain Driven Design (DDD)

Il Domain Driven Design è un approccio allo sviluppo del software focalizzato sulla creazione di un modello di dominio che rifletta una comprensione approfondita dei processi e delle norme specifiche del settore, questo è particolarmente efficace in ambiti complessi che necessitano di una logica dettagliata e spesso intricata.

Il DDD si concentra sulla gestione della complessità attraverso un’attenzione particolare al dominio, cioè al contesto specifico dell’ambito aziendale in cui il software viene applicato. Promuove l’adozione di un linguaggio onnipresente: un vocabolario comune tra sviluppatori e stakeholder aziendali, che, impiegato nella progettazione e realizzazione del software, assicura che questo rispecchi fedelmente il dominio di riferimento.

La comunicazione efficace rappresenta il fulcro di ogni progetto di sviluppo software riuscito. Nel framework DDD, il linguaggio onnipresente agisce come un collegamento essenziale tra sviluppatori, esperti del settore ed utenti. Questo linguaggio comune è impiegato costantemente durante tutto il processo di sviluppo software, partendo dalle discussioni preliminari e la documentazione, fino all’implementazione vera e propria. Questa pratica assicura che tutti i partecipanti ottengano una comprensione limpida e omogenea del dominio di business, promuovendo una collaborazione efficace e minimizzando il rischio di malintesi o interpretazioni errate.

Cell Based Architecture (CBA)

L’obiettivo principale dell’architettura CBA è quello di dare una struttura ed un’organizzazione ai sistemi in evoluzione, consentendo così una migliore manutenibilità e flessibilità nelle evoluzioni del software.

Uno degli elementi fondamentali è la cella: un insieme di elementi che vengono raggruppati e gestiti in maniera comune a partire dalla progettazione, passando per l’implementazione per arrivare alla distribuzione. Una cella viene distribuita in maniera indipendente, gli elementi all’interno della cella comunicano tra di loro con il supporto di appositi transport intra-cella, mentre verso l’esterno tramite gateway che espongono API o eventi.

Platformless: conclusioni

Centralizzare le attività che influenzano trasversalmente tutti i progetti consente di stimare con maggiore precisione tempi e costi per ciascuna soluzione, migliorando la produttività dei team e prevenendo la duplicazione di compiti comuni.

Per le organizzazioni che mirano all’eccellenza nell’ingegneria del software e nello sviluppo di prodotti digitali, è essenziale comprendere e integrare l’approccio Platformless per mantenere la competitività e prepararsi al futuro nel costante evolversi del panorama digitale.

La collaborazione diretta instaurata con WSO2 negli anni ha permesso a Profesia di diventare distributore di prodotti per la gestione di API, CIAM e integrazione. Lavorando con aziende leader nel mercato, abbiamo potuto accrescere le nostre competenze in settori complessi, garantendo un ruolo di consulenza specializzata nella definizione di architetture efficaci.

Codemotion Collection Background
Dalla community
Selezionati per te

Vuoi scoprire più articoli come questo? Dai un’occhiata alla collection Dalla community dove troverai sempre nuovi contenuti selezionati dal nostro team.

Share on:facebooktwitterlinkedinreddit

Tagged as:architecture platformless

gabroglio
Ricopro il ruolo di Platform Engineer presso Profesia, collaboro con le organizzazioni per definire le opportune scelte architetturali. Partendo dai requisiti di business lavoro per creare soluzioni efficienti ed estensibili nel tempo applicando gli opportuni pattern basati su standard e protocolli noti.
Giuseppe Alibrandi CTO @BPER: “Il CTO del futuro sarà sempre più parte del business”
Previous Post
Design System: come implementarlo
Next Post

Footer

Discover

  • Events
  • Community
  • Partners
  • Become a partner
  • Hackathons

Magazine

  • Tech articles

Talent

  • Discover talent
  • Jobs

Companies

  • Discover companies

For Business

  • Codemotion for companies

About

  • About us
  • Become a contributor
  • Work with us
  • Contact us

Follow Us

© Copyright Codemotion srl Via Marsala, 29/H, 00185 Roma P.IVA 12392791005 | Privacy policy | Terms and conditions