Anmelden
Die Deployment-Ansicht im Dashboard soll allen Beteiligten eine bessere Übersicht und mehr Kontrolle bei den Arbeitsabläufen vom Schreiben des Sourcecodes bis zur Veröffentlichung geben.
Atlassian hat mit Bitbucket Deployments die Integration des Continuous-Delivery-Prozesses ausgebaut, die das Unternehmen mit Bitbucket Pipelines im Oktober 2016 begonnen hatte[1]. Nutzer des Bitbucket-Cloud-Angebots erhalten damit das neue Deployments-Dashboard, das eine Übersicht darüber gibt, auf welchen Systemen welche Version der Software läuft.
Bitbucket kennt die drei Umgebungstypen Test, Staging und Produktion. Das Team sucht sich aus, welche Umgebungen es für das aktuelle Projekt benötigt. Das neue Dashboard zeigt im oberen Teil den jeweils letzten Deployment-Versuch für die drei Umgebungen an. Darunter listet es die komplette Deployment-Historie auf, inklusive des jeweils verantwortlichen Mitarbeiters. Über Filter lässt sich die Anzeige eingrenzen, um beispielsweise nachvollziehen zu können, welche Änderungen zu Problemen in bestimmten Umgebungen geführt haben.
Die Konfiguration der Deployments erfolgt über die YAML-Dateien für die Pipelines. Bitbucket Cloud stellt von sich aus die Verbindung zu den Änderungen in der Versionsverwaltung zwischen zwei Verteilungsprozessen her. Darüber hinaus automatisiert das System auch die Einbindung der manuellen Entscheidungen in den Arbeitsablauf.
Die jeweils Verantwortlichen können Software, die auf einer Umgebung fehlerfrei läuft, für die nächste Stufe freischalten. Nach dem Klick auf einen Promotion-Button im Dashboard erhalten sie zunächst eine vollständige Liste der seit dem letzten Deployment erfolgten Commits und die Unterschiede zwischen den Dateien. Anhand der Informationen entscheiden sie über die Freigabe für die nächste Umgebung. Mittelfristig will Atlassian zudem noch Jira-Issues und Pull Requests in die Ansicht integrieren.
Zum Einbinden des Deployment-Prozesses in die vorhandenen Pipelines genügt laut Atlassian eine Codezeile. Weitere Details lassen sich dem Blogbeitrag[2] entnehmen. Die Neuerung ist ab sofort als Preview in Bitbucket Cloud verfügbar. Zusätzliche Kosten fallen nicht an.
URL dieses Artikels:http://www.heise.de/-3907838
Links in diesem Artikel:[1] https://www.heise.de/meldung/Bitbucket-Cloud-Git-LFS-und-Pipelines-verlassen-Betaphase-3347929.html[2] https://blog.bitbucket.org/2017/12/05/introducing-bitbucket-deployments/[3] mailto:rme@ct.de
Copyright © 2017 Heise Medien
(Bild: Microsoft)
Um Unternehmen schneller an das Thema IoT heranzuführen, bietet Microsoft mit IoT Central eine Software aus der Cloud, die unkompliziert Geräte vernetzen, überwachen und steuern können soll. Die verwendeten Azure-Dienste bleiben im Hintergrund.
Mit IoT Central ergänzt Microsoft seine IoT-Dienste um eine Ebene, die in erster Linie einfacher sein soll als die vorhandenen Services. Das Unternehmen bezeichnet IoT Central als Software as a Service (SaaS). Das führt unter anderem mit sich, dass der Umgang mit IoT-Geräten in einem starreren Rahmen verläuft, als wenn man die Azure IoT Suite oder direkt die Azure-IoT-Infrastrukturdienste verwendet. Dafür soll IoT Central einen einfacheren Einstieg bieten.
Die Software verbindet sich mit vernetzten Geräten, bietet Masken für zeitabhängige Analysen und kann die Steuerung der Komponenten übernehmen. Mit Metriken lassen sich Regeln erstellen, die zum Beispiel eine Mail versenden, einen Webhook ansprechen, eine Azure Function ansprechen oder direkt an Salesforce/SAP melden, wenn ein bestimmtes Ereignis eintritt.
Eigenschaften der Geräte (Model, Seriennummer, zuständiger Techniker, Standort, ...) müssen Anwender von Hand eingeben. Microsoft bietet dafür einige Templates an. Automatisches Provisionieren über Excel-Tabellen oder Komma-separierte Listen ist angedacht, derzeit allerdings noch nicht möglich.
Jedes Device sendet zudem Metriken, die sich für Analysen und Regeln verwenden lassen. Über Settings lassen sich Eigenschaften steuern, etwa Lüftergeschwindigkeiten. Zu Beginn sind neue Geräte auf Simulationsmodus gestellt, sie müssen sich erst an IoT Central anmelden - die Methoden dafür stellen die Azure IoT SDKs bereit.
IoT Central [1] ist ab sofort weltweit in einer Public Preview verfügbar. In einer kostenlosen Testphase können Kunden 30 Tage lang 10 Geräte über das Angebot verwalten. Das Probeangebot umfasst 100 MByte Datenverkehr. Später gibt es einen Sockelbetrag von 500 US-Dollar pro Monat. Dieser erlaubt bis zu 100 Geräte und 1000 MByte Traffic. Möchte man mehr Devices anbinden, kostet das jeweils 50 Cent monatlich und erhöht das verfügbare Datenvolumen um 10 MByte. Möchte man lediglich letzteres erhöhen, gibt es 1 GByte für 30 US-Dollar. Kunden, die später zu den tieferliegenden Diensten wie der IoT-Suite wechseln wollen, müssen sich noch etwas gedulden, bis der Prozess automatisiert zur Verfügung steht.
URL dieses Artikels:
https://www.heise.de/ix/meldung/Microsoft-IoT-Central-soll-Einstieg-ins-Internet-der-Dinge-erleichtern-3908647.html
Links in diesem Artikel:
[1] https://www.microsoft.com/en-us/iot-central/
[2] mailto:jab@ix.de
AMD-Epyc-Mainboard für Microsoft Project Olympus
(Bild: Open Compute Project/OCP)
Microsoft setzt den AMD-Serverprozessor Epyc in den virtuellen Azure-Instanzen der "L Series" ein, die sich besonders für NoSQL-Datenbanken eignen.
Ab sofort können Microsoft-Kunden den AMD-Serverprozessor Epyc in der Azure-Cloud nutzen. Auf den neuen Project-Olympus-Servern mit je zwei Epyc 7551 mit 32 Kernen[1] laufen die "Storage-optimierten" virtuellen Maschinen der "L Series"[2], die Microsoft besonders für NoSQL-Datenbanken empfiehlt. Hier sind PCIe-NVMe-SSDs besonders leistungsfähig angebunden.
[Update:] Im Azure-Blog präzisiert Microsoft Azure Director of Compute Corey Sanders die verfügbaren Epyc-Instanzen[3]: L8s, L16s, L32s und L64s mit 8 bis 64 vCPUs, 64 bis 512 GByte RAM und 1 bis 8 NvMe-SSDs mit je 1,9 TByte.
Doch nicht nur Microsoft bringt den AMD Epyc jetzt in Fahrt, auch der bereits im November angekündigte[4] Rack-Server HPE ProLiant DL385 Gen10 mit zwei Epyc und bis zu 4 TByte RAM ist jetzt bei HPE bestellbar[5]. Die Preise beginnen bei rund 3400 Euro für eine Konfiguration mit einem einzelnen Octo-Core Epyc 7251 und 16 GByte RAM.
Für den maximalen Hauptspeicherausbau benötigt man bei Epyc-Servern DDR4-LRDIMMs mit je 128 GByte. Diese waren bisher vor allem als Zusatzkomponenten von den Server-Hersteller zu bekommen. Die Micron-Tocher Crucial verkauft aber seit kurzem das Modul CT128G4ZFE426S für knapp 4100 Euro[6]. Für 4 TByte RAM sind 32 dieser Octo-Rank-LRDIMMs nötig, die zusammen rund 131.000 Euro kosten.
URL dieses Artikels:http://www.heise.de/-3908665
Links in diesem Artikel:[1] https://www.heise.de/meldung/Serverprozessor-AMD-Naples-in-der-Microsoft-Cloud-3647855.html[2] https://azure.microsoft.com/en-us/pricing/details/virtual-machines/series/[3] https://azure.microsoft.com/en-us/blog/announcing-the-lv2-series-vms-powered-by-the-amd-epyc-processor/[4] https://www.heise.de/meldung/Server-Performance-AMD-Epyc-vs-Xeon-SP-in-der-SPEC-CPU2017-3896842.html[5] https://www.hpe.com/de/de/product-catalog/servers/servers/pip.models.hpe-proliant-dl385-gen10-server.1010268408.html[6] http://www.crucial.de/deu/de/ct128g4zfe426s[7] mailto:ciw@ct.de
Copyright © 2017 Heise Medien
Dass Container nur eine begrenzte Isolierung ermöglichen, ließ einen Markt für Produkte entstehen, die entsprechende Funktionen auf Clusterebene hinzufügen. Kata geht das Problem an, indem es die Container-Runtime anpasst.
Kata Containers sollen die starke Isolation von virtuellen Maschinen (VM) mit dem geringen Overhead von Containern verbinden und sich in einem Kubernetes-Cluster verwenden lassen. Technisch handelt es sich dabei um minimale VMs mit einem reduzierten Userspace. Die Entwicklungsarbeit kommt hauptsächlich von Intel (Clear Containers [1]) und Hyper [2]. Als Input verstehen Kata Containers Docker-Images – intern greifen sie auf dessen Container-Runtime zurück. Intel hat wohl vorwiegend am Design von VM und Kernel gearbeitet, während Hyper Technik um die Einbindung in Kubernetes einbringt, insbesondere deren runV.
Durch das Kapseln einzelner Apps in virtuellen Maschinen sollen Kubernetes-Cluster mandantenfähig werden. Beim Abschicken eines Workloads geben Nutzer an, ob dieser "trusted" oder "untrusted" ist. Kubernetes kann dann das passende Backend für den Job wählen, also auch ein Mischbetrieb mit Kata und blankem Docker ist möglich. Der Memory-Overhead pro Container beträgt 10 MByte.
Das Konzept wirkt etwas wie ein Schritt zurück in Zeiten vor dem Container-Hype. Die Entwickler versprechen jedoch die entsprechend hohe Performance und Flexibilität. Dazu kommt die Orchestrierung mit Kubernetes. Das wird im Gegenzug um eine weitere Ebene zur Isolation erweitert.
Verwaltung und Steuerung des Projekts liegen bei der OpenStack Foundation, es ist unter Apache-2.0-Lizenz veröffentlicht. Allerdings ist es kein Teil der OpenStack-Infrastruktur und besitzt auch ein eigenes Branding, ist also unabhängiger. Vorgestellt werden die Kata Container [3] im Rahmen der KubeCon in Austin [4].
URL dieses Artikels:
https://www.heise.de/ix/meldung/Kata-Container-so-isoliert-wie-virtuelle-Maschinen-3909015.html
Links in diesem Artikel:
[1] https://clearlinux.org/features/intel%C2%AE-clear-containers
[2] https://hyper.sh/
[3] https://katacontainers.io/
[4] http://events.linuxfoundation.org/events/kubecon-and-cloudnativecon-north-america
[5] mailto:jab@ix.de
(Bild: oporkka/iStockphoto.com)
Im TACNET-Projekt wollen 14 Partner aus Industrie und Forschung ihre Kräfte bündeln, um unter anderem ein einheitliches System für die industrielle Echtzeitkommunikation auf Basis des kommenden 5G-Mobilfunks zu entwickeln.
14 deutsche Unternehmen und Organisationen haben sich im Projekt TACNET 4.0 zusammengeschlossen, um ein einheitliches System für die industrielle Kommunikation in Echtzeit zu entwickeln. Das Projekt wird vom Bundesministerium für Bildung und Forschung (BMBF) gefördert. Grundlage des Systems soll der ab 2020 erwartete Mobilfunk der fünften Generation werden (5G). Im Zentrum stehen Verfahren für die Digitalisierung von Produktion und Robotik.
Orientiert an den Bedürfnissen des Marktes, soll eine Basis für vielfältige industrielle Anwendungen entstehen. Koordiniert wird TACNET vom Deutschen Forschungszentrum für Künstliche Intelligenz (DFKI) und den Nokia Bell Labs.
Den Projektnamen leiten die Teilnehmer von der sehr geringen Latenz des zugrundeliegenden 5G-Netzes ab – diese seien so niedrig, dass sie die Signallaufzeiten von Nervenfasern unterbieten und daher an taktile Wahrnehmung denken lassen (Tastsinn). Daher könne man von einem „taktilen Internet“ sprechen. TACNET 4.0 verspricht Reaktionszeiten von unter einer Millisekunde. Für Menschen ist die Signallaufzeit nicht mehr als Verzögerung wahrnehmbar.
Ausgangspunkt des TACNET-Projekts ist die vernetzte Produktion (Industrie 4.0). Mit der gegenwärtigen Technik sei die "notwendige höchste Zuverlässigkeit und Kommunikation in Echtzeit" noch nicht durchgängig möglich (Ende-zu-Ende). Die Projektteilnehmer wollen daher die Konzepte und Algorithmen entwickeln und "Voraussetzungen für viele Industrie 4.0-Anwendungen schaffen". Dazu zählen die direkte Interaktion zwischen Mensch und Maschine oder die drahtlose Prozesssteuerung.
Einer der wichtigsten Aspekte ist die lokale und standortübergreifende sichere Datenübertragung mit minimaler Verzögerung, um beispielsweise Maschinen fernsteuern zu können. Prof. Dr.-Ing. Hans Schotten meint, dass innovative 5G-Methoden "anspruchsvolle und bisher nicht realisierbare Szenarien in der Prozess- und Fertigungsautomatisierung" ermöglichen werden. Schotten ist Leiter des Forschungsbereichs Intelligente Netze am Deutschen Forschungszentrum für Künstliche Intelligenz (DFKI) in Kaiserslautern.
Ein solches Szenario sei zum Beispiel die Fernsteuerung von mobilen Maschinen oder Robotern, die in gefährlichen Arbeitsumgebungen im Einsatz sind oder die Bedienung durch lokal nicht verfügbares Fachpersonal erfordern. Dazu werden im Projekt auch neue Ansätze, wie Big Data-Analytics, Edge-Cloud-unterstützte Echtzeitsteuerung und Ferndienste, untersucht.
Schotten koordiniert das Projekt zusammen mit Dr. Peter Rost von Nokia Bell Labs. Rost ergänzt: "Taktiles Internet ist wichtig für eine umfassende Vernetzung von Menschen und Dingen, da diese Technologie zur industriellen Wertschöpfung beiträgt und das Leben der Menschen im Alltag erleichtern wird. Niemand entwickelt die Anwendungsszenarien von morgen alleine. Es braucht eine übergreifende Zusammenarbeit unterschiedlicher Branchen. Wir freuen uns, dass wir zusammen mit den Partnern in TACNET4.0 die Entwicklung des taktilen Internets vorantreiben können.“
TACNET 4.0 soll aber auch künftige 5G-Netze und gängige sowie neuartige industrielle Kommunikationsnetze integrieren, um die unterschiedlichste industrielle Anwendungen zu unterstützen. Dazu zählt auch die Einbindung von Feldbussystemen. TACNET 4.0 setzt dabei auf offene Schnittstellen, sodass die Netzwerkfunktionen etwa durch Apps erweitert werden können. Auch soll das Mobilfunknetz zur Weitbereichsabdeckung genutzt werden, anstatt wie bisher nur lokale drahtlose Sensornetze oder WLAN zu verwenden.
Zum TACNET-Konsortium gehören unter anderem das ABB Forschungszentrum, Bosch, das Institut für industrielle Informationstechnik (inIT) der Hochschule OWL, NXP, die TU Dresden und die Uni Bremen und Partner wie BASF, Busch-Jaeger, Hirschmann Automation and Control, Vodafone und andere Unternehmen und Institutionen.
Initiiert wurde TACNET 4.0[1] bereits im April 2017. Die Gesamtlaufzeit beträgt drei Jahre. Das BMBF fördert das Projekt[2] mit rund 6,4 Millionen Euro. Am 30.11.2017 fand in München das erste Konsortialtreffen zum ersten Projekt-Meilenstein statt. Damit schlossen die Teilnehmer die Analyse der Anwendungsfälle und Industrieanforderungen ab. Sie werden nun in die 3GPP-Standdardisierung eingebracht, sodass die technischen Arbeitsgruppen mit ihren Aufgaben starten können.
URL dieses Artikels:http://www.heise.de/-3908251
Links in diesem Artikel:[1] http://www.tacnet40.de[2] https://www.forschung-it-sicherheit-kommunikationssysteme.de/projekte/tacnet[3] mailto:dz@ct.de
Copyright © 2017 Heise Medien
(Bild: Raspberry Pi Foundation)
Nach der ARM- erscheint nun die x86-Variante des Raspberry Pi Desktops auf Basis von Debian Stretch. Mit an Bord ist ein Programm, mit dem Nutzer ihre Pi-Clients vom PC aus verwalten können.
Im Rahmen eines Updates haben die Raspbian-Entwickler die x86-Variante ihrer Linux-Distribution – einfach Raspberry Pi Desktop genannt – auf einen Stand mit dem Pi gebracht. Das Betriebssystem basiert nun auch für PCs und Macs erstmals auf Debian Stretch, Pi-Nutzern stand der Sprung von Jessie [1] im August diesen Jahres ins Haus.
Der Pi auf dem x86-Rechner entspricht fast vollständig seinem Raspbian-Bruder, einzig ein paar Programme wie Mathematica sind nicht enthalten. Der hauseigene Desktop ist jedoch derselbe. Entsprechend erhalten beide Varianten des Betriebssystems die Änderungen des Dateimanagers PCManFM – Teil des LXDE-Projekts –, dank der das Programm mit weniger angezeigten Optionen weniger Verwirrung stiften soll. Alle Entscheidungen der Designer können Nutzer in der Ankündigung [2] nachvollziehen, gleichsam lassen sich alle Vereinfachungen mit einem Klick rückgängig machen.
Wer den Raspberry Pi Desktop auf seinem Laptop installiert, wird sich über die Anzeige des Batteriestands freuen. Sie unterstützt außerdem bereits die erste Generation des pi-top. Ab Werk liegt der x86-Ausgabe die Anwendung PiServer bei. Mit ihr lassen sich Raspberry-Pi [3]-Clients zum Beispiel im Klassenzimmer zentral verwalten. Ein zweites Programm dient dem Zugriff auf die GPIO-Pins eines per USB am PC angeschlossenen Pi Zero [4]. Sie kann der Nutzer anschließend in Scratch oder Python verwenden. Optional lassen sich die beiden neuen Programme auch auf einem herkömmlichen Pi installieren.
Weitere Änderungen im Detail beheben in beiden Varianten einige Bugs. Der Raspberry Pi Desktop lässt sich als Live-Distribution starten oder auf der lokalen Festplatte aufsetzen, wobei das Installationsprogramm die letztere komplett überschreibt. Wer von Jessie ein Upgrade durchführen will, muss in den Dateien /etc/apt/sources.list und /etc/apt/sources.list.d/raspi.list Jessie durch Stretch ersetzen und einige Programme manuell installieren; die genauen Befehle können Interessierte in der Ankündigung der Entwickler [5] einsehen.
URL dieses Artikels:
https://www.heise.de/ix/meldung/Stretch-fuer-x86-Raspberry-Pi-Desktop-fuer-den-PC-und-Mac-aktualisiert-3907897.html
Links in diesem Artikel:
[1] https://www.heise.de/ix/meldung/Raspbian-Version-Stretch-auf-Basis-von-Debian-9-veroeffentlicht-3807824.html
[2] https://www.raspberrypi.org/blog/stretch-pcs-macs-raspbian-update/
[3] https://www.heise.de/preisvergleich/raspberry-pi-3-modell-b-a1400349.html
[4] https://www.heise.de/preisvergleich/?fs=raspberry+pi+zero&in=
[5] https://www.raspberrypi.org/blog/stretch-pcs-macs-raspbian-update/
[6] mailto:fo@heise.de
Die im November erfolgte Aktualisierung der Bedingungen für Apps im Play Store verbietet eine nervige Werbeform, und sorgt zudem für Klarheit in Sachen Alters-Rating und Design for Families.
Google hat die Verträge für Apps im Play Store aktualisiert: Nun ist eine nervige Werbeform verboten. Klarheit gibt es in Sachen Alters-Rating und Design for Families.
Das vom weit verbreiteten Dateimanager ES File “populär gemachte” Ersetzen des Sperrbildschirms von Android-Smartphones ist ab sofort untersagt. Der genaue Passus klingt so: “Unless the exclusive purpose of the app is that of a lockscreen, apps may not introduce ads or features that monetize the locked display of a device.”
Dank der obligatorischen dreißigtägigen Frist haben Entwickler bis zum 30. Dezember dieses Jahres Zeit, ihre Programme an die neuen Regulierungen anzupassen. Danach dürfte ein insbesondere bei technisch wenig versierten Nutzern universell verhasstes Problem der Vergangenheit angehören.
Der Schutz Minderjähriger ist seit jeher ein Problem für Store-Betreiber: Schon zu Zeiten von Jamba und Co gab es immer wieder Medienkampagnen. Google bietet Entwicklern schon länger die Möglichkeit, durch Ausfüllen eines Fragebogens zu einem Alters-Rating zu kommen. Neu ist hier, dass das Ausfüllen dieses Formulars ab sofort obligatorisch ist und unbewertete Applikationen aus dem Store fliegen.
Wer ein spezifisch für die Bedürfnisse von Kindern vorgesehenes Programm anbietet, kann seit Juli 2016 auf “Designed for Families” zurückgreifen. Google aktualisiert die diesbezüglichen Kriterien nun zum zweiten Mal – das letzte Update erfolgte im April. Die Attributliste[1] weist selbst keine Versionsinformationen auf, aber im Internet Archive finden sich ältere Varianten.
Beim Betrachten der Unterschiede fällt auf, dass Google im Bereich Log-in-Dienste schärfere Kriterien anlegt. So ist es nun im Allgemeinen verboten (may not), Google Sign In oder die Play Services als Log-in-Dienst zu verwenden. Bisher fand sich an der Stelle die offenere Formulierung "should not". Wie bisher gibt es für “Mixed Audience”-Apps eine Ausnahme, sofern das Einloggen nicht verpflichtend ist.
Aufgrund des offenen Aufbaus von Android ist das Aufkommen diverser Arten von Malware unvermeidlich: Gerade das Ersetzen des Lockscreens mit Zeitverzögerung (wie bei ES File) ist eine für wenig seriöse Entwickler gewinnbringende Maßnahme. Durch das Ändern der Play-Store-Bedingungen ist Google in der Lage, das Ökosystem zu steuern: Für viele User sind Applikationen, die nicht per Google Play erhältlich sind, quasi unsichtbar.
(Tam Hanna) /
URL dieses Artikels:http://www.heise.de/-3907487
Links in diesem Artikel:[1] https://play.google.com/about/families/designed-for-families/program-requirements/[2] mailto:rme@ct.de
Copyright © 2017 Heise Medien
(Bild: Johannes-Gutenberg-Universität Mainz)
Ohne Hochleistungsrechner ist Klimaforschung ebenso undenkbar wie die Erkundung kleinster Atomteilchen. Mit Mogon II an der Mainzer Uni bekommt das "High Performance Computing" in Deutschland neuen Schub.
Der leistungsstärkste Computer einer deutschen Universität hat in Mainz seinen Betrieb aufgenommen[1]. Offiziell eingeweiht wird der Supercomputer Mogon II im März. Die Anlage, die nach dem antiken Stadtnamen Mogontiacum aus der Römerzeit benannt ist, dient künftig vor allem der Grundlagenforschung in Physik, Biologie, Medizin und Geologie. Physiker des Helmholtz-Instituts Mainz wollen die Anlage für die Simulation von Teilchenkollisionen nutzen. "Auch Wetter und Klima sind ein Thema für Mogon II", sagt der Leiter des Zentrums für Datenverarbeitung (ZDV) an der Johannes-Gutenberg-Universität Mainz, André Brinkmann.
Die Klimaforschung profitiert von der Fähigkeit des Supercomputers, auch sehr hohe Auflösungen zu berechnen. "Je mehr Rechenkapazität wir haben, umso feiner können wir auflösen", erklärt Brinkmann. Klimaforscher und Meteorologen könnten dann viel feinere Eigenschaften modellieren und in ihre Berechnungen einbringen. "Für die Zukunft gibt es daher noch viel Raum für deutlich präzisere Vorhersagen."
Mogon II, aufgebaut neben seinem Vorgänger aus dem Jahr 2012[2], kann in einer Sekunde rund 2 Billiarden Einzelberechnungen oder 2 Petaflops ausführen, 1.967.800.000.000.000 Gleitkommaoperationen (floating operations) pro Sekunde, abgekürzt als FLOPS. In der Liste der weltweit 500 schnellsten Rechner[3] liegt Mogon II damit auf Platz 65. In der Spitze sind sogar 2,8 Petaflops drin.
Wenn nicht nur die Leistung, sondern auch der Stromverbrauch gemessen wird, rangiert der Mainzer Supercomputer in der Weltrangliste der Top-500-Supercomputer auf Platz 51. "Die Fortschritte der Computer-Technologie ermöglichen es, dass der neue Hochleistungsrechner bei nahezu siebenfacher Peak-Leistung gegenüber seinem Vorgängersystem mit einer Leistungsaufnahme von 657 Kilowatt nur 40 Prozent mehr Strom als dieses benötigt", erklärt Brinkmann.
Mogon II "wird das wissenschaftliche Rechnen im Bereich des High Performance Computing in Deutschland und insbesondere in Rheinland-Pfalz maßgeblich beeinflussen und nachhaltig befördern", erklärt Wolfgang Nagel vom Vorstand der Gauß-Allianz. Der Zusammenschluss kümmert sich um die Zusammenarbeit der Hochleistungsrechner (HPC) in Deutschland.
Die Verfügbarkeit leistungsstarker HPC-Systeme trage dazu bei, "Deutschlands Expertise im Bereich der Algorithmen, Simulations-Software und Software-Werkzeuge zu sichern und weiter auszubauen", erwartet Nagel, der an der Technischen Universität Dresden das Zentrum für Informationsdienste und Hochleistungsrechnen leitet. Im Kreis der Bundesländer mit HPC-Präsenz gewinne Rheinland-Pfalz nun verstärkt an Bedeutung.
Der Mainzer Hochleistungsrechner ist nicht der einzige im Bundesland. Neben einer HPC-Anlage der BASF in Ludwigshafen ist an der Technischen Universität Kaiserslautern der Supercomputer Elwetritsch im Einsatz[4], benannt nach einem Pfälzer Fabelwesen. Dieser Rechner bringt es nach Angaben einer Sprecherin auf eine Leistung von 230 Teraflops, also 0,230 Petaflops. Anfang kommenden Jahres wird der neue Hochleistungsrechner Elwetritsch II in Betrieb genommen, der die doppelte Rechenleistung bieten wird.
Beide Uni-Anlagen sind über eine 120-Gigabit-Glasfaserleistung miteinander verbunden, in der Allianz für Hochleistungsrechnen Rheinland-Pfalz (AHRP)[5]. "Wir versuchen, unsere Systeme ähnlich zu betreiben und von den anderen zu lernen, um Probleme schneller beheben zu können", erklärt Brinkmann. Außerdem kann im Verbund die Rechenlast ausbalanciert werden: Wenn Wissenschaftler in Kaiserslautern mehr Rechenleistung benötigen, als Elwetritsch zur Verfügung stellt, kann Mogon aushelfen.
Die mit Hilfe der Supercomputer erzielten Ergebnisse führen in der Regel nicht zu kurzfristigen Produkten, sondern dienen der Grundlagenforschung. "Das ist ohne öffentliche Förderung nicht machbar", erklärt Brinkmann. Die Johannes-Gutenberg-Universität und das Helmholz-Institut Mainz haben seit 2016 insgesamt 10,6 Millionen Euro in den neuen Mainzer Hochleistungsrechner investiert.
"Hochleistungsrechner sind heutzutage eine unverzichtbare Schlüsseltechnologie in nahezu allen Disziplinen", betont der rheinland-pfälzische Wissenschaftsminister Konrad Wolf (SPD). Im Verbund von Mainz und Kaiserslautern werde allen Wissenschaftlern in Rheinland-Pfalz Zugang zu Rechenleistungen der internationalen Spitzenklasse ermöglicht.
Was heute noch Topstandard der Hardware-Technik ist, kann in wenigen Monaten schon überholt sein. Die Dynamik bei Hochleistungsrechnern ist so groß, dass die jetzt in der Top-500-Liste genannten Computer bald nach unten durchgereicht werden. Aber die Liste wird nur zweimal im Jahr aktualisiert. Wenn im März die Einweihung von Mogon II ansteht, kann der Computer noch stolz seinen Platz 65 präsentieren.
(Peter Zschunke, dpa) /
URL dieses Artikels:http://www.heise.de/-3907460
Links in diesem Artikel:[1] https://hpc.uni-mainz.de/high-performance-computing/mogonbild/[2] https://www.heise.de/meldung/Supercomputer-Mogon-an-der-Uni-Mainz-eingeweiht-1594597.html[3] https://www.heise.de/meldung/Supercomputer-China-wieder-first-America-second-3889197.html[4] https://elwe.rhrk.uni-kl.de/[5] https://www.ahrp.info/index.shtml[6] mailto:bbo@ix.de
Copyright © 2017 Heise Medien
Amazon legte diesjährige re:Invent als ein Festival der Superlative aus. Aber bei näherem Hinsehen zeigten sich einige Schwächen, die den bisherigen Steigflug der AWS-Cloud bremsen könnten.
Es war die sechste re:Invent und es war alles in allem ein Mega-Event. Während bei der ersten Veranstaltung 2012 knapp 6000 Teilnehmer in die Wüstenstadt Las Vegas reisten, kamen dieses Jahr über 43000 Cloud-Fans [1]. Für sie fuhr Amazon rund 1300 Sessions, inklusive einer mehrstündigen Keynote, auf. Und auch sonst ließ AWS-Chef Andy Jassy keinen Zweifel daran aufkommen, dass man mit einem Marktanteil von 44,1 Prozent eindeutig der Platzhirsch unter den Cloud-Providern ist. Gartner sieht bereits eine rapide zunehmende Konsolidierung und viele Beobachter gehen davon aus, dass es in wenigen Jahren nur noch eine Handvoll Anbieter geben wird.
Aber gerade diese Konsolidierung und die bereits erreichte Größe könnten für AWS gefährlich werden. IBM, Google und Microsoft haben da bereits schmerzliche Erfahrungen gemacht. So dürfte AWS schon bald die Kartellbehörden auf den Plan rufen. Das Problem sieht man natürlich auch bei Amazon und versucht bereits gegenzusteuern. "Cloud-Computing ist ein Billionen-Markt mit beachtlichen Steigerungsraten in allen Teilbereichen, wie Infrastruktur, Middleware, Anwendungen und Services. Alle großen Anbieter verzeichnen ordentliche Wachstumsraten. Hier ist noch genügend Platz für viele und vieles", meinte AWS‘ Infrastrukturchef Peter DeSantis in einem Interview.
In der Tat scheint das Cloud-Rennen trotz der rekordverdächtigen AWS-Zahlen noch nicht entschieden. So zeichnet sich gerade in deren umfangreichen Servicenagebot ein Rückschlag ab. So rühmte sich AWS-CTO Werner Vogels noch sehr dafür, dass man in den letzten fünf Jahren knapp 4000 Neuheiten oder Verbesserungen herausgebracht habe, doch dieses immense Angebot wird immer häufiger als negativ eingestuft. "Das Angebot ist zu unübersichtlich geworden und viele Angebote überlappen sich; AWS entwickelt sich zu einem Anbieter, der immer schwerer zu managen ist", sagt Brent Bracelin, Senior Analyst bei der Investmentbank Pacific Crest.
Es gibt auch deutliche Angebotsunterschiede bei den großen Providern. Dazu gehört beispielsweise die Unterstützung einer Hybrid-Cloud-Umgebung, also der Cloud, die sich inzwischen durchgesetzt hat. Wenn in so einer Architektur der On-Premise-Teil überwiegend auf Microsoft-Systemen basiert, ist Azure der AWS-Plattform in vielen Punkten überlegen. Das zeigt sich beispielsweise an den Hybrid-Management-Tools, wie Azure Stack, Hybrid SQL und Azure StoreSimple. Der Grund dafür ist, dass Amazon ursprünglich eine reinrassige Cloud-Only-Strategie verfolgte und jede Art von In-House-IT als unnötig abstempelte. Microsoft hat dagegen von Anfang an auf eine hybride Nutzung gesetzt – und das könnte sich bei einer zunehmenden Ausbreitung der Hybrid Cloud auszahlen.
Trotz des gewaltigen Angebotes an stets neuen Diensten ist AWS aber nicht immer an der vordersten Front vertreten, wenn es um angesagte Trends geht. Insbesondere die Blockchain lässt der Konzern links liegen. Mit Bitcoin gerät sie zwar manchmal negativ in die Schlagzeilen, doch andererseits setzen viele Länder sie immer häufiger in der öffentlichen Verwaltung ein. Während IBM und Microsoft hierzu entsprechende Dienste anbieten, hat man bei Amazon keinerlei Pläne. "Wir entwickeln keine Technologien, nur weil manche meinen, sie sei cool", gab Andy Jassy in der Pressekonferenz als Begründung für die AWS-Abstinenz an. Seiner Ansicht nach gibt es nur einen begrenzten Anwendungsfall für die Blockchain, der den Entwicklungsaufwand nicht rechtfertigen würde. Allerdings räumte er ein, dass man die Entwicklung genau verfolge. "Wir schauen uns sehr genau an, was sich bei unseren Kunden auf diesem Gebiet tut", lautete sein vielsagender Ausblick.
Ein Dämpfer könnte auch der erkennbare Schulterschluss von AWS mit Amazons Online-Shop sein. Große Teile der Keynotes von Jassy und Vogels waren reinrassige Werbeveranstaltungen für Alexa und das neue Gadget, die smarte Kamera DeepLens. Vogels widmete dabei einen großen Teil seiner Rede der Sprache als Mensch-Maschine-Interface. Sein Ausgangspunkt war der, dass Maus und Tastatur keine natürlichen Kommunikationsmittel seien, sondern dafür geschaffen wurden, um die Schwächen früherer Systeme zu umgehen. Seine Forderung: "Nicht der Mensch soll sich an die Maschinen anpassen, sondern umgekehrt."
Damit kommt er aber zu spät. Ein Blick in jeden Warteraum, in einen Zug oder ein Café zeigt deutlich, dass die Anpassung des Menschen ans Handy oder Tablet schon längst stattgefunden hat. Hinzu kommt, dass vor allem die Sprachausgabe wesentlich ineffizienter ist, als es grafische Ausgaben sind. Vogels nutzte eine Business-Anwendung von Alexa die Frage: "Alexa, wie viele Laptops haben wir auf Lager?" Eine Sprachantwort gab es nicht, denn die wäre ja auch nicht sonderlich attraktiv ausgefallen. Mit einer Zahl als Antwort, beispielsweise 76, wäre die Frage zwar korrekt beantwortet, doch jede Standardanfrage mit Tastatur oder Maus hätte nicht nur die Zahl 76 auf den Bildschirm befördert, sondern außerdem eine Tabelle geboten, in der alle Systeme mit Bild und weiteren technischen Daten übersichtlich dargestellt sind. Das vorzulesen macht weder Sinn, noch macht es die Arbeit produktiver.
URL dieses Artikels:
https://www.heise.de/ix/meldung/Analyse-Amazon-kann-die-AWS-Defizite-nicht-mit-neuen-Diensten-uebertuenchen-3907466.html
Links in diesem Artikel:
[1] https://www.heise.de/ix/meldung/re-Invent-2017-Amazon-ueberkommt-die-Cloud-Ankuendigungswut-3903783.html
[2] mailto:fo@heise.de
Django 2.0 gibt die Unterstützung für Python 2 endgültig auf. Das URL-Routing lässt sich jetzt auch ohne reguläre Ausdrücke aufsetzen.
Ernsthafte Webentwicklung bedeutet heutzutage in der Regel den Einsatz eines Webframeworks, das dem Entwickler viele Routinetätigkeiten abnimmt. In der Python-Welt ist Django, benannt nach dem Jazz-Gitarristen Django Reinhardt, seit zehn Jahren das Webframework der Wahl. Konkurrenten wie Flask konnten bislang nur Nischen besetzen.
Django setzt konsequent das Model-View-Controller-Konzept um, kapselt Datenbankzugriffe über eine objektrelationale Abbildung und generiert automatisch eine Oberfläche zur Verwaltung von Datenbank und Benutzern. Das Framework enthält eine leistungsfähige Template-Sprache und bietet eine flexible URL-Konfiguration.
Die frisch erschienene Version 2.0 ist trotz des großen Versionssprungs weitgehend rückwärtskompatibel zur Vorversion 1.11 – mit einer Ausnahme: Django 2 arbeitet nur noch mit Python 3.4, 3.5 und 3.6 zusammen. Wer noch Python 2.7 nutzt, muss bei Django 1.11 bleiben, das als LTS-Version noch bis April 2020 Sicherheits- und kritische Bugfixes erhalten soll. Django 1.10 hat mit dem Erscheinen der neuen Version das Ende des Supports erreicht.
Mit dem neuen Release kommt ein neues Versionierungsschema, das die Python-Macher im Blog-Beitrag zur neuen Version [1] als eine "lockere Form von semantischer Versionierung" bezeichnen. Zukünftig soll es zwei Minor Versions ohne Langzeit-Support (2.0, 2.1) und dann eine LTS-Version (2.2) geben. Anschließend folgt eine neue Major Version (3.0). Die wird dann entsprechend mit Version 3.2 Langzeit-Support erhalten.
Zu den wichtigsten technischen Neuerungen in Django 2.0 gehört eine vereinfachte Syntax zum URL-Routing, die ohne reguläre Ausdrücke auskommt: Statt
url(r'^articles/(?P
kann man jetzt auch
path('articles/
schreiben.
Die automatisch generierte Adminoberfläche ist jetzt responsiv. Zahlreiche weitere Neuerungen, darunter auch die neuen Window Expressions, erläutern die Django 2.0 release notes [2].
URL dieses Artikels:
https://www.heise.de/ix/meldung/Django-2-0-Neue-Version-des-Python-Webframeworks-3907355.html
Links in diesem Artikel:
[1] https://www.djangoproject.com/weblog/2017/dec/02/django-20-released/
[2] https://docs.djangoproject.com/en/2.0/releases/2.0/
[3] mailto:odi@ix.de
Nachdem Reporter ohne Grenzen mit ihrer Klage gegen den BND-Datenstaubsauger vor deutschen obersten Gerichten erfolglos blieb, trägt die Organisation diese nun vor den Straßburger Gerichtshof für Menschenrechte.
Die Aktivisten von Reporter ohne Grenzen (ROG) lassen mit ihrer Klage gegen die "strategische Fernmeldeüberwachung" durch den Bundesnachrichtendienst (BND) nicht locker. Die zivilgesellschaftliche Organisation hat ihre Beschwerde gegen die Massenüberwachung[1] jetzt vor den Europäischen Gerichtshof für Menschenrechte (EGMR[2]) gebracht. Zuvor war sie mit einem einschlägigen Verfahren vor dem Bundesverwaltungsgericht weitgehend gescheitert[3]. Auch der Gang vor das Bundesverfassungsgericht[4] blieb erfolglos: Die Karlsruher Richter nahmen die entsprechende Verfassungsbeschwerde mit einem Beschluss von Ende April nicht zur Entscheidung an.
ROG wirft dem Auslandsgeheimdienst vor, im Zuge seiner heftig umstrittenen Überwachungspraktiken den E-Mail-Verkehr der Organisation mit ausländischen Partnern, Journalisten und anderen Personen ausgespäht zu haben. Es bei den Klagen vor allem um Befugnisse aus dem sogenannten G10-Gesetzes[5], das dem BND umfangreiche Eingriffe ins Fernmeldegeheimnis erlaubt, das in Artikel 10 Grundgesetz verankert ist. So dürfen die Spione etwa einen Datenstaubsauger einsetzen[6], um den internationalen Telekommunikationsverkehr mithilfe bestimmter Suchbegriffe und sonstiger Selektoren zu durchforsten.
BND ) </span>
Die bislang angerufenen obersten deutschen Gerichte sahen ihre Hände gebunden, da ROG nicht habe glaubhaft machen können, dass die Organisation selbst von der BND-Bespitzelung betroffen war. Der geforderte Nachweis ist wegen der Geheimniskrämerei bei dem Nachrichtendienst schwer zu erbringen. In der Klageschrift an den EGMR führt die Vereinigung nun an, dass der BND ihr Recht auf Achtung der Korrespondenz sowie des Rechts auf Meinungs- und Informationsfreiheit gemäß den Artikeln 8 und 10 der Europäischen Menschenrechtskonvention[7] verletzt habe. Die ausufernden Suchkriterien des Geheimdienstes führten zu einer durch den mutmaßlichen Zweck der Maßnahmen keinesfalls gedeckten Reichweite der Eingriffe.
Darüber hinaus macht Reporter ohne Grenzen geltend, in ihrem Recht auf wirksame Beschwerde verletzt worden zu sein. Der weitaus größte Teil der Betroffenen erfahre nicht einmal im Nachhinein etwas davon, "dass ihre E-Mails erfasst und durchsucht werden", schreibt die Organisation. Selbst die Allgemeinheit mit den jährlichen Berichten des Parlamentarischen Kontrollgremiums des Bundestags regelmäßig erst dann über Überwachungsmaßnahmen informiert, wenn sogar entscheidende Protokolldaten schon gelöscht worden seien. Klagen dagegen vor deutschen Gerichten seien unter den aufgeführten Umständen unmöglich.
"Die ausufernde Überwachungspraxis des BND stellt die Vertraulichkeit digitaler Kommunikation grundsätzlich in Frage und untergräbt damit eine Voraussetzung journalistischer Recherche", begründete ROG-Geschäftsführer Christian Mihr den neuen Schritt. Jetzt sei es an den Straßburger Richtern, "dem Grundrecht auf Rechtsschutz vor der anlasslosen und unverhältnismäßigen BND-Massenüberwachung endlich zur Geltung zu verhelfen". Parallel ist der Teil der ursprünglichen Klage gegen das vom BND geführte Metadaten-Analysesystem Veras[8] weiter anhängig; auch eine Verfassungsbeschwerde von Amnesty International gegen den Datenstaubsauger der Schlapphüte läuft noch[9].
Der EGMR beschäftigt sich parallel mit Klagen von Bürgerrechtlern und Nichtregierungsorganisationen[10] gegen die gegen die Internet- und Computerspionage des britischen Geheimdiensts GCHQ[11]. Zu den Beschwerdeführern gehören hier unter anderem Provider, Constanze Kurz vom Chaos Computer Club (CCC)[12] sowie Privacy International. Eine Anhörung dazu fand Anfang November statt[13], bei der die Richter die Hacking-Methoden der Londoner Behörde hinterfragten. Mit einem Urteil des Menschengerichtshof in diesen Fällen ist 2018 zu rechnen.
(Stefan Krempl) /
URL dieses Artikels:http://www.heise.de/-3907198
Links in diesem Artikel:[1] https://www.heise.de/meldung/NSA-Skandal-Reporter-ohne-Grenzen-klagt-gegen-BND-2732465.html[2] http://www.echr.coe.int/[3] https://www.heise.de/meldung/Bundesverwaltungsgericht-lehnt-Klagen-gegen-BND-teilweise-ab-3570480.html[4] https://www.heise.de/meldung/Verfassungsgericht-Reporter-ohne-Grenzen-klagt-gegen-BND-Ueberwachung-3642414.html[5] https://www.gesetze-im-internet.de/g10_2001/[6] https://www.heise.de/meldung/NSA-Ausschuss-Kanzleramt-will-BND-Datenstaubsauger-strenger-regulieren-3356342.html[7] http://www.echr.coe.int/Documents/Convention_DEU.pdf[8] https://www.heise.de/meldung/NSA-Ausschuss-BND-kann-Daten-zu-Kontaktpersonen-schier-unbegrenzt-sammeln-3538172.html[9] https://www.heise.de/meldung/Internetueberwachung-Amnesty-klagt-gegen-BND-Datenstaubsauger-3466588.html[10] https://www.heise.de/meldung/Neue-Klage-gegen-GCHQ-Hacking-vor-dem-Menschengerichtshof-3289446.html[11] https://www.heise.de/meldung/UK-Geheimdienst-Britisches-Gericht-billigt-weitgehendes-GCHQ-Hacking-3103064.html[12] https://www.heise.de/meldung/GCHQ-Ueberwachung-Buergerrechtler-klagen-in-Strassburg-1972227.html[13] https://netzpolitik.org/2017/anhoerung-beim-menschenrechtsgerichtshof-d%20ie-rechtswidrigkeit-der-massenueberwachung/[14] mailto:it@ct.de
Copyright © 2017 Heise Medien
Die Zentrale des IT-Sicherheitsspezialisten Kaspersky in Moskau.
(Bild: dpa, Pavel Golovkin)
Die britische Zentrum für Cyber-Sicherheit NCSC (National Cyber Security Centre) hat Regierungsbehörden vor Anti-Virus-Software der in Moskau ansässigen Firma Kaspersky Lab gewarnt.
Britische Regierungsbehörden sollen nach Meinung des britischen Zentrums für Cyber-Sicherheit NCSC (National Cyber Security Centre) keine Anti-Virus-Software der in Moskau beheimateten Firma Kaspersky Lab einsetzen. Das geht aus einem Brief von NCSC-Chef Ciaran Martin an britische Minister hervor, der auf der Webseite des Zentrums veröffentlicht wurde. Zur Begründung hieß es, Russland habe die Absicht, die britische Regierung und entscheidende Infrastruktur des Landes anzugreifen.
Es gäbe "offensichtliche Risiken" hinsichtlich Anti-Virus-Software, die von ausländischen Firmen stamme. "Wir empfehlen daher, dass dort, wo ein Zugriff des russischen Staates auf Informationen ein Risiko für die nationale Sicherheit darstellen würde, kein in Russland ansässiges Anti-Virus-Unternehmen gewählt wird", schreibt Martin. Das Zentrum sei derzeit im Gespräch mit Kaspersky über ein Abkommen, damit die Sicherheit empfindlicher Daten gewährleistet werden könne. Kaspersky hat Spionage-Vorwürfe stets bestritten. Auf Anfrage der Deutschen Presse-Agentur hob ein Kaspersky-Sprecher am Samstag hervor, dass die Warnung weder an Privatnutzer noch an Unternehmen gerichtet sei.
(dpa) /
URL dieses Artikels:http://www.heise.de/-3907209
Links in diesem Artikel:[1] mailto:it@ct.de
Copyright © 2017 Heise Medien
Nachdem Reporter ohne Grenzen mit ihrer Klage gegen den BND-Datenstaubsauger vor deutschen obersten Gerichten erfolglos blieb, trägt die Organisation diese nun vor den Straßburger Gerichtshof für Menschenrechte.
Die Aktivisten von Reporter ohne Grenzen (ROG) lassen mit ihrer Klage gegen die "strategische Fernmeldeüberwachung" durch den Bundesnachrichtendienst (BND) nicht locker. Die zivilgesellschaftliche Organisation hat ihre Beschwerde gegen die Massenüberwachung[1] jetzt vor den Europäischen Gerichtshof für Menschenrechte (EGMR[2]) gebracht. Zuvor war sie mit einem einschlägigen Verfahren vor dem Bundesverwaltungsgericht weitgehend gescheitert[3]. Auch der Gang vor das Bundesverfassungsgericht[4] blieb erfolglos: Die Karlsruher Richter nahmen die entsprechende Verfassungsbeschwerde mit einem Beschluss von Ende April nicht zur Entscheidung an.
ROG wirft dem Auslandsgeheimdienst vor, im Zuge seiner heftig umstrittenen Überwachungspraktiken den E-Mail-Verkehr der Organisation mit ausländischen Partnern, Journalisten und anderen Personen ausgespäht zu haben. Es bei den Klagen vor allem um Befugnisse aus dem sogenannten G10-Gesetzes[5], das dem BND umfangreiche Eingriffe ins Fernmeldegeheimnis erlaubt, das in Artikel 10 Grundgesetz verankert ist. So dürfen die Spione etwa einen Datenstaubsauger einsetzen[6], um den internationalen Telekommunikationsverkehr mithilfe bestimmter Suchbegriffe und sonstiger Selektoren zu durchforsten.
BND ) </span>
Die bislang angerufenen obersten deutschen Gerichte sahen ihre Hände gebunden, da ROG nicht habe glaubhaft machen können, dass die Organisation selbst von der BND-Bespitzelung betroffen war. Der geforderte Nachweis ist wegen der Geheimniskrämerei bei dem Nachrichtendienst schwer zu erbringen. In der Klageschrift an den EGMR führt die Vereinigung nun an, dass der BND ihr Recht auf Achtung der Korrespondenz sowie des Rechts auf Meinungs- und Informationsfreiheit gemäß den Artikeln 8 und 10 der Europäischen Menschenrechtskonvention[7] verletzt habe. Die ausufernden Suchkriterien des Geheimdienstes führten zu einer durch den mutmaßlichen Zweck der Maßnahmen keinesfalls gedeckten Reichweite der Eingriffe.
Darüber hinaus macht Reporter ohne Grenzen geltend, in ihrem Recht auf wirksame Beschwerde verletzt worden zu sein. Der weitaus größte Teil der Betroffenen erfahre nicht einmal im Nachhinein etwas davon, "dass ihre E-Mails erfasst und durchsucht werden", schreibt die Organisation. Selbst die Allgemeinheit mit den jährlichen Berichten des Parlamentarischen Kontrollgremiums des Bundestags regelmäßig erst dann über Überwachungsmaßnahmen informiert, wenn sogar entscheidende Protokolldaten schon gelöscht worden seien. Klagen dagegen vor deutschen Gerichten seien unter den aufgeführten Umständen unmöglich.
"Die ausufernde Überwachungspraxis des BND stellt die Vertraulichkeit digitaler Kommunikation grundsätzlich in Frage und untergräbt damit eine Voraussetzung journalistischer Recherche", begründete ROG-Geschäftsführer Christian Mihr den neuen Schritt. Jetzt sei es an den Straßburger Richtern, "dem Grundrecht auf Rechtsschutz vor der anlasslosen und unverhältnismäßigen BND-Massenüberwachung endlich zur Geltung zu verhelfen". Parallel ist der Teil der ursprünglichen Klage gegen das vom BND geführte Metadaten-Analysesystem Veras[8] weiter anhängig; auch eine Verfassungsbeschwerde von Amnesty International gegen den Datenstaubsauger der Schlapphüte läuft noch[9].
Der EGMR beschäftigt sich parallel mit Klagen von Bürgerrechtlern und Nichtregierungsorganisationen[10] gegen die gegen die Internet- und Computerspionage des britischen Geheimdiensts GCHQ[11]. Zu den Beschwerdeführern gehören hier unter anderem Provider, Constanze Kurz vom Chaos Computer Club (CCC)[12] sowie Privacy International. Eine Anhörung dazu fand Anfang November statt[13], bei der die Richter die Hacking-Methoden der Londoner Behörde hinterfragten. Mit einem Urteil des Menschengerichtshof in diesen Fällen ist 2018 zu rechnen.
(Stefan Krempl) /
URL dieses Artikels:http://www.heise.de/-3907198
Links in diesem Artikel:[1] https://www.heise.de/meldung/NSA-Skandal-Reporter-ohne-Grenzen-klagt-gegen-BND-2732465.html[2] http://www.echr.coe.int/[3] https://www.heise.de/meldung/Bundesverwaltungsgericht-lehnt-Klagen-gegen-BND-teilweise-ab-3570480.html[4] https://www.heise.de/meldung/Verfassungsgericht-Reporter-ohne-Grenzen-klagt-gegen-BND-Ueberwachung-3642414.html[5] https://www.gesetze-im-internet.de/g10_2001/[6] https://www.heise.de/meldung/NSA-Ausschuss-Kanzleramt-will-BND-Datenstaubsauger-strenger-regulieren-3356342.html[7] http://www.echr.coe.int/Documents/Convention_DEU.pdf[8] https://www.heise.de/meldung/NSA-Ausschuss-BND-kann-Daten-zu-Kontaktpersonen-schier-unbegrenzt-sammeln-3538172.html[9] https://www.heise.de/meldung/Internetueberwachung-Amnesty-klagt-gegen-BND-Datenstaubsauger-3466588.html[10] https://www.heise.de/meldung/Neue-Klage-gegen-GCHQ-Hacking-vor-dem-Menschengerichtshof-3289446.html[11] https://www.heise.de/meldung/UK-Geheimdienst-Britisches-Gericht-billigt-weitgehendes-GCHQ-Hacking-3103064.html[12] https://www.heise.de/meldung/GCHQ-Ueberwachung-Buergerrechtler-klagen-in-Strassburg-1972227.html[13] https://netzpolitik.org/2017/anhoerung-beim-menschenrechtsgerichtshof-d%20ie-rechtswidrigkeit-der-massenueberwachung/[14] mailto:it@ct.de
Copyright © 2017 Heise Medien
Intels Management Engine (ME) auf dem Chip lässt sich bei Rechnern des Anbieters System 76 per Firmware-Update deaktivieren. Denn die ME war durch Sicherheitslücken ins Gerede gekommen.
Um Bedenken seiner Kunden wegen möglicher Sicherheitslücken oder Backdoors[1] auszuräumen, stellt der amerikanische Anbieter von Linux-Komplettsystemen System 76 ein Firmware-Update bereit, das die Intel Management Engine deaktiviert. Möglich macht dies das sogenannte HAP-Bit, das einen Betrieb als High Assurance Platform einleitet – und auf Betreiben der Sicherheitsdienste Eingang in den Code gefunden haben soll.
Intel baut die Management Engine seit über 10 Jahren in seine Chipsätze und System-on-Chip-Prozessoren ein. Die in der ME enthaltenen Funktionen ermöglichen bei bestimmten Chips unter anderem, einen Rechner aus der Ferne hochzufahren, auch wenn dieser ausgeschaltet ist. Umgehen kann man die ME eigentlich nicht, weil sie wesentliche Systemfunktionen steuert.
Doch bei der Suche nach Sicherheitslücken in der ME[2] entdeckten Experten der russischen Firma PTE auch eine Möglichkeit, die ME ganz abzuschalten. Das macht sich jetzt System 76 zunutze und erledigt dies durch ein Firmware-Update[3]. Der Code kommt bei den hauseigenen Rechnern zum Einsatz und ist auf Github frei verfügbar.
URL dieses Artikels:http://www.heise.de/-3907151
Links in diesem Artikel:[1] https://www.heise.de/ct/artikel/Tipps-zur-Intel-ME-Sicherheitsluecke-SA-00075-3704454.html[2] https://www.heise.de/ct/ausgabe/2017-20-Intel-ME-wohl-weitgehend-abschaltbar-3828734.html[3] http://blog.system76.com/post/168050597573/system76-me-firmware-updates-plan[4] mailto:js@ix.de
Copyright © 2017 Heise Medien
Um den Einsatz von Windows 10 rechtskonform und sicher zu gestalten, lässt der Bund für seine Verwaltung den sogenannten Bundesclient entwickeln. Über dessen Sicherheitseigenschaften schweigt sich das Bundesinnenministerium allerdings aus.
Mit dem Einsatz von Microsofts Betriebssystem Windows 10 in der Verwaltung stellen sich angesichts der hochgradigen Vernetzung des Systems zahlreiche Datenschutz- und -Sicherheitsfragen. Derzeit ist es beispielsweise nicht möglich, über Gruppenrichtlinien die Datenströme zwischen dem eigenen Rechner und den Microsoft-Servern vollständig zu kontrollieren, wie das Bayerische Landesamt für Datenschutzaufsicht (BayLDA) feststellte. [1]
Um doch einen sicheren Einsatz des von Microsoft periodisch aktualisierten Windows 10 in der öffentlichen Verwaltung zu ermöglichen, wird deshalb derzeit vom Informationstechnikzentrum Bund und dem IT-Dienstleister der Bundeswehr BWI ein spezieller „Bundesclient“ entwickelt. Dies entschied Mitte November der zuständige Lenkungsausschuss.
Der „Bundesclient“ ist ein Standard-IT-Arbeitsplatz, wie ihn das Bundeskabinett bereits im Mai 2015 im Rahmen eines Grobkonzepts zur IT-Konsolidierung Bund für die Bundesverwaltung beschlossen hat. Er wird ausschließlich für die Beschäftigten der Bundesverwaltung konzipiert und soll ab 2019 ersten Behörden zur Verfügung stehen. Dabei soll er für verschiedene Endgeräteklassen, so auch für die mobile Nutzung, entwickelt werden.
Das Bundesinnenministerium hat sich vertraglich bei Microsoft sogenannte Downgrade-Rechte zusichern lassen. Damit hat der Bund das uneingeschränkte Recht, ältere Versionen einzusetzen, auch wenn Microsoft ein unter dem Betriebssystem verfügbares Produkt durch eine neue Version ersetzt hat.
Entwickelt wird der Bundesclient von den IT-Dienstleistern des Bundes unter Einbeziehung des Bundesamtes für Sicherheit in der Informationstechnik (BSI) sowie der Bundesdatenschutzbeauftragten. Hierfür sollen mehrere Aufträge an verschiedene Unternehmen vergeben werden. Über den Umfang der geplanten Aufwendungen schweigt sich das Bundesinnenministerium aus. Gegenüber heise online teilte ein Sprecher mit: „Sie können nicht veröffentlicht werden, damit anstehende Ausschreibungen nicht beeinflusst werden.“
Zur Absicherung des Bundesclients wurde eine Sicherheitsinfrastruktur entworfen, über deren Einzelheiten das Bundesinnenministerium ebenfalls Stillschweigen bewahren will, „da die Kenntnis der konkreten Maßnahmen es unbefugten Personen erleichtern würde, zielgerichtet Sicherheitsmechanismen des Bundesclients anzugreifen.“ Es verspricht jedoch, dass eine Verarbeitung von Daten bis einschließlich „VS-Nur für den Dienstgebrauch“ ermöglicht werden soll. Die Entwicklung des Bundesclients und die Abnahme erfolgt im Einvernehmen mit dem BSI und nach Durchführung der erforderlichen Tests. Die Bundesdatenschutzbeauftragte ist im Moment nicht in den Abnahmeprozess involviert und hat kein Veto-Recht.
Das Thema Standardarbeitsplätze ist in der Verwaltung nicht neu. Der IT-Dienstleister Dataport, der die Verwaltung mehrerer Bundesländer mit IT versorgt, hat diese bereits seit 2005 im Portfolio und versorgt zurzeit rund 100.000 Arbeitsplätze. Auch andere IT-Dienstleister auf Landesebene haben Erfahrungen mit Standardarbeitsplätzen. Gegenüber heise online sagte Dataport-Geschäftsführer Johann Bizer, dass eine Standardisierung „grundsätzlich zu begrüßen“ sei. Er fügte aber hinzu: „Ich habe einen Erfahrungsaustausch mit dem Bund bereits mehrfach angeboten.“ Dieser sei sinnvoll, weil der Bund von den Erfahrungen, die die Landes-Dienstleister mit der Konzeption und dem Betrieb von Standardarbeitsplätzen gemacht haben, profitieren könnte.
Bei Dataport werden derzeit Windows-Arbeitsplätze sukzessive auf Windows 10 migriert. Sie müssen allerdings ohne die Online-Services auskommen, da sie analog zu dem Deployment-Modell von Dataport „vollständig abgeklemmt“ sind, wie Dataport versichert.
Die Entscheidung zwischen komfortablem Online-Zugang und datenschutzkonformen Betrieb müssen auch Privatbetriebe fällen, wie das IT-Magazin iX schon im Juni dieses Jahres feststellte [2]. Eine "restriktive Konfiguration ziehe erhebliche Nachteile im Alltagsbetrieb nach sich" war die Quintessenz eines Artikels zur Windows-10-Administration. Generell ist mit der Einführung von Windows 10 das Datenschutzniveau stark gesunken. [3]
URL dieses Artikels:
https://www.heise.de/ix/meldung/Bund-will-Windows-10-ueber-Bundesclient-sicher-nutzen-koennen-3907088.html
Links in diesem Artikel:
[1] http://www.lda.bayern.de/media/windows_10_report.pdf
[2] https://www.heise.de/ix/heft/Kollateralgenerve-3716760.html
[3] http://www.heise.de/ix/heft/Datenschleuder-3356982.html
[4] mailto:js@ix.de
Die Independent System Architecture (ISA) stellt Prinzipien für Microservices auf. ISA definiert grundlegende Eigenschaften von Microservices, die erhebliche Probleme aufwerfen, wenn sie nicht eingehalten werden.
Das Ziel ist, die fundamentalen Konzepte von Microservices darzustellen und nicht nur einen bestimmten Ansatz, Microservices umzusetzen, wie dies Self-contained Systems[1] (SCS) tun. SCS waren schon Thema eines anderen Blog-Beitrags[2].
Es gibt neun Prinzipien:
1. Das System ist in Module aufgeteilt. Module sind eine alte Idee. Das erste Prinzip stellt Microservices in diese Tradition. So wird deutlich, dass andere Modularisierungsansätze Alternativen zu Microservices sein können. Wegen des Modulbegriff treffen auch Konzepte wie Information Hiding auf Microservices zu. Microservices dürfen daher nicht von den Interna anderer Microservices abhängen. Beispiel: Wie Klassen in einem OO-System keine internen Daten anderer Klassen (Instanzvariablen) nutzen dürfen, so dürfen Microservices nicht Daten anderer Microservices direkt auslesen, indem sie beispielsweise auf die Datenbank-Schemata des Microservice zugreifen.
2. Die Module laufen als Docker-Container, Prozesse oder virtuelle Maschinen. Also würde ein Bestellprozess-Modul beispielsweise in einem eigenen Docker-Container laufen. Diese Implementierung unterscheidet ISA fundamental von anderen Modularisierungen und hat einige Vorteile. Beispielsweise können Module in unterschiedlichen Programmiersprachen geschrieben sein oder unabhängig voneinander deployt werden.
3. Die Architektur wird in die Mikro-Architektur, die nur einzelne Module betrifft, und die Makro-Architektur unterteilt, die das gesamte System umfasst. Die Makro-Architektur gibt die minimalen Regeln vor, um die langfristige Evolution sicherzustellen und zu garantieren, dass das System nach außen wie ein System erscheint. Die weiteren Prinzipien sind Teile der Makro-Architektur.
4. Die Integration der Module muss definiert sein. Die Module können synchron, asynchron oder auf der UI-Ebene integriert werden. Das ist notwendig, damit das System am Ende tatsächlich ein System ist und nicht etwa nur Module ohne Zusammenhalt.
5. Kommunikation beispielsweise per RESTful HTTP oder Messaging muss ebenfalls standardisiert sein, damit die Module miteinander kommunizieren können.
6. Jedes Modul hat eine eigene Continuous Delivery Pipeline. Die Module können prinzipiell unabhängig voneinander deployt werden, weil sie als Container umgesetzt sind. Mit einer getrennten Continuous Delivery Pipeline ist ein getrenntes Deployment auch tatsächlich möglich. Da die Pipeline vor allem Tests umfasst, müssen also insbesondere die Test der Module unabhängig voneinander sein.
7. Der Betrieb sollte standardisiert sein. Das betrifft zum Beispiel Logs, Monitoring, Konfiguration und Deployment. Die Standardisierung reduziert den Aufwand, weil so zwar die Anzahl der Containern steigt, aber sie zumindest einheitlich behandelt werden können.
8. Alle Standards sollen auf Ebene der Schnittstelle definiert sein. Eine Kommunikation per RESTful HTTP mit einem festen Datenschema oder ein bestimmtes Monitoring-System auf einem bestimmten Server sind Standardisierungen auf Ebene der Schnittstelle. Wenn die konkrete REST-Bibliothek oder eine Bibliothek für Monitoring vorgegeben wird, wird die Technologie standardisiert. Das schränkt die mit ISA gewonnenen Freiheiten ein. In einem Projekt kann sich natürlich dennoch ein einheitlicher Technologie-Stack durchsetzen und so Aufwände einsparen. Langfristig kann der Stack bei der Evolution des Systems durch einen anderen Stack abgelöst oder ergänzt werden, ohne die Standards zu verletzen. So kann der Technologie-Stack aktualisiert werden, und das System bleibt zukunftssicher.
9. Resilience ist die Fähigkeit eines Moduls, bei einem Ausfall eines anderen Moduls weiter zu funktionieren - gegebenenfalls mit schlechteren Ergebnissen. Das unterbindet Fehlerkaskaden, bei denen der Ausfall eines Moduls andere Module ebenfalls zum Ausfall bringt und so das gesamte System letztendlich ausfällt. Ebenso müssen Module damit umgehen können, dass sie auf einen anderen Server neu gestartet werden. Das erleichtert den Betrieb im Cluster, bei dem Module auf unterschiedlichen Servern laufen müssen und gegebenenfalls Server ausfallen oder gewartet werden müssen.
Dieser Blog-Beitrag bietet nur eine Einführung in die ISA-Prinzipien. Weitere Informationen finden sich unter isa-principles.org[3]. Insbesondere die Begründungen sind für ein besseres Verständnis interessant.
Die gesamte Website steht unter Creative Commons Attribution Share Alike. Der Quellcode der Website findet sich auf GitHub[4] wieder. Wer Verbesserungsvorschläge oder Kritik hat, kann einen Issue einstellen, einen Pull Request erstellen oder an der Diskussion[5] teilnehmen. Ebenso gibt es eine Präsentation[6], die man auch als PowerPoint[7] herunterladen kann und die ebenfalls unter Creative Commons Attribution Share Alike steht.
URL dieses Artikels:http://www.heise.de/-3889160
Links in diesem Artikel:[1] http://scs-architecture.org[2] https://www.heise.de/developer/artikel/Self-contained-Systems-ein-Architekturstil-stellt-sich-vor-3038718.html[3] http://isa-principles.org[4] https://github.com/ISA-Principles/isa-principles.org/[5] http://isa-principles.org/discussion.html[6] http://isa-principles.org/slidedeck/ISA.pptx[7] https://speakerdeck.com/isaprinciples/isa-principles
Copyright © 2017 Heise Medien
Das Implementieren von Bestell- beziehungsweise Bezahlprozessen innerhalb von Webanwendungen kann mitunter recht komplex sein. Die sogenannte Payment Request API[1], die momentan beim W3C ausgearbeitet wird und vor etwa einem Monat zusammen mit den Payment Method Identifiers[2] als "Candidate Recommendation" veröffentlicht wurde, soll hier Abhilfe schaffen.
Die API sieht vor, den Browser als Vermittler zwischen folgenden bei einem Bestellprozess involvierten Akteuren einzusetzen: dem Zahlungsempfänger (beispielsweise einem Online-Händler), dem Zahlungssender (also dem Käufer) und demjenigen, der die Hilfsmittel für eine Zahlung bereitstellt (Kreditkarte etc.).
Folgende Typen werden durch die API bereitgestellt:
Ob die API vom aktuellen Browser unterstützt wird, lässt sich innerhalb einer Website wie gewohnt über Feature Detection prüfen, beispielsweise durch Überprüfung auf das PaymentRequest-Objekt:
FreshRSS if (window.PaymentRequest) {
// Payment Request API wird unterstützt
} else {
// Payment Request API wird nicht unterstützt
}Momentan unterstützen lediglich Chrome, Opera und Microsoft Edge die API[3], in Firefox kann die API als experimentelles Feature über das Flag "dom.payments.request.enabled" unter "about:config" aktiviert werden.
Um eine Bezahlanfrage zu formulieren, erstellt man eine Instanz von PaymentRequest, wobei dem Konstruktor drei Konfigurationsobjekte als Parameter übergeben werden können:
const methodData = { /* siehe Listings unten */ };
const details = { /* siehe Listings unten */ };
const options = { /* siehe Listings unten */ };
const paymentRequest = new PaymentRequest(
methodData,
details,
options
);Über methodData lassen sich die zur Verfügung stehenden Bezahlmethoden angeben. Der Eigenschaft supportedMethods kann dabei ein Array von Kennzeichnern für unterstützte Bezahlmethoden hinterlegt werden:
// Konfiguration der Bezahlmethoden
const methodData = [
{
supportedMethods: ['basic-card'],
data: {
supportedNetworks: ['visa', 'mastercard'],
supportedTypes: ['debit', 'credit'],
}
}
];
Nähere Angaben zu der Bestellung wie etwa Identifikationsnummer einer Bestellung, die zu bestellenden Artikel, Versandkosten etc. lassen sich über das Konfigurationsobjekt details konfigurieren:
// Konfiguration der Bestelldetails
const details = {
id: 'order-123-12312',
displayItems: [
{
label: 'Summe',
amount: { currency: 'EUR', value: '25.00' },
},
{
label: 'Mehrwertsteuer',
amount: { currency: 'EUR', value: '4.75' },
},
],
shippingOptions: [
{
id: 'standard',
label: 'Standardversand',
amount: { currency: 'EUR', value: '5.00' },
selected: true,
},
{
id: 'express',
label: 'Expressversand',
amount: { currency: 'EUR', value: '11.00' },
},
],
total: {
label: 'Gesamtsumme',
amount: { currency: 'EUR', value: '34.75' },
},
};
Über das dritte Konfigurationsobjekt options lässt sich definieren, welche Informationen der Nutzer während des Bestellvorgangs eingeben muss, beispielsweise Name, E-Mail-Adresse oder Telefonnummer:
// Konfiguration der Pflichtangaben
const options = {
requestPayerEmail: true,
requestPayerName: true,
requestPayerPhone: true,
requestShipping: true,
};
Um eine Bezahlanfrage zu starten und damit den entsprechenden Dialog zu öffnen, verwendet man die Methode show() am PaymentRequest-Objekt. Zurück gibt die Methode ein Promise-Objekt, das erfüllt wird, wenn der Nutzer den Bezahlprozess über den Dialog abschließt. Innerhalb des darauf folgenden Callbacks lässt sich dann auf die vom Nutzer eingegebenen Daten zugreifen, üblicherweise um sie zur Überprüfung an den Server zu senden (im Folgenden durch den Aufruf von verify() symbolisiert).
// Hier normalerweise Überprüfung durch Server
const verify = (paymentResponse) => Promise.resolve(true);
Der Aufruf der Methode complete() teilt dem Browser anschließend mit, dass der Bezahlprozess abgeschlossen wurde. Als Parameter lassen sich hier die Werte "success" für eine erfolgreiche Bezahlung oder "failure" bei Auftreten eines Fehlers übergeben. Dem Browser steht es laut Spezifikation dann frei, ob er eine entsprechende Meldung anzeigt oder nicht.
paymentRequest.show()
.then((paymentResponse) => {
// Zugriff auf die vom Nutzer
// eingegebenen Daten.
const {
requestId,
methodName,
details,
shipping,
shippingOption,
payerName,
payerEmail,
payerPhone
} = paymentResponse;
// verify() als imaginäre Funktion, mit der
// die Bezahlanfrage mit der Serverseite überprüft wird
verify(paymentResponse).then((success) => {
if (success) {
console.log('Bezahlung erfolgreich durchgeführt');
return paymentResponse.complete('success');
} else {
console.error('Fehler bei Bezahlung');
return paymentResponse.complete('failure');
}
});
})
.catch((error) => {
console.error('Fehler:', error);
});
Die Payment Request API will Bestell- bzw. Bezahlprozesse innerhalb von Webanwendungen vereinfachen und vereinheitlichen. Wer die API heute schon testen möchte, kann den oben gezeigten Code in einem der zuvor genannten Browser ausführen. Anmerkungen und Verbesserungsvorschläge zur API kann man übrigens über die Issue-Seite[4] des entsprechenden GitHub-Projekts loswerden.
URL dieses Artikels:http://www.heise.de/-3694012
Links in diesem Artikel:[1] https://www.w3.org/TR/payment-request/[2] https://www.w3.org/TR/payment-method-id/[3] http://caniuse.com/#feat=payment-request[4] https://github.com/w3c/browser-payment-api/issues
Copyright © 2017 Heise Medien
Softwareentwicklung findet im Team statt und hat daher einen sozialen Aspekt. Aber wie viel Rücksicht sollte man darauf nehmen?
Für Technologieentscheidungen gibt es viele Einflussfaktoren. Ob es darum geht, serverseitig HTML zu erzeugen oder eine Single-Page App (SPA) zu entwickeln, eine NoSQL-Datenbank oder eine relationale Datenbank einzusetzen, Containerisierung oder Bare Metal zu nutzen: Neben der technischen Eignung beeinflussen auch soziale Aspekte solche Entscheidungen. Wenn alle anderen Faktoren gleich sind, ist die Technologie risikoärmer, mit der das Team bereits gearbeitet hat. Neben Erfahrung spielt auch Motivation eine Rolle: Technologien, die das Team gerne nutzen will, können eine bessere Wahl sein.
Interessant wird es, wenn der soziale Aspekt im Widerspruch zu anderen Aspekten steht. Schließlich haben die Technologien immer bestimmte Stärken und Schwächen. In einigen Situationen sind SPAs die bessere Wahl, in anderen serverseitiges HTML. Relationale Datenbanken und NoSQL-Datenbank sind in unterschiedlichen Situationen unterschiedlich sinnvoll.
Im Extremfall nutzt das Projekt eine unpassende Technologie und Architektur, weil die Team-Mitglieder die Technologie oder Architektur präferieren oder schon Erfahrungen damit haben. So werden die eigentlich passende Technologie und Architektur nicht umgesetzt. Sollte man auch in solchen Situationen so einen starken Fokus auf die soziale Seite der Entscheidung legen?
Hinzu kommt: Ein Pragmatic Prgrammer[1] sollte pro Jahr mindestens eine neue Programmiersprache lernen. Gilt das nicht noch viel mehr für Technologien oder gar Architekturkonzepte? Warum also solche Situationen nicht nutzen, um neue technische Skills zu erlernen?
Technologie- und Architekturentscheidungen haben soziale Aspekte. Diese spielen manchmal aber eine zu große Rolle. Ergebnis: Schlechte Technologiewahl, schlechte Architektur und eine vergebene Gelegenheit, Neues zu lernen.
Danke an meine Kollegen Frederik Dohr, Christoph Iserlohn, Tammo van Lessen, Till Schulte-Coerne, Michael Simons, Christian Stettler und Stefan Tilkov für das Feedback zu einer früheren Version des Blog-Beitrags.
URL dieses Artikels:http://www.heise.de/-3824481
Links in diesem Artikel:[1] https://en.wikipedia.org/wiki/The_Pragmatic_Programmer
Copyright © 2017 Heise Medien
Ein wesentliches Design-Prinzip unter Node.js ist es, den Code getreu dem Motto "small is beautiful" in möglichst kleine, wiederverwendbare Packages zu strukturieren. Bei komplexeren Projekten kann das jedoch schnell unübersichtlich werden, wenn für jedes Package ein eigenes Git-Repository zu verwalten ist. Das Tool "Lerna" verspricht Abhilfe.
Wer unter Node.js oder allgemein in JavaScript ein komplexes Projekt entwickelt und seinen Code getreu dem vorgenannten Motto in viele kleine Packages strukturiert, landet recht schnell bei 50, 100 oder noch mehr Packages. Verwaltet man jedes davon in einem eigenen Git-Repository, artet das schnell in viel Konfigurationsarbeit aus: sei es, um Abhängigkeiten untereinander zu verwalten, Build-Prozesse zu organisieren oder das Deployment zu npm zu steuern.
Aus diesen Gründen strukturieren Entwickler bekannter Frameworks wie Angular[1], React[2], Meteor[3] und Ember[4] oder bekannter Tools wie Babel[5] und Jest[6] ihren Code mittlerweile in sogenannten Monorepositories[7], kurz Monorepos oder auch Multi-Package-Repositories. Die Idee: Statt jedes Package in einem eigenen Git-Repository vorzuhalten, bündelt man zusammengehörige Packages in einem einzelnen Repository.
Die Vorteile liegen auf der Hand: Zum einen muss man sich nicht mit mehreren Git-Repositories "herumschlagen", zum anderen lässt sich der Build-Prozess für alle Module stark vereinfachen und, wie wir gleich sehen werden, auch das Deployment zur npm-Registry. Ein Tool, das hierbei hilft, ist Lerna[8].
Ursprünglich Teil von Babel[9], ist Lerna mittlerweile ein eigenständiges Node.js-Package und kann wie gewohnt über den Package Manager npm als globale Abhängigkeit installiert werden:
$ npm install -g lerna
Anschließend kann das Tool über den Befehl lerna aufgerufen werden, wobei eine Reihe verschiedener Parameter zur Verfügung stehen:
Ein Multi-Package-Repository definiert sich im Wesentlichen durch seine Struktur und über zwei globale Konfigurationsdateien: Zum einen über eine package.json-Datei, die Meta-Informationen für alle verwalteten Packages enthält, zum anderen über eine Konfigurationsdatei namens lerna.json, die wiederum Lerna-spezifische Meta-Informationen enthält. Die einzelnen Packages wiederum werden standardmäßig in einem Unterverzeichnis mit Namen packages einsortiert, sodass die Gesamtstruktur wie folgt aussieht:
multirepo/
node_modules/
packages/
package1/
node_modules/
src/
index.js
package.json
package2/
package3/
package4/
package5/
package6/
package.json
lerna.json
Diese Struktur kann man zwar manuell erzeugen. Alternativ steht aber auch wie oben schon erwähnt der Befehl lerna init zur Verfügung, der zumindest die beiden Konfigurationsdateien automatisch generiert:
$ git init multirepo
$ cd multirepo
$ lerna init
Dadurch wird zum einen das Modul Lerna als Abhängigkeit zu der package.json-Datei hinzugefügt (sofern dort noch nicht vorhanden) und zum anderen die Konfigurationsdatei lerna.json erzeugt. Zu Anfang sieht die Datei wie folgt aus und enthält die Versionsnummer der verwendeten Lerna-Bibliothek, eine Angabe darüber, unter welchem Verzeichnis die Packages liegen sowie eine Versionsnummer, die global für alle Packages gilt. Welche weiteren Konfigurationsmöglichkeiten es hier gibt, entnimmt man am besten der offiziellen Dokumentation[10].
{
"lerna": "2.0.0-beta.38",
"packages": [
"packages/*"
],
"version": "0.0.0"
}Die Struktur der einzelnen Packages in einem Multi-Package-Repositories unterscheidet sich nicht von einem Package, das als Single-Package-Repository verwaltet wird. Das heißt beispielsweise, dass jedes Package weiterhin über seine eigene package.json-Datei verfügt und darüber zum Beispiel auch seine eigenen Abhängigkeiten definiert.
Für Abhängigkeiten hingegen, die nur während der Entwicklung benötigt werden (Eintrag "devDependencies" in package.json) ist es in den meisten Fällen sinnvoll, diese in der globalen package.json eines Multi-Package-Repositories anzugeben.
Das hat mehrere Vorteile: zum einen ist auf diese Weise sichergestellt, dass alle Packages die gleiche Version einer verwendeten Abhängigkeit haben. Zum anderen reduzieren sich dadurch sowohl die Installationszeit als auch der verwendete Speicherplatz für die entsprechende Abhängigkeit, da sie – logisch – nur einmal für alle Packages (und nicht einmal für jedes Package) installiert wird.
Ein ebenfalls nützlicher Befehl ist lerna bootstrap. Dieser sorgt dafür, dass die Abhängigkeiten aller Packages installiert werden. Mit anderen Worten: Lerna ruft für jedes Package den Befehl npm install aus. Aber nicht nur das. Zusätzlich werden für alle Packages im Multi-Package-Repository, die als Abhängigkeit von einem anderen Package im Repository verwendet werden, symbolische Links erzeugt, was – Node.js-Entwickler werden das bestätigen – bei der Entwicklung enorm hilfreich ist. Zu guter Letzt wird dann noch für jedes Package der Befehl npm prepublish aufgerufen, wodurch die in den package.json-Dateien definierten "prepublish"-Skripte[11] ausgeführt werden.
Nimmt einem Lerna bis hierhin schon viel Arbeit ab, wird es bezüglich Deployment beziehungsweise Publishing noch besser. Der Befehl lerna publish sorgt dafür, dass die Versionsnummer für alle Packages, die sich seit dem letzten Release geändert haben, entsprechend hochgezählt wird. Dabei kann über einen kleinen Kommandozeilendialog ausgewählt werden, ob es sich um einen "Patch", einen "Minor Change", einen "Major Change" oder um einen "Custom Change" handelt (nett: Die jeweils neue Version wird in Klammern hinter der jeweiligen Auswahl angezeigt).
Aber nicht nur das: lerna publish sorgt weiterhin dafür, dass entsprechende Tags und Commits für die neue Version in Git erzeugt und alle Packages separat bei npm publiziert werden.
Die Bibliothek Lerna hilft bei komplexen JavaScript-Projekten, die aus mehreren zusammengehörigen Packages bestehen, den Überblick zu behalten: Sie erleichtert die Konfiguration des Build-Prozesses, die Verwaltung über Git und das Publishing zu der npm-Registry. Als Empfehlung sollte jeder Node.js-Entwickler, der mit komplexen Projekten oder einer komplexen Package-/Repository-Struktur zu "kämpfen" hat, bei Gelegenheit mal einen Blick riskieren. Eventuell lohnt sich ja der Umstieg.
URL dieses Artikels:http://www.heise.de/-3718109
Links in diesem Artikel:[1] https://github.com/angular/angular/tree/master/modules[2] https://github.com/facebook/react/tree/master/packages[3] https://github.com/meteor/meteor/tree/devel/packages[4] https://github.com/emberjs/ember.js/tree/master/packages[5] https://github.com/babel/babel/tree/master/packages[6] https://github.com/facebook/jest/tree/master/packages[7] https://github.com/babel/babel/blob/master/doc/design/monorepo.md[8] https://github.com/lerna/lerna[9] https://babeljs.io/[10] https://github.com/lerna/lerna/#lernajson[11] https://docs.npmjs.com/misc/scripts
Copyright © 2017 Heise Medien
Es gibt gute und schlechte Softwarearchitektur – so viel ist klar. Aber gibt es die optimale?
Was ist eine gute Softwarearchitektur? Ist langfristige Wartbarkeit ein Zeichen für eine gute Architektur? Für ein Start-up-Unternehmen ist langfristige Wartbarkeit nicht so wichtig. Wenn es nicht schnell einen ausreichenden Umsatz erzielt, dann wird es vom Markt verschwinden. Langfristige Wartbarkeit hilft erst danach.
Dann ist vielleicht Skalierbarkeit wichtig? Ein System für die Verarbeitung medizinischer Daten kommt vielen Anforderungen nach, die nichts mit Skalierbarkeit und Wartbarkeit zu tun haben. Die Daten müssen sicher sein. Nicht nur vor unberechtigtem Zugriff – sondern auch vor Hardware-Problemen, und sogar bei hoher Last dürfen keine Daten verloren gehen. Es muss protokolliert werden, welche Mitarbeiter welche Daten wann gesehen oder geändert haben. Diese Anforderungen gehen über eine einfach Sichtweise auf Sicherheit hinaus.
Eine wesentliche Aufgabe der Architektur ist, solche Anforderungen zu ermitteln. Wer die Anforderungen nicht kennt, kann sie wohl kaum erfüllen. Leider scheitern viele Architekturen schon an diesem Punkt. Erst auf Basis dieser Anforderungen kann man dann eine technische Lösung entwerfen. Also können Architekturen ohne diese Anforderungen keine guten technischen Lösungen werden.
Die Anforderungen lassen sich in Qualitätsszenarien festhalten. Sie beschreiben konkret, wie sich ein System verhalten soll. Ein Beispiel für ein Qualitätsszenario: "Ein neues Land muss im System unterstützt werden. Die Änderung kann in höchsten 10PT umgesetzt werden."
Eine Qualitätsbaum kann als Überblick dienen und hilft sicherzustellen, dass alle möglichen Kategorien erfasst worden sind. Die "arc42 Documentation"[1] zeigt, wie Qualitätsszenarien und Qualitätsbäume dargestellt werden können.
Am Ende ist jede Architektur wegen anderer Anforderungen individuell und auf den jeweiligen Kontext angepasst. Also gibt es keine allgemeingültigen Best Practices oder die optimale Architektur – sondern nur Lösungen für bestimmte Probleme. Aus denen muss sich der Architekt bedienen – und das macht natürlich auch Spaß!
Architekturen sind spezielle technische Lösungen. Also muss man die Anforderungen des Projekts kennen und dafür eine individuelle Lösung entwerfen. Qualitätsbäume und Qualitätsszenarien helfen.
URL dieses Artikels:http://www.heise.de/-3785166
Links in diesem Artikel:[1] http://docs.arc42.org/section-10/
Copyright © 2017 Heise Medien
