Hyper-V Server: Tatsächlichen freien Speicher der VMs auswerten

Wenn man in einer Hyper-V VM einen Blick auf den belegten bzw. freien RAM wirft, dann wird man häufig feststellen, dass nicht mehr viel übrig ist – und zwar dann, wenn man “Dynamic Memory”, den “Dynamischen Arbeitsspeicher” aktiviert hat. Dieser sorgt dafür, dass eine VM die Menge an Arbeitsspeicher bekommt, die sie aktuell benötigt – zumindest, solange noch Speicher frei ist und sich die VM in den vom Admin gesteckten Grenzen bewegt. So kann man seit dem Windows Server 2012 bzw. seit Hyper-V 3.0 drei verschiedene Werte konfigurieren:

DynMem0

Es lässt sich neben dem Startwert (Wieviel RAM bekommt die VM, wenn sie eingeschaltet wird?) weiterhin festlegen, wieviel die VM mindestens haben muss (Sie kann nie weniger haben, als hier festgelegt ist) und welche Menge ihr maximal zur Verfügung stehen könnte (Vorausgesetzt, es ist genügend RAM vorhanden; hier lässt sich auch ein Wert festlegen, der über dem insgesamt vorhandenen RAM liegt).

Bei Bedarf kann der “Minimale RAM” auch unter dem “Startwert” liegen – dies ist vor allem dann sinnvoll, wenn die VM während des Starts und der Anfangszeit nach dem Boot viel Speicher benötigt, um z.B. Dienste und Anwendungen zu starten, dann im Alltagsbetrieb aber mit weniger auskommt.

Nehmen wir nun an, eine VM hat folgende Konfiguration:

  • Start: 2GB
  • Min: 512MB
  • Max: 3GB

Nun wird sie also beim Einschalten zunächst 2GB bekommen, nach dem erfolgreichen Start ihres Betriebssystems den tatsächlichen RAM-Bedarf an Hyper-V melden und Hyper-V weist der VM dann diesen Bedarf plus einen Sicherheitsaufschlag (den “Arbeitsspeicherpuffer”) zu. Dieser ist nötig, damit die VM nicht jedes weitere benötigte Megabyte speicher einzeln anfordern muss, sondern dies immer “paketweise” tun kann.

Benötigt die VM nun mehr, dann bekommt sie mehr – solange, bis entweder das Maximum der VM-Konfiguration erreicht oder der RAM des Host-Systems voll ist. Einem System im laufenden Betrieb mehr RAM zuzuweisen ist nicht so kompliziert und ging bereits lange vor dem Virtualisierungszeitalter (ja, da musste man dann noch echte Speicherriegel in den Server stecken!).

Spannender wird der Vorgang, einer VM Speicher wegzunehmen, z.B. wenn sie eben nach dem Starten weniger Speicher benötigt, als im Startwert festgelegt. Wirklich Speicher “wegnehmen” kann man nicht. Dies wird durch eine Technik namens “Balooning” gelöst. Wenn der VM nun z.B. 512MB RAM weggenommen werden sollen, dann wird stattdessen in der VM (bzw. in deren Speicherbereich) eine “Ballon aufgeblasen”, der diese 512MB RAM belegt – die VM glaubt also, der Speicher wäre weiterhin vorhanden, aber aktuell belegt. Der Hypervisor “weiss” nun, dass er diesen RAM anderweitig vergeben kann, da er ja nicht wirklich belegt ist. Soll die VM wieder mehr Speicher bekommen, wird der Ballon stückweise kleiner gemacht, bis er verschwindet.

DynMem1

(In der Abbildung sehen wir eine VM, die nach dem Start, der mit 2GB RAM durchgeführt wurde,
nur noch 661MB benötigt und inkl. Aufschlag 788MB RAM zugewiesen bekommen hat)

Soweit die Technik, die in der Praxis sehr gut funktioniert. Jedoch hat sie einen Haken: Die VM im obigen Beispiel, welche nach dem erfolgreichen Start einen RAM-Bedarf von bspw. 661MB an Hyper-V meldet und 20% “Aufschlag” bekommt, soll nun 788MB RAM zugewiesen bekommen (Also 1260MB weniger als beim Start). In der Realisierung sieht sie weiterhin ihre 2GB – davon aber einmal die 1260MB Differenz (den “Ballon”) plus den tatsächlichen RAM-Bedarf (also 661MB) belegt. In der Konsequenz sind als (z.B. im TaskManager) 1921MB (1,87GB) belegt – von 2048MB insgesamt – also nur noch ca. 6% frei!

