Een cloudplatform dat meegroeit met de onderneming.

We beginnen met de begrippen die het werk bepalen. Wat is een opdracht? Wanneer is die geaccepteerd? Wie mag haar aanpassen? Wanneer is het werk klaar, en wanneer is de financiële afhandeling klaar?

Dat zijn geen details voor later. Ze bepalen het gegevensmodel, de API’s en de controles. We maken toestanden en toegestane overgangen expliciet. Zo hoeft iedere toepassing niet opnieuw te bedenken wat een status betekent.

Een centrale bedrijfslogica betekent niet dat alles één groot programma moet worden. We verdelen verantwoordelijkheden in herkenbare onderdelen en kiezen pas een aparte service wanneer schaal, beveiliging of onafhankelijk beheer dat rechtvaardigt.

Onze voorkeur is een documentgerichte NoSQL-database. Daarin slaan we gegevens die bij elkaar horen, zoals de kenmerken en status van een opdracht, samen op in een gegevensrecord. Hiervoor gebruiken we Firestore, een beheerde databasedienst van Google Cloud.

Een relationele database ordent gegevens in tabellen die aan elkaar gekoppeld zijn. Als die structuur beter past bij de onderlinge verbanden, berekeningen en rapportages, kiezen we daarvoor. Cloud SQL biedt ons die mogelijkheid binnen Google Cloud.

Bij beide vormen bepalen we welke wijzigingen samen moeten slagen, hoe mensen informatie opvragen en wat groei betekent voor snelheid en kosten. De opslag moet passen bij het werk dat het platform ondersteunt.

In de praktijk: partnerafspraken en commissies

Voor een aanvraag- en partnerplatform verzorgden we analyse, ontwerp en de bouw van het portaal en de API. Partners en subpartners hebben eigen afspraken over commissiestaffels, grondslagen en kosten. Aanvraagstatussen komen vanuit een extern systeem binnen en krijgen een eigen betekenis in het portaal.

We realiseerden een Vue-portaal, een Express-/TypeScript-API en een relationeel model met Sequelize en MySQL, met configuratie voor App Engine en Cloud SQL. Samenhangende administratieve wijzigingen bij een commissiebatch worden in één SQL-transactie verwerkt. Dat houdt de registratie bij elkaar; de bankbetaling zelf is een afzonderlijke handeling.

Voor iedere omgeving leggen we vast welke gegevens, services en toegangen erbij horen. Testen en ontwikkelen vragen eigen omgevingen, geen onzichtbare afhankelijkheid van productie.

Voor een platform voor merken en retailteams bouwden we import- en conversietaken voor kassadata. De verwerking werd via Pub/Sub verdeeld over achtergrondtaken. Binnen het platform werden gegevens gekoppeld aan winkels, merken, producten en medewerkers. Merkomgeving, teambeheer en interne operatie konden daardoor op dezelfde betekenis van de gegevens voortbouwen.

De financiële afhandeling kende daarnaast uitbetalingsbatches, ontvangers en verwerkingsstatussen. Niet één lang verzoek dat alles tegelijk probeert te doen, maar herkenbare stappen met een eigen verantwoordelijkheid.

Bij JobLog zien we een andere toepassing van die aanpak: terugkerend werk wordt in batches verwerkt, met registratie van voortgang, voltooiing en fouten. De bedrijfsafspraak bepaalt welke taken ontstaan; de verwerking maakt zichtbaar wat daarmee is gebeurd.

Autoscaling helpt capaciteit aanpassen aan de vraag. De instellingen voor gelijktijdige verzoeken en minimum- en maximuminstanties beïnvloeden prestaties én kosten. Google adviseert die instellingen in een testomgeving te beproeven. Zie het beheer van Cloud Functions.

Wij verbinden dat aan concrete gebruikssituaties. Bijvoorbeeld veel medewerkers die rond hetzelfde tijdstip hun rooster openen, of een reeks opdrachten die tegelijk wordt verwerkt. We onderzoeken ook de grens buiten het platform: de database, een betaalprovider of een administratiekoppeling kan eerder vollopen dan de applicatieserver.

Daar horen wachtrijen, begrensde retries en bewaking bij. Extra servers zijn niet voor ieder knelpunt het antwoord.

Bij integraties hoort onzekerheid. Een verzoek kan een timeout geven terwijl de andere partij het al heeft verwerkt. Een webhook kan opnieuw worden aangeboden. Twee gebruikers kunnen vrijwel tegelijk dezelfde opdracht aanpassen.

We ontwerpen kritieke handelingen met herkenbare transacties, versiecontroles en herhaalbaarheid zonder dubbel effect. Dat laatste heet idempotentie. Een onbekende uitkomst blijft onbekend tot ze is opgehelderd; we behandelen haar niet gemakshalve als mislukt en proberen blind opnieuw.

Een wijziging in de eigen database en een handeling bij een externe leverancier zijn niet automatisch één transactie. Daarom maken we tussenstappen, herstel en handmatige opvolging onderdeel van het ontwerp.

Bestaande software bevat vaak waardevolle kennis. We hoeven die niet in één keer te vervangen. We kunnen verantwoordelijkheden afbakenen, een integratielaag verbeteren en onderdelen geleidelijk vernieuwen. Onze opdracht bij een Amerikaanse bouwmaterialenleverancier laat de rol zien die we bij bestaande bedrijfssoftware innemen.

Bij een architectuuropdracht leveren we een systeemoverzicht, belangrijke ontwerpbesluiten, gegevens- en integratiegrenzen en een uitvoerbaar plan. Bij realisatie bouwen en toetsen we die basis. Capaciteit, hersteldoelen en beheer spreken we af voor het werk dat het platform moet dragen. De kwaliteits- en beheerafspraken maken duidelijk hoe jullie en onze ontwikkelaars ermee verder werken.