eBizTalk - Berichten, Unterhalten, Weiterbilden
Ob Branchendiskurs, Fachartikel oder ein Blick hinter die Unternehmenskulissen: eBizTalk ist die Plattform, die uns auffordert, unsere Leser über Events und Projekte auf dem Laufenden zu halten. Und uns gegenseitig natürlich auch.

Wasser und Licht

Veröffentlicht am 15.06.2017 von Clemens Kruse , Insights@ebizcon

Es ist Montagmorgen, ich sitze an meinem Arbeitsplatz, klappe meine Höllenmaschine von Laptop auf und Blicke gespannt zum Rascheln an der Tür. Der Chef stürmt rein, heute sieht er noch entschlossener aus als sonst. Ich gehe in Deckung.

"Student, ich habe von Deiner Bachelorarbeit geträumt! Es wird fett!" - "Jawoll, Chef!" – es ist schön hier.

Dass wir uns mit Chef und Student anreden ist ein Artefakt aus alten Tagen, da wir beide aus Firmen kommen, wo man das noch so gemacht hat.

Tatsächlich bin ich nicht von Anfang an hier. Ich begann mein duales Studium bei einem Unternehmen, dessen Name mir entfallen ist und sah mich dort bald an den Grenzen meiner Entwicklungsmöglichkeiten. Um meine Situation zu verbessern bewarb ich mich also bei der eBiz. Unter anderem. Am Ende hatte ich die Wahl zwischen Firmen in meiner Heimat Dresden (was unheimlich bequem gewesen wäre) und der totalen Blackbox - fremde Firma, fremde Stadt, wieder in eine WG ziehen (ich dachte eigentlich, aus dem Alter wäre ich raus), organisatorischer und nervlicher Stress.

Da brauchte ich nicht lange nachzudenken: Blackbox.

Das kann nun daran liegen, dass ich ein Teufelskerl bin und die Gefahr liebe. Aber eigentlich liebe ich die Gefahr nicht sonderlich. Tatsächlich gehe ich gern auf Nummer sicher, was die wichtigen Entscheidungen im Leben betrifft.

Und genau darum geht es: die wichtigen Entscheidungen im Leben. 2014 Nach meinem Ausflug in die Medieninformatik an der TU nochmal von vorn zu beginnen fällt sicherlich in diese Kategorie. Ebenso die Entscheidung, mitten im Studium den Praxispartner zu wechseln. Das sollte man nicht leichtfertig abtun.

Nach der Zusage der eBiz hatte ich innerhalb von 24 Stunden alles unter Dach und Fach. WG in Frankfurt organisiert, die Zelte in Dresden abgerissen und die Mutti um Verzeihung gebeten, dass ich mein Glück in der Welt suchen gehe, auch wenn mir ihre Nusstorte fehlen wird.

Und, habe ich es gefunden?

Mein Bauchgefühl hat mir gesagt, dass ich nach Frankfurt muss, wenn ich es ernst meine mit dem "sich entwickeln, Potenzial ausschöpfen und so" - also habe ich darauf gehört und bin jetzt seit einem Jahr Part of the Team . Ich werde jetzt immer auf mein Bauchgefühl hören.

Bei der eBiz hat man als Student alles was das Herz begehrt. Und ich rede nicht vom Kaffeevollautomaten, vom fancy Laptop oder der Xbox. Klar, das haben die dort auch. Aber die Dinge die ich eigentlich meinte, sind viel größer als das.

Für mich ist meine Firma der Nährboden auf dem ich als kleine Blume wachsen kann. Hier habe ich alles was man als Blume so braucht: Wasser, Licht und unbegrenzt Bohnenkaffee.

google_about_ebiz fb_about_ebiztwitter_about_ebizxing_about_ebiz
ebiz_consulting_expertise

Geheimnisse sichern mit Azure Key Vault

Veröffentlicht am 01.06.2017 von Alexander Müller , Azure , Security

Da IT-Sicherheit in der heutigen Zeit immer mehr an Bedeutung gewinnt, gehört das Basiswissen über kryptografische Protokolle, Verschlüsselungsalgorithmen und Hash-Funktionen sowie deren kryptografische Stärke zum Basisrepertoire eines jeden Entwicklers. Mit dem aktuellen Trend zur Cloud stellt sich häufig die Frage wie dort Geheimnisse und Schlüssel geschützt werden können. Microsoft bietet dafür den Service „Azure Key Vault“ an.

