Kalibaarheid is een essentieel onderdeel van bedrijfssoftware. Het vanaf het begin prioriteit geven aan schaalbaarheid leidt tot lagere onderhoudskosten, een betere gebruikerservaring en een grotere wendbaarheid.

Softwareontwerp is een evenwichtsoefening waarbij ontwikkelaars werken aan het beste product binnen de beperkingen van tijd en budget van de klant.

Er is geen ontkomen aan de noodzaak van compromissen. Er moeten compromissen worden gesloten om aan de eisen van een project te voldoen, of die nu technisch of financieel zijn.

Maar al te vaak geven bedrijven echter voorrang aan kosten boven schaalbaarheid of wijzen ze het belang ervan zelfs volledig af. Dit is helaas gebruikelijk bij big data-initiatieven, waar schaalbaarheidsproblemen een veelbelovend project kunnen doen mislukken.

Kalibaarheid is geen “bonuskenmerk”. Het is de kwaliteit die de levenslange waarde van software bepaalt, en bouwen met schaalbaarheid in het achterhoofd bespaart zowel tijd als geld op de lange termijn.

Wat is schaalbaarheid?

Een systeem wordt als schaalbaar beschouwd wanneer het niet opnieuw hoeft te worden ontworpen om effectieve prestaties te behouden tijdens of na een sterke toename van de werklast.

“Werklast” kan betrekking hebben op gelijktijdige gebruikers, opslagcapaciteit, het maximum aantal verwerkte transacties, of iets anders dat het systeem over zijn oorspronkelijke capaciteit duwt.

Kalibaarheid is geen basisvereiste van een programma, in die zin dat niet-schaalbare software goed kan draaien met een beperkte capaciteit.

Het geeft echter wel het vermogen van de software weer om te groeien of te veranderen naar gelang de eisen van de gebruiker.

Elke software die verder kan groeien dan de basisfuncties – vooral als het bedrijfsmodel afhankelijk is van de groei – moet worden geconfigureerd voor schaalbaarheid.

De voordelen van schaalbare software

Kalibaarheid heeft zowel lange- als kortetermijnvoordelen.

In het begin kan een bedrijf alleen aanschaffen wat het direct nodig heeft, niet elke functie die later van pas kan komen.

Een bedrijf dat een proefprogramma voor data-intelligentie start, kan bijvoorbeeld kiezen voor een enorme enterprise analytics-bundel, of ze kunnen beginnen met een oplossing die alleen de functies afhandelt die ze in het begin nodig hebben.

Een populaire keuze is een dashboard dat de resultaten van hun primaire gegevensbronnen en bestaande bedrijfssoftware binnenhaalt.

Wanneer ze groot genoeg worden om meer analyseprogramma’s te gebruiken, kunnen die gegevensstromen aan het dashboard worden toegevoegd in plaats van het bedrijf te dwingen met meerdere visualisatieprogramma’s te jongleren of een geheel nieuw systeem te bouwen.

Op deze manier bouwen bereidt voor op toekomstige groei en creëert tegelijkertijd een slanker product dat aan de huidige behoeften voldoet zonder extra complexiteit.

Het vereist ook een lagere initiële financiële uitgave, wat een belangrijke overweging is voor leidinggevenden die zich zorgen maken over de omvang van investeringen in big data.

Kalibaarheid laat ook ruimte voor veranderende prioriteiten. De kant-en-klare analysebundel kan aan relevantie inboeten als een bedrijf zich aanpast aan de eisen van een evoluerende markt.

Door te kiezen voor schaalbare oplossingen wordt de initiële technologie-investering beschermd. Bedrijven kunnen dezelfde software langer blijven gebruiken omdat deze is ontworpen om mee te groeien.

Wanneer het tijd is om te veranderen, is voortbouwen op solide, schaalbare software aanzienlijk minder duur dan proberen minder flexibele programma’s aan te passen.