DynMem2 Der Taskmanager innerhalb der VM zeigt etwa zur selben Zeit, zu der der vorherige Screenshot erzeugt wurde, einen RAM-Verbrauch von 1,8GB und freien Speicher in Höhe von 204MB. Das hier etwas mehr RAM frei ist als bei der Rechnung oben liegt daran, dass die VM etwas mehr Speicherbedarf an Hyper-V meldet als tatsächlich bereits belegt sind.

Eine entsprechende Serverüberwachung, die es nicht besser weiss, meldet nun also, dass der RAM zu Neige geht. Das Fatale dabei ist aber, dass wenn man dieser VM z.B. einen größeren Startwert gibt, bspw. 3GB, dann wird die Rechnung noch schlimmer:

  • 3072MB beim Start
  • Nach dem Start 661MB belegt, 788MB zugewiesen
  • Ballon iHv 2284MB
  • Als belegt zu sehender Speicher: 2945MB (Ballon + 661MB tatsächlicher Bedarf)
  • Übrig bleiben dann 127MB (Der Puffer) – was hier nur noch etwa 4% (statt 6% bei 2GB Start-RAM) entspricht!

Dies geschieht, obwohl die VM augenscheinlich mehr RAM hat (oder zumindest haben KÖNNTE) und immer noch den selben Bedarf (von 661MB) hat! Hier darf man sich also nicht täuschen lassen.

Als Lösung könnte man den RAM-Verbrauch der VMs mittels PowerShell analysieren und dann bspw. bei Unterschreitung eines Schwellwertes bzgl. des freien RAMs alamieren. Ein solcher Aufruf, der den freien RAM aller VMs in Prozenten zeigt, könnte dabei so aussehen:

DynMem3

Zum Kopieren:

Get-VM | Where DynamicMemoryEnabled | Where State -eq "Running"
    Format-Table Name,
                 @{n='Benötigt(GB)';e={$_.MemoryDemand/1GB};FormatString='N3'},
                 @{n='Zugewiesen(GB)';e={$_.MemoryAssigned/1GB};FormatString='N3'},
                 @{n='Frei/Aktuell (%)';e={100-($_.MemoryDemand/$_.MemoryAssigned*100)};FormatString='N2'},
                 @{n='Frei/Max (%)';e={100-($_.MemoryDemand/$_.MemoryMaximum*100)};FormatString='N2'} -AutoSize

Die Spalte “Frei/Aktuell” liefert einen Wert, wieviel Speicher bezogen auf den aktuell zugewiesenen Wert frei ist (dieser Wert sollte sich in etwa in der Größe des Speicherpuffers bewegen, solange genügend RAM verfügbar ist und die VM mehr RAM als das Minimum benötigt).

Die letzte Spalte “Frei/Max” zeigt, wieviel Speicher bezogen auf den maximal möglichen RAM der VM noch frei ist. Erst wenn dieser Wert zu niedrig wird (bspw. unter 20% fällt) besteht Bedarf, der VM mehr RAM zuzuweisen.

Insgesamt sehen dann die Werte in der PowerShell, dem Taskmanager der VM und dem Hyper-V Manager so aus:

DynMem4 (Anklicken zum Vergrößern)

Hyper-V VMs werden angehalten, wenn der Speicherplatz knapp wird

Auch wenn die Tatsache selbst nicht neu ist möchte ich den folgenden Fakt etwas genauer beleuchten, da immer mehr Unternehmen Hyper-V für produktive Virtualisierungszwecke verwenden.

Eine Hyper-V VM wird vom System angehalten, wenn der Speicherplatz auf dem Laufwerk, welches von der VM für die virtuelle Festplatte verwendet wird, knapp wird. Dies geschieht in erster Linie nur dann, wenn die VM mit einer dynamisch wachsenden VHD oder VHDX arbeitet. Auf Grund eines Bugs waren aber bei früheren Hyper-V Versionen (2008 / 2008 R2) auch VMs mit statischen VHDs betroffen.

