Bedrijfsgeheim
Jouw code:
Klant zou jouw code tegen de afspraak overnemen en maakt er dit van:
Flauw voorbeeldje, maar ga nu maar eens aan een rechter zonder verstand van zaken uitleggen dat dit gewoon jouw code is maar met andere variabelenamen ...
Ondanks dat je dus een afspraak hebt, is het maar de vraag wat die waard is op het moment dat die klant een paar heel kleine dingen wijzigt.
Een API in de cloud is daarvoor dé oplossing, alleen moet je de bouwstenen wel ontleden. Misschien is dat een werkbaar compromis: de klant heeft alle data en jij houdt het 'algoritme' verborgen.
Gewijzigd op 04/03/2021 08:28:04 door Ward van der Put
FOREIGN TABLES, en dblink waardoor ik twee voordelen behoud: data-manipulatie zoveel mogelijk bij de bron houden, en de oplossingsrichting blijft bij het programma, het domein waar ik het meest in thuis ben.
Met een TLS-verbinding naar de on premise database, in een VPN huls is dat alles veilig genoeg.
Mijn idee zou dan zijn om een klantomgeving op te zetten als een soort van satellietprogramma, met code dat geen of weinig bedrijfsgeheimen bevat. De database kan opgesplitst, PostgreSQL heeft daarvoor opties als Met een TLS-verbinding naar de on premise database, in een VPN huls is dat alles veilig genoeg.
Foreign tables over internet klinkt mij niet als een fantastisch idee, dat kan met latencies e.d. nog wel eens rare dingen opleveren. Moet er wel bij zeggen dat ik er geen ervaring mee heb.
Foreign tables voorzien in een behoefte van externe storage. Latencies zijn inderdaad een probleem, vooral als queries niet goed worden geoptimaliseerd. En dat gebeurt nog wel eens. Ik heb er al mee geëxperimenteerd en ben er wel een beetje uit.
De applicatie gebruikt toch niet altijd alle data tegelijk uit een foreign table, maar het maakt heel erg uit hoe je queries schrijft. Als het niet lekker loopt merk je het vanzelf, een query met een onhandige JOIN die niet wordt geoptimaliseerd gaat van een paar msec ineens naar seconden tot (veel) erger.
Het helpt dan om eerst alleen de nodige foreign data op te halen in een WITH-statement, voordat de rest van de query wordt uitgevoerd.
Daar waar het niet lekker blijft lopen is dblink een optie, je kunt daarmee eerst queries door de foreign server laten uitvoeren en in de eigen database verder werken met het resultaat.
Ik geloof dat daarmee het plaatje behoorlijk compleet begint te worden. Twee eigen bare metal servers (eentje als fail-over) extern hosten, daarop PHP / PostgreSQL als SaaS, en een On Premise klantomgeving met PHP / PostgreSQL met foreign tables.
Verwerking op de eigen servers, die de data niet hoeven op te slaan.
Databeveiliging op de klantomgeving met SSE, codebeveiliging via IonCube. Klantomgeving koppelen via VPN.
Zo kan ik mijn systeem verder integreren met andere klantsystemen zonder dat het bedrijfsgeheim veel risico loopt. En als de klant niet heeft betaald en de grace periode is verlopen dan heb ik altijd een stok achter de deur.
Als de klant huiverig is voor gebrek aan continuïteit is er ook nog zoiets als een i-DEPOT waarmee e.a.a. geborgd kan worden. Dan wordt het af te nemen product SaaS & On Premise, en komt er niet te veel spanning tussen verantwoordelijkheid en afhankelijkheid.
Lang verhaal, maar als iemand nog wat wil toevoegen: graag!
Er worden dagelijks nieuwe vulnerabilities bekend die je allemaal zelf zal moeten patchen.
Voor een kernel-update moet een machine bijvoorbeeld herstarten dus moet je ook rekening met redundancy, high-availibility, etc. om nog niet te spreken van disaster-recovery.
Zeker in zakelijke context is het niet zo simpel als een Apache/PostgreSQL servertje opspinnen en je er nooit meer druk om maken.
Ik kan hele boeken volschrijven over waar je allemaal aan moet denken, om je een idee te geven van de schaal en mijn ervaring:
Ik ben 8 jaar terug begonnen voor een MKB-bedrijf een enterprise webplatform te schrijven in PHP, wat uitgerold werd op eigen hardware. Dat was verdeeld over 5 fysieke machines en ongeveer 15 VMs en kostte ongeveer 30% van mijn tijd om te beheren.
Na 5 jaar ben ik overgestapt naar een ander bedrijf en doe daar de infra-kant waar wij als team ~3000 VMs en een Kubernetes platform beheren (private cloud dus) en daar hebben we met 8 man een dagtaak aan, ondanks alle automatisering.
Ik wil hier prima over doorpraten en/of e.e.a. toelichten/uitdenken maar ik denk dat dat nogal buiten de scope van dit forum en draadje gaat :)
Denk er goed over na of je dit soort taken er bij wil of dat je een managed VPS afneemt zodat je het uitbesteed.
Gewijzigd op 05/03/2021 09:29:07 door Thom nvt
Ik wil inderdaad liever geen infra beheren, dus ik zal uitkijken naar dedicated servers.
Kubernetes klinkt eng. Ondanks de video https://www.youtube.com/watch?v=4ht22ReBjno is het voor mij niet te volgen, kortweg te complex... dan zou je dat ook moeten uitbesteden, en die risico's contractueel afdekken?
Kubernetes is een mooie technologie maar heeft een vrij steile leercurve, niet iets wat je in productie omgevingen wil gaan leren.
In de basis is het een verzameling APIs waarmee je middels yaml files Docker containers op start maar het kan veel meer. Het is in feite een datacenter in een (extreem configureerbaar) doosje.
Ik zou in jouw geval kijken naar een managed VPS oplossing, dan neem je in feite alleen rekenkracht af en besteed je al het beheer en onderhoud uit. Hosted.nl levert die dienst bijvoorbeeld: https://www.hosted.nl/managed-vps/
Edit: Dat is natuurlijk duurder dan een "kale" VPS huren bij bijvoorbeeld TransIP maar je koopt in feite al het beheer en de verantwoordelijkheid daarvoor af.
Updates, server downtime, etc. is dan niet jouw probleem meer, daar betaal je de provider voor.
Gewijzigd op 05/03/2021 12:02:34 door Thom nvt
Wederom bedankt Thom, ik kijk er naar.