Er is ook een kortere “ramp up” tijd om nieuwe functies online te brengen dan om geheel nieuwe software te implementeren.

Als bijkomend voordeel heeft het personeel niet veel training of overtuigingskracht nodig om dat geüpgrade systeem te adopteren. Ze zijn al bekend met de interface, dus het werken met de extra functies wordt gezien als een bonus in plaats van een karwei.

De gevolgen van schaalfouten

Wat gebeurt er dan als software niet schaalbaar is?

In het begin is de zwakte moeilijk te ontdekken. De werklast is licht in het beginstadium van een app. Met relatief weinig gelijktijdige gebruikers wordt er niet veel van de architectuur gevergd.

Wanneer de werklast toeneemt, ontstaan er problemen. Hoe meer gegevens worden opgeslagen of hoe meer gelijktijdige gebruikers de software verzamelt, hoe meer de architectuur van de software onder druk komt te staan.

Beperkingen die in het begin niet belangrijk leken, worden een belemmering voor de productiviteit. Patches kunnen sommige van de vroege problemen verlichten, maar patches voegen complexiteit toe.

Complexiteit maakt het diagnosticeren van problemen op een continue basis meer vervelend (vertaling: duurder en minder effectief).

Als de werklast stijgt voorbij het vermogen van de software om te schalen, daalt de prestaties.

Gebruikers ervaren trage laadtijden omdat de server er te lang over doet om te reageren op verzoeken. Andere potentiële problemen zijn verminderde beschikbaarheid of zelfs verloren gegevens.

Dit alles ontmoedigt toekomstig gebruik. Werknemers zullen workarounds vinden voor onbetrouwbare software om hun eigen werk gedaan te krijgen.

Dat brengt het bedrijf in gevaar voor een datalek of erger.

Wanneer de software klantgericht is, verhoogt onbetrouwbaarheid de kans op churn.

Google ontdekte dat 61% van de gebruikers een app geen tweede kans zal geven als ze een slechte eerste ervaring hadden. 40% gaat in plaats daarvan rechtstreeks naar het product van een concurrent.

Schaalbaarheidsproblemen zijn niet alleen een beginnersfout die door kleine bedrijven wordt gemaakt, ook. Zelfs Disney kwam in de problemen met de oorspronkelijke lancering van hun Applause-app, die was bedoeld om kijkers een extra manier te geven om te communiceren met favoriete Disney-shows. De app kon de vloed van gelijktijdige streaming video-gebruikers niet aan.

Gefrustreerde fans lieten negatieve recensies achter totdat de app nog maar één ster had in de Google Play-winkel. Disney-functionarissen moesten de app uit de lucht halen om de schade te herstellen, en de negatieve publiciteit was zo intens dat de app nooit meer online is gegaan.

Prioriteiten stellen

Sommige bedrijven geven geen prioriteit aan schaalbaarheid omdat ze er het onmiddellijke nut niet van inzien.

Schaalbaarheid wordt terzijde geschoven ten gunste van snelheid, kortere ontwikkelingscycli, of lagere kosten.

Er zijn eigenlijk enkele gevallen waarin schaalbaarheid geen hoofdprioriteit is.

Software die bedoeld is als prototype of laag-volume proof of concept zal niet groot genoeg worden om problemen te veroorzaken.

Ook interne software voor kleine bedrijven met een lage vaste limiet van potentiële gebruikers kan andere prioriteiten stellen.

Ten slotte, wanneer ACID-conformiteit absoluut verplicht is, neemt schaalbaarheid een ondergeschikte plaats in ten opzichte van betrouwbaarheid.

Als algemene regel geldt echter, dat schaalbaarheid eenvoudiger is en minder middelen vergt, wanneer er vanaf het begin naar wordt gekeken.

Voor één ding heeft de databasekeuze een enorme invloed op schaalbaarheid. Migreren naar een nieuwe database is duur en tijdrovend. Het is niet iets dat later gemakkelijk kan worden gedaan.