Das Anhalten der VM geschieht, um einen Absturz des Gastbetriebssystemes auf Grund von Speicherplatzmangel zu vermeiden (die VM “glaubt” noch reichlich Speicherplatz zu haben und versucht, diesen zu belegen, u.a. auch für die Auslagerungsdatei, in Wahrheit ist der Speicherplatz auf dem Datenträger bereits fast vollständig belegt).

Das Anhalten der VM wird dann mit dem Status “Angehalten – Kritisch” markiert (“Paused – Critical” auf englischen Systemen):

HVFreeSpace01

Insbesondere wenn viele VMs mit dynamisch wachsenden VHDs das selbe Plattensystem nutzen ist das Risiko, dass dies geschieht, relativ groß.

Glücklicherweise kündigt sich das bereits vorab an:

HVFreeSpace03

Im Ereignisprotokoll wird unterhalb von “Microsoft / Windows / Hyper-V-VMMS / Admin” ein Ereignis 16050 protokolliert, welches auf den zur Neige gehenden Speicherplatz hinweist.

Das Problem dabei: Dies geschieht erst, wenn der freie Speicherplatz unter 2GB fällt und benötigt auch einige Sekunden nach dem diese Grenze erreicht wurde, bis der Eintrag protokolliert wird.

Wenn der Speicherplatz dann noch knapper wird und eine oder mehrere VMs angehalten wurden wir dies ebenfalls vermerkt:

HVFreeSpace04

Hier wird im selben Protokoll das Ereignis 16060 vermerkt. Dieses weist nun also auch auf die Tatsache hin, dass eine VM angehalten wurde. Dies geschieht allerdings erst, wenn nur noch 200MB oder weniger zur Verfügung stehen!

HVFreeSpace02

(Hinweis: Die Screenshots stammen von einem Testsystem; Es wird ausdrücklich nicht empfohlen, Hyper-V Daten auf dem Betriebssystem-Laufwerk abzulegen!)

Wenn man mit Snapshots / Checkpoints arbeitet, dann sollte man noch beachten, dass die Daten nach dem Snapshot evtl. auf einem anderen Laufwerk abgelegt werden als vorher!

Mittels “Aufgabe an dieses Ereignis anfügen…” kann man z.B. ein Skript oder eine E-Mail auslösen, wenn die betreffenden Ereignisse eintreten:

HVFreeSpace05

(Dazu muss dann das betreffende Ereignis mittels Rechtsklick angeklickt werden, im Screenshot habe ich ein beliebiges anderes Ereignis gewählt)

Einige Neuerungen im Windows Server 2015 (Technical Preview) bezüglich Hyper-V

In der aktuell verfügbaren Technical Preview auf den künftigen Windows Server (aktuell unter verschiedenen Namen bekannt, Windows Server 10, Windows Server 2015, Threshold, …) sind bereits einige Neuerungen in Hyper-V erkennbar. Einige davon möchte ich hier kurz ansprechen:

Production Checkpoints vs. Standard Checkpoints

Neben den bisherigen “regulären” Snapshots/Checkpoints (Im Windows Server 2015 als “Standard Checkpoints” bezeichnet) gibt es nun “Production Checkpoints”, die explizit für Maschinen im Produktiv-Betrieb gedacht sind.

Checkpoints1

Hierbei wird mit Hilfe der Datensicherungstechniken des Gastbetriebssystems (bei Windows via VSS, bei Linux über den Systempuffer) ein Snapshot erzeugt, der auf Konsistenz ausgelegt ist. Sollte ein solcher Snapshot nicht möglich sein, wird auf einen regulären Snapshot ausgewichen (bei dem eben keine Konsistenz aller Daten gegeben ist). Wurde der Production Snapshot erfolgreich erzeugt, wird eine entsprechende Meldung ausgegeben:

Checkpoints2

Für den Production Snapshot muss die Windows Server-Sicherung im Gast-System NICHT installiert sein:

Checkpoints3

