CPQ-cloud

"Stateless, stateful, multi-tenant, single-tenant, virtualisatie, microservices, orchestrators, virtualisatie..."

Deze, en vele andere soortgelijke termen, maken deel uit van mijn vocabulaire als KBMax-architect. Het zou je verbazen dat ze tegenwoordig deel uitmaken van ieders leven, ook als het niet duidelijk is. In de wereld van vandaag gebruikt iedereen een cloudsysteem in een of andere vorm, maar is zich misschien niet bewust van de implicaties van de service die dagelijks wordt gebruikt, zoals kosten, beveiliging, beschikbaarheid en privacy.

"Wat is cloudarchitectuur en waarom zou het me iets kunnen schelen?"

If you are selecting CPQ software (or any software) for your company, you may be interested in preventing wasted resources on future hidden costs, by simply investing in (or buying) future-proof software. I’ve seen many companies who were convinced they were getting a cloud application, but later realized that they had purchased ‘virtualized software’ and paid a very high price to end up getting stuck with the same version of the software forever, racking up hidden costs.

Omdat ik al 40 jaar programmeer, wilde ik je de geschiedenis van cloudarchitectuur vertellen vanuit mijn oogpunt. Je kunt elk van de bovenstaande termen googlen, maar ik denk dat je het 'waarom' achter sommige van de architecturale keuzes beter kunt begrijpen nadat je de geschiedenis erachter hebt geleerd. Net als op elk ander gebied zijn 'ontdekt' het antwoord op actuele problemen en behoeften.

Een korte geschiedenis van gedistribueerde computers

Mainframes

Ik zal het mainframe overslaan omdat het te diep in de oude geschiedenis van informatica zit.

Servers en verbonden desktops

Laten we in plaats daarvan beginnen met het begin van deze eeuw, waar desktopcomputers gebruikelijk waren en servers in de buurt waren, maar slechts voor een paar taken zoals het delen van bestanden, afdrukken, gebruikersauthenticatie en databases. De data was fysiek 'eigendom' en de software en hardware werden samen verkocht. Gedurende deze tijd was de software voor gebruikers voornamelijk een lokale applicatie met instances die op een desktopcomputer waren geïnstalleerd. Beveiliging was geen echt probleem, ook al was iedereen een 'beheerder' en sommige gebruikers hadden zelfs een 'post-it' met hun wachtwoord op de monitor. Het belangrijkste probleem was het versiebeheer van de software, het onderhoud van de hardware, de back-up en de onderbenutting van de servers. 

Ik herinner me dat de 'server' het duurste onderdeel van 'de deal' was, en het meest onderbenut: het was niet zeldzaam om in te loggen op een server en te zien dat de meest veeleisende CPU-toepassing de draaiende 3D-tekst van het Windows-scherm was spaarder (ik heb nooit begrepen waarom het de meest voorkomende was). Het updaten van een applicatie was erg lastig en er waren verschillende technici nodig om de verschillende problemen op te lossen die zich voordeden. Onderhoud gebeurde dus natuurlijk alleen als het nodig of onvermijdelijk was. 

Webgebaseerd computergebruik

Toen begon het web op een zinvolle manier het bedrijf binnen te komen, omdat het hebben van een website al snel verplicht werd. Die onderbenutte server begon te worden gebruikt door de meest vooruitstrevende en dappere bedrijven. Organisaties niet weten dat ze 'dapper' waren, maar dat waren ze echt, gezien de enorme beveiligingsproblemen die ze begonnen te krijgen. IT-afdelingen begonnen te groeien: servers, dedicated internetverbindingen, netwerkrandapparatuur, rack, kabels, UPS'en, enz...

Servervirtualisatie

Het was tijd voor een nieuw kind in de buurt: virtualisatie. "In plaats van veel onderbenutte servers te hebben, wat als we een virtuele kopie van elke server zouden maken en ze vervolgens allemaal op één fysieke server zouden plaatsen?" Het idee was geweldig, en eerlijk gezegd is het vandaag de dag nog steeds een geweldig idee.

Maar vanuit het oogpunt van desktopsoftware was alles precies hetzelfde totdat we begonnen te zien dat webapplicaties daadwerkelijk zakelijk gebruikt werden. Een webtoepassing is meestal opgesplitst in 2 delen: de gebruikersinterface (gebruikersinterface) gebouwd in HTML, CSS en Javascript die de logica in de client uitvoert, en het resterende deel dat wordt uitgevoerd aan de serverzijde.