Beginselen van schaalbaarheid

Er zijn verschillende factoren die de algehele schaalbaarheid van software beïnvloeden:

Gebruik

Gebruik meet het aantal gelijktijdige gebruikers of verbindingen dat mogelijk is. Er zouden geen kunstmatige grenzen aan het gebruik moeten zijn.

Het verhogen ervan zou zo eenvoudig moeten zijn als het beschikbaar stellen van meer middelen aan de software.

Maximaal opgeslagen gegevens

Dit is vooral relevant voor sites met veel ongestructureerde gegevens: door gebruikers geüploade inhoud, site-rapporten, en sommige soorten marketinggegevens.

Data science-projecten vallen ook onder deze categorie. De hoeveelheid gegevens die door dit soort inhoud wordt opgeslagen, kan dramatisch en onverwacht toenemen.

Of het maximum aan opgeslagen gegevens snel kan worden geschaald, hangt sterk af van de stijl van de database (SQL vs NoSQL-servers), maar het is ook van cruciaal belang om aandacht te besteden aan een goede indexering.

Code

Onervaren ontwikkelaars hebben de neiging om code-overwegingen over het hoofd te zien bij het plannen van schaalbaarheid.

Code moet zo worden geschreven dat deze kan worden aangevuld of gewijzigd zonder de oude code te refactoren. Goede ontwikkelaars streven ernaar dubbel werk te voorkomen, waardoor de totale omvang en complexiteit van de codebase afneemt.

Applicaties worden wel groter naarmate ze zich ontwikkelen, maar door de code schoon te houden, wordt dit effect geminimaliseerd en wordt de vorming van “spaghetticode” voorkomen.

Scaling Out Vs Scaling Up

Scaling up (of “verticale schaalvergroting”) houdt in dat je groeit door meer geavanceerde of sterkere hardware te gebruiken. Schijfruimte of een snellere centrale verwerkingseenheid (CPU) wordt gebruikt om de toegenomen werklast aan te kunnen.

Opschalen biedt betere prestaties dan uitschalen. Alles zit op één plek, waardoor het sneller rendement oplevert en er minder kwetsbaarheid is.

Het probleem met opschalen is dat er maar zo weinig ruimte is om te groeien. Hardware wordt duurder naarmate het geavanceerder wordt. Op een gegeven moment lopen bedrijven aan tegen de wet van de afnemende meeropbrengst bij de aanschaf van geavanceerde systemen.

Het kost ook tijd om de nieuwe hardware te implementeren.

Omwille van deze beperkingen is verticale schaalvergroting niet de beste oplossing voor software die snel en met weinig kennisgeving moet groeien.

Uitschalen (of “horizontale schaalvergroting”) wordt veel meer gebruikt voor bedrijfsdoeleinden.

Bij outscaling groeit de software door meer – niet geavanceerdere – hardware te gebruiken en de toegenomen werklast over de nieuwe infrastructuur te verdelen.

De kosten zijn lager omdat de extra servers of CPU’s van hetzelfde type kunnen zijn dat momenteel wordt gebruikt (of een compatibel type).

Scaling gebeurt ook sneller, omdat niets hoeft te worden geïmporteerd of herbouwd.

Er is echter een kleine afruil in snelheid. Horizontaal geschaalde software wordt beperkt door de snelheid waarmee de servers kunnen communiceren.

Het verschil is echter niet groot genoeg om door de meeste gebruikers te worden opgemerkt, en er zijn hulpmiddelen om ontwikkelaars te helpen het effect te minimaliseren. Als gevolg hiervan wordt schaalvergroting beschouwd als een betere oplossing bij het bouwen van schaalbare toepassingen.

Guidelines for Building Highly Scalable Systems

Het is zowel goedkoper als gemakkelijker om rekening te houden met schaalbaarheid tijdens de planningsfase. Hier volgen enkele best practices om schaalbaarheid vanaf het begin mee te nemen:

Gebruik load balancing software

Load balancing software is van cruciaal belang voor systemen met een gedistribueerde infrastructuur (zoals horizontaal geschaalde applicaties).

Deze software maakt gebruik van een algoritme om de werklast over servers te verdelen om ervoor te zorgen dat geen enkele server wordt overweldigd. Het is een absolute noodzaak om prestatieproblemen te voorkomen.

Location matters

Kalibreerbare software doet zoveel mogelijk dicht bij de client (in de app-laag). Vermindering van het aantal keren dat apps door het zwaardere verkeer in de buurt van core-bronnen moeten navigeren, leidt tot hogere snelheden en minder stress op de servers.

Edge computing is iets anders om te overwegen. Met meer toepassingen die resource-intensieve toepassingen vereisen, verlaagt het houden van zo veel mogelijk werk op het apparaat de impact van gebieden met een laag signaal en netwerkvertragingen.

Cache waar mogelijk

Wees je bewust van veiligheidsoverwegingen, maar caching is een goede manier om te voorkomen dat je dezelfde taak steeds opnieuw moet uitvoeren.

Leidt met API

Gebruikers maken verbinding via een verscheidenheid aan clients, dus leiden met API die niet uitgaan van een specifiek clienttype kan al deze clients bedienen.

Asynchrone verwerking

Het verwijst naar processen die zijn gescheiden in afzonderlijke stappen die niet hoeven te wachten tot de vorige is voltooid voordat ze worden verwerkt.

Bijv. een gebruiker kan een “verzonden!” worden getoond terwijl de e-mail technisch nog wordt verwerkt.

Asynchrone verwerking verwijdert enkele knelpunten die de prestaties van grootschalige software beïnvloeden.

Limiteer gelijktijdige toegang tot beperkte middelen

Dupliceer geen inspanningen. Als meer dan één verzoek om dezelfde berekening van dezelfde bron vraagt, laat dan de eerste afmaken en gebruik alleen dat resultaat. Dit verhoogt de snelheid en vermindert de belasting van het systeem.

Gebruik een schaalbare database

NoSQL-databases zijn meestal schaalbaarder dan SQL. SQL schaalt leesbewerkingen goed genoeg, maar als het op schrijfbewerkingen aankomt, botst het met beperkingen die bedoeld zijn om ACID-principes te handhaven.

Het schalen van NoSQL vereist minder strikte naleving van die principes, dus als ACID-conformiteit geen zorg is, kan een NoSQL-database de juiste keuze zijn.

Overweeg PaaS-oplossingen

Platform-as-a-service verlicht veel schaalbaarheidsproblemen omdat de PaaS-provider het schalen beheert. Schalen kan zo eenvoudig zijn als het upgraden van het abonnementsniveau.

Kijk naar FaaS

Function-as-a-service is geëvolueerd uit PaaS en is zeer nauw verwant. Serverless computing biedt een manier om alleen de functies te gebruiken die op een gegeven moment nodig zijn, waardoor er minder onnodige eisen worden gesteld aan de back-end infrastructuur.

FaaS is nog in ontwikkeling, maar het kan de moeite waard zijn om te bekijken als een manier om de operationele kosten te verlagen en tegelijkertijd de schaalbaarheid te verbeteren.

Vergeet het onderhoud niet

Stel software in voor geautomatiseerd testen en onderhoud, zodat wanneer het groeit, het werk van het onderhoud niet uit de hand loopt.

Bouw met het oog op de toekomst

Prioriteit geven aan schaalbaarheid bereidt uw bedrijf voor op succes. Denk er vroeg over na, en u zult de vruchten plukken in flexibiliteit wanneer dat het meest nodig is.

Bent u op zoek naar software die met uw bedrijf kan meegroeien? Maak een gratis afspraak met een van onze ontwikkelaars om te bespreken waar u naar toe wilt en hoe wij u daar kunnen brengen!