Je Monoliet naar Services Ombouwen

In het SDN-magazine zie je veel auteurs vertellen over microservices, maar ook op onze SDN-events of andere conferenties zijn er veel sessies over. Ze vertellen dan altijd dat het belangrijk is om naar microservices over te stappen, want daarmee wordt het leven een stuk eenvoudiger. De voorbeelden die ze geven zijn dat altijd de standaardvoorbeelden van een product-order systeem of ze komen met voorbeelden vanuit een greenfield situatie. De presentaties gaan bijna altijd uit van het niet aanwezig zijn van legacy code of legacy systemen. Maar onze werkelijkheid is vaak veel weerbarstiger.

Veel bedrijven hebben een monoliet en een monoliet is niet iets waar je voor hoeft te schamen. Er zijn maar weinig omgevingen waar niet een vorm van monolithische code of omgeving is ontstaan. Zelfs bij startups begint het altijd met een redelijk puristische manier van ontwikkelen, maar na enkele weken/maanden wint de tijdsdruk van de schoonheid en raakt de software langzaamaan vervuild. Op zichzelf hoeft dat ook helemaal niet erg te zijn. Mits je tijdig refactor-slagen uitvoert en bij iedere volgende aanpassing/verbetering/bugfix je code weer beter achterlaat (incheckt) dan dat je hem gevonden hebt: de Boyscout rule, laat het kampeerterrein schoon achter voor de volgende gebruiker en liefs nog iets schoner. Ook hier voer je dus verbeteringen uit stapje voor stapje, hapje voor hapje. Ik ben een groot voorstander van “Make-it-work-then-make-it-better-then-make-it-pretty”.

“Make it work then make it better then make it pretty”

Want hoe migreer je vanuit een bestaande omgeving naar een service georiënteerde omgeving of microservices. Het antwoord is heel simpel zoals je ook een olifant eet, hapje voor hapje. “Haha wat leuk, neem je ons niet serieus of zo?”. Jazeker wel en ik zal jullie uitleggen hoe ik dat bedoel.

Monoliet naar Services

Door de conferenties en artikelen (waar Microservice behoorlijk gehypet worden) hebben veel bedrijven de wens om over te stappen naar een service georienteerde architectuur en bij voorkeur naar een Microservices architectuur. Maar natuurlijk moet de winkel wel open blijven en dat betekent dat support en bigfixes wel gewoon moeten door blijven gaan. Tenslotte betalen de huidige klanten de rekeningen en organisaties hebben niet de mogelijkheid om voor een paar maanden of soms jaren onder een steen te kruipen om orde op zaken te stellen. Natuurlijk kan dat niet, tenslotte zijn klanten de reden waarom het bedrijf bestaat en zij betalen niet voor een product dat niet verbetert, wordt onderhouden en gewoon stilstaat. Ander risico is dat er een andere partij opstaat en jouw plekje inneemt.

Ik denk ook niet dat je dicht hoeft om tijdens het rijden een wiel te verwisselen. Alleen moet je dan als bedrijf wel een behoorlijke tijd uittrekken om te migreren. Je zult dat wel dubbel onderhoud en dubbele code moeten accepteren. Wat vaak in jaren is opgebouwd, is niet in een paar weken terug te draaien. En doordat je niet alles vanaf de grond opnieuw bouwt, zul je meerdere refactor slagen moeten maken en Projects/files/classes/code meerdere malen zult aanpassen. Het is pas af als jullie puntje op de horizon gehaald is.

Ja, dat is niet exclusief voor Service Oriëntatie! Klopt, want het begint bij het ontrafelen van de kluwen van code en zorgen dat alle onbedoelde maar ingeslopen afhankelijkheden weer ongedaan gemaakt worden. Pas als je de basis op orde hebt, dan kun je de stap voorwaarts maken en nieuwe dingen toevoegen. Ook microservices (hoe hip ook) zijn niet perse nodig. Wel wil je dat verantwoordelijkheden goed verdeeld zijn over de verschillende servers, computer systemen of code.