Hier zien we de opkomst van een nieuwe architecturale term: Stateful. Stateful betekent dat de server volledig op de hoogte is van de klant en de context van elke transactie. Elke transactie wordt uitgevoerd in de context van eerdere transacties en de huidige transactie kan worden beïnvloed door wat er tijdens eerdere transacties is gebeurd. Om deze redenen gebruiken stateful-apps dezelfde servers telkens wanneer ze een verzoek van een gebruiker verwerken. Dit is het belangrijkste probleem: aangezien elke server een beperkt aantal clients heeft die hij kan bedienen, is schalen niet eenvoudig. Je kunt niet zomaar een nieuwe server toevoegen. In plaats daarvan moet u een logica maken zoals: "Klanten met een naam die begint met A tot G gaan naar server 1, van G naar O gaan naar server 2...", enzovoort. 

Maar 'stateful' betekent ook dat de context op de server wordt opgeslagen. Soms bevat de server ook de database, of host deze verschillende virtuele servers op dezelfde hardware.

Zoals je je kunt voorstellen, als de server om welke reden dan ook uitvalt, is alles verloren!

De oplossing voor deze uitdaging presenteert de tegenovergestelde term: Staatloos. Een stateless server slaat de context van de client niet op, maar voert alleen het verzoek uit. De client springt tussen servers en een 'load balancer' die dynamisch clients aan elke server toewijst en de belasting verdeelt. Als een server uitvalt, geen probleem! De 'load balancer' stopt om het verkeer naar de offline server te leiden. Als de belasting groter wordt dan de capaciteit van de server, is het gewoon een kwestie van extra stateless servers toevoegen. Uiteraard is het tegenovergestelde ook waar: als het aantal clients afneemt, kunnen servers eenvoudig worden uitgeschakeld. Dit wordt ook wel een 'elastisch zwembad'.

Vanuit het oogpunt van een ontwikkelaar betekende dit historische moment een enorme verschuiving. We moesten afstappen van de desktop, waar alles één enkele applicatie was waar alle bronnen en componenten van de software waren gecomprimeerd. Alle vaardigheden en problemen waren in één 'singulariteit'. Dit introduceerde een nieuwe reeks problemen: servers, verbindingen, frontend-logica, backend-logica, nieuwe talen en data-abstractie. Velen probeerden hun kennis aan te passen aan dit nieuwe paradigma, in plaats van helemaal opnieuw te beginnen en zich te specialiseren in bepaalde gebieden (mensen zitten vandaag nog steeds vast in de singulariteit van de desktop-applicatie). Je komt nog regelmatig software tegen waarvan je duidelijk kunt zien dat het een 'poort' was van een desktopapplicatie naar een cloudinfrastructuur, vooral als je genoodzaakt bent om te gaan met 'installaties', 'bestanden' en 'versies'. 

Cloud-applicaties

We zijn nu in 2011: Occupy Wall Street draait op volle toeren en er worden eindelijk 'cloudapplicaties' ontwikkeld voor een 'cloudbesturingssysteem'. Het is belangrijk op te merken dat de uitvoering van de software nog steeds plaatsvond in virtuele machines. De software-architectuur was 'monolithisch', wat inhoudt dat elke virtuele staatloze server een kopie van de software had. De maximale optimalisatie had een webcomponent en 'worker'-componenten. De 'werker' was het onderdeel 'uitvoering', zoals het maken van documenten, het comprimeren van bestanden, rekenalgoritmen en langlopende taken.

Deze architectuur was niet echt efficiënt vanuit het oogpunt van CPU-gebruik en resulteerde in overbelaste of onderbenutte servers. Het was ook niet efficiënt voor ontwikkelaars om met deze monolithische architectuur om te gaan, omdat je om een klein deel van de software te updaten de applicatie op alle servers moest vrijgeven, met downtime tot gevolg. Monolithische architectuur is gemakkelijker te ontwikkelen, testen en implementeren... maar moeilijk te schalen.

Ook hier krijgen we weer een uitdaging te zien die de cloud vooruit duwde: "Hoe kunnen we een monolithische applicatie opsplitsen in kleinere stukjes?"

Microservices, orkestrators en containers, oh my!

Het antwoord op monolithische cloudapplicaties is 'orkestratie met microservices'. Stel je voor dat je een applicatie opsplitst in op zichzelf staande stukjes bedrijfsfunctionaliteit, volgens de 'UNIX-filosofie: "Doe één ding en doe het goed". Zodra u uw aanvraag in deze stukken hebt opgesplitst, kunt u ze aanroepen 'microdiensten'. Stel je al deze microservices voor als stukjes in een Tetris-game, waarbij alle virtuele servers bij elkaar passen op een manier om de CPU, het geheugen, het netwerk en de opslagbronnen beter te benutten.

