La tecnologia dietro un SaaS gestito da un solo uomo

Ogni volta che vedo ingegneri scrivere sulla loro stack, sono curioso di scoprire nuovi strumenti. Soprattutto quando si gestiscono le cose da soli, si è sempre alla ricerca di imparare dall'esperienza degli altri.

Nel 2015 ero frustrato dal livello attuale dei gestori di password, in particolare dal fatto che non c'era nulla di decente per le persone che gestiscono server privati. Ho iniziato a lavorare su Psono, un gestore di password open source con un livello di crittografia decente e opzioni di condivisione sicura. Psono non è mai stato pensato per essere eseguito come SaaS, altrimenti probabilmente avrei supportato più tenenti sin dall'inizio.

Solo per darti un'idea della scala di Psono. Psono è attualmente installato localmente in circa 70 paesi, con più di 4000 installazioni. Psono SaaS è attualmente utilizzato da oltre 15.000 persone, la maggior parte delle quali utilizza la nostra edizione comunitaria gratuita di Psono che gira sulla stessa stack tecnologica del nostro prodotto Enterprise a pagamento.

La stack di un'installazione tipica di Psono consiste in un database, un server, due client web (uno per gli utenti normali e uno per gli amministratori), app per iOS e Android, estensioni del browser per Chrome e Firefox. Un cliente può installare un gateway LDAP o un file server sopra questo.

Oltre a ciò ho molta altra infrastruttura in atto. Partendo dal sito web che alimenta la homepage dell'azienda e la pagina del prodotto, ho un server di licenze per il nostro prodotto aziendale, un sistema ERP centrale per gestire preventivi e fatture, un negozio dove le persone possono acquistare Psono SaaS e gestire la loro installazione e un servizio di autenticazione con OIDC.

Nel corso dell'articolo vedrete che preferisco tecnologie vecchie e noiose.

Linguaggi

• Python: Tutto il codice backend è scritto in Python. I maggiori vantaggi di Python sono il suo vasto ecosistema. La mancanza di tipi (molte persone lo considerano uno svantaggio) rende estremamente veloce la scrittura del tuo servizio web, che come startup è uno degli aspetti chiave da cercare in un linguaggio di programmazione.
• Javascript: Oh no... chi l'avrebbe mai detto... È semplicemente impossibile creare qualsiasi sito web senza Javascript, già nel 2015. ;)

Python è per i web service il mio linguaggio preferito. (Ometto i miei pensieri su perché non XY è migliore di Python. Questo riempirebbe un altro articolo del blog.) C'è solo uno svantaggio che devi contrastare ed è la possibilità di distribuire il codice con tutte le dipendenze in modo affidabile, cosa particolarmente cruciale se le persone installano il tuo software localmente e chiedono supporto se incontrano problemi. (La velocità, che altre persone potrebbero aggiungere qui, non importa. Python è abbastanza veloce).

Framework

• Django: "È come un superpotere per sviluppatori solitari" (se mi è permesso citare Athony N. Simons qui). Insieme all'ecosistema risolve quasi tutti i problemi che potresti incontrare. Autenticazione, template, email, migrazioni del database, totp, ... solo per citarne alcuni.
• Django Rest Framework: Attualmente alimenta tutte le API e fa un ottimo lavoro. I diversi livelli (serializzazione, autenticazione, permessi, viste) mantengono il tuo codice estremamente pulito.
• React: Ho recentemente migrato il client web regolare a React. Il vecchio client web (ricorda che è stato avviato nel 2015) era scritto in AngularJS ed è stata un'impresa mantenere la compatibilità con il vecchio client, ad esempio tutti i percorsi per l'utente non devono cambiare, poiché potrebbero avere collegamenti preferiti a segreti nella loro documentazione o avere cosiddetti link di condivisione in uso. Inoltre, le persone usavano il branding personalizzato con loghi propri e così via, dove i percorsi sul sistema non dovevano cambiare.
• webpack: Volevo menzionarlo qui, poiché attualmente è l'unica parte di cui non sono soddisfatto. È lento, stressante, difficile da imparare ... l'unico vantaggio è che non rimani mai bloccato. Qualsiasi problema che potresti incontrare, è stato già chiesto su Stackoverflow e trovi una soluzione.
• Gatsby: Alimenta i nostri siti web statici per l'azienda e il prodotto. In tempi precedenti ho usato wordpress, ma la gestione con gli aggiornamenti e la paura costante che il sito web venisse compromesso (e la potenziale cattiva pubblicità) ci ha fatto passare a Gatsby. Finora non mi sono mai pentito.
• Vuepress: Il sistema di gestione della documentazione più decente che ho trovato. Compila in siti web statici, ha un aspetto moderno e attualmente alimenta la documentazione di Psono
• Material UI: La main library che alimenta il frontend. È ricca di funzionalità, funziona bene insieme a React e ha un aspetto abbastanza moderno, in contrasto con i vecchi temi basati su Bootstrap.

Ci sono sicuramente innumerevoli altri che meriterebbero di essere menzionati qui, eppure questi sono i "più importanti" secondo la mia opinione.

