De tech achter een eenpersoons SaaS

Wanneer ik ingenieurs zie schrijven over hun stack, ben ik nieuwsgierig om nieuwe tools te leren. Vooral als je dingen solo runt, ben je altijd op zoek om te leren van de ervaring van anderen.

In 2015 was ik gefrustreerd over het huidige niveau van wachtwoordmanagers, vooral omdat er niets fatsoenlijks was voor mensen die privéservers draaien. Ik begon te werken aan Psono, een open source wachtwoordmanager met een behoorlijk niveau van encryptie en veilige deelopties. Psono was nooit bedoeld om als SaaS te draaien, anders had ik waarschijnlijk vanaf het begin ondersteuning ingebouwd voor meerdere huurders.

Om je een beetje een overzicht te geven van de schaal van Psono. Psono is momenteel lokaal geïnstalleerd in ongeveer 70 landen, met meer dan 4000 installaties. Psono SaaS alleen wordt momenteel gebruikt door meer dan 15.000 mensen, de meeste van hen maken gebruik van onze gratis community-editie van Psono die op dezelfde tech stack draait als ons betaalde Enterprise-product.

De stack van een typische Psono-installatie bestaat uit een database, server, twee webclients (een voor gewone gebruikers en een voor beheerders), apps voor iOS en Android, browserextensies voor Chrome en Firefox. Een klant kan bovenop dat alles een LDAP-gateway of een fileserver installeren.

Naast dat alles heb ik nog veel meer infrastructuur in gebruik. Beginnend met de website die de bedrijfswebsite en productpagina aanstuurt, heb ik een licentieserver voor ons enterprise product, een centraal ERP-systeem om offertes en facturen te beheren, een winkel waar mensen Psono SaaS kunnen kopen en hun installatie kunnen beheren, en een authenticatieservice met OIDC.

In de loop van het artikel zul je zien dat ik de voorkeur geef aan oude en saaie technologie.

Talen

• Python: Alle backend code is geschreven in Python. De grootste voordelen van Python zijn het rijke ecosysteem. Het gebrek aan typen (veel mensen beschouwen dit als nadelig) maakt het extreem snel om je webservice te schrijven, wat als startup een van de belangrijkste aspecten is waar je naar moet kijken in een programmeertaal.
• Javascript: Oh nee... wie had dat gedacht... Het was al in 2015 onmogelijk om een website te maken zonder Javascript.

Python is voor webservices mijn favoriete taal. (Ik laat hier mijn gedachten weg waarom niet XY beter is dan Python. Dat zou nog een andere blogpost vullen.) Er is slechts één nadeel dat je moet tegengaan en dat is de mogelijkheid om code met alle afhankelijkheden betrouwbaar te verzenden, wat vooral cruciaal is als mensen je software lokaal installeren en om ondersteuning vragen als ze problemen ondervinden. (Qua snelheid, wat andere mensen hier misschien zouden toevoegen, maakt het niet uit. Python is snel genoeg.)

Frameworks