Durch einen Vortrag auf der Technical Summit 2016 bin ich auf Azure Key Vault aufmerksam geworden. Da das Thema im Vortrag nur in einem Nebensatz erwähnt wurde, habe ich beschlossen mich näher damit auseinanderzusetzen und meine Erkenntnisse zu teilen.

Die Herausforderung

Als .NET-Entwickler hat man sich daran gewöhnt Connection Strings, API Keys etc. im Klartext in der Konfigurationsdatei der Anwendung (z. B. app.config) gleich neben den Anwendungseinstellungen abzulegen – meist einhergehend mit dem Gefühl, dass dies nicht der sicherste Ort dafür ist. Denn die Konfigurationsdatei wird in der Quellcodeverwaltung hinzugefügt und ist dadurch für das gesamte Entwicklungsteam, aber auch für alle anderen Personen mit Zugriff auf das Repository oder das Dateisystem, sichtbar. 

Azure Key Vault 

Mit Azure Key Vault bietet Microsoft einen Cloud Service an, mit dessen Hilfe geheime Schlüssel von der Anwendung separiert und an einem gesicherten Ort abgelegt werden können. So bleibt die Kontrolle über diese Daten beim Besitzer. Der Anwendung selbst wird bei Bedarf die Verwendung eines Schlüssels eingeräumt, jedoch nie direkter Zugriff darauf gewährt. Weiterhin wird jede Aktion in Azure Key Vault geloggt. Dieses Log kann zur Analyse von Monitoring-Systemen genutzt werden, um im Falle einer kompromittierten Anwendung, schnell gewarnt zu werden. Selbst im Fall der Fälle, können bei Verwendung eines Read-only Service Users keine Schlüssel durch die Anwendung geändert oder gelöscht werden.

Schlüssel und Geheimnisse

 image

In Azure Key Vault können Schlüssel und Geheimnisse gespeichert werden, doch worin liegt der Unterschied?

Mit Schüssel (keys) sind kryptografische Schlüssel zum Verschlüsseln und Entschlüsseln von sensiblen Daten in der Anwendung gemeint. Besonders zu schützende Schlüssel können direkt in Hardwaresicherheitsmodule (HSM) importiert oder dort generiert werden (Premium Service Tier notwendig, siehe auch Key Vault – Preise). Damit ist sichergestellt, dass diese nur innerhalb der Modulgrenzen bekannt sind.

In Azure Key Vault gibt es keine semantische Vorgabe, was als Geheimnis zählt und was nicht. Allerdings existiert eine Größenlimitierung von 25KB. Passwörter, API Keys, Connection Strings sind dort bspw. richtig aufgehoben. 

Schutz durch Azure Active Directory

Wie können Anwendungen nun auf die geheimen Daten zugreifen, ohne selbst wieder ein Geheimnis für den Zugriff auf Azure Key Vault preiszugeben? Die Antwort ist „Azure Active Directory“Authentifizierung. Die Anwendung wird im Active Directory registriert und authentifiziert sich dann mit Hilfe von ClientID und ClientSecret. Daraufhin ist der Zugriff auf den Key Vault, welcher sich im selben Active Directory befindet, möglich.

Aber wohin nun mit ClientID und ClientSecret? Beide können als Anwendungseinstellung in der Konfigurationsdatei der Anwendung gespeichert werden, sind dann jedoch wieder für jede Person mit Berechtigung auf Repository oder Dateisystem sichtbar. Zur Umgehung dieses Problems, gibt es zwei Lösungsansätze:

  1. Statt die Werte im Klartext in der Konfigurationsdatei zu speichern, werden „leere“ Einstellungen für ClientID und ClientSecret erstellt und die Werte selbst in den Anwendungseinstellungen im Azure Portal hinzugefügt. Dadurch werden vorhandene Werte zur Laufzeit durch die im Portal konfigurierten Werte überschrieben. Das Portal gilt als sicherer, da es in der Regel nur von einem eingeschränkten Personenkreis administriert wird und durch Zwei-Faktor-Authentifizierung zusätzlich geschützt werden kann. Dennoch, das Geheimnis ist im Klartext im Portal ersichtlich. 
  2. Mehr Sicherheit bietet die Authentifizierung mit ClientID und Zertifikat. Dies ist die sicherste Methode, da in Azure hinzugefügte Zertifikate nicht heruntergeladen werden können und der private Schlüssel nicht über die Oberfläche sichtbar ist. 