De 'orkestrator' is echt degene die 'Tetris speelt', en de VM's heten 'Knooppunten' (of de niveaus/borden in ons Tetris-spel). Als een knoop punt uitvalt, kan de Orchestrator nieuwe knoop punten maken of de services naar een of meer knoop punten verplaatsen. Als u een microservice bijwerkt, kan de Orchestrator de oude versie in leven houden, de nieuwe versie implementeren en vervolgens de oude versie stoppen. 

Zoals je je kunt voorstellen is de Orchestrator met microservices een zeer flexibele en robuuste architectuur, maar hij heeft een probleem... iemand moet de Orchestrator beheren en onderhouden!

Dit dreef ons ertoe om de 'virtuele machine' opnieuw uit te vinden. Een virtuele machine is een logische server die de volledige softwarestack bevat: stuurprogramma's, besturingssysteem en toepassing. Een fysieke machine kan meerdere VM's hosten, zelfs voor verschillende klanten, omdat ze volledig van elkaar zijn geïsoleerd. Deze aanpak is erg krachtig, maar niet erg efficiënt omdat het besturingssysteem veel bronnen gebruikt om te 'bestaan', en elke VM onderhoud vereist, zoals upgrades, beveiligingspatches en configuraties.

EEN container isoleert de toepassing en deelt het besturingssysteem tussen alle andere containers. In plaats van de hardware te virtualiseren, zoals een VM in een container, wordt het besturingssysteem gevirtualiseerd.

Oké, terug naar de architectuur. Je hebt misschien al geraden dat de beste kandidaat om in een container te zitten een microservice is. Als microservices volledig zijn gescheiden, kunt u 'bevatte microservices' van verschillende instanties binnen dezelfde Orchestrator hosten.

Serverloos

We zijn bij de laatste stap van onze geschiedenisles, dus laten we naar het laatste semester kijken: Serverloos. Als de orkestrator wordt beheerd door iemand anders, zoals een cloudprovider, is het ontwikkelen van een applicatie als KBMax slechts een kwestie van het ontwikkelen en implementeren van gecontaineriseerde microservices. De microservices kunnen automatisch worden geschaald, verplaatst, opnieuw gestart en geüpgraded zonder bedrijfsmiddelen te verspillen. Maar hoe wordt de applicatie aan elke klant bediend?

De eerste optie, Enkele huur, is het meest voor de hand liggend voor een 'on-premise' optie omdat het een speciale applicatie en een speciale opslag en database betreft. Het is een cloudtoepassing met één exemplaar van alles voor elke klant. Deze aanpak heeft voor- en nadelen: elke klant kan een ander upgradepad, back-up en controle hebben. Het wordt echter snel een aanslag op de middelen, omdat de klant de verkeerde indruk krijgt dat hij de vrijgave en de beveiliging kan controleren.

De tegenovergestelde optie heet Multi-tenancy: Er is slechts één applicatie en één opslag/database. Alle klanten gebruiken dezelfde applicatie en hun gegevens worden naast elkaar bewaard op dezelfde opslag/DB. Deze optie is zeer efficiënt en de software-releases zijn over het algemeen frequenter en minder opdringerig. Maar er is een vangst. Als u een bedrijf bent dat bijzonder veel aandacht besteedt aan beveiliging, wilt u waarschijnlijk niet dat uw gegevens worden opgeslagen naast de gegevens van andere bedrijven. KBMax lost dit probleem op met Hybride huur: Eén applicatie, maar een dedicated storage/DB voor elke klant.

Choosing a Real CPQ-cloud

Hopelijk helpt deze diepe duik in de geschiedenis van cloud computing je iets meer te begrijpen over de ins en outs van de cloudarchitectuur. We delen deze kennis graag met andere bedrijven, zodat ze kunnen leren hoe ze applicaties kunnen herkennen die niet de meest recente trends volgen om snelheid, beveiliging en toegang te optimaliseren.

KBMax is built using the latest cloud architectures following development best practices, ensuring top performance and security for our CPQ cloud customers. We often come across customers who were sold a ‘fake cloud’ by another CPQ vendor, only to realize the grift once it was too late. Look for a future article, where we’ll discuss the differences between types of cloud infrastructures (SaaS, IaaS, PaaS, etc.) and how they can fundamentally change the customer experience and total cost of ownership. Because, yeah, not all ‘clouds’ are the same.