Multi-tenant Dynamic Staging

Multi-tenant ontwikkelen plaatst je voor nieuwe uitdagingen.
Vaak zie je dat uitbreidingen en aanpassingen aangevraagd worden door een enkele klant (tenant).
Deze uitbreidingen worden aanvankelijk klantspecifiek opgezet en getest. Op enig moment zal de aanpassing dan naar staging moeten worden gepubliceerd om te worden ingezet als een beta omgeving voor die ene klant.

Natuurlijk willen we niet de klant lastig vallen met speciale beta url's waar hij zijn nieuwe product kan beta testen. Dit zal in veel gevallen ook niet mogelijk zijn om dat de tenant's afnemers vaak de url hebben geautomatiseerd of hebben gebookmarked.

Een oplossing voor dit probleem kan zijn een dynamische staging/productie omgeving.
Per tenant kan eenvoudigweg door een instelling in zijn profiel te wijzigen on the fly (dus in productie) de route worden gewijzigd van productie naar staging en visa versa.
De klant test zijn product, bij falen kan er direct terug worden geschakeld, bij succes kan de nieuwe versie van de applicatie naar productie worden gepubliceerd zodat de overige tenants ook gebruik kunnen maken van de nieuwe functionaliteit.

Een belangrijk onderdeel van deze oplossing is de 'Reversed Proxy Server'.
Kom ik later op terug.

Multi-tenant software architectuur.

Een multi-tenant (multi huurder) gebouw is een aanduiding die afkomstig is uit de vastgoed sector. Daar betreft het een bedrijfsverzamelgebouw bestaande uit bedrijfsunits waarin alle basisvoorzieningen benodigd voor algemene bedrijfsvoering zoals energie, telefonie, internet, sanitair, koffieautomaten maar ook vergaderzalen en spreekkamers centraal worden gedeeld door de huurders.
Het doel is om vooral startende ondernemers scherp geprijsde professionele bedrijfshuisvesting te bieden waarbij geen of weinig startkosten zijn gemoeid. De centrale kosten zijn in het huurbedrag verwerkt.

In softwareontwikkeling zie je een zelfde trent. In de vorm van software die als een enkele applicatie is ontwikkeld en centraal op een enkele server(omgeving) draait. De software is zo ingericht dat er per gebruikersessie wordt gekeken bij welke tenant (huurder) de gebruiker is aangesloten. Vervolgens wordt er een tenant specifieke omgeving getoond.

De techniek achter dit type software noemen we multi-tenant architectuur.
Bekende voorbeelden van multi-tenant applicatie’s zijn:

• CMS systemen: Joomla, Wordpress of Dotnetnuke. 
• Blogsites: Google Blogspot, Bloggy, Wordpress. 
• Social media: Facebook, Hyves, Twitter. 

Deze applicatie’s hebben met elkaar gemeen dat je in meer of mindere mate je eigen omgeving virtueel kunt aanpassen naar je eigen wensen. Je bouwt als het ware je eigen website, echter achter de schermen deel je een enkele applicatie met andere deelnemers.
De voordelen van dit soort applicatie's voor de gebruikers zijn onder andere het flexibele en snelle opzetten van je eigen omgeving en natuurlijk ook de kosten.
De meeste multi-tenant applicatie’s bieden wel een gratis start omgeving waarin de basisfunctionaliteit wordt aangeboden.
Een ander voordeel is de schaalbaarheid en daarmee de exploitatiekosten. Aanbieders van multi-tenant applicatie’s kunnen bij succes eenvoudig de hardware uitbreiden naar meerdere of snellere servers. Er hoeft immers slechts een enkele applicatie opgeschaald te worden.
Uiteraard is er ook kritiek op deze techniek. De complexiteit van multi-tenant applicatie’s ligt in het algemeen gesproken hoger en ook de ontwikkelfase zal meer tijd in beslag nemen dan bij een traditionele applicatie. Echter dit zie ik als een nonissue. Een cloud applicatie zal niet uitgevoerd kunnen worden in een traditionele applicatie zonder een vorm van multi-tanancy.