Fazit

Azure Key Vault ist ein Service, mit dem Schlüssel und Geheimnisse leicht zentral und separiert von der Anwendung administriert werden können. Laut Produktbeschreibung kann nicht einmal Microsoft selbst diese Daten einsehen. Der zusätzliche Programmieraufwand zur Verwendung des Service hält sich sehr in Grenzen, sodass der Aufwand auch für kleinere Applikationen gerechtfertigt werden kann. Besonders für Cloud-Anwendungen, in denen mit personenbezogenen Daten gearbeitet wird, sollte die Verwendung in Erwägung gezogen werden. Erste Schritte mit Azure Key Vault habe ich in diesem Sway dokumentiert. Eine Kostenübersicht für Azure Key Vault ist hier zu finden.

google_about_ebiz fb_about_ebiztwitter_about_ebizxing_about_ebiz
ebiz_consulting_expertise

SQL Server 2016 - Improvements: InMemory

Veröffentlicht am 01.05.2017 von Ireen Raue , SQL Server , Custom Development , Data

Seit Juni 2016 steht der SQL Server 2016 zur Verfügung und bringt eine Unmenge an Weiterentwicklungen und Verbesserungen mit sich.

Einen ersten groben Überblick dazu habe ich bei den ‚SQL TechnologieDay SQL Server 2016‘ der ppedv in Leipzig bekommen. Dort wurde sehr kompakt auf die Neuerungen eingegangen. Manche dieser Neuerungen sind sehr interessant und spannend, weshalb ich mich damit etwas intensiver beschäftigt habe.

Sehr viele Verbesserungen gab es vor allem im InMemory-Bereich. Da ich mich aktuell für den SQL Server 2014 mit diesem Thema beschäftige, war das eine der für mich sehr interessanten Neuerungen.

InMemory-Erweiterung

Die erste inMemory-Technologie wurde mit dem SQL Server 2012 mit dem ColumnStore Index eingefügt und von Version zu Version stetig erweitert.

image

Auch die Analyse bestehender Projekte auf Migrationsmöglichkeiten hat sich deutlich vereinfacht. Wo beim SQL Server 2014 noch über ein Data Warehouse und DataCollector eine Datenbasis zum Auswerten aufgebaut werden muss, kann der ARM-Report beim SQL Server2016 direkt auf den Produktivdaten ausgeführt werden. So ist ohne größeren Aufwand eine Analyse möglich.

image

Durch die Aufhebung vieler Einschränkungen bei der Migration zu InMemory-Tabellen oder nativly compiled Procedures wird es mit dem SQL 2016 auch deutlich einfach für bestehende Projekte diese Technologie einzusetzen.

google_about_ebiz fb_about_ebiztwitter_about_ebizxing_about_ebiz
ebiz_consulting_expertise

DevOps - eine schöne neue Welt?

Veröffentlicht am 17.04.2017 von Florian Hieber , DevOps , ALM

Die DevOps Welt ist recht neu und mit agilen Ansätzen versehen. Theoretisch klingt das sehr gut, aber wie sieht es in der Praxis aus? Wie gut ist das Produkt, dass dabei herauskommt? Wo liegen die Schwierigkeiten? Ich versuche mich einmal an einer Betrachtung.

Microsoft propagiert seit Neustem die Prinzipien von DevOps – also dem Schulterschluss zwischen Softwareentwicklern (Developer) und IT-Betrieb (Operations). Noch vor einem Jahr gab es auf der Technical Summit 2015 Empfehlungen, die auf der diesjährigen Tech Summit wieder verworfen wurden. DevOps ist dieses Jahr das Trendthema schlechthin. Es gab sehr viele Vorträge, eine Keynote und eine Diskussionsrunde zu dem Thema. SCRUM, Canban oder gar klassische Vorgehensmodelle wurden noch nicht einmal angesprochen. Als zertifizierter Projektleiter und SCRUM Master bin ich naturgemäß an neuen Vorgehensmodellen interessiert. Dementsprechend verfolge ich den DevOps-Ansatz schon über ein Jahr mit Interesse.

