De eerste stap in de reis naar het verplaatsen van monolithische apps te Kubernetes
Tijdens mijn loopbaan van software engineering één van de meest waardevolle vragen die ik heb geleerd om te vragen van een collega is “Wat doet het $iets voor u betekenen?”. Het dwingt de andere ingenieur om hun implicaties van het gebruik van een bepaald woord te evalueren. Naar aanleiding van de eerste bewegende monolithische toepassingen Kubernetes call, ik wilde een paar minuten praten over wat een monolithische toepassing is. Of wat het voor mij betekent.
dit is een interessante ruimte die enige aandacht nodig heeft. Terwijl het bedienen van een stateless microservice op Kubernetes is relatief eenvoudig, het bedienen van een grote stateful applicatie heeft nog een lange weg te gaan. Begrijpen wat een monolithische toepassing is zal de eerste stap zijn om het migratieproces gemakkelijker te maken.
om een monolithische toepassing te definiëren moeten we eerst de componenten van een toepassing begrijpen waar we om geven. De drie componenten waarin we geïnteresseerd zijn, zijn de gebruikersinterface, de data access layer en de data store.
de gebruikersinterface is het ingangspunt van de toepassing en is ook het punt van het programma waarmee een gebruiker zal communiceren. Dit kan een main () functie, website, web service, of diverse andere toegangspunten.
de data access layer is de laag van het programma dat een gegevensopslag zal wrap. Typisch de data access layer zal zorgen behandelen zoals authenticatie met een data store, en het saniteren van gegevens voordat het in de data store.
de gegevensopslag is het meest fundamentele onderdeel van het systeem, en is verantwoordelijk voor het opslaan van willekeurige informatie (gegevens) en het ophalen ervan. Deze component is meestal slechts een database.
deze drie componenten vormen een veel voorkomende vorm van toepassing genaamd een stateful applicatie. Wat betekent, dat de applicatie slaat en manipuleert gegevens in de tijd. Daarom zeggen we dat de aanvraag staat heeft. Belangrijker is dat de status van de toepassing in de loop van de tijd kan veranderen.
in het geval van een monolithische toepassing zien we vaak meerdere lagen van de toepassing die nauw met elkaar verbonden zijn. In het onderstaande voorbeeld kunnen we zien dat de gebruikersinterface en de laag data access gegroepeerd zijn. Dit wordt meestal gedaan via een grote code repository, en beide lagen zullen waarschijnlijk afhangen van de andere op zijn plaats om te draaien. Bovendien zijn de gebruikersinterface en data access lagen meestal gebundeld in hetzelfde proces tijdens runtime. Dit betekent dat ze communiceren op hetzelfde systeem, met behulp van systeembronnen (geheugen en rekencycli) om te communiceren met andere delen van het systeem.
integendeel, een microservice-gebaseerde applicatie zou bestaan uit kleine modulaire componenten die gemakkelijk kunnen worden geschakeld. Dit biedt een concept van composeerbaarheid voor een operator en is een teken dat u werkt met microservices in plaats van een monolithische toepassing. Onderstaand voorbeeld toont een flexibele en modulaire toepassing. Merk op dat we in dit model de kleinere componenten zelfstandig kunnen draaien en een netwerk kunnen gebruiken om ons systeem met elkaar te verbinden. Deze aanpak is veel schaalbaarder.
dus wat is een monolithische toepassing? Het is een single-tiered software applicatie waarin de gebruikersinterface en data access code worden gecombineerd in een enkel programma op een enkel platform. Het is ook een applicatie die meerdere componenten draait in hetzelfde proces, op hetzelfde systeem.We proberen de nuances van het migreren van monolithische toepassingen naar Kubernetes te begrijpen en hopen dat dit een waardevolle eerste stap in onze reis is. Omdat het proces relatief ongedocumenteerd is, zijn we van plan om de geleerde lessen te delen, zodat iedereen ervan kan profiteren.