Eerst moeten we voor ons zelf bepalen, wat de reden is om te migreren naar Service Oriëntatie. Wat zijn de huidige uitdagingen met je applicatie, platform of service? Is het dat het testen niet meer te doen is? Of dat het aanpassen van code op de ene plek betekent dat er op een andere plek code / functionaliteit omvalt? Er te veel afhankelijkheden tussen verschillende onderdelen bestaan? Of dat het deployen een probleem is geworden en gewoon te lang duurt? Of wil de organisatie van het ASP (Application Serivice Provider) model af en omvormen naar overstappen naar een SAAS (Software As A Service) model? Is de applicatie, service of platform eigenlijk niet geschikt voor multi users omgeving? Of is je oplossing niet of nauwlijks in staat op te schalen bij meer gebruik? Is in het algemeen reageren op gewijzigde wensen van je klanten gewoon lastig, omdat er te vlug andere functionaliteit omvalt.

Belangrijk is, dat de reden niet moet zijn omdat iedereen het doet of dat services of erger microservices zo belangrijk lijken in de business. Op zichtzelf hoeft er niks mis te zijn aan een monoliet. Er moeten andere redenen zijn om aan te passen. Ik heb liever een goede monoliet dan een slecht uitgevoerde Service Oriëntatie. Technology is een middel en moet nooit een doel op zichzelf zijn.

Technology is een middel en niet een doel

De formele beschrijving van een Service Orientation Architecture service: “A SOA service is a discrete unit of functionality that can be accessed remotely and acted upon and updated independently, such as retrieving a credit card statement online. SOA is also intended to be independent of vendors, products and technologies.”. Microservices zijn opzichzelf niet heel anders, maar waar we de definitie van een op zichzelf staande eenheid van functionaliteit wel iets strakker wordt neergezet. In een minder goed uitgevoerde Service Oriëntatie omgevingen zijn de services vaak te klein, waardoor de services elkaar aanroepen en eigenlijk niet meer los van elkaar gebruikt worden. Dat resulteert meestal in een Chatty systeem, waarbij services elkaar herhaaldelijk aanroepen en allesbehalve onafhankelijk van elkaar zijn. Iedere aanroep van een service levert weer vertraging op en als het een losse service is. Soms zijn de services dan ook nog eens zo gebouwd, dat ze niet verwachten dat de aanroepende service stuk of niet aanwezig is. En dat gebeurt juist als het zo losgekoppeld is. Waarmee de “updated independently” uit de definitie eigenlijk niet meer kan, andere services rekenen op elkaar en feitelijk heb je dan een monoliet in stukjes.

Belangrijkste in de definitie is volgens mij ook op zichzelf staande functionaliteit. Er staat nergens hoe groot de “op zichzelf staande functionaliteit” moet zijn. Wat er wel staat, alles wat de service nodig heeft om volledig autonoom te kunnen werken onafhankelijk van de rest van de systemen. Even heel gechargeerd, een monoliet is in deze beschrijving dus ook een goede service. Een monoliet herbergt misschien te veel verschillende functionaliteiten. Zoals een ordersysteem, een productsysteem, een klantsysteem etc. Ik schrijf expliciet systeem om aan te geven dat het losse onderdelen moeten zijn. Maar het ordersysteem heeft informatie nodig van de producten en de klanten! Ja, dat klopt, maar het ordersysteem zal niet het adres van de klant updaten in de database. Ieder systeem heeft zijn eigen verantwoordelijkheden. Het ordersysteem gebruikt de data van het klantsysteem. Verandert het adres in het ordersysteem? Dan maakt het ordersysteem een werkbon voor het klantsysteem om dit aan te passen. Voor hier gaat het te ver om hier dieper op in te gaan, lees het artikel van Dennis van der Stelt uit ons vorige magazine eens over het Starbucks model. Vuistregel is, maak je functionaliteit niet te klein en let goed op welke verantwoordelijkheden de functionaliteit heeft. Services zijn ook een middel en niet een doel. Keep it simple, maar om met Einstein te spreken; maak het niet simpeler dan dat.