• Django: "Het is als een superkracht voor solodevelopers" (als ik hier Anthony N. Simons mag citeren). Samen met het ecosysteem lost het bijna alle problemen op die je kunt tegenkomen. Authenticatie, sjablonen, e-mail, database-migraties, totp,... om er maar een paar te noemen.
• Django Rest Framework: Het stuurt momenteel alle API's aan en doet dat uitstekend. De verschillende lagen (serialisatie, authenticatie, permissies, views) houden je code extreem schoon.
• React: Ik heb zojuist de normale webclient gemigreerd naar React. De oude webclient (onthoud alsjeblieft dat deze in 2015 is gestart) was geschreven in AngularJS en het was behoorlijk een uitdaging om achterwaarts compatibel te blijven met de oude client, bijvoorbeeld alle paden naar de gebruiker mogen niet veranderen, aangezien ze mogelijk links naar geheimen in hun documentatie hebben gebookmarked of zogenaamde linkshares in gebruik hebben. Ook gebruikten mensen aangepaste branding met eigen logo's enzovoort, waar paden in het systeem niet zouden moeten veranderen.
• webpack: Ik wilde het hier noemen, omdat het momenteel het enige onderdeel is waar ik ontevreden over ben. Het is traag, haren uit de kop trekkend, moeilijk te leren... het enige voordeel dat je hebt, is dat je nooit vastloopt. Elk probleem dat je misschien ervaart, is al gesteld op Stackoverflow en je vindt een oplossing.
• Gatsby: Aansturing van onze statische websites voor het bedrijf en het product. Vroeger gebruikte ik WordPress, maar de beheerslast met updates en de constante angst dat de website wordt gehackt (en de potentiële negatieve publiciteit) deden ons overstappen naar Gatsby. Tot nu toe nooit meer omgekeken.
• Vuepress: Het meest fatsoenlijke documentatiebeheersysteem dat ik kon vinden. Het compileert naar statische websites, ziet er modern uit en stuurt momenteel de Psono documentatie aan.
• Material UI: De belangrijkste bibliotheek die de frontend aandrijft. Het is rijk aan functies, werkt goed samen met React en ziet er behoorlijk modern uit, in tegenstelling tot oudere Bootstrap-thema's.

Er zijn ongetwijfeld talloze anderen die hier vermeld moeten worden, maar dit zijn volgens mij de "belangrijkste".

Databases

Hoewel Django meerdere databases ondersteunt, kwam ik al vroeg de vraag tegen of ik alle databases van Django wilde ondersteunen of slechts een specifieke. De reden voor deze vraag was dat ik geneste boomstructuren opsloeg in de database. Dus bomen met meerdere wortels en gedeelde takken. Deze efficiënt opvragen was cruciaal, dus na het verkennen van alle beschikbare opties besloot ik te gaan met de ltree-extensie van PostgreSQL.

Als je iets plant en het solo wilt uitvoeren, moet het betrouwbaar in de cloud werken, beheerd door de cloudprovider. Je wilt waarschijnlijk ook geen vendor lock-in, dus niets clouds-specifiek, wat je keuzes behoorlijk beperkt.

Mijn besluit:

