In questi giorni, è difficile passare troppo tempo a leggere le tendenze di e-commerce senza inciampare in un articolo sull'ecommerce dei microservizi.
In effetti, molte aziende stanno abbandonando applicazioni monolitiche a favore dei microservizi. Uno studio condotto da LightStep ha rilevato che il 92% dei 353 stakeholder senior coinvolti nell'indagine ha rilevato un aumento nell'adozione di microservizi nelle proprie organizzazioni nell'ultimo anno e si aspettava che tale tendenza continuasse nel prossimo anno.
Ma cosa significa esattamente architettura di microservice e come influenza l'e-commerce? Spesso si vede il microservizio in contrasto con il suo opposto: l'architettura monolitica. In che cosa i microservizi sono diversi da un monolite e perché molte marche si muovono in direzione di un microservizio?
Un'architettura di microservizi è un insieme di servizi liberamente accoppiati che collaborano alla creazione di un sistema. I microservizi operano su sistemi intrinsecamente distribuiti che si connettono tramite gateway API.
Questo grafico mostra la struttura di base di un monolite che contiene tutti gli elementi del sistema di e-commerce. Qui, è paragonato a un'offerta SaaS (software-as-a-service) tradizionale che si integra con sistemi di terze parti, così come uno stile architettonico microservizi che disaccoppia i servizi e li collega tramite API.
Molti siti su larga scala come Netflix e Spotify sono passati da monoliti a sistemi di microservizi. In tal modo, possono adattarsi alle nuove innovazioni più rapidamente e scegliere le migliori soluzioni disponibili. Poiché le parti del sistema, o microservizi, operano in modo indipendente, le modifiche possono essere apportate più rapidamente portando a un time to market più rapido per aggiornamenti e integrazioni più agili.
In questa immersione approfondita, vedremo quale architettura dei microservizi è, come si è evoluta dai monoliti, quale commercio senza headless è e come si confronta e cosa considerare prima di fare un passaggio.
Commercio digitale tradizionale
Per illustrare perché i microservizi stanno prendendo le redini dopo decenni di dipendenza dai monoliti, torniamo all'inizio della storia umana. Molto prima che ci fosse l'e-commerce o il software o addirittura i soldi, c'era semplicemente l'umanità che cercava di cavarsela con una buona caccia e raccolta antiquata.
I gruppi di cacciatori-raccoglitori erano sistemi autosufficienti e autonomi. Tutti sapevano tutto e potevano fare decentemente la maggior parte dei compiti richiesti per la sopravvivenza.
Anche dopo la Rivoluzione Agricola, gli umani vivevano in piccole comunità intime dove potevano ancora riuscire a cavarsela con le economie del baratto e della reciprocità.
Poi la vita è diventata molto più complicata.
L'ascesa delle città e il miglioramento dei trasporti hanno portato nuove opportunità di specializzazione. Le persone non potevano più sapere tutto, quindi hanno iniziato a padroneggiare compiti specifici. E così nacquero calzolai, vasai, fornai e dottori.
In molti modi, possiamo vedere paralleli nell'evoluzione dell'architettura dei microservizi da monoliti.
Fino a poco tempo fa, la maggior parte delle piattaforme di e-commerce erano supportate da architetture monolite. Questi sono i sistemi autosufficienti, self-hosted, jack-of-all-trades originali. Forniscono alle aziende un sistema centralizzato, on-premise e ricco di funzionalità per soddisfare le loro esigenze. Tuttavia, poiché un'azienda diventa più complessa, questi sistemi possono spesso essere lenti e difficili da scalare.
L'architettura di microservizi offre un approccio decentralizzato e disaccoppiato. Invece di una soluzione che fa tutto, separa le diverse esigenze aziendali in servizi diversi che poi comunicano tra loro.
Ciò significa che anche se il business e le sue esigenze diventano più complesse, i microservizi possono offrire velocità e flessibilità.
Proprio come i primi umani scoprirono che potevano ottenere risorse e servizi migliori se commerciavano (e in seguito pagavano) per loro da specialisti, i microservizi offrono alle aziende la possibilità di combinare i migliori servizi individuali per soddisfare le loro attività.
Il risultato è una piattaforma agile in grado di incapsulare tutti i requisiti aziendali, ma anche di innovare rapidamente con le mutevoli richieste del mercato.
Problemi con i modelli Monolith
Come spiegato sopra, due decenni fa, le architetture monolite erano l'unica opzione per le aziende di e-commerce. Le imprese non avevano altra scelta che costruire e aggiornare e mantenere costantemente queste strutture sempre più complicate.
In un certo senso, un monolite sembrerebbe essere più semplice. Tutti i componenti necessari sono contenuti in un unico sistema. Tuttavia, col passare del tempo, molti marchi hanno sperimentato sfide e problemi con queste strutture all-in-one.
1. Le personalizzazioni portano a complicazioni.
Le piattaforme monolitiche funzionano per definizione con un sistema di frontend e backend strettamente accoppiato. Al fine di aggiornarli per creare personalizzazioni o personalizzazioni, gli sviluppatori devono modificare il codice del database sottostante e la piattaforma front-end. Questo può richiedere molto tempo. Può inoltre rendere il sistema sempre più complicato nel tempo, in particolare con le crescenti capacità aziendali e diversi team di sviluppo che lavorano nel sistema nel corso degli anni.
2. La risposta alle nuove tendenze del mercato è lenta.
I clienti si aspettano sempre di più dalle loro esperienze di acquisto e-commerce. I marchi devono essere agili per implementare rapidamente i cambiamenti e soddisfare le nuove tendenze e aspettative.
Poiché una piattaforma monolite può essere più lenta e complicata da aggiornare, può rallentare il ciclo DevOps e rendere più difficile per il marchio effettuare aggiornamenti rapidi.
3. L'alta dipendenza porta a un singolo punto di errore.
Le piattaforme di monolito sono fragili. Poiché le parti sono accoppiate e dipendenti l'una dall'altra, quando un pezzo del puzzle non si adatta, può far cadere l'intero sistema.
4. Gli aggiornamenti richiedono molti test prima di andare in diretta.
A causa del potenziale per una semplice modifica che abbatte il sistema, tutti gli aggiornamenti devono essere attentamente testati. Ciò richiede più forza lavoro e tempo per sottoporsi a tutti i test necessari per assicurarsi che nulla vada storto.
Commercio senza testa
Una versione dell'approccio dei microservizi è il commercio senza testa. Il commercio headless comporta il disaccoppiamento del livello di presentazione front-end dal motore di e-commerce back-end.
Il frontend o la 'testa' della maggior parte dei siti di e-commerce è il tema o il modello che controlla ciò che i clienti vedono. Headless consente una maggiore flessibilità nella distribuzione dei contenuti perché è possibile collegare un sistema di gestione dei contenuti (CMS) o una piattaforma di esperienza digitale (DXP) o dispositivo Internet of Things (IoT) specificamente progettato per la creazione di commercio basato sul contenuto o sull'esperienza. È quindi possibile sostituire il front-end senza influire sulle operazioni di back-end.
Il frontend scelto comunica all'e-commerce back-end tramite semplici chiamate API.
Le aspettative dei clienti stanno aumentando. Vogliono opzioni di spedizione veloci, gestione sicura dei dati e esperienze digitali uniche. Stanno anche acquistando più omni-channel che mai e vogliono vedere le loro esperienze online riflesse offline e viceversa. Headless e microservizi possono aiutare ad affrontare queste aspettative.
Come Adam Grohs, il co-fondatore dell'agenzia di innovazione digitale Particular, afferma: "La prossima generazione di piattaforme di commercio abbraccerà con tutto il cuore i microservizi, l'architettura headless e event-driven in quanto l'e-commerce per i marchi non riguarda più una destinazione. Eventi ed esperienze monetizzabili saranno più della norma di un sito di e-commerce come destinazione. "
Headless consente alle aziende di essere agili e di innovare perché possono apportare modifiche al loro frontend più velocemente senza compromettere componenti di e-commerce essenziali come il loro checkout e la sicurezza.
Per ulteriori informazioni sul commercio headless e le ragioni per cui le marche lo stanno abbracciando, dai un'occhiata a questo articolo approfondito.
Qual è la differenza tra Headless e Microservice Architecture?
Con headless, alcune parti del sistema sono disaccoppiate (il frontend dal backend). Tuttavia, una vera architettura di microservizi consente alla piattaforma e all'architettura orientata ai servizi di essere completamente disaccoppiati.
Con entrambe le piattaforme disaccoppiate e senza testa, l'ambiente di gestione dei contenuti e gli ambienti di distribuzione del contenuto sono separati. In un ambiente disaccoppiato, tuttavia, il contenuto viene attivamente inserito nell'ambiente di consegna. Un CMS senza testa, d'altra parte, rimane inattivo in uno stato reattivo finché non viene inviata una richiesta di contenuto.
Un CMS privo di headless è composto da strumenti di creazione di contenuti e editoriali e ha un'API che è resa disponibile per le applicazioni di terzi che pubblicano il suo contenuto. Al contrario, un CMS disgiunto è più proattivo, in quanto ha tutte le caratteristiche di un CMS senza testa e anche strumenti per i modelli. Non solo copre la preparazione dei contenuti, ma li spinge anche in un ambiente di consegna.
Motivi per il passaggio a microservizi e senza testa
Considerati i problemi con un sistema monolite menzionato sopra, non c'è da stupirsi che i marchi aziendali inizino a cercare nuove soluzioni. Per rispondere rapidamente alle esigenze dei clienti e alle tendenze del mercato, un'architettura di microservizi fornisce una base flessibile.
L'utilizzo di componenti microservice liberamente accoppiati per creare il sistema completo presenta una serie di vantaggi sia per gli sviluppatori che per gli utenti finali.
1. Il traffico di frontend pesante non influisce sul back-end.
Un chiaro vantaggio di avere un'architettura di microservizio è che il frontend e il backend possono essere ridimensionati singolarmente. Gli sviluppatori possono estendere i servizi laddove sono necessari senza che sia necessario adeguare l'intero sistema. Ciò significa che un elevato traffico sul frontend non influirà sulle operazioni di back-end.
2. Maggiori opportunità per personalizzazione e personalizzazione.
Con un sistema senza testa, puoi avere più frontend che si collegano a un sistema di backend. Questo presenta l'opportunità di implementare più nuovi touchpoint sul frontend.
3. Lo stack tecnologico consente un'implementazione rapida.
Poiché i microservizi oi sistemi headless hanno un processo di sviluppo decentralizzato, è più facile per gli sviluppatori di team diversi collaborare per adeguare il codice base e arrivare sul mercato più velocemente.
4. Ottieni solo ciò di cui hai bisogno.
Un monolite è un sistema all-in-one ricco di funzionalità, ma si può finire per pagare e lavorare attorno a funzionalità e funzionalità che la tua azienda non richiede. Con un approccio basato sui microservizi, ciascun microservizio serve una funzione aziendale. Puoi aggiungere solo ciò che effettivamente utilizzerai per il tuo sistema, creando uno stack tecnologico più snello ed efficiente.
5. Ottieni soluzioni best-in-breed.
Invece di affidarsi a un sistema per provare a fare tutto, puoi scegliere i servizi e i fornitori di servizi che si specializzeranno esattamente in ciò di cui hai bisogno. Avere un approccio indipendente dal fornitore ti consentirà di perfezionare servizi che corrispondono alle tue esigenze aziendali.
BigCommerce consente la flessibilità dei microservizi, ma a un prezzo più accessibile.
Potenziali svantaggi dei microservizi rispetto al commercio headless
Vi sono chiaramente numerosi vantaggi nell'architettura dei microservizi, il che spiega perché così tante aziende si stanno muovendo in quella direzione. Tuttavia, quali sono alcuni dei potenziali ostacoli e ostacoli da prendere in considerazione?
1. Richiederà cambiamenti organizzativi.
Passare a un'architettura di microservizi non richiede solo una modifica al modo in cui è organizzata la tua piattaforma di e-commerce. Può causare una modifica all'intera struttura organizzativa. La gestione dei diversi microservizi richiede team interfunzionali e verticali in grado di collaborare allo sviluppo e alla manutenzione del sito. Headless non richiede necessariamente queste stesse modifiche. Di solito puoi conservare molti dei tuoi stessi sistemi e collegarli a un motore di e-commerce come BigCommerce.
2. Potrebbe richiedere modifiche dell'infrastruttura.
Un'altra considerazione potenziale del passaggio a un sistema di microservizi è che potrebbe modificare l'infrastruttura e gli strumenti necessari per monitorare i diversi microservizi. Siate consapevoli di quali cambiamenti saranno necessari e fateli carico del costo totale di proprietà. Questo è anche il motivo per cui può essere preferibile senza testa, in quanto è possibile ottenere i vantaggi della flessibilità con meno modifiche ai sistemi esistenti.
3. I microservizi completamente disaccoppiati possono essere costosi.
A seconda del budget, il costo di un sistema di microservizi completamente disaccoppiato può essere un deterrente. Strumenti come Elastic Path e commercialetools offrono un'architettura di microservizi completamente disaccoppiati, ma possono anche essere incredibilmente costosi. Questo è uno dei motivi per cui le marche possono considerare una soluzione senza testa tramite BigCommerce come alternativa.
Aziende che scelgono il commercio senza testa su microservizi
Qui ci sono alcune aziende che stanno vedendo i vantaggi di un approccio headless, basato su API al loro e-commerce.
1. FireWire Surfboards.
FireWire Surfboards è stato un innovatore nella creazione e vendita di tavole da surf eco-compatibili mentre si collegava ai clienti in esperienze offline in California Surf Ranch.
Hanno usato un CMS WordPress per il loro frontend e lo hanno collegato tramite un semplice plug-in alla piattaforma BigCommerce per un e-commerce scalabile e sicuro sul back-end. L'ambiente WordPress consente a FireWire di creare un'esperienza di content + commerce per i clienti senza calpestare l'e-commerce come un ripensamento.
2. Carluccio's
Il ristorante italiano Carluccio e il fornitore di specialità alimentari è un altro esempio di business costruito utilizzando il plugin BigCommerce per WordPress per creare una soluzione senza testa.
Costruendo il loro livello di presentazione su WordPress, sono in grado di creare un viaggio coerente dell'acquirente dalla pagina del prodotto alla cassa.
3. Zwift.
Zwift è un'app di allenamento a casa per connettere i ciclisti di tutto il mondo. Zwift ha collaborato con The ZaneRay Group per sviluppare un webstore su BigCommerce, integrando un CMS prismatico senza testa con l'interfaccia programmata in React come un'applicazione Web progressiva.
Questa configurazione consente a Zwift di integrare tutti i loro sistemi senza dover riprogrammare il loro sito e fornisce loro un negozio online che crescerà con la loro attività.
Passare da un'architettura Monolith a Microservices o Headless
Ci sono una serie di ragioni per cui potresti voler passare da un monolite a un microservizio o un'architettura senza testa.
Forse stai riscontrando dei limiti con il tuo attuale sistema e fare e testare le modifiche sta diventando un processo troppo lento. Vorresti un sistema che spezzi il tuo sistema in sezioni più piccole e autosufficienti che sono più facili da testare e distribuire.
Un altro motivo per cui potresti prendere in considerazione una mossa è perché il tuo sistema attuale richiede un aggiornamento o è in fase di eliminazione. Ad esempio, se sei un cliente Magento 1, potresti aver programmato uno switch a causa del tramonto del prodotto nel 2020.
I marchi che considerano un passaggio da un sistema monolite a un sistema di microservizi possono essere cauti su ciò che serve per eseguire la sostituzione. Tuttavia, ci sono buone notizie!
A differenza del passaggio da un monolite a un altro, il passaggio da un monolite a un microservizio o piattaforma senza testa può essere fatto in modo incrementale.
Come spiega Shane Baker, Digital Strategist e Brand Influencer Consultant di Shane Barker Consulting: "È estremamente semplice adottare un approccio basato sui microservizi perché puoi farlo gradualmente. Non devi prepararti per un cambiamento grande e istantaneo che potrebbe interrompere le tue operazioni. È molto semplice scalare i servizi e le funzioni più importanti senza la necessità di ridimensionare l'intera applicazione. "
Con un approccio incrementale, puoi prima decidere quali capacità disaccoppiare e quando separare lentamente l'intero monolite in un sistema di microservizi. Puoi iniziare la transizione verso la tua nuova piattaforma, mentre stai ancora costruendo il resto delle parti.
Attraverso un metodo noto come pattern di strangolatore, si interrompe in sostanza il monolite in componenti di servizio singolo e li si sostituisce con microservizi pezzo dopo pezzo.
Conclusione
Due decenni fa un sistema monolite era l'unica opzione per le grandi marche per costruire la propria presenza e-commerce. Tuttavia, le piattaforme monolitiche possono limitare l'innovazione rapida che richiede la vendita al dettaglio moderna.
Un approccio basato su API e microservizi può essere un modo efficace per aumentare la flessibilità e consentire esperienze migliori ai clienti. Consente ai team di sviluppatori di offrire in modo pulito consegne continue durante gli aggiornamenti.
Allo stesso modo il commercio senza testa consente molti dei vantaggi dei microservizi, senza alcuni degli svantaggi.
Se stai pensando di passare da un monolite a un'architettura di microservizi oa un commercio headless, fai la tua ricerca per determinare in che modo l'utilizzo di soluzioni best-in-breed in un sistema decentralizzato possa avere un impatto sul TCO, sulla velocità delle tue operazioni e sul tuo capacità di offrire la migliore esperienza possibile per i vostri clienti.