Terug naar ons initiële probleem. We zien de monoliet als een samengeklonterde functionaliteit, maar feitelijk bestaat deze toch ook uit losse stukken en op zichzelf staande functionaliteit. Echter de functionaliteit is alleen te veel op de achtergrond geraakt door gebruik van technology. Vaak zijn databases te ver uitgenormaliseerd (8st normaalvorm) of is object Oriëntatie te strict doorgevoerd. Heel vaak is door technologische overload de functionaliteit teveel door elkaar heen gaan lopen. De technologie geeft de mogelijkheid en de druk om snel nieuwe functionaliteit er uit te sturen neemt dat ook toe.

Maar als je het goed doet, dan kun je het best weer naar zijn oorsprong ontrafelen. Je zult dan strict bezig moeten zijn met de functionaliteit en de technologie weer een middel laten zijn.

Maak een vertical slice van je functionaliteit

Laagjes zoals in een taart

De volgende stappen kunnen dan gedaan worden. Bepaal een stuk functionalitieit dat op zichzelf staat of had moeten staan. Beschrijf het dan van de user interface tot aan de kern (de dataopslag of de servicebus of wat ook het eindpunt is). En zodra je een afhankelijkheid spot, bedenk dan steeds of deze afhankelijkheid noodzakelijk is en of er andere oplossingen zijn. Als er geen eindpunt is, dan is er misschien een uitdaging met de functionaliteit zelf. Poplulair gezegd maak een verticale doorsnede (vertical slice) van je applicatie. Zie het als de taart met die vele gekleurde laagjes, beschrijf alles van dat ene stuk uitgesneden staart en alleen wat bij dat stuk hoort. Bouw dan dat stuk opnieuw en hergebruik zo min mogelijk eerdere code. Anders word je te vlug weer in de rabbithole getrokken. Bereid je voor op het herhaaldelijk refactoren van de code. Er lijkt geen einde aan te komen, maar uiteindelijk zal het beter worden.

Vertical Slices

Deze strategie maakt het ook mogelijk om de oude flow van de functionaliteit nog beschikbaar te houden en de nieuwe er echt los van te laten. Uiteindelijk is dat ook je doel in Service Oriëntatie. Als je dan volledig tevreden bent met de nieuwe implementatie, dan zet je de wissel om.

Soms kan de aanpassing ook aan de buitenkant gemaakt worden, waardoor bepaalde werkvoorraad niet eens je platform/applicatie of omgeving bereikt. Controle aan de deur. Beschrijf deze functionaliteit zo onafhankelijk mogelijk en als je of het team de behoefte voelt om andere functionaliteit toe te voegen of samen te voegen, stel dan de waarom vraag zo vaak mogelijk. Als je dan nog steeds niet zonder kunt, dan moet je het samenvoegen niet laten.

Maar iedere andere wijziging verstoort het proces. Dus probeer niet gelijk ook volledig nieuwe functionaliteit toe te voegen of bestaande functionaliteit volledig te veranderen. Niet omdat het niet zou kunnen, maar als we technologie of functionaliteit wijzigingen gaan doorvoeren dan worden we afgeleid en wij mensen kunnen helaas niet teveel multitasken. Het onafhankelijk en losgeweken van het stukje functionaliteit is al moeilijk genoeg. Daarom moet je de eenheid ook zo klein mogelijk maken. Dat voorkomt dat de rest van de applicatie/omgeving op slot zit voor aanpassingen of wijzigingen.

Het is te doen, maar je zult wel heel gericht door moeten gaan en je niet laten afleiden. En als je eenmaal begonnen ben, dan kun je eigenlijk niet meer stoppen. Meer dan eens zullen verschillende stukken software door je handen gaan en meer dan eens zal je code aanpassen om deze later weer ongedaan te maken. Dat geeft niet, je doel is op zichzelf staande stukken software/services. Niets is onmogelijk. Maar laat technologie niet de reden zijn! En blijf refactoren.