Laufende Anwendungen werden bei dieser Snapshot-Technik nicht berücksichtigt. Nach einem Revert (Zurücksetzen auf einen Snapshot) muss die VM neu gestartet werden, Anwendungen, die zum Zeitpunkt des Snapshots liefen, gehen dadurch verloren. Allerdings verhält sich das Gast-Betriebssystem so wie nach einem regulären, sauberen Shutdown:

Checkpoints4

Hyper-V Manager Remote Management

Bereits frühere Versionen des Hyper-V Managers haben es ermöglicht, von einem System aus mehrere Hosts unter einer GUI zu verwalten. Dabei fand das Login auf den Remote-Servern immer mit den Credentials des interaktiv angemeldeten Benutzers statt. Der neue Hyper-V-Manager macht es jetzt möglich, alternative Login-Daten anzugeben:

HyperV1

Damit wird es möglich, Maschinen in fremden Domänen, in Workgroups oder in der DMZ anzusprechen.

Windows Server 2012 R2: Einrichten eines Failover-Clusters am Beispiel Hyper-V

Ein Failover-Cluster ist eine gute Sache: Er sorgt für Hochverfügbarkeit! Damit lassen sich diverse Dienste geclustert betreiben. Mehrere Server teilen sich eine Aufgabe und die dazugehörige Last. Fällt nun einer der beteiligten sogenannten “Knoten” aus, so übernehmen die verbliebenen die Aufgabe sofort automatisch. Damit lässt sich beispielsweise auch Hyper-V bzw. die darauf laufenden virtuellen Maschinen gegen einen Ausfall absichern.

Für eine Minimal-Konfiguration werden benötigt:

  • Ein Domänencontroller
  • Zwei weitere Server als Mitglied der Domäne
  • Zentraler Speicher

Für den zentralen Speicher kämen die beiden SAN-Technologien iSCSI und FiberChannel in Frage. Optional geht seit Server 2012 auch SMB3.0 (“Scale Out File Server”). Für eine Testumgebung ist iSCSI sehr gut geeignet. Wie man ein iSCSI-Target einrichtet und den dazugehörigen Initiator nutzt habe ich in einem meiner letzten Blogartikel beschrieben (Windows Server 2012 R2: iSCSI Target und Initiator einrichten).

Der Domänencontroller sowie die beiden Member-Server laufen unter Windows Server 2012 R2.

Es werden 2 iSCSI-Targets benötigt, eines mit min. 512MB Speicher, das zweite mit ausreichend Speicher für die vorgesehenen VMs und deren VHD(X)-Dateien, in meinem Fall 40GB. Die beiden Targets müssen bereits auf beiden Knoten eingebunden sein, die beiden Datenträger online geschaltet worden sein, initialisiert und formatiert (ohne Laufwerksbuchstaben).

Weiterhin muss das Netzwerk sauber konfiguriert sein. Für eine Testumgebung reicht es, wenn die beiden Hosts über genau eine Netzwerkverbindung verfügen. Dort muss das selbe Subnetz eingerichtet sein, ebenso ein passender DNS-Server und ein Gateway. Für Produktivzwecke empfehlen sich deutlich mehr Netzwerkverbindungen, z.B. eine dedizierte für den Heartbeat (Link zwischen den Knoten), eine für die Anbindung an das Storage, eine für die Verwaltung, eine für die Anbindung an das reguläre Netzwerk und so weiter und so fort.

Als nächstes muss auf allen künftigen Knoten das Feature “Failoverclustering” installiert werden. Dazu werden auch die Verwaltungstools angeboten, die zumindest auf einem System installiert sein müssen, um den Cluster einrichten zu können:

failover1

failover2

failover3

Wenn die Installation auf beiden/allen künftigen Knoten abgeschlossen ist kann der “Failovercluster-Manager” gestartet werden, z.B. über “Tools” im Servermanager:

failover4

Dort wird durch einen Rechtsklick auf das Wort “Failovercluster-Manager” im Baum links mittels “Cluster erstellen…” der Prozess begonnen:

failover5

In den ersten Schritten sind die künftigen Knoten auszuwählen:

failover6 failover7
failover8 failover9
failover10  

