Veel softwaretrajecten beginnen met een infrastructuurvraag: "waar gaat dit draaien?" Alsof dat een fundering is die er eerst moet liggen, en alsof het antwoord de bouw hoort te sturen. De misvatting is dat de hostingkeuze een vroege, dure beslissing is. Bij software die declaratief wordt opgeleverd is het een late en goedkope: de applicatie beschrijft zelf hoe hij moet draaien, en wáár dat gebeurt, is een invulling van die beschrijving.
De beschrijving is het product
Declaratief opleveren betekent dat de omgeving van de applicatie — afhankelijkheden, configuratie, opbouw — als beschrijving in het project zit. Uitrollen is die beschrijving uitvoeren, door een mens of door een machine. Dit is dezelfde eigenschap die de eerste werkdag op een project kort houdt, van de andere kant bekeken: wat een nieuwe ontwikkelaar in één commando lokaal opbouwt, bouwt een server net zo op. Containers en orkestratie liggen dan voor de hand en zijn bij ons nooit ver weg, maar ze zijn een uitvoeringsvorm van de beschrijving, niet de reden ervan.
Drie uitkomsten, één project
Met die beschrijving op orde zijn dit geen drie projecten maar drie uitvoeringen:
- SaaS bij ons — wij draaien de applicatie op onze eigen infrastructuur, met error tracking, monitoring en updates erbij.
- On-premises bij jou — je zegt "wij hebben dit en dit", en de applicatie landt in jouw omgeving. Geen speciale poort-over-de-schutting-versie; dezelfde artefacten, dezelfde beschrijving.
- Een kale machine — een webserver, een runtime en de beschreven stappen. Niet elke applicatie verdient een orkestratieplatform, en een klein intern systeem is op een enkele machine prima af.
De bare-metal-route is daarbij geen terugvaloptie voor als het moet, maar een gelijkwaardige uitkomst. Het punt is nooit de tool; het punt is dat de route beschreven en herhaalbaar is.
Waarom dit goedkoper is
De inspanning zit één keer in het project, in plaats van elke keer in de uitrol. Een nieuwe omgeving optuigen is geen dagenwerk van overzetten en uitproberen, maar het uitvoeren van iets dat al bestaat en al dagelijks bewezen wordt. Dat is efficiënt voor ons en dus goedkoper voor jou — en het werkt door in alles eromheen: een teststraat of acceptatieomgeving is dezelfde beschrijving nog een keer, en wie ooit wil verhuizen, verhuist een beschrijving in plaats van een verzameling handwerk.
Er zit ook een eerlijkheidsargument in. Een applicatie die alleen draait waar de bouwer hem heeft neergezet, bindt je aan die bouwer. Een applicatie die zijn eigen omgeving beschrijft, kun je meenemen. Wij bouwen het tweede, in de wetenschap dat een leverancier die makkelijk te verlaten is er een is waar je kunt blijven.
Uit eigen keuken
Dit is ook hoe onze eigen software leeft, deze website incluis: elke wijziging is een commit, en de uitrol volgt de beschrijving in het project — automatisch, zonder dat iemand "even de server in moet". Hoe die pijplijn werkt en waarom een release daardoor geen gebeurtenis meer is, is een eigen verhaal.
De vraag op het juiste moment
Bij ons komt "waar gaat dit draaien?" aan het eind van het gesprek, als duidelijk is wat er draait en voor wie. Wil je software laten bouwen zonder je op dag één aan een omgeving vast te leggen, of heb je een applicatie die nu alleen draait waar hij toevallig staat: neem contact op of vraag een voorstel aan.