Offerte aanvragen
Kennisbank

Is je cloudomgeving ingewikkelder geworden dan nodig?

Is je cloudomgeving ingewikkelder geworden dan nodig? Complexiteit ontstaat meestal stap voor stap.

Is je cloudomgeving ingewikkelder geworden dan nodig?

Veel cloudomgevingen beginnen overzichtelijk. Een virtuele server, een database, wat storage en misschien een CDN. Precies genoeg om een applicatie of platform goed te laten draaien.

Maar een omgeving blijft zelden hetzelfde. Er komen nieuwe applicaties bij, meer gebruikers, extra leveranciers, monitoringtools, back-ups, security-oplossingen en verschillende vormen van storage. Voor iedere nieuwe behoefte wordt iets toegevoegd.

Totdat de infrastructuur technisch nog prima functioneert, maar niemand meer precies weet waarom alles ooit zo is ingericht.

Meer mogelijkheden hebben is handig. Onnodige complexiteit niet.

Complexiteit ontstaat meestal stap voor stap

Vrijwel niemand besluit bewust om een ingewikkelde cloudomgeving te bouwen. Complexiteit ontstaat vaak geleidelijk.

Een extra dienst wordt toegevoegd omdat die op dat moment de snelste oplossing is. Een nieuwe leverancier heeft nét een functionaliteit die ontbreekt. Een tijdelijke server blijft uiteindelijk jarenlang draaien. Een oude omgeving kan nog niet worden uitgezet omdat één applicatie ervan afhankelijk blijkt te zijn.

Iedere afzonderlijke keuze kan logisch zijn. Het probleem ontstaat wanneer niemand meer naar het totaal kijkt.

Dan heb je misschien vijf oplossingen die allemaal hun eigen functie vervullen, maar ook vijf dashboards, contracten, facturen, supportkanalen en technische afhankelijkheden.

Meer techniek betekent ook meer beheer

De kosten van een cloudomgeving zitten niet alleen in compute, storage en dataverkeer.

Iedere extra component moet worden ingericht, gemonitord, bijgewerkt en beheerd. Certificaten verlopen, software krijgt updates, opslag groeit, back-ups moeten worden gecontroleerd en incidenten moeten worden onderzocht.

Dat kost tijd. En vaak is het juist de tijd van developers of technische medewerkers die eigenlijk aan het product of de dienstverlening zouden moeten werken.

Een oplossing die technisch goedkoop lijkt, kan daardoor operationeel alsnog duur worden.

Hoeveel leveranciers heb je eigenlijk nodig?

Een andere bron van complexiteit is het aantal leveranciers binnen één infrastructuur.

Compute bij partij A, object storage bij partij B, CDN bij partij C en monitoring of beheer weer ergens anders kan technisch prima werken. Maar zodra er een probleem ontstaat, wordt de keten belangrijk.

Is de applicatie traag door de server, het netwerk, de database of het CDN? Wie onderzoekt het probleem? En wie neemt verantwoordelijkheid wanneer meerdere onderdelen betrokken zijn?

Hoe meer partijen onderdeel zijn van dezelfde dienstverlening, hoe belangrijker duidelijke verantwoordelijkheden en goede monitoring worden.

Wat gebeurt er als één medewerker wegvalt?

Een infrastructuur kan technisch uitstekend zijn ingericht en toch een groot risico bevatten: kennis die bij één persoon zit.

Die ene developer of systeembeheerder weet waarom een bepaalde server bestaat, welke instelling absoluut niet gewijzigd mag worden en hoe een storing normaal gesproken wordt opgelost.

Zolang die persoon beschikbaar is, lijkt er weinig aan de hand.

Maar wat gebeurt er tijdens vakantie, ziekte of wanneer iemand de organisatie verlaat?

Goed beheer betekent daarom niet alleen dat techniek werkt. Configuraties, verantwoordelijkheden, monitoring en herstelprocedures moeten ook overdraagbaar zijn.

Niet alles hoeft opnieuw