Persoonlijk heb ik al een aantal jaren ervaring met multi-tenancy. Ik heb tal van modules geschreven voor CMS systemen en momenteel werk ik voor mijn huidige werkgever in de automotive branche voor een multi-tenant online catalogus.
Voor mij geeft deze architectuur een extra boost aan mijn motivatie omdat er nog veel ontgonnen gebied is op dit onderwerp. Daar bij geniet ik altijd weer van de verbazing van mijn opdrachtgevers als ik binnen een paar dagen een volledig nieuw ogende online catalogus kan aanbieden aan een van onze businespartners.

Url Rewriting

SEO (Search engine optimalization) is hip.
Terecht zou ik zeggen, want als Google je niet vindt dan vindt niemand je.
Als je verdieping gaat zoeken betreffende SEO dan begrijp je al snel dat de belangrijkste factor voor succes semantieke samenhang is. De url moet wat zeggen over het artikel.
Maar wat nou als je net een jaar lang bezig bent een heel stevige business applicatie op te tuigen voor intranet doeleinden en men besluit dezelfde app buiten op internet te gaan gebruiken.
Dan zijn onderstaande urls niet echt optimaal.

http://shop1.hbase.nl/default.aspx?shopid=3&merk=DAT&type=742&groupid=100

http://shop1.hbase.nl/default.aspx?shopid=11&merk=DAT&type=742&groupid=100

Geen mens die iets zinnigs over deze urls kan vertellen, laat staan een zoekmachine. Google snapt domweg niet het semantieke verband tussen url en content. Daar bij komt in dit geval ook nog dat beide urls nagenoeg gelijk zijn omdat beide sites uit het zelfde framework worden gegenereerd.
De eerste url is een catalogus voor plaatwerk voor auto's en de tweede voor olie en vloeistoffen.

Hoe lossen we dit op?
Laten we eerst de vraag stellen hoe we de urls dan wel graag willen zien.

http://plaatwerk.nl/merk/audi/type/A4/categorie/bumpers

http://vloeistoffen.nl/merk/audi/type/A4/categorie/koelvloeistof

Met deze urls is het meteen duidelijk wat we kunnen verwachten, dus kunnen we er van uit gaan dat Google het nu ook snapt.
Maar hoe lossen we dit technisch op? De gehele url structuur in de applicatie wijzigen zou een karwei van omvang zijn en hoe houden we het dan backwords compatibel?

Url Rewriting is hier het antwoord.
En de .net omgeving geeft ons goede mogelijkheden hiertoe. In een .net webapplicatie kunnen we het volgende bestand vinden:

'Global.asax'
In Global.asax kunnen we de volgende event ontsluiten:

protected void Application_BeginRequest(object sender, EventArgs e) { }

Deze event is de eerste die wordt getriggered wanneer een request wordt gedaan aan de webserver.
In deze event kunnen we de aanvragende url verkrijgen via 'Request.Url.OriginalString'.

We gaan er van uit dat onze systeembeheerder het domein plaatwerk.nl naar onze webserver heeft gelinkt.
en dat een gebruiker het volgende in de browser heeft ingetikt:

http://plaatwerk.nl/merk/audi/type/A4/categorie/bumpers.

Deze url zullen we nu moeten herschrijven naar een url die begrepen wordt door onze applicatie.

http://shop1.hbase.nl/default.aspx?shopid=3&merk=DAT&type=350&groupid=40

We zullen methodes moeten bouwen welke de volgende data verzamelen

http://plaatwerk.nl	Haal shopid uit alias tabel	Shopid=3
merk/audi	Haal autocode uit merktabel	Merk=AD
type/A4	Haal autotypecode uit autotype tabel	Type=350
categorie/bumpers	Haal subgroup code uit categorien tabel	Groupid=40

Ik vat deze methodes hier samen als : "RewriteLogicUrl(string url)"
De laatste stap die we moeten uitvoeren is om met 'Context.RewritePath()' de herschreven url in de context te plaatsen.

protected void Application_BeginRequest(object sender, EventArgs e){
  string logicUrl = Request.Url.OriginalString;
  string systemUrl = RewriteLogicUrl(logicUrl);
  Context.RewritePath(systemUrl);
} 


Thats all folks.