Tweakers maakt gebruik van cookies, onder andere om de website te analyseren, het gebruiksgemak te vergroten en advertenties te tonen. Door gebruik te maken van deze website, of door op 'Ga verder' te klikken, geef je toestemming voor het gebruik van cookies. Je kunt ook een cookievrije versie van de website bezoeken met minder functionaliteit. Wil je meer informatie over cookies en hoe ze worden gebruikt, bekijk dan ons cookiebeleid.

Meer informatie

Door , , reacties: 15, views: 11.263 •

Microsoft heeft zijn Windows Azure-sdk van een update voorzien. Ook heeft de softwaregigant een hpc-scheduler uitgebracht waarmee high performance computing-applicaties aan Microsofts clouddienst kunnen worden gekoppeld.

In de Windows Azure Tools for Visual Studio 2010 zijn volgens Microsoft diverse verbeteringen doorgevoerd om de koppeling met Azure voor developers eenvoudiger te maken. Zo bevat de vernieuwde sdk diverse wizards om een in Visual Studio ontwikkelde applicatie te laten draaien op een virtuele machine binnen Microsofts cloudplatform. Ook zou het eenvoudiger moeten zijn om de benodigde Azure-accounts te beheren en meer inzicht te krijgen in draaiende processen in de clouddienst.

Microsoft heeft ook de 'Windows Azure HPC Scheduler sdk For .Net' uitgebracht. Deze ontwikkelkit bestaat uit diverse modules om parallel draaiende en rekenintensieve applicaties te draaien op Windows Azure. Ten slotte zijn de Azure Libraries voor .Net geüpdatet naar versie 1.6. Daarbij is onder andere de Windows Azure Emulator verbeterd.

Reacties (15)

Microsoft Azure werkt echt mooi. Je maakt gewoon je applicatie in .NET met een paar kleine aanpassingen en hup je publiceert het in de cloud. Je schijnt tegenwoordig ook PHP in Azure te kunnen doen, maar dat heb ik (nog) niet gedaan.

[Reactie gewijzigd door Xenan op 15 november 2011 14:15]

Uiteraard is het zo dat je de applicatie gewoon in .NET kan maken en dat je deze met enkele aanpassingen in de cloud kunt zetten. De insteek dient echter te zijn dat je de .NET applicatie specifiek voor de cloud ontwikkelt. In de cloud dien je met andere dingen rekening te houden dan op je desktop machines. Aangezien het bij Azure voornamelijk om een pay per use opzet gaat is het van belang om hier vanaf het begin al rekening mee te houden. Gebruik de tools die de SDK en de cloud leveren zo efficient mogelijk en maak niet een standaard .NET applicatie die je wel even omzet naar een cloud applicatie.
Web applicaties leven over het algemeen zo kort voor de meeste bedrijven dat dit niet zo heel veel uitmaakt.

Over een paar jaar willen ze (die bedrijven) de tools wel weer veranderen en dan kun je het wel weer ergens anders naartoe poorten.
En als je het bij Google doet zit je vast aan...
En als je het bij Amazon doet zit je vast aan...
En als je het bij ... doet zit je vast aan...

Dus wat is de toegevoegde waarde van je opmerking?
Is het geen nadeel dat je nooit een server desktop hebt waar je beheer kan uitvoeren?
Als je net even wat anders wil dan standaard is?
Dat je geen beheer hebt (hoeft te doen), is juist een voordeel.
Maar je kan ook een complete VM in Azure huren. Daar kan je dan gewoon met remote desktop bij als je dat graag wilt.
Ja, Azure heeft potentie en ja je krijgt in de Cloud zeker in meer of mindere mate een vendor-lock-in

Ik vraag me af of ik Azure applicaties in de cloud zou kunnen testen maar toch on-premise in een productieomgeving kan draaien.

Wat ik namelijk begrepen heb is dat je een cloud variant van je applicatie bouwt. Dus je moet in het begin van je softwareontwikkeling kiezen voor in de Cloud draaien of niet.