Cloud Strategie

Er wordt de laatste tijd erg veel gesproken over het opstellen van Cloud Strategieën bij bedrijven. Maar gaat het daadwerkelijk om Cloud strategieën of gaat het om een breder omvattende IT strategie waar Cloud een implementatie vorm van is?

Voor een bredere IT strategie is het volgens mij belangrijk om te bepalen wat de core business is en welke processen ondersteunend zijn. De voorwaarden en eisen van deze processen bepalen welke software ondersteuning kunnen bieden. Mogelijk is out-of-the-box software  (OOB) of software as a service (SAAS) een oplossing. Als dan blijkt dat er geen software op de markt is om de processen te ondersteunen, dan is er een optie om de software zelf te ontwikkelen. Dit inzicht bepaalt dan waar de inspanningen moeten liggen. Voor de OOB software of zelfgemaakte software heb je dan een Cloud strategie nodig.

Maar is het dan een Cloud strategie of gewoon een implementatie strategie? Bijvoorbeeld OOB software stelt bepaalde eisen aan de onderliggende infrastructuur. De frequentie waarmee de software pieken en dalen van gebruik zal ondergaan, gecombineerd met ondersteuning van de software voor het opvangen van deze pieken, met deze parameters kunnen dan de kostverschillen tussen eigen hosting of een Cloud omgeving bepaald worden. Hierbij dienen dan wel de non functionele parameters voor o.a. beheer, back-ups en monitoring meegenomen worden. Applicatie beheer moet ook een plekje krijgen in het kostenplaatje.

Als de ondersteunende software zelf ontwikkelt wordt, dan gelden dezelfde afwegingen als bij iedere implementatie. Welke architectuur, welke technieken en welke diensten kunnen we hergebruiken. Een strategie hier is dan buy-before-build, of populairder kunnen we gebruik maken van PAAS (platform-as-a-service diensten).

Welke deployment omgeving is mede afhankelijk van de gebruikte technieken of platform onderdelen. Daarbij komt ook de vraag, ontwikkelen we in eigen beheer of besteden we ontwikkeling uit? In het laatste geval kunnen we ook bepalen of de ontwikkelpartner wellicht de hosting en beheer over kan nemen.

Een Cloud strategie zou onderdeel kunnen zijn van de IT strategie. Cloud is een implementatie methode en behelst het geheel van on premise private Clouds tot public Clouds. In welke Cloud de software optimaal en flexibel landt, is helemaal afhankelijk van de requirements.

Op basis van een matrix met de requirements en de applicatie behoefte, zou je met een beslisboom redelijk kunnen bepalen waar de keuzes uit bestaan. De IT strategie zal dan zijn SAAS versus eigen hosting. Voor software ontwikkeling is de Cloud strategie dan PAAS versus IAAS of buy-before-build.

API Management

Het is voor leveranciers van producten bijna onmogelijk om voor ieder platform mobiele applicaties te maken. Natuurlijk kun je dan als leverancier zorgen voor een goede responsieve mobiele website. Het nadeel van deze manier is dat je de capaciteiten en mogelijkheden van een mobiel device niet volledig uit nut.

Daarom zijn er ook leveranciers die hun backoffice via API’s beschikbaar stellen aan de wereld. Meestal wil je dat niet zonder pardon doen en wil je er als leverancier wellicht geld aan verdienen. Dus je wil een Developer portal maken met verschillende groepen, help pagina’s, voorbeeldcode, monitoring, issue lijst, FAQ, maar ook malafide gebruikers/applicaties blacklisten. Kortom het vergt meer dan even het beschikbaar stellen van een paar webservicesje.