Deshalb habe ich mich unter anderem auch dazu entschlossen, an der Tech Summit in Darmstadt teilzunehmen und dort einige Veranstaltungen zu diesem Thema zu besuchen. Gerade die Diskussionsrunde war sehr spannend, da auch einige Teilnehmer dabei waren, für die DevOps nicht nur graue Theorie war, sondern gelebtes Verhalten. Zwei Teilnehmer waren sogar aus der mittleren Führungsebene, die DevOps in ihr Unternehmen gebracht haben und die ihre Erfahrungen ebenfalls bereitwillig geteilt haben. Ein weiterer Teilnehmer war Administrator und konnte seine Erfahrungen mit DevOps ebenfalls vorbringen. Um es vorweg zu nehmen, es gab niemanden, der DevOps lebte und unzufrieden war. Aber was ist DevOps überhaupt?

DevOps ist eine Methodik, die Softwareentwicklung unter agilen Gesichtspunkten ansieht.

  • Entwickelt werden Produkte, es geht nicht um Projekte
  • Produkte werden durch Funktionen beschrieben
  • Projekte dagegen werden durch Kosten, Zeit und Annahmen der Funktionen beschrieben
  • Projekte dagegen beziehen den Auftraggeber nur sehr eingeschränkt ein
  • Zum Team gehören Betreiber und Entwickler des Produktes
  • Release-Zyklen sind sehr kurz (bis zu mehrmals täglich)

Die Idee, Betrieb und Entwicklung als zusammengehörige Einheiten zu betrachten, ist sicherlich gut, erfordert aber ein Umdenken im gesamten Unternehmen und nicht zuletzt bei den Beteiligten. Ein Prozess, der bislang auch in den Aussagen der Beteiligten noch nicht abgeschlossen ist. Der Gedanke, Produkte zu entwickeln und nicht Projekte zu definieren ist nicht neu, sondern wird bei allen agilen Methoden genutzt. Die Nachteile (keine Kostenschätzung möglich, keine Kontrolle des Funktionsumfangs möglich, etc.) sind immer noch in den Köpfen der meisten Mitarbeiter und der Führungsebene fest verankert. Dieses Denken steht der DevOps Methode auch entgegen. Neue Ansätze, wie eine engere Zusammenarbeit zwischen Betrieb und Entwicklung finden sicher schnell Gefallen im Unternehmen, mehrmals am Tag ein produktives System neu zu releasen aber ganz sicher nicht. Unternehmen, die DevOps einsetzen, stellen mehrmals am Tag ein Release ein. Damit der Prozess aber von anderen Abteilungen akzeptiert wird, nennen sie den Vorgang dann „Update“.

Ein „Release“ hatte bislang immer eine Besonderheit inne. Nicht nur aus der Gefahr, Fehler in den produktiven Betrieb zu bringen, sondern auch aus Marketing Gesichtspunkten. Ein Release war eine Neuerung, die vielleicht sogar preisliche, sicher aber funktionale Änderungen beinhaltete, die es wert waren, angekündigt zu werden. Auch das fällt mit DevOps weg.

Besonders die sehr kurzen Zyklen zur Bereitstellung neuer Funktionen am Produkt werfen aber die Frage auf, wie man in so kurzer Zeit verlässlich Testen kann. Um es vorweg zu nehmen, keine der beteiligten Parteien und auch die anderen Beiträge brachten mir da eine wirklich befriedigende Antwort.

In der Diskussion kamen viele Stimmen auf, die meinten, Tests (von Unit bis Systemtests) würden nichts bringen und nur Zeit und Geld kosten, deshalb hätten sie das Testen auf Akzeptanztests reduziert. Diesen Ansatz halte ich für problematisch, auch wenn es bislang laut der Anwesenden zu keinen großen Problemen gekommen sei. Die Gefahr, dass es zu solchen Problemen kommen kann, ist doch sehr hoch. Ganz zu schweigen davon, dass weder Qualitätskontrollen noch Zertifizierungen möglich sind. Quality Gates sind in den Köpfen vieler Menschen keine Kostenfresser, sondern unerlässlich, wenn man ISO-zertifizierte Qualität liefern will.