Database

Anche così, Django supporta più database e mi sono trovato molto presto a dover decidere se volevo supportare tutti i database di Django o solo uno particolare. La radice di questa domanda era che stavo memorizzando strutture ad albero nidificate nel database. Quindi alberi con più radici e rami condivisi. Querying efficienti erano cruciali, quindi dopo aver esplorato tutte le opzioni disponibili ho deciso di andare con l'estensione ltree di Postgre.

Se hai intenzione di sviluppare qualcosa e gestirlo da solo, deve funzionare nel cloud in modo affidabile, gestito dal provider di cloud. Molto probabilmente non vuoi nemmeno essere vincolato al fornitore, quindi niente di specifico per il cloud, il che limita abbastanza le tue scelte.

La mia decisione:

• Postgres: Ci sono due database open source tra cui puoi scegliere. MariaDB o Postgres. Ho sempre pianificato di andare con Maria (principalmente a causa del Galera Cluster di Maria DB, una di queste storie sbagliate "giovane sviluppatore deve pianificare la crescita iper" ;D) ma a causa delle estensioni ltree mancanti le mie mani erano forzate. Al giorno d'oggi, con tutto lo sviluppo che entra nelle opzioni di sharding di Postgres, non mi sono mai pentito di questa decisione finora.
• Redis: Pianificato di essere utilizzato come cache per installazioni più grandi. Anche qui puoi scegliere tra Redis o Memchache. Entrambi sono eccellenti, ma principalmente a causa del protocollo Redis che al giorno d'oggi è lo standard de facto per il caching, sono andato con Redis. L'unico svantaggio che ho mai sperimentato con Redis è che è single threaded.

Infrastruttura

Solo una piccola panoramica dell'infrastruttura su cui si basa Psono:

• Gitlab: Gitlab alimenta tutta l'automazione di Psono. Degno di nota è che tutto in Psono è automatizzato, il che è uno degli aspetti chiave di come posso gestire i rilasci e mantenere l'intero ecosistema di Psono. Nel 2015 ogni progetto open source funzionava su github, ma Gitlab era (e lo è tutt'ora) così potente e superiore in termini di funzionalità (ad eccezione della funzionalità di ricerca di github). Gitlab alimenta build, rilasci, scansioni di vulnerabilità di OGNI pezzo di software che usiamo.
• Cloudflare: Probabilmente l'azienda più innovativa che conosco che mi ha influenzato negli ultimi 10 anni. È giusto dire che Cloudflare sta alimentando Internet al giorno d'oggi. Mi fornisce nameserver affidabili, TLS, una CDN decente e funzionalità avanzate come il loro edge worker. La protezione DDoS e la funzionalità WAF forniscono un certo extra, che come gestore di password è abbastanza importante. Mi piacerebbe usare la loro funzione SSL come servizio per consentire ai clienti SaaS di configurare i propri domini, ma il paywall del livello Enterprise di Cloudflare è semplicemente troppo duro. Spero ancora che lo rilascino da qualche parte come un plugin indipendente che si può acquistare.
• namecheap: La mia soluzione di riferimento per domini e certificati ssl.
• Google Cloud Run: Tutti i server backend funzionano su Google Cloud Run, che è estremamente conveniente e affidabile quando vuoi avviare una flotta di servizi. Una volta che hai la tua stack in esecuzione, fa un ottimo lavoro. La loro integrazione API / CLI di prim'ordine è un assoluto plus qui. Ci sono alcuni svantaggi, come il supporto mancante da parte di Google o la minaccia che Google potrebbe decidere a un certo punto che essere #3 come provider di servizi cloud potrebbe non valere la pena e cancellano il prodotto.
• Artifactory: Protegge la mia pipeline di build contro le interruzioni di npm e memorizza i miei artefatti di build (che non era incluso in Gitlab nel 2015)
• Docker Hub: Memorizza tutti i container docker e esegue alcune ulteriori scansioni di sicurezza e distribuzione dei miei container.
• Mailgun: Gestisce tutte le email. In contrasto con la maggior parte dei provider di soluzioni email, Mailgun ha funzioni di logging e analisi decenti. Il loro supporto è di prim'ordine. L'unico problema è che le loro email vengono a volte inviate nella casella di spam (anche con SPF, DMARC e così via tutto in atto), ma oltre a ciò fanno un ottimo lavoro.
• Poeditor: Gestisce tutte le traduzioni. La cosa bella è che i contributori possono richiedere l'accesso, che è cruciale se si vuole che gli esterni aiutino a tradurre il tuo progetto. Il loro supporto è fantastico e si ottengono risposte estremamente veloci.
• Docker: Una delle migliori decisioni per l'intero progetto. Soprattutto dato che uso Python e distribuire codice Python funzionante con tutte le dipendenze Python / librerie OS è difficile. Se le cose devono funzionare con un cliente on-premise e il requisito che possa aggiornare e mantenere il sistema. Docker ci consente di fare tutto questo e mi dà il pieno controllo dei pacchetti installati, il che risolve almeno il 70% di tutti i problemi di supporto (mentre introduce il 20% di nuovi problemi poiché le persone non sono abituate a Docker ;D).

Monitoraggio

Quindi le cose possono andare storte e devi sapere quando succede e ottenere alcune informazioni sul problema. Ecco dove questi strumenti tornano utili:

• Google Cloud logging: Se sei su Google, la tua soluzione naturale
• Sentry: La mia soluzione numero uno per la segnalazione degli errori. Una volta provata non vorrete mai farne a meno. Mi dà l'idea necessaria di tutti gli errori.
• Uptimerobot: Chiama l'healthcheck dei miei vari servizi e mi avverte se qualcosa va giù. La pagina di stato pubblico per Psono tra l'altro può essere trovata qui https://stats.psono.com/, che è solo una piccola frazione dei servizi che questo strumento monitora per me, ma si spera che dimostri un po' l'affidabilità del sistema.

Infrastruttura di sviluppo

Una piccola panoramica di come appare la mia stack di sviluppo locale:

• Windows con WSL: Probabilmente riceverò molti commenti negativi per questo, ma sì, sto girando su Windows. Negli ultimi anni avevo sempre da qualche parte una VM Linux a cui mi collegavo per lo sviluppo, ma al giorno d'oggi è alimentato da WSL. Sto ottenendo il meglio di entrambi i mondi.
• Pycharm / Webstorm: Uso Jetbrain IDE. La funzionalità di sviluppo remoto è cruciale per il mio flusso di lavoro di sviluppo e questa filosofia "batteries included" mi si addice bene. A volte ho circa 20 progetti aperti, il che richiede un hardware decente con abbastanza RAM. VSCode sembra essere una buona alternativa al giorno d'oggi, ma nel corso degli ultimi anni mi sono abituato a Jetbrains e imparare qualcosa di nuovo richiede sempre una certa forza mentale che attualmente non sono disposto a investire in questo. Direi che ognuno dovrebbe usare qualcosa a cui è abituato.

Supporto

Ci sono ovviamente strumenti necessari per gestire il supporto per le persone che utilizzano il prodotto:

• Freshdesk: Un tipico software di ticket email. Mi aiuta a tenere traccia delle varie richieste dei clienti. Nei primi tempi forniva un livello gratuito decente, che è cruciale soprattutto nella fase di fondazione.
• Discord: Alcune persone potrebbero preferire la chat o richiedere una conversazione / aiuto più diretto. È qui che Discord torna utile.

Altro

Ci sono alcuni altri strumenti che volevo menzionare che potrebbero essere utili ad altri. Soprattutto le banche per coloro che vogliono gestire la loro attività in Germania:

• Odoo: Il miglior sistema ERP. La sua edizione open source è gratuita e può essere facilmente estesa con conoscenze di python e un po' di XML. Le sue opzioni di personalizzazione e integrazione con API personalizzate sono di prim'ordine.
• Holvi: Il nostro conto bancario principale. In Germania, hai bisogno di una banca che ti permetta di aprire un conto per i fondatori, in tedesco "Gründerkonto", quindi un conto bancario che è legato a una società che non è ancora completamente registrata e dove puoi trasferire il denaro iniziale che è necessario per registrare l'azienda. Un po' un problema di uovo e gallina. E le grandi banche che lo permettono di solito costano una fortuna. Il processo di registrazione ha funzionato anche in modo piuttosto fluido. L'unico aspetto negativo è il supporto mancante per i pagamenti internazionali, ma è qui che entra in gioco il servizio successivo.
• Wise: Il nostro secondo conto bancario. Le loro commissioni sono estremamente basse (ad esempio, nessuna commissione mensile), il processo di configurazione funziona senza problemi, sono ben collegati e permettono trasferimenti bancari internazionali e i trasferimenti sono effettuati rapidamente, quindi non devi aspettare settimane o simili.

Sicurezza

Immagino che questo potrebbe essere un post sul blog a parte su come abbiamo strutturato gli account utente, l'infrastruttura, i diritti di accesso. Poiché questo è uno degli aspetti più cruciali della sicurezza di Psono, non entrerò nei dettagli qui e cercherò di essere abbastanza vago. Stiamo usando sia i servizi Google Cloud che Azure. Entrambi con utenti e gruppi completamente separati. Ci sono utenti dedicati per compiti amministrativi e account utente per "il quotidiano". Ci sono diversi sistemi fisici e virtuali che uso per accedere / supportare / gestire / amministrare Psono. I compiti amministrativi vengono eseguiti solo su un dispositivo fisico separato, specialmente rinforzato, utilizzato esclusivamente per questi compiti. Ogni account è protetto con token hardware. Tutti i sistemi sono gestiti centralmente e ci sono politiche di sicurezza in atto per garantire che tutti i dispositivi seguano gli standard di sicurezza che si trovano di solito nelle banche.

Crediti

Questo articolo è stato fortemente ispirato dall'articolo di Anthony N. Simon su Panelbear.