Danach folgt eine Abfrage bezüglich des “Konfigurationsvalidierungstests”. Dabei werden die beteiligten Server “auf Herz und Nieren geprüft”. Dieser Test dauert ca. 10 Minuten. Man könnte ihn abschalten – verzichtet dann auber auf den Support durch Microsoft und wertvoll Hinweise zur Konfiguration. Nicht zuletzt kann der Test einem auch Fehler aufzeigen, die man bei der Vorbereitung übersehen hat. Ich würde ihn also immer laufen lassen…

failover11 failover16
failover13 failover14
failover15 failover16

Am Ende des Tests wird einem das Ergebnis angeboten (“Bericht anzeigen”):

failover17

In diesem Fall liegt nur eine Warnung vor: Es gibt nur eine Netzwerkverbindung!

Nun muss noch ein Name für den Cluster sowie eine entsprechende IP-Adresse bestimmt werden. Außerdem kann man auswählen, dass der gesamte verfügbare Speicher dem Cluster hinzugefügt werden soll:

failover18 failover19
failover20 failover21

Danach beginnt die eigentliche Bildung des Clusters. Ist diese abgeschlossen, kann die Clusterkonfiguration verändert werden bzw. der Cluster mit Rollen ausgestattet werden. Dabei ist zum einen die Netzwerkkonfiguration zu prüfen: Wenn es einen dedizierten Link zwischen den Hosts geben soll, so ist bei dieser Netzwerkkonfiguration der Haken “Clients das Herstellen einer Verbindung…” zu entfernen. Weiterhin muss das zweite iSCSI-Target noch als “Cluster Shared Volume” (CSV) bzw. al “freigegebenes Clutservolume” hinzugefügt werden. Das sorgt dafür, dass dieses “Laufwerk” auf allen Clutserknoten unter C:\ClusterStorage eingebunden wird und dort genutzt werden kann (z.B. für die VMs und VHDs)

failover22

failover23

Abschließend können nun VMs im Cluster erzeugt werden. Dabei ist darauf zu achten, das alle relevanten Daten unter C:\ClusterStorage liegen!

failover24

failover25

failover26

failover27

Wenn die VM fertig konfiguriert ist und läuft, dann kann man ganz einfach die Funktionsfähigkeit des Clusters testen und einen einfachen Ausfall simulieren: Man zieht einfach das Netzwerkkabel aus dem Host heraus, auf dem die VM aktuell ausgeführt wird. Dann sollte sie in kurzer Zeit auf dem verbliebenen Host neu gestartet werden und dann kurz darauf wieder regulär zur Verfügung stehen!

Weitere Informationen zum Thema Windows Server 2012 R2 finden Sie auch unter http://www.ppedv.de/R2 

Hyper-V 4.0: Live Größenänderung von virtuellen Festplatten

Eine der wirklich praktischen Neuerungen im Hyper-V 4.0 unter Windows Server 2012 R2 ist die Möglichkeit, eine virtuelle Festplatte im laufenden Betrieb zu vergrößern oder zu verkleinern. Dies funktioniert, wenn:

  • Die virtuelle Festplatte das VHDX-Format verwendet und
  • Am SCSI-Controller angebunden ist

Wenn man eine virtuelle Maschine der 2.Generation (Gen2-VM) verwendet, stellt sich die Frage nach der zweiten Bedingung nicht, da hier ja ohnehin nur noch SCSI zum Einsatz kommt.

In der Abbildung ist eine Muster-VM zu sehen, die neben ihrer OS-Platte noch über eine zweite Platte (VHDX, SCSI-Controller) mit 30GB verfügt:

vhdxresize1

vhdxresize2

vhdxresize3

Nun kann diese VHDX-Festplatte im laufenden Betrieb vergrößert werden. Dazu ist nur ein Klick auf “Bearbeiten” nötig:

vhdxresize4

Der Assistent führt einen dann durch die notwendigen Schritte, bei dem schließlich auch die gewünschte neue Größe angegeben wird: (Klick auf Bild für Vergrößerung)

 

vhdxresize5 vhdxresize6
vhdxresize7 vhdxresize8

 

Am Ende steht dann eine Festplatte mit mehr Speicher zur Verfügung, bei der anschließend noch die Partition erweitert werden muss:

vhdxresize9