Een complexe omgeving hoeft niet automatisch volledig opnieuw te worden gebouwd.

Vaak zit de grootste winst juist in het kritisch bekijken van wat er al staat. Welke onderdelen worden daadwerkelijk gebruikt? Welke tijdelijke oplossingen zijn permanent geworden? Welke diensten overlappen elkaar? En welke infrastructuur kan eenvoudiger worden ingericht?

Soms betekent dat consolideren. Soms juist een onderdeel loskoppelen zodat het beter kan schalen. En soms blijkt dat de huidige architectuur prima is, maar dat monitoring, documentatie of beheer beter moet worden georganiseerd.

Het doel is niet zo min mogelijk techniek. Het doel is een omgeving waarvan duidelijk is waarom ieder onderdeel er staat.

Wanneer is het tijd om je omgeving opnieuw te bekijken?

Er zijn een aantal signalen die erop kunnen wijzen dat de infrastructuur onnodig complex is geworden:

  • Niemand heeft meer volledig overzicht over de omgeving.
  • Er zijn meerdere leveranciers nodig om één storing te onderzoeken.
  • Developers besteden steeds meer tijd aan infrastructuurbeheer.
  • Kosten stijgen, maar het is niet duidelijk waardoor.
  • Oude servers of diensten blijven draaien omdat niemand zeker weet of ze uitgezet kunnen worden.
  • Kritische kennis zit bij één of enkele medewerkers.
  • Een wijziging aan één onderdeel heeft onverwachte gevolgen elders in het platform.

Herken je meerdere van deze punten, dan hoeft dat niet te betekenen dat de architectuur verkeerd is. Het is wel een goed moment om opnieuw naar het geheel te kijken.

Begin niet bij producten, maar bij de omgeving

Vereenvoudigen begint niet met de vraag welke server, storage-oplossing of clouddienst je moet kopen.

Begin met de huidige situatie. Welke workloads draaien er? Welke data wordt opgeslagen? Waar zitten afhankelijkheden? Welke onderdelen zijn bedrijfskritisch? Hoe wordt gemonitord en hoe wordt er hersteld wanneer iets uitvalt?

Daarna kun je bepalen welke onderdelen logisch zijn om te behouden, samen te voegen, te vervangen of anders te beheren.

Dat voorkomt dat een nieuwe oplossing simpelweg boven op de bestaande complexiteit wordt gebouwd.

Waar Scalia waarde toevoegt

Scalia kijkt naar infrastructuur als één geheel. Compute, object storage, CDN, databases, netwerk, monitoring en managed beheer hoeven geen verzameling losse producten te zijn.

We kijken samen naar wat een platform daadwerkelijk nodig heeft en welke onderdelen logisch bij elkaar kunnen worden gebracht. Daarbij hoeft een bestaande omgeving niet direct volledig te worden verhuisd.

Je kunt beginnen bij het onderdeel waar de meeste beheerlast, kosten of afhankelijkheid zit en vanuit daar verder bouwen.

Omdat onze engineers zelf betrokken zijn bij de infrastructuur en het beheer, blijven de lijnen kort wanneer er iets verandert of onderzocht moet worden.

Conclusie

Een volwassen cloudomgeving hoeft niet de omgeving met de meeste diensten, tools of leveranciers te zijn.

De beste infrastructuur is uiteindelijk de infrastructuur die past bij wat je organisatie nodig heeft, waarvan duidelijk is hoe deze is opgebouwd en die beheersbaar blijft wanneer je groeit.

Complexiteit is soms noodzakelijk. Maar wanneer niemand meer precies kan uitleggen waarom die complexiteit bestaat, is het tijd om opnieuw naar het ontwerp te kijken.

Is jouw cloudomgeving door de jaren heen steeds complexer geworden?

Scalia kijkt graag met je mee naar de huidige infrastructuur en waar deze eenvoudiger, overzichtelijker of beter beheersbaar kan worden ingericht.

Bekijk Managed Services

Bespreek je infrastructuur met Scalia