Yenlo ondersteunt organisaties bij elke cloud-strategie
Soms stellen bedrijven met een behoorlijke historie, dat ze de afgelopen tijd de ontwikkeling maakten van Cloud First naar Cloud Native. Dat lijkt een merkwaardige bewering. Hoe kun je nou, terwijl de onderneming wellicht vér voor de opmars van clouddiensten ‘geboren’ werd, stellen dat je de overstap maakte naar Cloud Native?
In deze tekst zet ik de begrippen Cloud First, Cloud Native én Cloud Only op een rij. En ik geef daarbij aan hoe Yenlo bij elke cloudstrategie die organisaties kiezen kan ondersteunen.
Cloud First als strategie
Laat ik beginnen met Cloud First. In feite is dat een keuze van een onderneming op strategisch niveau. Het bedrijf neemt het besluit steeds te kijken of ze een clouddienst kunnen vinden die direct aan de eisen voldoet. Men zoekt dan bijvoorbeeld binnen de servicebibliotheek van Amazon Web Services (AWS) naar een oplossing die precies past bij de requirements van de use case die speelt. En dan is het de bedoeling die oplossing als eerste keuze uit te proberen. Mocht AWS niet in een oplossing voorzien, dan kan ook voor andere Cloud Service Providers gekozen worden. In de basis heeft een cloud service de eerste voorkeur. Cloud First is daarmee een strategische keuze.
Cloud Native bij development
Bij Cloud Native maakt je een keuze op het niveau van development en integratie. Kiest een bedrijf daarvoor, dan gaan developers daadwerkelijk aan de slag met als doel de hele applicatie in te steken op bouwstenen die beschikbaar zijn in de cloud. Elk element draait vanaf het begin (vandaar ‘native’) in de cloud. Bij AWS kun je dan bijvoorbeeld gebruik maken van serverless computing, waarbij de zogenaamde AWS Lambda-services het mogelijk maken code direct in de cloud te schrijven.
Een goed moment om te heroverwegen of jouw API Platform klaar is voor de nieuwe wereld.
Nu downloadenAPI’s als communicatiekanaal
Je gebruikt als developer die blokjes code om een applicatie te bouwen. Nu heeft iedere applicatie een bepaalde throughput: er gaat iets in en dat moet leiden tot een resultaat. Dit vereist communicatie met andere applicaties. Daarbij spelen API’s een essentiële rol, en zoals bekend geldt Yenlo als een absolute specialist op het gebied van het ontwikkelingen, beveiligen en beheren van API’s. Vandaar dat we ons intensief bezighouden met bedrijven die voor Cloud Native kiezen.
Relatie tot on-premise
Laat ik terugkeren tot de eerdere omschrijving van Cloud First. Zoals gezegd gaat het daarbij om een strategische keuze: bij nieuwe ontwikkelingen kiest de onderneming voor een cloud-oplossing die af wordt genomen bij een provider, zoals AWS. Daarbij zal in het bedrijf nog steeds sprake kunnen zijn van on-premise applicaties. Dat hoeft geen probleem te zijn. Uiteraard kunnen API’s van een cloud-oplossing heel goed communiceren met andere cloud-solutions, maar er is geen enkele reden waarom ze dat niet ook met on-premise software zouden kunnen doen.
Legacy-omgevingen
Yenlo heeft verschillende grote klanten in bijvoorbeeld banking of het verzekeringswezen, die nog steeds met legacy-omgevingen (moeten) werken en forse on-premise stacks hebben. Dat biedt ons en de klant interessante kansen. Deze klanten bieden we vaak een API-management oplossing in de cloud die de onderliggende on-premise-omgeving van de klant ontsluit. Dan kiest de klant in feite voor een Cloud First approach, om de bestaande diensten toch online te kunnen ontsluiten.
Dat soort trajecten verzorgen we bij Yenlo vaak, onder meer met het Connext Platform. Daarmee kunnen we bij een dergelijke klant al bij een week live gaan met het online ontsluiten van de dienstverlening van die klant.
Yenlo als strategische partner
Natuurlijk kan een bedrijf er ook voor kiezen een connectie te bouwen vanuit het eigen datacenter en de gewenste online-applicaties via een eigen API-management laag te benaderen. Maar dat moet je wel onderhouden. Je moet de mensen en kennis in huis hebben en daarbij toch denken aan de nodige FTE’s voor het beheer ervan. Voor heel veel ondernemingen is dat niet haalbaar, dus dan zoeken ze daarvoor een strategische partner zoals wij.
Standaard integratie-oplossingen
Dan speelt nog het verschil tussen Cloud Native en Cloud Only. Bij Cloud Native is er geen of minder legacy (meer) in de organisatie. Er is in dat opzicht sprake van een ‘greenfield’. Zoals gezegd ga je een applicatie bouwen en je doet dat meteen helemaal in de cloud. Je denkt er niet eens aan dit on-premise te draaien. Je gebruikt meteen de meest geschikte technologie.
Dat kan met ons Connext Go Platform, daarin bieden we een omvangrijke bibliotheek van standaard integratie-oplossingen, onder meer voor het koppelen van softwaresystemen, waarmee klanten direct uit de voeten kunnen. Dit Connext Go platform van Yenlo is zelf volledig Cloud Native. De basis van deze omgeving is het containerisatieplatform Kubernetes.
Cloud Only
Daarnaast gaan we nog een stap verder bij wat we Cloud Only noemen. Daarbij zetten we volledig serverless technologieën in. Om daar ook integraties mee aan te bieden aan onze klanten. Die bieden echt in extreme mate schalingsmogelijkheden en maakt zo een dynamiek mogelijk waar je met andere manieren van development niet zomaar tegenop kan. Je plaatst code in AWS en die provider houdt het draaiende. Dan maakt het niet uit hoeveel gebruikers tegelijkertijd komen, de provider schaalt automatisch genoeg capaciteit om daarin te kunnen voorzien en schaalt meteen weer af als het niet meer nodig is. Je beheert niet de servers maar je beheert jouw code in de cloud.
Uit deze schets blijkt wel hoe dynamisch de cloud is. Er is elke dag iets nieuws te vinden en te ontwikkelen. Het biedt ongelofelijk veel mogelijkheid om klanten te helpen. Dat maakt het werken in de cloud voor mij zo mooi.