• Postgres: Er zijn twee open source-databases waaruit je kunt kiezen. MariaDB of Postgres. Ik was altijd van plan om met Maria te gaan (meestal vanwege MariaDB's Galera Cluster, een van die misleidende "jonge ontwikkelaar moet plannen voor hypergroei" verhalen; D) maar vanwege de ontbrekende ltree-extensies waren mijn handen gebonden. Tegenwoordig, met alle ontwikkeling die in de sharding-opties van Postgres is gestoken, heb ik die beslissing nog nooit betreurd.
• Redis: Gepland als cache voor grotere installaties. Ook hier kun je kiezen voor Redis of Memcache. Beide zijn uitstekend, maar vooral vanwege het Redis-protocol, dat tegenwoordig de de facto standaard is voor caching, ben ik met Redis gegaan. Het enige nadeel dat ik ooit met Redis heb ervaren, is dat het enkel-draad is.

Infrastructuur

Een klein overzicht van de infrastructuur waarop Psono vertrouwt:

• Gitlab: Gitlab ondersteunt alle automatisering van Psono. Noemenswaardig is dat alles in Psono geautomatiseerd is, wat een van de belangrijkste aspecten is hoe ik releases kan beheren en het hele Psono-ecosysteem kan onderhouden. In 2015 draaide elk open source-project op GitHub, maar Gitlab was (en is nog steeds) zo machtig en functioneel superieur (met uitzondering van de zoekfunctionaliteit van GitHub). Gitlab ondersteunt builds, releases, kwetsbaarheidsscans van ELK stuk software dat we gebruiken.
• Cloudflare: Waarschijnlijk het meest innovatieve bedrijf dat me de afgelopen 10 jaar heeft beïnvloed. Het is eerlijk om te zeggen dat Cloudflare tegenwoordig het internet aandrijft. Het biedt me betrouwbare naamservers, TLS, een fatsoenlijke CDN en geavanceerde functies zoals hun edge worker. De DDoS-bescherming en WAF-functionaliteit bieden een bepaalde extra, wat als wachtwoordmanager behoorlijk belangrijk is. Ik zou graag hun SSL als een serviced functie willen gebruiken om SaaS-klanten hun eigen domeinen te laten configureren, maar de betaalmuur van Cloudflare's Enterprise-niveau is gewoon te moeilijk. Ik hoop nog steeds dat ze het ergens als een onafhankelijk plugin uitbrengen die men kan aanschaffen.
• namecheap: Mijn go-to oplossing voor domeinen en SSL-certificaten.
• Google Cloud Run: Alle backend-servers draaien op Google Cloud Run, wat buitengewoon kostenefficiënt en betrouwbaar is als je een vloot services wilt starten. Zodra je stack draait, doet het een geweldige job. Hun top-notch API / CLI-integratie is hier absoluut een pluspunt. Er zijn een paar nadelen, zoals de ontbrekende ondersteuning van Google of de dreiging dat Google op een gegeven moment zou kunnen besluiten dat de derde plaats als cloudserviceprovider het misschien niet waard is en ze het product annuleren.
• Artifactory: Beschermt mijn build-pipeline tegen npm-uitval en slaat mijn build-artifacts op (wat in 2015 niet gebundeld was in Gitlab).
• Docker Hub: Slaat alle docker-containers op en doet enkele extra beveiligingsscans en distributie van mijn containers.
• Mailgun: Verzorgt alle e-mails. In tegenstelling tot de meeste e-mailsoplossingsaanbieders heeft Mailgun fatsoenlijke log- en analysemogelijkheden. Hun ondersteuningsniveau is top-notch. Het enige probleem is dat hun e-mails soms in de spam-inbox terechtkomen (zelfs met SPF, DMARC enzovoort, allemaal op hun plaats), maar afgezien daarvan doen ze geweldig werk.
• Poeditor: Verwerkt alle vertalingen. Het leuke is dat bijdragers toegang kunnen aanvragen, wat cruciaal is als je externen wilt helpen met het vertalen van je project. Hun ondersteuning is geweldig en je krijgt extreem snel antwoorden.
• Docker: Een van de beste beslissingen voor het hele project. Vooral omdat ik Python gebruik en werkende Python-code met alle Python / OS-bibliotheekafhankelijkheden te verzenden moeilijk is. Als dingen verondersteld worden te werken met een klant on-premise en de vereiste dat hij het systeem kan updaten en onderhouden. Docker stelt ons in staat om dat allemaal te doen en geeft me volledige controle over de geïnstalleerde pakketten, waardoor ten minste 70% van alle ondersteuningsproblemen worden opgelost (terwijl 20% nieuwe problemen worden geïntroduceerd, aangezien mensen niet gewend zijn aan Docker ;D).

Monitoring

Dus dingen kunnen misgaan en je moet weten wanneer dat gebeurt en enig inzicht krijgen in het probleem. Dat is waar deze tools van pas komen:

• Google Cloud Logging: Als je bij Google zit, is dit een natuurlijke oplossing.
• Sentry: Mijn nummer één foutmeldingsoplossing. Zodra je het hebt geprobeerd, wil je het nooit meer missen. Het geeft me het nodige inzicht in alle fouten.
• Uptimerobot: Roept de gezondheidscheck van mijn verschillende services aan en zal me waarschuwen als er iets uitvalt. De openbare statuspagina voor Psono kan je trouwens hier vinden https://stats.psono.com/, wat slechts een klein gedeelte is van de services die dit ding voor mij monitort, maar hopelijk een beetje de betrouwbaarheid van het systeem laat zien.

Ontwikkelinfrastructuur

Een klein overzicht van hoe mijn lokale ontwikkelstack eruitziet:

• Windows met WSL: Ik krijg hier waarschijnlijk veel kritiek op, maar ja, ik werk op Windows. De afgelopen jaren had ik altijd ergens een Linux VM waar ik verbinding mee maakte voor ontwikkeling, maar tegenwoordig wordt het aangedreven door WSL. Ik krijg het beste van beide werelden.
• Pycharm / Webstorm: Ik gebruik Jetbrain IDE's. De remote development functionaliteit is cruciaal voor mijn ontwikkelworkflow en deze "batterijen inbegrepen" filosofie past bij mij. Soms heb ik ongeveer 20 projecten openstaan, waarvoor een behoorlijke hardware met voldoende RAM nodig is. VSCode lijkt tegenwoordig een goed alternatief, maar in de loop van de afgelopen jaren ben ik gewend geraakt aan Jetbrains en iets nieuws leren vergt altijd wat mentale kracht dat ik momenteel niet bereid ben te investeren. Ik zou zeggen dat iedereen het beste kan gebruiken wat hij gewend is.

Support

Er zijn natuurlijk bepaalde tools nodig om de ondersteuning voor mensen die het product gebruiken te beheren:

• Freshdesk: Een typische e-mailticketsoftware. Het helpt me om de verschillende klantverzoeken bij te houden. In vroege tijden bood het een fatsoenlijke gratis versie, wat vooral in de oprichtingsfase cruciaal is.
• Discord: Sommige mensen geven misschien de voorkeur aan chat of hebben behoefte aan meer directe hulp. Daar komt Discord goed van pas.

Overige

Er zijn bepaalde andere tools die ik wilde noemen die nuttig kunnen zijn voor anderen. Vooral de banken voor mensen die hun bedrijf in Duitsland willen runnen:

• Odoo: Het beste ERP-systeem. De open source-editie is gratis en kan eenvoudig worden uitgebreid met Python en enige XML-kennis. De aanpassings- en integratiemogelijkheden met aangepaste API's zijn top-notch.
• Holvi: Onze hoofdbankrekening. In Duitsland heb je een bank nodig die je toestaat om een Stichtingsrekening op te zetten, in het Duits "Gründerkonto", dus een bankrekening die is gekoppeld aan een bedrijf dat nog niet volledig is geregistreerd en waar je het initiële geld kunt overboeken dat nodig is om het bedrijf te registreren. Een beetje een kip en ei probleem. En de grote banken die dat toestaan, kosten meestal een vermogen. Het registratieproces verliep ook vrij soepel. Het enige nadeel is het ontbreken van ondersteuning voor internationale betalingen, maar daar komt de volgende dienst van pas.
• Wise: Onze tweede bankrekening. Hun kosten zijn extreem laag (bijv. geen maandelijkse kosten), het opzetproces werkt vlekkeloos, ze zijn goed verbonden en staan internationale bankoverschrijvingen toe en overboekingen worden snel uitgevoerd, dus je hoeft geen weken te wachten of iets dergelijks.

Beveiliging

Ik denk dat dit een aparte blogpost kan zijn over hoe we gebruikersaccounts, infrastructuur, toegangsrechten hebben gestructureerd. Aangezien dit een van de cruciale aspecten is voor de beveiliging van Psono, ga ik hier niet in details en probeer ik vaag genoeg te zijn. We gebruiken zowel Google Cloud als Azure-services. Beide met volledig gescheiden gebruikers en groepen. Er zijn gebruikers die zijn toegewezen aan beheertaken en gebruikersaccounts voor het "dagelijkse werk". Er zijn verschillende fysieke en virtuele systemen die ik gebruik om Psono te ondersteunen/beheren/administreren. Beheertaken worden alleen uitgevoerd op een apart, speciaal gehard fysiek apparaat dat exclusief wordt gebruikt voor deze taken. Elk account is beveiligd met hardwaretokens. Alle systemen worden centraal beheerd en beveiligingsbeleid is van kracht om ervoor te zorgen dat alle apparaten voldoen aan de beveiligingsnormen die je doorgaans in banken vindt.

Credits

Dit artikel is sterk geïnspireerd door Anthony N. Simon's artikel over Panelbear.