Iemand hands-on ervaring met deze materie..?
Wij gebruiken .NET en Silverlight. Daardoor hebben we al een vendor-lock-in, zo je wilt. Vroeger hosten we onze spullen in een "regulier" datacenter. Nu hosten we diezelfde spullen in Azure. Wat mij betreft geen extra nadeel. En als het moet kunnen we de hele handel ook zo weer terug verhuizen naar een regulier datacenter. (Al zou ik niet weten waarom we dat zouden willen.)

Overigens hebben wij geen Cloud variant van de software. We hebben ook een testomgeving op eigen servers en sommige klanten willen het spul lokaal draaien. Kan allemaal. Azure is gewoon een extra manier voor deployment. Er zit een extra projectje in je Visual Studio solution.
Zeker wat hands-on ervaring, we zijn de grootste azure klant in west-europa.

Vendor lock-in heeft voor- en nadelen, zoals elke keuze voor een platform. In het geval van Microsoft met Azure heb je als enige cloud oplossing de beschikking over een totaal integrale oplossing voor ontwikkeling, test en deployment naar een cloud platform. Dat alles wordt dan ook nog van uitstekende support voorzien.

Server desktop is gewoon beschikbaar, je kunt simpel een remote desktop starten naar alle machines. Eigen VM's deployen is ook geen enkel probleem, je kunt dus alles er draaien wat je maar zou willen.

In principe valt deze vender-lock-in dus nog wel mee, als je wilt kun je gewoon een WAMP server draaien bijvoorbeeld.
Naar tweakers met hands-on ervaring vragen ... is een beetje open deur intrappen ;)

Bedankt voor jullie reactie,

Bij ons bedrijf (geen MKB) wil men nog niet meteen met productie app-servers de Cloud in.
Van databases maar te zwijgen.

En met testomgevingen in Azure kan de organisatie wel ervaren hoe het een en ander werkt wat betreft latency en beschikbaarheid, traffic en noem maar op.

De vraag is of het dus zinvol/mogelijk is om de op Azure ontwikkelde en geteste applicatie op een in-house server te draaien.

Ik heb wel vertrouwen in MS Azure maar bij sommige organisaties moet je nu eenmaal "step by step" gaan.
Ik snap je punt niet helemaal. Zoals ik bij m'n vorige reply ook aangaf, is wat jij wilt dus al wat wij doen, maar dan andersom. Wij hebben 1 oplossing, Visual Studio solution. Wij deployen naar een interne testomgeving, die dus niet in Azure draait en wij dyployen, vanuit dezelfde solution, naar Azure, waar onze acceptatie- en productieomgevingen draaien.

Ik zou zeggen, neem een Azure test account en ga er gewoon mee aan de slag. Bestaande oplossingen moet je redelijk eenvoudig naar Azure kunnen brengen. Het is ons ook gelukt... ;)
Maar dan draai je lokaal wel in een Azure runtime....

Terug naar een lokale oplossing is niet echt een probleem zolang je geen azure functionaliteit gebruikt zoals de table-storage, servicebus, queues, etc. Zodra je dat wel gaat doen krijg je een afhankelijkheid van Azure, en als je dan weer lokaal wilt draaien zul je moeten ombouwen of blijven communiceren met de azure services die je hebt gebruikt. Hybride oplossingen waarbij een klein deel van de functionaliteit in Azure draaien en communicatie bestaat tussen on-premises applicaties en cloud-services zijn erg goed mogelijk, ook door de firewall heen...
Okay Franckey,

Inderdaad zoals jij zegt, zou het ook andersom moeten kunnen.

We zijn ook van plan met een test account een proof of concept te gaan doen.

Thx.

Op dit item kan niet meer gereageerd worden.



Populair: Vliegtuig Tablets Luchtvaart Samsung Crash Smartphones Microsoft Apple Games Rusland

© 1998 - 2014 Tweakers.net B.V. onderdeel van De Persgroep, ook uitgever van Computable.nl, Autotrack.nl en Carsom.nl Hosting door True

Beste nieuwssite en prijsvergelijker van het jaar 2013