Enige tijd geleden had ik ook zo’n droom. Ik wilde voor de SDN een evaluatie app maken. Bezoekers van een SDN event kunnen dan mobiel een evaluatie formulier invullen. Deze evaluatie data wordt in een data store op Azure bewaard. Uiteraard wil ik niet mijn tokens/connectionstrings/passwords etc in mijn mobiele apps opslaan. En aangezien ik niet voor elk device zelf een applicatie kan schrijven, deze gegevens delen met wildvreemde developers.

Screenshot (1)

Dus bedacht ik dat ik een aantal Webapi services beschikbaar moest stellen. Maar zoals hierboven genoemd, had ik behoefte aan eer developers portal om mijn services uit te leggen en wat ze opleveren. Dat is veel werk voor zo’n API als dit. Dit is mijn landingspagina nu; http://sdnevalapp.azurewebsites.net/.

1-7-2015 4-34-32 PM

Gelukkig is daar een oplossing voor op het Azure platform. De API management service (documentatie site).

1-7-2015 4-40-33 PM

1-5-2015 9-53-21 AM

Als je de service gemaakt hebt, dan is er een aparte portal (https://marcelmeijer.portal.azure-api.net/admin) waar je alle instellingen doet, waar je de metrics van je API ziet, de applicaties die aangemeld zijn, welke API het vaakst aangeroepen wordt etc.

1-5-2015 9-53-33 AM

Bij de settings kun je dan de webservices beschikbaar stellen. De verschillende operaties, welke http verb, welke responses er verwacht kunnen worden, welke URL, omschrijving en helpteksten.

1-5-2015 9-56-59 AM

1-5-2015 9-57-15 AM

De URL naar de bron services kan ook on-premises gehost worden. Uiteraard is het dan wel verstandig om de endpoints op deze URL te beveiligen met een Certificaten, UserName/Password combinatie of via OAuth.

Dit is de management portal voor de beheerder van de API(https://marcelmeijer.portal.azure-api.net/admin), voor de ontwikkelaars is er een aparte portal (https://marcelmeijer.portal.azure-api.net/). Deze kan tot op zekere hoogte ook gestyled en aangepast worden.

Deze Developer portal is redelijk compleet. Alle genoemde zaken zijn hier wel te vinden.

1-5-2015 9-53-44 AM

Zo is er een handig overzicht van de beschikbare API’s.

1-5-2015 9-53-59 AM

Van de beschikbare API kun je de beschikbare endpoints zien. Je ziet dan de omschrijving en de  URL om API aan te spreken. Om het endpoint te gebruiken moet je een subscription key meegeven. Het hele idee van deze portal is dan ook om gebruik te reguleren en met behulp van de subscription key is de API per applicatie/ontwikkelaar apart. Aangezien de endpoints aan de basis beveiligd zijn met Certificaten, Username/Passwords of via OAuth, heeft het geen zin om rechtstreeks naar de bron te gaan.

Op deze Developer portal kun je API methode ook uitproberen en de verschillende gedefinieerde HTTP acties uitvoeren. Je krijgt dan de trace en het resultaat te zien.

1-5-2015 9-54-38 AM

1-5-2015 9-54-56 AM

1-5-2015 9-55-30 AM

Helemaal onderaan de pagina kun je per programmeertaal voorbeeldcode krijgen. Alles om de ‘klanten’ van je API te ondersteunen en te helpen.

1-5-2015 9-55-45 AM

Zoals ik in het begin al zei, het beschikbaar stellen van een API is een maar om er een hele developer portal bij te maken is twee. Door deze Azure service kun je je richten op het echte leuke en belangrijkste van de API, de functionaliteit.

Waarom zou je het zelf doen, als je gebruik kunt maken van de expertise van andere. “You can reach further while standing on the shoulders of giants”

Azure Webjobs

Tijdens de afgelopen Microsoft Techdays 2014 deed ik een sessie over Azure Cloud Services. De opname is te vinden op Channel 9. In het begin van Azure waren Cloud services de “way to go”.

Cloud Servies is een krachtig concept, maar er kleefde ook de nodige nadelen aan. Bestaande applicaties konden niet zomaar via de Lift en Shift methode naar de Cloud gebracht worden. Meestal was dit gewoon te wijten aan de applicaties zelf. Weinig applicaties zijn of waren zuiver stateless, asynchroon in de basis en in staat als meerdere instanties naast elkaar te draaien.

In de afgelopen jaren is het Azure platform rijker geworden met verschillende diensten. In plaats van iets zelf te verzinnen of te kopieren van anderen, zijn er nu bestaande tools/producten opgepakt en in samenwerking geschikt gemaakt voor Azure (Hadoop, Docker, etc).

Maar ook is IT development een stuk volwassener geworden. Developers en architecten realiseren zich steeds vaker dat Scale up niet helpt met availability, dat services/servers stuk gaan en dat een internet applicatie de potentie van een miljoenen publiek heeft.

Standaard dogma’s als SOA architecture, Servicebussen of SOAP webservices lijken ook hun kracht te verliezen, Microservices krijgen meer draagvlak en betere tooling. Daarover ga ik zeker nog vaker bloggen.

Terug naar mijn Techdays demo. Die zag er zo uit:

blog2

De solution zag er zo uit. De code is te downloaden of op te vragen. Zoals gezegd bestond het uit een WebRole en een WorkerRole. De WebRole voor het uploaden en bekijken van de plaatjes.

webjob1

De flow van de applicatie zag er zo uit.

 Slide1 

Zoals je ziet, de WebRole moest naast het uploaden ook een bericht op een queue zetten voor de WorkerRole. Aan de WorkerRole kant moet er een mechanisme zijn om de queue leeg te lezen. Zoals ik vertelde in mijn sessie, moet je dan ook het Busy waiting oplossen. Het lezen van de queue is een transactie en dat kost geld. Een belangrijk onderdeel van architectuur op Azure is Cost Based design. Dus wil je het lezen van bijvoorbeeld een queue zo efficiënt en effectief mogelijk houden met het oog op de kosten.

Op Azure zijn tegenwoordig Webjobs beschikbaar. Met deze webjobs is het mogelijk om deze te laten triggeren na het toevoegen van een nieuwe blob op storage. Dat scheelt in mijn geval een bericht op de queue en eigen check actie van de queue. Het hele wachten en kijken of er werk (nieuwe blob op storage) is, wordt nu door het platform verzorgd en geregeld. En wat ik niet hoef te doen, dat scheelt tijd en het platform kan dat efficiënter. Dus de WorkerRole wordt vervangen door een Webjob. De WebRole heeft ook een alternatief. Moest ik voor de WebRole toch nog iets aparts leren, zoals bijvoorbeeld het lezen van de configuratie settings. Met een Azure Website kan ik de technieken gebruiken die ik altijd al gebruikte. En voor de settings zie je in mijn vorige blogpost de oplossing.

Het proces plaatje ziet er dan zo uit.

 Slide2

En de website ziet er na een kleine redesign zo uit.

blog3 

En de code van de Webjob is eigenlijk alleen dit, ongeveer 55 regels.

function1

De WorkerRole besloeg ongeveer het dubbele aantal regels code, waarvan het grootste gedeelte zaken die niets met het proces te maken hebben.

Op deze manier krijg je precies zoals ik altijd zeg tijdens presentaties. We kunnen ons richten op de functionaliteit en het echte werk, de rest wordt overgenomen en geregeld door het Azure platform.

Oke, nu wil ik eigenlijk dat de Client niet op de queue hoeft te kijken, maar op een andere manier genotificeerd wordt.

NB In deze blogpost beweer ik niet dat Cloud Services niet bruikbaar zijn. Voor het hier genoemde scenario waren de uitgebreide mogelijkheden van Cloud Services niet nodig. Kijk op deze page voor een betere vergelijking tussen de mogelijkheden.

ConnectionStrings / AppSettings Azure

Tijdens mijn poging om Azure webjobs te doorgronden kwam ik het volgende tegen.

Een Webjob wordt gedeployed bij een Azure website. Bij de Webjob hoort ook een dashboard. Na het deployen van mijn Webjob ging ik naar dit dashboard. Tot mijn verbazing zag ik dat mijn Webjob gestart was, maar dat er wel Errors en Warnings waren over een setting.

siteconstring1

Zoals de error/warning verteld, moet je de Connectionstring toevoegen aan het Connectionstring gedeelte van de Azure website. Daarna is de error/warning weg.

siteconstring2

Eerst dacht ik dat ik deze Connectionstring op twee plekken moest configureren. Een keer op de portal en een keer in de app.config van de Webjob. Dat stuitte mij tegen de borst, ik hou niet van om settings op twee plekken hetzelfde te configureren. Dat blijkt ook niet te hoeven.

In je code gebruik je:
var storageAccount =
CloudStorageAccount.Parse(
ConfigurationManager.
ConnectionStrings[
“AzureWebJobsStorage”].
ConnectionString
);

Maar de Connectionstrings of App settings geef je een waarde op de Configure tab van de Azure Website.

image

En dit werkt ook voor de App.config van een Azure Webjob.

Meer informatie: http://www.asp.net/identity/overview/features-api/best-practices-for-deploying-passwords-and-other-sensitive-data-to-aspnet-and-azure

Microsoft Azure: Linux

Tijdens het afgelopen Connect(); event in New York werd ook duidelijk dat Microsoft Linux en Open Source een warm hart toedraagt. Ze hebben hun .NET framework open source gemaakt dat is een stap. Maar eerder is ook geroepen door Satya Nadella, Microsoft Love Linux.

Microsoft_LOVES_Linux

In het begin bestond Azure uit Microsoft gerelateerde producten. Sterker nog Azure was alleen een PAAS. Virtual Machine zoals bij Amazon bijvoorbeeld waren niet mogelijk. Ooit is er de VM Role geweest, maar dat is later gauw vervangen door echte IAAS.

Sinds de nieuwe HTML portal (http://manage.windowsazure.com) behoort IAAS oftewel Virtual Machine echt tot Microsoft Cloud landschap. Ook bijna vanaf dag 1 zaten daar Linux images bij. Dat leverde gefronste ogen op, maar dat is alleen maar uitgegroeid. Op de huidige preview Portal (http://portal.azure.com) is de lijst met Linux images erg groot. Het lijkt mij onwaarschijnlijk dat dit het einde is. Wellicht komen er leveranciers die vanuit de Marketplace images gaan aanbieden. Hoe groter de vraag, hoe meer aanbod er gaat komen..

11-23-2014-15-36-59

Tijdens mijn dagelijkse snuffelrondje (Microsoft Azure verandert zo snel) kwam ik tegen dat ik ook een Minecraft server in de lucht kon brengen. Enige dat je nodig hebt, is een naam en 15 minuten. Daarna heb jij je eigen Minecraft server. How cool! Deze draait op een Linux image by the way.

minecraftazure

Welke reden heb jij om geen gebruik te maken van Microsoft Azure?

Azure Virtual Machines still evolving!

De wizard om een Virtual Machine te maken op Azure is aangepast. Er zijn nu nog meer mogelijkheden.

Voor de grootte van een virtual machine kun je nu kiezen uit een Basic of Standard tier. Het verschil tussen beide is niet alleen een kostenaspect. De Standard tier machines hebben een Azure Load balancer en standaard voorbereid op Auto scaling. Bij een Basic tier machine kun je ook auto scaling bewerkstellingen met behulp van availabiltysets.

25-5-2014 15-48-05

Eerder werden bij het maken van een VM twee standaard endpoints toegevoegd. Als je er meer nodig had, dan kon je die na creatie van de VM toevoegen. Nu kun je ze bij het maken van de VM gelijk invullen. Dat is handig als je bijvoorbeeld een NAV VM wilt maken. Dat scheelt weer een stap in de verdere installatie.

25-5-2014 15-48-25

Je kunt nu ook allerlei extensions direct via deze wizard installeren. Naast standaard extensions zoals Puppet en Chef kun je ook je eigen scripts laten uitvoeren. Je kunt nu ook kiezen voor security extensions.

 25-5-2014 15-48-46

Het tool van Microsoft BGInfo is nu standaard onderdeel van een VM.

ext1

Ik heb het al eens eerder gezegd, dat het erg handig is om je MSDN account te koppelen aan je Azure subscription. Je kunt dan heel eenvoudig een development omgeving activeren. Of het nu gaat om een BizTalk, SharePoint of NAV development omgeving, met een paar klikken kun je aan de slag.

msdn1

msdn2

Je ziet het al in de Visual studio keuzes die er zijn, maar het is nu ook mogelijk om een Client OS omgeving te starten. Op die manier kun je Azure voor echte Dev/Test scenario’s gebruiken.

msdn3

Wil je alvast kennis maken met de volgende versie van Visual Studio. Gewoon even een standaard VM met VS14 configureren en 15 minuten later weet jij wat VS14 straks gaat bieden.

vs14

Zoals je ziet gaan de Azure ontwikkelingen erg snel en staan ze niet stil. Het platform evolueert naar een echte omgeving voor Dev/Test scenario’s.

Scheduled Jobs Azure Websites

Heb je op je Microsoft Azure Website een scheduled job nodig? Bijvoorbeeld om bestanden naar een andere plek te kopieren of iets uit te voeren op de achtergrond? Tot voor kort werd je dan altijd door Azure specialisten door verwezen naar het gebruik van Cloud Services. Daar kun je deze in een aparte thread maken en laten lopen.

25-5-2014 15-44-16

Maar nu kun je ook webjobs maken op Microsoft Azure websites. Deze kun je dan laten lopen volgens een schedule. Dat scheelt extra development.

Azure Websites staging

Een ontwikkeltraject van software bestaat altijd uit een stuk design, bouw, testen en deployment. Of je dit nu agile of niet doet, de stappen komen altijd terug. Voor de verschillende onderdelen heb je ook verschillende omgevingen. Bouwen doe je op een development omgeving en vaak lokaal. Testen doe je op een Testomgeving en deze staat meestal centraal. Op Productie wordt alleen maar gedeployed en hebben de vorige stappen gevalideerd dat de software werkt en goed is.

Soms bevat een deployments (productie of test maakt niet zo uit) procesjes om de omgeving voor te verwarmen. Bijvoorbeeld de eerste call naar een website duurt meestal iets langer op een vers geinstalleerde omgeving. Niet zo gek er moeten allerlei zaken gecached worden en opgestart. Maar als je een nieuwe versie gepubliceerd hebt, dan merken je productie gebruikers deze vertraging. Niet fijn en zeker in onze snelle maatschappij waar we bijna niet meer willen wachten niet handig.

Dan zou het handig zijn om alvast een deployment te doen, de boel op te warmen en deze dan beschikbaar te stellen aan je gebruikers.

Bij Microsoft Azure Cloud Services deden we dat door de staging omgeving gebruiken. Op deze Staging omgeving kon je dan alles even aanraken en zorgen dat de eerste vertraging uit de lucht is. Daarna kon je met een Swap Staging naar Productie brengen..

25-5-2014 16-00-19

Bij Microsoft Azure websites was de Staging omgeving er niet. Maar sinds kort bestaat dit ook voor de Websites. Scherm technisch ziet het er iets anders uit, maar werkt ongeveer gelijk. De Staging omgeving is er niet standaard en moet je zelf toevoegen.

25-5-2014 15-54-30

 25-5-2014 15-55-47

En wil je Staging Productie maken, dan gaat het net zo eenvoudig.

 25-5-2014 15-57-38 

Happy Websites!