PS: Die VHDX lässt sich auch verkleinern, allerdings nur, wenn die Partition im Inneren kleiner ist, als der Datenträger...

Weitere Informationen: http://technet.microsoft.com/en-us/library/dn282286.aspx

Training, Schulung, März Aktion

Month List

ppedv Team Blog | BYOD is dead

BYOD is dead

ICONIA_W3Ausgestattet mit zwei Tablets (Acer W3 und Surface Pro als Give Away auf der BUILD konferenz), einem Smart Phone und einem Convertible Notebook kommt man zur Entscheidung, nicht der Packesel für Elektronik sein zu wollen. Auch wenn's einzeln immer weniger wiegt, wird man sich entscheiden müssen- irgendwas muss weg.

Und hier kommt die schlechte Nachricht #1

das Tablet ist Tod.

Zumindest im Formfaktor und Funktionsumfang wie das Apple mit dem iPad definiert hat. Zu groß, zu schwer und kann zu wenig. Folglich wird in wenigen Jahren verschwunden sein. Wer heute noch in Software für das iPad investiert, kann dies auch mit Dampfmaschinen tun. Ab und zu braucht man so was, aber meistens nicht.

Abgelöst wird das Tablet durch den 7” Mini Formfaktor. Ich hatte damals ein iPad 1 und ein Kindle. Das Kindle passt in eine größere Hosentasche und das iPad… funktioniert ganz gut auf der Couch. Wenn man leise ansetzte, die Studien von Gartner und Co in Zweifel zu ziehen, konnte man sich schnell in mitten eines Shitstorms finden. Ich hatte auch Zweifel an meiner eigenen Meinung, schließlich wurden 100 Millionen Geräte verkauft und soviel Kunden können nicht irren. Doch! - wenn sie hormongesteuert ihrer angebeteten hinterher hecheln. Heute ist das IPad aus der Öffentlichkeit weitestgehend verschwunden. Ersetzt durch Smartphone und Notebook.

Damit sind wir gleich bei einem anderen Hype Irrung der IT. Die Consumerization of IT. Hab ich immer so verstanden, das Geschäftskunden jetzt egal sind, man als Hersteller ein möglichst strammes Korsett anzieht und die Endkunden spätestens alle Zwei Jahre (oder bei Displaybruch auch vorher) sich in die Schlange vorm Apple Store stellen, viel Geld ausgeben um damit seinem Arbeitgeber zu dienen.

Stimmt nicht. Für Firmen sind selbst mitgebrachte Geräte der Sicherheitssupergau und unglaublich teuer zu warten. Die Besitzer merken vom ständigen rumtragen wird das Zeugs auch nicht besser (Stichwort Displaybruch). Ganz nebenbei trägt man ja quasi nur mehr sein Smartphone mit sich rum. Das nun geschrumpfte Tablet wird nahezu ausschließlich in Reichweite des heimischen Wifi Access Points benutzt. Und da hat man auch mit perfekter Work Live Balance selten Arbeit im Kopf oder schreibt an seiner Dissertation. Die neuen Tablet dienen zum konsumieren. Und insofern kann man consumerization auch deuten, aber auch nicht mehr.

Der eindeutige Sieger ist das Smartphone. Dieses betrachtet der Benutzer als seine persönliche Sphäre zum konsumieren und kommunizieren. Auf keinen Fall will man sich vom Administrator der Company dreinreden lassen, welche Apps da drauf kommen und welche nicht. Welche Apps installieren sich die Menschen? Spiele, Kommunikation und Konsumation. APP Entwickler werden ihre Aktivitäten immer stärker danach richten. Firmen werden ihren Mitarbeitern eher einfache Webfrontends anbieten für Dienste innerhalb des Unternehmens. Der Neue Trend wird als Bring Your Own Phone (BYOP).