Auch sollen nach der Meinung von Microsoft keine Branches zu Testzwecken im Code Repository genutzt werden. Nach der Entwicklung (und Test) auf dem lokalen Entwicklerrechner geht es in die Produktion. Richtig ist das Argument der DevOps-Verfechter, dass normalerweise keine großen Änderungen in den Zyklen gemacht werden und deshalb ein auftretender Fehler auch schnell rückgängig gemacht werden kann. Was ist jedoch mit schleichenden Fehlern, die erst sehr spät auffallen, da sie sich auf Bereiche im Produkt auswirken, die man nicht im Fokus hatte? Ein Fehler, der erst nach Wochen, also nach mehreren Zyklen, auffällt ist durchaus möglich und nicht nur Theorie. Ob man dann auch noch so schnell reagieren kann?

Bislang konnte ich keine Person ausfindig machen, die wirklich negative Erfahrungen mit DevOps gemacht und die Methodik dann wieder verworfen hat. Insofern scheinen meine Zweifel nicht berechtigt, dennoch werde ich sie nicht los. Meine Berufserfahrung scheint meiner Gutgläubigkeit etwas entgegenzustehen.

Trotz meiner Zweifel bezüglich Test und Dokumentation finde ich die Methodik sehr interessant und würde gerne einmal eine Produktentwicklung mit DevOps unterstützen.

google_about_ebiz fb_about_ebiztwitter_about_ebizxing_about_ebiz
ebiz_consulting_expertise

Ein kleiner Einstieg in die Windows 10 IoT Welt

Veröffentlicht am 31.03.2017 von Ronny Ulbricht , IoT , Azure

Das Internet der Dinge (englisch: Internet of Things) wird gern als die nächste industrielle Revolution bezeichnet. Das Thema der „intelligenten Gegenstände“ hat in den letzten Jahren immens an Fahrt aufgenommen und ist mittlerweile sowohl im Enterprise als auch im Consumer Umfeld angekommen. Mit Windows 10 als Plattform, den Universal Windows Platform Apps und dem Azure IoT Hub mischt auch Microsoft kräftig mit.

clip_image002

Für die eBiz Consulting GmbH als Beratungsunternehmen und Integrationspartner für Software-Systeme, aber auch für mich persönlich als interessierter Entwickler ist das Thema „Internet of Things“ (IoT) schon länger auf dem Radar relevanter Trendthemen.

Meine Erfahrungen beschränkten sich dabei jedoch eher auf theoretisches Wissen aus verschiedenen Blog-Artikeln und anderen Publikationen sowie Samples, die ich bei Kollegen und befreundeten Entwicklern bestaunen durfte.

Im Rahmen der Microsoft Veranstaltung „Technical Summit 2016“ bot sich die Möglichkeit, an einem Tages-Workshop teilzunehmen und so in den praktischen Teil der IoT-Welt einzusteigen. Ich bekam einen ersten Überblick mit welchen Dingen man sich beschäftigen sollte und mit welchen nicht, wenn man sich in der Microsoft Welt des Internet der Dinge bewegt. Im Folgenden möchte ich diese Erfahrungen nun gern teilen.

Die richtige Idee

„Einfach mal so probieren“ mag im Bereich der Software Entwicklung ein probater Ansatz sein, um in neue Themen einzusteigen und sich auszuprobieren, am Ende liefert aber ein konkreter Anwendungsfall das höchste Motivationspotenzial. Eine halbwegs sinnvolle Idee sollte daher am Anfang aller Bemühungen stehen. Das ist schon deshalb notwendig, weil die benötigte Hardware mit einem finanziellen Investment verbunden ist, das sich je nach Ausstattung der Hardware (Anschlüsse, Sensoren) unterscheiden kann. Hier zum Beispiel eine Liste verschiedener Windows 10 IoT-fähiger Devices:

clip_image004

Eine naheliegende Idee ist beispielsweise das Auslesen und Weiterverarbeiten von Sensordaten einer Kaffeemaschine, einer Wetterstation oder das Ansteuern eines LED Displays zur Darstellung von Zustandsinformationen.

Wie den richtigen Einstieg finden?

Weiß man was man machen möchte, dann ist es zielführend sich Hilfestellung zu organisieren um geleitet in das Thema einzusteigen. Microsoft bietet für den Einstieg in die Windows 10 IoT-Welt einen „Get started“-Bereich im Windows Dev Center.

https://developer.microsoft.com/de-de/windows/iot/getstarted

Hier wird man mit Hilfe eines Wizards beim Aufsetzen des Devices unterstützt.

Wichtig ist, dass man sich im Vorfeld alle für Setup, Entwicklung und Deployment notwendigen Tools besorgt. Die meisten der Tools werden im Wizard erwähnt und verlinkt, hier jedoch noch mal eine Liste der Tools, die man auf jeden Fall haben sollte:

· Windows Assessment and Deployment Kit - Tools, zum Anpassen von Windows-Images

· https://github.com/ms-iot/iot-adk-addonkit/ - command line Skripte zur Paketierung und zur Image Erstellung

· Windows Driver Kit – enthält toolset zum Entwickeln, Bauen, Paketieren, Ausliefern, Testen, und Debugging von Geräte Treibern für die Windows Plattform

Der Wizard geht von der Verwendung der Standard-Images für die Windows 10 IoT-Editionen aus. Es besteht darüber hinaus noch die Möglichkeit eigene Images zu erstellen, um bestimmte Device-Voreinstellungen und andere Constraints setzen zu können, wie beispielsweise das Abschalten von Gerätefeatures. Dies ist bei einfachen Samples und wenigen Geräten nach Verwendung eines Standard-Images aber auch direkt über das Device selbst möglich und in dem Fall das empfohlene Vorgehen.

Nicht zuletzt, weil der Prozess der Erstellung von eigenen Images noch nicht wirklich ausgereift und daher fehleranfällig ist.

Anmerkung: Eine Übersicht über die Windows 10 IoT-Editionen und weitere Zusatzinformationen zu Windows 10 für das Internet der Dinge findet man unter:

https://www.microsoft.com/de-de/WindowsForBusiness/windows-iot

Universal Windows Platform Apps

Hat man das Setup seines Devices abgeschlossen und eine laufende Version von Windows 10 IoT deployed, so kann man sich an die eigentliche Aufgabe machen und seine App Entwickeln.

Grundsätzlich gibt es im Umfeld von Windows IoT nicht sonderlich viel zu beachten. Aufgrund des Konzeptes von Windows Universal Platform und der Universal Windows Platform Apps ist es einzig notwendig, dass die App für die richtige Prozessorarchitektur gebaut wird, um lauffähig zu sein, z.B. ARM für Raspberry Pi 2, Raspberry Pi 3 oder x86 für MinnowBoard Max.

Was eine Universal Windows Plattform App ist und vieles mehr dazu erfährt man unter:

https://msdn.microsoft.com/en-us/windows/uwp/get-started/whats-a-uwp

Für Apps, die Hersteller-spezifische Bauteile und Features nutzen wollen, benötigt man entsprechende Bibliotheken. So ist z.B. für das Pin Board und die Nutzung von GPIO das Windows IoT Extension SDK notwendig.

Wie man seine Apps auf das IoT-Device deployed kann man hier gut nachvollziehen.

https://developer.microsoft.com/en-us/windows/iot/Docs/appdeployment#csharp

Befindet sich das IoT-Device im Netzwerk mit Zugang zum Internet, kann direkt vom Device eine Verbindung zu Cloud Services oder ähnlichem aufgebaut werden und zwar bidirektional.

Azure IoT Hub

Last but not least bietet Microsoft mit dem Azure IoT Hub noch die Möglichkeit, die IoT-Devices zu verbinden, überwachen und zu verwalten.

Neben zahlreichen hilfreichen Features ist hier vor allem die Möglichkeit einer zuverlässigen, bidirektionalen Kommunikation mit dem Device der Grund, warum man sich Azure IoT Hub auf jeden Fall einmal ansehen sollte.

Zugang zum Azure IoT Hub findet man hier:

https://azure.microsoft.com/de-de/services/iot-hub/

Zu Testzwecken kann man sich kostenlos für den Dienst registrieren und bis zu 8000 Nachrichten am Tag für Testszenarien an seine Devices verschicken.

Kurze Schlussbemerkung

Mir persönlich hat der IoT-Workshop Lust gemacht, mich nochmal etwas praktischer mit dem Thema auseinander zu setzen. Natürlich weiter im Umfeld von Windows IoT, da mein technischer Fokus im Arbeitsalltag auch auf Microsoft-Technologien liegt. Aber auch die Möglichkeiten, die Microsoft Entwicklern bietet, sich kostengünstig dem Thema zu nähern, haben mich überzeugt.

Stellt sich nun die Frage, ob ich an die Elektronik unserer Kaffeemaschine darf ☺

google_about_ebiz fb_about_ebiztwitter_about_ebizxing_about_ebiz
ebiz_consulting_expertise