Wer nicht als Kernaufgabe die Entwicklung von Sicherheitsprotokollen oder darauf bezogenen Code hat, sollte solchen Code nicht schreiben, sondern auf fertige Bibliotheken und Dienste zurückgreifen. Auch kleine Bugs können sonst in diesem Bereich katastrophale Auswirkungen haben.
Was macht eine Plattform fit für moderne Cloud-Anwendungen? Die Liste der möglichen Antworten wäre lang. In dieser Kolumne greife ich drei grundlegende, aus meiner Sicht wichtige Punkte heraus und möchte zeigen, dass .NET und C# in dieser Hinsicht Musterschüler sind.
Der Siegeszug von Software as a Service (SaaS) hat dazu geführt, dass wir daran gewöhnt sind, alle unsere Web-APIs und Webanwendungen über das öffentliche Internet zu erreichen. Aus Benutzersicht ist das eine praktische Sache, einer DevSecOps-Expertin bereitet dieser Gedanke allerdings schlaflose Nächte. Jeder Service, der über das Internet verfügbar ist, ist Ziel von Angriffen. Inwiefern private Endpoints für Azure-Web-Apps hier Abhilfe schaffen können, betrachten wir in diesem Artikel.
Neue Programmiersprachen laden dazu ein, sie aus Neugier und Abenteuerlust auszuprobieren und auf ihre Alltagstauglichkeit zu prüfen. So ist Go für mich interessant, weil es sich perfekt für Containertechnologien eignet. Dann kam mit WebAssembly eine Plattform zum sicheren Ausführen von plattformunabhängigem Code aus dem Web, die meine Neugier weckte, und in deren Folge Rust. So wie Go die Sprache für Containertechnologien ist, so ist Rust die Sprache rund um WebAssembly. Eine der Eigenschaften von Rust ist das ausgefeilte Konzept von Memory Ownership. In diesem Artikel wird dieses Konzept vorgestellt und zum besseren Verständnis mit C# verglichen.
In dieser Kolumne habe ich schon mehrmals über Zero Trust Networking geschrieben. Man verabschiedet sich bei diesem Ansatz von der Annahme, dass irgendein Netzwerk sicher ist. Traditionell unterschieden Firmen früher zwischen dem bösen unsicheren Internet und dem sicheren lokalen Netzwerk. Die Grenze zwischen den beiden wurde von Firewalls bewacht. Diese Denkweise kann in der heutigen Zeit nicht mehr aufrechterhalten werden. Erstens haben unzählige Vorfälle gezeigt, dass lokale Netze speziell in großen Organisationen nicht pauschal sicher sind. Zweitens öffnen sich in der heutigen Zeit viele Firmen und bieten APIs bewusst im öffentlichen Internet an.
Azure Functions bringen viele Eigenschaften mit, die einem die Arbeit erleichtern. Für länger laufende Prozesse sind sie allerdings weniger gut geeignet. Hier helfen Durable und Entity Functions weiter.
Kürzlich habe ich bei einem größeren Kunden, den ich in Sachen Übergang zu Cloud-Computing beraten darf, einen schönen Punkt in einer Präsentation gesehen: „Vom Ticket zum Selfservice“. Gemeint war, dass Entwicklungsteams in Zukunft die für sie notwendigen IT-Ressourcen nicht mehr über Supporttickets anfordern müssen, sondern das selbstständig über entsprechende Portale, APIs oder Scripts in der Public Cloud erledigen können. Ziel sind die Reduktion der Wartezeit und die Steigerung der Produktivität, da das Kommunizieren der Anforderungen und die damit nicht selten verbundenen Missverständnisse entfallen.
In dieser Kolumne habe ich schon mehrmals über Zero Trust Networking geschrieben. Man verabschiedet sich bei diesem Ansatz von der Annahme, dass irgendein Netzwerk sicher ist. Traditionell unterschieden Firmen früher zwischen dem bösen unsicheren Internet und dem sicheren lokalen Netzwerk. Die Grenze zwischen den beiden wurde von Firewalls bewacht. Diese Denkweise kann in der heutigen Zeit nicht mehr aufrechterhalten werden. Erstens haben unzählige Vorfälle gezeigt, dass lokale Netze speziell in großen Organisationen nicht pauschal sicher sind. Zweitens öffnen sich in der heutigen Zeit viele Firmen und bieten APIs bewusst im öffentlichen Internet an.
Azure Functions bringen viele Eigenschaften mit, die einem die Arbeit erleichtern. Für länger laufende Prozesse sind sie allerdings weniger gut geeignet. Hier helfen Durable und Entity Functions weiter.
Kürzlich habe ich bei einem größeren Kunden, den ich in Sachen Übergang zu Cloud-Computing beraten darf, einen schönen Punkt in einer Präsentation gesehen: „Vom Ticket zum Selfservice“. Gemeint war, dass Entwicklungsteams in Zukunft die für sie notwendigen IT-Ressourcen nicht mehr über Supporttickets anfordern müssen, sondern das selbstständig über entsprechende Portale, APIs oder Scripts in der Public Cloud erledigen können. Ziel sind die Reduktion der Wartezeit und die Steigerung der Produktivität, da das Kommunizieren der Anforderungen und die damit nicht selten verbundenen Missverständnisse entfallen.
Meine Twitter-Timeline läuft im Moment über wegen der Diskussionen, ob Microservices nicht ein großer Irrtum waren. Man hört Lobgesänge auf elegante Monolithen. Microservices seien im Betrieb viel zu komplex. Die lose Kopplung der Services führe zu enormem Kommunikationsaufwand und damit schlechter Performance. Getrennte Datenspeicher für jeden Microservice seien der pure Horror angesichts der zigfach duplizierten Datenbestände und der daher notwendigen Datensynchronisation.
Meine Twitter-Timeline läuft im Moment über wegen der Diskussionen, ob Microservices nicht ein großer Irrtum waren. Man hört Lobgesänge auf elegante Monolithen. Microservices seien im Betrieb viel zu komplex. Die lose Kopplung der Services führe zu enormem Kommunikationsaufwand und damit schlechter Performance. Getrennte Datenspeicher für jeden Microservice seien der pure Horror angesichts der zigfach duplizierten Datenbestände und der daher notwendigen Datensynchronisation.
![Portrait: Albtraum menschliches Gesicht [Video]](https://entwickler.de/wp-content/uploads/2014/11/bildschirmfoto_2014-01-21_um_15.51.01-300x200.jpg)
Der Begriff „Wahnsinn“ bekommt durch das neue Projekt des Künstlerkollektivs Milkyeyes auf einmal eine positive Konnotation. Denn das, was sich die beiden...