Nokia_Lumia_800_02Wie geht's mit Smartphones weiter, was wird die führend Plattform? Ziemlich egal. Die Telefon sehen heute wie rechteckige bunte Badfliesen aus. Obs 1 mm dünner ist oder nicht ist egal. Selbst Ecken oder abgerundet- egal. Betriebssystem egal. 1 Million Apps im Store, werden irgendwann alle haben- egal. Alle werden schärfer, schneller und bessere Fotos machen (ja Fotos ist wichtig)- auch egal. Die Provider wie Telekom oder Vodafone haben ein riesen Interesse an diesen Kunden, weil man damit zuverlässig 50 € pro Monat Einnahmen kalkulieren kann ( viel mehr als meine Telefonrechnung vor 20 Jahren war) und schmeißen jedes Device für 1 € in den Markt – auch egal. Damit werden die Preise allgemein eher nach unten gehen. Hersteller können sich quasi nicht mehr unterscheiden. Innovationen sind nicht in Sicht. Dazu eine Vision von mir. Das Come Back des Klapp Handys mit zweigeteilten Display. Wenn dem letzten Smartphone Users unzerbrechliches Gorilla Display scharfkantige Risse zeigt, werden auch sie erkennen, das Telefone beim runterfallen kaputt gehen (Tablets übrigens auch- nur ist das Wohnzimmer selten asphaltiert).

html5Ich fass mal zusammen: Tablet Tod, BYOD Tod, Handys immer billiger, Apps naja, HTML 5. Oh da war er noch der HTML 5 Hype. Ist besser als HTML 4 aber einfach zu unflexibel, zu Device spezifisch und bietet zu wenig Funktion. Summa summarum, hat es seinen Anwendungsbereich, wird aber krampfhaft überschätzt. Meine Einschätzung Come Back von C++. Das Tooling ist viel besser, die Sprache in der Zwischenzeit modern und man kann's kompilieren. Ich bin übrigens auch ganz zuversichtlich für ASP.NET. Das frickel yet another Frameworks Zeug ist einen Hauch zu agil um Unternehmenssoftware unter ROI Gesichtspunkten zu planen.

Der Notebook wird der nächste Come Back Shooting Star. Mit unterschiedlichsten Formfaktoren, Gewicht Größe Laufzeit. In jedem Fall viel leichter, mit Tastatur (die eine gewisse Stabilität bietet) mit Touch und allerlei sonderbaren Dingen wie Scanner oder NFC. Apple ist mit seinem OS gut dabei, aber Microsoft kann (auch dank der vielen Formfaktoren und Partner) wieder Boden gutmachen. Windows 8.1 ist ein sehr guter Schritt in diese Richtung. Praktisch alle meine Kritikpunkte wurden erhört und gelöst. Auf der BUILD Konferenz kam auch nicht mehr der Eindruck rüber, das man nun alles auf Tablet optimieren muss oder gar JavaScript dafür braucht. Einzig der Zwang zum AppStore stört mich noch erheblich. Die Softwarehersteller sind groß geworden indem sie für die Microsoft Plattform ohne Zwänge die exakt passende Lösung für Ihren Kunden gebaut haben. Wobei einige den Store Zwang auch gut finden. Ich finde er muss weg. Hier verliert Microsoft kaum Umsatz, schlägt aber Apple auf einem Feld in dem  diese wegen der wirtschaftlichen Bedeutung nicht umkehren können.

Microsoft?

Was man hört und liest will Microsoft (oder Steve B?) nun eine Services und Devices Company werden. Wäre mir glatt egal, wenn sie ihre bisherigen Erfolge und Kunden nicht vergessen. Budgets werden aber vornehmlich in Projekte gesteckt, in denen man (oder Shareholder) die Zukunft sieht.  Wie Yammer. Im Azure Umfeld kommt Microsoft subjektiv ganz gut voran. Es wird auch ohne PRISM Presse, immer Kunden geben die die Daten nicht aus der Hand geben wollen. Spannend finde ich die Strategie von Adobe den Lizenzverkauf zu stoppen und nur mehr Online Abos anzubieten. So eines gab's übrigens auf der BUILD. Muss ich also mal ausprobieren.

microsoft

Ob es auf Dauer wirklich so sexy ist Hardware zu verkaufen, bzw. Margen zu haben die über 100% liegen, wage ich stark zu bezweifeln. Am Ende läuft's wie bei Sony, Panasonic oder gar Nokia… gar nicht gut. Windows ist auf einem guten Weg weiterhin das multi Platform multi Device OS zu bleiben.

Training, Schulung, März Aktion

Month List