Laden...

REST-API mit Request-URL-Check

Erstellt von Froschkoenig84 vor 5 Jahren Letzter Beitrag vor 5 Jahren 2.830 Views
F
Froschkoenig84 Themenstarter:in
63 Beiträge seit 2015
vor 5 Jahren
REST-API mit Request-URL-Check

Hallo. 😃

Zunächst einmal, ich bin noch kein C#/ASP.NET-Profi.

Ich plane eine relativ einfache REST-API die als Controller zwischen den JS-Clients (JS-Requests) meiner Kunden (bestimmte Kunden-URLs) und meiner serverseitigen Datenbank (BSON/JSONB).

Zunächst sollen folgende Dinge geprüft werden:1. Passen [URL] und [ClientToken] zusammen? - Also ob der Request überhaupt valid/accepted ist. [] Hat der angemeldete Benutzer (via [UserToken]) die nötige Berechtigung, um auf den Controller (Database), Action (Collection), Index (SingleElement) zuzugreifen? [] Sind alle notwendigen Übergabe-Parameter gesetzt, bzw. sind diese gültig/anwendbar?[/list]

Jeder Request soll folgende Token mitsenden: [list][] ClientToken [i](identifiziert den Kunden, der es bei sich auf der Website einbaut und überprüft den Referer/RemoteAddr/RemoteHostIp mit der im Kundenbereich hinterlegten URL)[/i] [] UserToken [i](jeder in meinem System registrierte Benutzer erhält nach dem Login einen lebenslänglichen UserToken, ggf. zusätzlich noch eine SessionId)[/i] [*] RequestToken [i](bei jedem Request wird ein Token mitgesendet, der den Request identifiziert und somit auch serverseitig dokumentiert)[/i][/list]

Der ClientToken repräsentiert quasi den Referer, bzw. den Kunden, der Zugriff auf meine API hat. Der RequestToken ist erstmal rein optional und mehr eine ID, als ein echter Token. Ob es überhaupt eine Session-ID benötigt weiß ich auch noch nicht.

Zu meiner Frage... Ist es möglich in der Global.asax einen der folgenden Werte sicher abzufragen... [list][]Referer [] RemoteAddr [*] RemoteHostIp[/list]...um die URL des abrufenden REQUESTs zu prüfen?

Denn irgendwie muss ja ermittelt werden können, von welcher URL (oder zumindest IP-Adresse) aus, der Request abgesendet, bzw. der Response angefordert wurde. Ich möchte eben verhindern, dass irgendein [URL]http://www.gemeiner-mitbewerber.com[/URL] auf meine API zugreifen kann, indem er sich einfach das Script inkl. ClientToken von einer Kundenseite auf seine eigene Website herüber kopiert.

Falls da jemand eine Lösung hat, immer her damit.
Ich werde außerdem mal prüfen ob Apache, nginx, IIS oder Kestrel bereits einen HostnameLookup überprüft und ggf. Regeln befolgt, wie Zugriff nur für [LISTE VON URLS].
Aber irgendwie würde ich es dann trotzdem gerne nochmal in meiner API prüfen.

Besten Dank im Voraus. 😃

16.807 Beiträge seit 2008
vor 5 Jahren

Ich plane eine relativ einfache REST-API die als Controller zwischen den JS-Clients (JS-Requests) meiner Kunden (bestimmte Kunden-URLs) und meiner serverseitigen Datenbank (BSON/JSONB).

Dann plane bitte mit ASP.NET Core und nicht mehr mit dem alten ASP.NET.
In der neuen, modernen, aktuellen Welt mit Microsoft Support gibt es keine Global.asax. ⚠

Passen

286 Beiträge seit 2011
vor 5 Jahren

**Jeder Request soll folgende Token mitsenden:**1. ClientToken (identifiziert den Kunden, der es bei sich auf der Website einbaut und überprüft den Referer/RemoteAddr/RemoteHostIp mit der im Kundenbereich hinterlegten URL)

  1. UserToken (jeder in meinem System registrierte Benutzer erhält nach dem Login einen lebenslänglichen UserToken, ggf. zusätzlich noch eine SessionId)
  2. RequestToken (bei jedem Request wird ein Token mitgesendet, der den Request identifiziert und somit auch serverseitig dokumentiert)

[..]

Ich möchte eben verhindern, dass irgendein
>
auf meine API zugreifen kann, indem er sich einfach das Script inkl. ClientToken von einer Kundenseite auf seine eigene Website herüber kopiert.

Schau dir mal den IdentityServer4 an. Der kann dir im Prinzip alles liefern was du brauchst. Zwar nicht in der Form wie von dir gewünscht aber du kommst zum gleichen Ziel.

Wie Abt schon erläutert hat, muss du vor allem zwischen Authentifizierung und Authorisierung unterscheiden.

Die meisten Funktionen bietet dir IdSvr per default. Du kannst sowohl deine WebApp als auch deine API damit schützen. So kannst du über den IdSvr festlegen, dass nur bestimmte Clients (hier = Website) auf die API zugreifen dürfen, damit wäre dein "gemeiner Mitbewerber" sofort aus dem Rennen.

Die Authentifizierung läuft normalerweise über User, sprich du musst in deinem Backend nur noch zuordnen, welcher Kunde welche UserIDs hat. Die Authentifizierung übernimmt komplett der IdSvr (ohne dass du selber viel coden musst). Es bleibt also nur noch die Authorisierung und die kannst du sehr leicht über HttpContext.User durchführen.

In diesem sind die Claims des Users enthalten (die UserID, z.B. per default). D.h. du jagst die Anfrage vom Controller in deines Business-Logik und die suchst anhand der UserID, die korrekten Daten. So kann niemals ein Kunde die Daten des anderen Kunden abfragen, da die Entscheidung welche Daten ausgeliefert werden komplett im BAL fällt und nicht durch die URL definiert ist.
Du kannst übrigens auch Rollen verwenden sodass z.B. ein Projektleiter beim Kunden mehr Daten sehen kann, als eine Sachbearbeiter. Kannst du alles nach deinem gusto in der BAL selber definieren.

Und alle deine Kunden rufen die gleiche URL auf, z.B. mydomain.com/profile anstatt für jeden Kunden customer.mydomain.com/profile

Beste Grüße
emuuu

2+2=5( (für extrem große Werte von 2)

F
Froschkoenig84 Themenstarter:in
63 Beiträge seit 2015
vor 5 Jahren

@Abt:

CORE
Klar, Core steht ganz oben auf meiner Liste, sobald ich das Ding unter Linux zum Laufen gebracht habe. 😉 Aktuell kämpfe ich genau damit. 😕 Aber Scott Hanselmann ist ja ein guter Vorreiter. Ich bin nur nicht so fit auf der Linux-Shell.

URL-CHECK
Na ja, eigentlich ist der ClientToken unsinnig. Wichtig ist allein die Identifizierung der URL, von der aus der Request aufgerufen wird. Der Token sollte eigentlich für einen Kunden stehen, somit allerdings auch diversen Daten und Einstellungen, so beispielsweise der eingesetzten URL für die Aufrufe meiner REST-API. - Mir geht es primär darum, verhindern zu können, dass unauthentifizierte URLs (Kunden) auf meine REST-API zugreifen können. Tokens lassen sich kopieren, aber ich vermute, dass es Wege gibt, die Remote-URL abzufragen.

USER-AUTH
API-User-Authentifizierung erfolgt durch einen UserToken. Daher absolut Standard-Prozedere. Wenn ich das mit der Kunden-URL hinbekommen würde, wäre ich auch mit oAuth zufrieden. - Mal sehen. Aber die User-Authentifizierung ist aktuell nicht das Problem. Sondern eben jener URL-Check.

REST-VALIDATE
Auch die Validierung sollte kein Problem darstellen. Da die REST-API nah an RESTfull orientiert sein soll und um keine Special-Methods oder logische Operatoren erweitert wird. 😃 Klar müssen alle Request-Attribute geprüft werden, aber das sollte einfach sein.

@emuuu:

Ich bin immer noch der Meinung, dass sich JWT (wird von ++IdentityServer4 ++verwendet) einfach zu klonen oder zu manipulieren ist, insofern eine der beiden Seiten clientseitig (bspw. JavaScript) verarbeitet wird. Na ja, ... ich bin grundsätzlich ein großer Fan von oAuth, hatte ich auch schon in PHP eingesetzt. Muss nur schauen, wie ich ein Script (bzw. alle Request aus einer bestimmten Remote-URL) identifiziere, ohne dass jemand einfach den Token kopieren kann. - Die User-Auth ist mir dann klar.

Prinzipiell finde ich, ist dieser ++IdentityServer4 ++genau das, was ich suche. Auch wegen dem Unterschied zwischen Kunde und Nutzer. - Komplizierter ist allerdings meine Business-Logik, denn Nutzer sind global und können auch auf verschiedenen Kundenseiten die Requests abfeuern, also egal über welche Kunden-URL. Kunden sind die, die den Service auf ihrer Website anbieten wollen. User sind unabhängig von den Kunden, daher global. Sie können sich also auf allen Kunden-URLs anmelden und den Service nutzen.

Rein fiktives Beispiel:

Stellt euch vor, es gibt eine Datenbank voll mit Kneipen, Restaurants usw... Der User hat einen Account bei eat-n-drink.com und kann dort auch seine Daten verwalten oder schauen, welche Kneipen ihn ansprechen (Ort, Getränke, Essen, Preise, Öffnungszeiten, Fotos, Bewertungen, etc...).

Dann gibt es ja noch die Vergleichsseiten (die sprießen ja derzeit aus jeder Richtung hervor), bspw. wohin-in-berlin.de oder dublin-afterwork.ie. Der "Kunde" (also bspw. wohin-in-berlin.de) kann auf alle für ihn relevanten Daten (Kneipen, Restaurants, Clubs usw...) zugreifen, sein Design/Frontend aber selber auswählen. - Erstmal egal ob nun ein registrierter Nutzer darauf zugreift oder nicht.

Wenn nun aber ein bereits registrierter User über wohin-in-berlin.de darauf zugreift (via Cookie oder Web Storage) oder - falls der Kunde es auf seiner Seite zulässt - sich direkt einloggt, kann der User nun auch sehen, welcher seiner Freunde bereits welche Kneipen besucht hat oder deren Bewertungen lesen, ggf. auch eigene Bewertungen verfassen. Quasi über wohin-in-berlin.de auf die REST-API von eat-n-drink.com darauf zuzugreifen.

Okay, das Beispiel hinkt ein wenig, da es hier sicherlich zu Datenschutz-Konflikten kommen würde (aber ich bin kein Jurist und es ist ein rein fiktives Beispiel, hätten auch Reisebüros und die API eines Fluglinien-Portals sein können). Trotzdem soll aber nun verhindert werden, dass was-geht-ab-in-berlin.x.gp jene REST-API benutzen kann, ohne bei mir einen Kunden-Account anzulegen, diverse Settings zu setzen und natürlich den AGBs zuzustimmen.

M
184 Beiträge seit 2012
vor 5 Jahren

Und die AGB sagen aus, dass der Token nicht veröffentlicht werden darf.
Deine Kunden müssen das dann sauber Serverseitig umsetzen - notfalls durch eine eigene Proxy-API.
Im Idealfall bietest du denen ein SDK an.

Oder was spricht dagegen?

F
Froschkoenig84 Themenstarter:in
63 Beiträge seit 2015
vor 5 Jahren

Ein einfaches Rich-Client über eine clientseitige REST-API wäre mir und vielen Kunden lieber. 😕

286 Beiträge seit 2011
vor 5 Jahren

CORE
Klar, Core steht ganz oben auf meiner Liste, sobald ich das Ding unter Linux zum Laufen gebracht habe. [...] Ich bin nur nicht so fit auf der Linux-Shell.

Der Witz bei ASP.NET Core ist doch, dass die Umgebung relativ egal ist. Nehmen wir Docker: Du kannst exakt das gleiche Projekt problemlos in einen Windows-Container genauso wie in einen Linux-Container packen, ohne Anpassungen.

Ich bin immer noch der Meinung, dass sich JWT (wird von ++IdentityServer4 ++verwendet) einfach zu klonen oder zu manipulieren ist, insofern eine der beiden Seiten clientseitig (bspw. JavaScript) verarbeitet wird.

Also zunächst mal: Nein. Es gibt bestimmt Angriffsvektoren mit denen man ein JWT abgreifen kann, aber das gilt für so ziemlich alles was man baut. Also JWT pauschal als unsicher darzustellen ist schlichtweg Verunglimpfung.

Wenn du vor der Manipulation Angst hast verwende Reference-Token, die werden auf dem IdentityServer abgelegt und können nicht (von außen) manipuliert werden.

Komplizierter ist allerdings meine Business-Logik, denn Nutzer sind global und können auch auf verschiedenen Kundenseiten die Requests abfeuern, also egal über welche Kunden-URL. Kunden sind die, die den Service auf ihrer Website anbieten wollen. User sind unabhängig von den Kunden, daher global. Sie können sich also auf allen Kunden-URLs anmelden und den Service nutzen.

Das ist jetzt kein besonders kompliziertes Verhalten. Für dich gilt Kundenservice = Client und deine Clients kannst du auf dem IdentityServer genauso dynamisch registrieren wie einen User.
Und die ClientID ist genau das was du brauchst wenn du aufwendig die URL des abfragenden Services analysieren willst.

Trotzdem soll aber nun verhindert werden, dass was-geht-ab-in-berlin.x.gp jene REST-API benutzen kann, ohne bei mir einen Kunden-Account anzulegen, diverse Settings zu setzen und natürlich den AGBs zuzustimmen.

Nochmal: CLIENTS.
Du registrierst einen Client (= eine Website = eine URL) in deinem IdentityServer (mit PW und ClientID). Und gibst deiner Website diese Information mit. Wenn also irgend ein nicht von dir registrierter Client versucht die API abzurufen kriegt er einfach nur ein 401 zurück.

Prinzipiell finde ich, ist dieser IdentityServer4 genau das, was ich suche.

Dann benutz ihn und schustere keine eigene Lösung. Keine deiner Anforderungen matcht nicht mit dem IdentityServer und der ist kostenlos, open-source, wird aktiv weiterentwickelt, usw. Eigentlich eine eierlegende Wollmilchsau.

2+2=5( (für extrem große Werte von 2)

16.807 Beiträge seit 2008
vor 5 Jahren

Daher absolut Standard-Prozedere.

Nein.

Aber die User-Authentifizierung ist aktuell nicht das Problem. Sondern eben jener URL-Check.

.. der unnötig ist.

Da die REST-API nah an RESTfull orientiert sein soll und um keine Special-Methods oder logische Operatoren erweitert wird.

Entweder die API erfüllt REST - oder nicht.
"Orientiert" heisst: wird nicht erfüllt.

Siehe auch Evolution einer API: Richardson Maturity Model

Ich bin immer noch der Meinung, dass sich JWT (wird von ++IdentityServer4 ++verwendet) einfach zu klonen oder zu manipulieren ist, insofern eine der beiden Seiten clientseitig (bspw. JavaScript) verarbeitet wird.

Sei mir nicht böse - aber das Thema scheint nicht Deine Stärke zu sein.
JWT ist der absolute Standard und das aktuelle Best Practise Scenario - besonders wenn wir hier auch noch vom On Behalf Flow sprechen.

Zu behaupten das Thema sei klonbar; dann müsstest Du vom Internet im Gesamten Abstand nehmen.
Dazu dass es pauschal unsicher sei: definitiv nicht Dein Thema 😉

Kunden sind die, die den Service auf ihrer Website anbieten wollen. User sind unabhängig von den Kunden, daher global. Sie können sich also auf allen Kunden-URLs anmelden und den Service nutzen.

Du beschreibst Multi Tenancy. Ein Standardfall.

Im Jahr 2018 eine eigene Authentifizierung zu erfinden, und dabei kein tiefgründiges Wissen (ich hab das auch nicht!) zu haben, ist in meinen Augen vorsätzlich fahrlässig.

F
Froschkoenig84 Themenstarter:in
63 Beiträge seit 2015
vor 5 Jahren

Zunächst mal an alle... Vielen Dank für eure Infos.

Ich weiß, dass es für @Abt nicht vorstellbar scheint, dass jemand in eine Programmiersprache wechselt und bereits mit dem ersten Tag, Aufträge oder Stories abarbeiten muss. - Wenn es nach mir ginge, würde ich auch gerne erstmal 1-2 Jahre mit den Fremd-Modulen, Erweiterungen oder zusätzlichen Libs spielen. - Aber ich bin eben genau wegen dieser Projekte von PHP (was zwar in den vergangen Jahren stärker geworden ist, aber noch lang nicht mit Python oder eben .NET mithalten kann) zu C#.NET gewechselt und muss irgendwie mein Brot verdienen.

Ich habe mir jetzt noch mal die exakte Beschreibung des JWTs durchgelesen und dort im Forum einige Beiträge entdeckt, die das ähnlich sehen wie ich. Aber inzwischen ist mir klar, dass die Checksum einfach nicht via JS generiert werden kann, da sie sonst offen läge und somit auch "manipulierbar" wäre. Insofern die Checksum (inkl. Verschlüsselung) auf beiden Seiten im Backend liegt, ist das problemlos nutzbar. - Mir gefällt dieser Standard sogar, da er simpel und durchdacht ist.

Wegen der URLs, ... na ja, wenn der Zugriff auf mein System ausschließlich übers Frontend (bspw. JS) stattfindet, dann liegt der Token offen und kann auch kopiert genutzt werden. Genau dieser Kopien dienen Token ja auch. - Allerdings, sollte die Authentifizierung entweder backendseitig (bzw. nicht öffentlich) stattfinden oder ich muss beim Zugriff eins Client eben die URL prüfen, um sichergehen zu können, dass hier niemand einfach nur einen Token kopiert. Kurz gesagt, müsste der Token beidseitig mit der URL verknüpft sein. 😃

Aber aktuell versuche ich meinem Kunden diesen ganzen Blödsinn von wegen MiddleWare-AccessLayer auszureden. Ich denke, wichtiger ist es, dass er eine möglichst starke REST-API (CRUD, GPPAD) bekommt und ein vernünftiges Verifizierung-Werkzeug. Hier dachte ich an oAuth oder im größeren Stil dann eben den IdentityServer4. - Leider mach ich das derzeit FullStack und finde kaum Zeit für DockerContainer, obwohl ich die Technologie zur Pseudo-Virtualisierung sehr interessant finde. - Ich muss das Produkt erstmal auf den Markt bringen und zwar so sauber und sicher wie es nur geht. Mein Kunde träumt von einem Tool, dessen Frontendausmaße gigantisch werden und aktuell geht mehr Zeit darauf, meinem Kunden Traumschlösser auszureden, als tatsächlich daran arbeiten zu können.

Dazu kommt, dass ich (selbst für einen PHP-Entwickler) als FullStack trotz C#.NET-Core + VueJS + Bootstrap + WebPack ziemlich schwach bezahlt werde - und eben alleine bin. Aber wenn das Ding erstmal läuft, gehört mir ein Teil davon und ich hoffe, dass es sich dann auch wirtschaftlich lohnt. 😃 Wobei ich das Projekt in erster Linie angenommen habe, weil mir der Aspekt und die Idee, sowie die programmatischer Herausforderung gefällt.

**Nochmals vielen Dank an alle. 😃 **
Besonders an @emuuu, denn ich erkenne in dir ein wenig den Mutmacher. 😃 Ich mag solche Menschen, die verschwinden nämlich in der Szene mehr und mehr. 😕

286 Beiträge seit 2011
vor 5 Jahren

Wenn das ganze unter Wirtschaftlichkeits-Aspekten laufen soll und dein Problem zu viel Aufwand ist, dann würde ich in Richtung serverless gehen. Sprich: Du deployst das ganze und hast mit allem was Hosting angeht nix am Hut.

Azure Functions könnte für dich interessant sein, insbesondere weil du die per Request bezahlen kannst. Praktisch zahlst du schon die Ausführungszeit, die wird dir aber nur berechnet, wenn der Service tatsächlich angesprochen wird und nicht für die Zeit in der er ansprechbar ist.

Und das ganze ist skalierbar. Wenn dein Produkt also ein Riesenerfolg wird hast du nicht mit überlasteten Servern zu kämpfen.

Beste Grüße
emuuu

2+2=5( (für extrem große Werte von 2)

F
Froschkoenig84 Themenstarter:in
63 Beiträge seit 2015
vor 5 Jahren

@emuuu

Joa, aber ich denke, das ist ähnlich wie AWS aufgebaut. Die bieten ja inzwischen auch ziemlich coole Cluster, bzw. Virtualisierungen an. Also anstatt eines Serververbundes hat man dann 100 Docker-Einheiten für die Datenbanken, 100 für die statischen Files (Buckets) und 100 für die API... oder so. Der Vorteil bei AWS ist, dass die Server rund um die ganze Welt bereitgestellt werden, was für ein Projekt, das eventuell einen internationalen Charakter hält interessant werden könnte.

Mal sehen. Ich hab das Projekt und auch die Idee jetzt quasi allein übernommen, da mein Compagnon aktuell mit einem großen EK-VK-Projekt beschäftigt ist, das für mich wirtschaftlich sowieso nicht mehr nachzuvoellziehen ist. (Sorry, der kauf irgendwelche Massenware im Ausland billig auf, "veredelt" sie und verkauft sie dann in der westlichen Welt wieder mit 400% oder so ähnlich.)

Na ja, wenn das Produkt nun mein privates ist, muss ich schauen, wie ich es finanziere und ob ich neben meinem normalen Job auch noch genug Zeit finde ein Projekt dieser Größe - ganz alleine - nebenbei aufzuziehen.

Kollegen haben mir geraten erstmal einen "keen prototype" zu basteln und den dann zu publizieren und gleich vom ersten Tag an Werbekunden, Partner usw. zu finden, um 100% der Anteile zu halten, ohne sich zu verkaufen.

Toll ist aber auch, dass nun kein Druck mehr auf mir lastet. Also kann ich in aller Ruhe mal die ganzen .NET-Core-Tutorials durchspielen und dann Stück für Stück den deutlich vereinfachten Prototypen basteln. 😃 Ich meine so schwer kann es nicht sein, eine einfache RESTful/CRUD-API in Core zu bauen. Etwas schwieriger ist die Entscheidung des Frontends... Angular, VueJS, React... oder doch was ganz anderes? Vielleicht auch nur ES6 und ein JS-dyn. CSS. Muss ich mir alles demnächst mal überlegen. Aber ist ja auch nur der Prototyp.

Sobald sich Interesse, Erfolg und Wirtschaftlichkeit signalisieren, müsste ich sowieso ein paar Entwickler organisieren, die das Ding von Grund auf neu aufsetzen. Denn Code-Optimierungen und Refactoring wird dann in 1-2 Jahren nicht mehr funktionieren. 😉

Jetzt wird aus einem programmatischen Projekt ein Business-Projekt und da habe ich wirklich viel hinzuzulernen. Wirtschaftlichkeit, Keen-Business und auch

286 Beiträge seit 2011
vor 5 Jahren

Der Vorteil bei AWS ist, dass die Server rund um die ganze Welt bereitgestellt werden, was für ein Projekt, das eventuell einen internationalen Charakter hält interessant werden könnte.

Azure ist jetzt keine lokale Klitsche aus DE.. sondern Microsoft.

da mein Compagnon aktuell mit einem großen EK-VK-Projekt beschäftigt ist, das für mich wirtschaftlich sowieso nicht mehr nachzuvoellziehen ist. (Sorry, der kauf irgendwelche Massenware im Ausland billig auf, "veredelt" sie und verkauft sie dann in der westlichen Welt wieder mit 400% oder so ähnlich.)

Klingt ein bisschen sehr nach Glücksritter.

Sobald sich Interesse, Erfolg und Wirtschaftlichkeit signalisieren, müsste ich sowieso ein paar Entwickler organisieren, die das Ding von Grund auf neu aufsetzen. Denn Code-Optimierungen und Refactoring wird dann in 1-2 Jahren nicht mehr funktionieren. 😉

Das ist eine grundlegend falsche Herangehensweise á la "Mit dem Mist soll sich mein Zukunfts-Ich herumschlagen".

Ich behaupte einfach mal, dass du keine wahnsinnig neue, disruptive Idee hast. Dafür ist zu viel schon dagewesen.
D.h. höchstwahrscheinlich willst du etwas bestehendes in einer neuen Form zusammensetzen, in der es das bisher noch nicht gibt. Oder kurz: Du willst etwas besser lösen als es bisher gelöst ist.

Und zu sagen "meine Idee ist so gut, dass Kunden über meine schlechte Technik hinwegsehen" halte ich für ein wenig vermessen.

Beste Grüße
emuuu

2+2=5( (für extrem große Werte von 2)

16.807 Beiträge seit 2008
vor 5 Jahren

Davon abgesehen, dass Azure deutlich größer ist als AWS und GDP zusammen, hat AWS ebenfalls ein Serverless-Produkt namens Lambda.

Serverless ist aber auch aktuell ein Hype mit vielen Mythen.
Es ist nicht unter Garantie so, dass Serverless leistungsstärker oder günstiger wäre...

Ansonsten bin ich voll und ganz bei emuuu...
Bei der Herangehensweise - ohne den Mut zu nehmen - ist der Knall quasi vorprogrammiert.
Die Frage ist eigentlich nur, wie sehr es knallt. Aber keine Frage; jeder muss Fehler machen um selbst draus zu lernen - will ich gar nicht infrage stellen 😃
Kritik kann man halt positiv aufnehmen und es als Rückenwind nutzen - oder nicht.

3.003 Beiträge seit 2006
vor 5 Jahren

Davon abgesehen, dass Azure deutlich größer ist als AWS und GDP zusammen

Äh, was? AWS ist mit großem Abstand Marktführer.

LaTino

"Furlow, is it always about money?"
"Is there anything else? I mean, how much sex can you have?"
"Don't know. I haven't maxed out yet."
(Furlow & Crichton, Farscape)

286 Beiträge seit 2011
vor 5 Jahren

AWS ist mit großem Abstand Marktführer.

2+2=5( (für extrem große Werte von 2)

3.003 Beiträge seit 2006
vor 5 Jahren

Ja, eben. Und IAAS ist noch das Segment, das für die Mitbewerber gut aussieht.

Aber ich wollte eigentlich nicht derailen, Entschuldigung.

LaTino

"Furlow, is it always about money?"
"Is there anything else? I mean, how much sex can you have?"
"Don't know. I haven't maxed out yet."
(Furlow & Crichton, Farscape)

16.807 Beiträge seit 2008
vor 5 Jahren

Richtig emuuu; im Sinne des <Workloads> - und das zeigt Deine Grafik - ist AWS "größer" bzw. Leistungsstärker. Das ist halt ein einziger Faktor von vielen.
Das liegt daran, dass AWS eine sehr starke IaaS Plattform ist. Das merkt man auch an deren Service-Stärke, dass die Produkte, die unter IaaS eingestuft werden, maßgeblich sind.
Das resultiert darin, dass AWS die Plattform ist mit dem größten theoretischen Compute-Netz sowie mit dem meisten Traffic (Netflix und Twitch sind beide auf AWS unterwegs, gehören zu den größten Traffic-Verursachern überhaupt); aber auch die Plattform mit der höchsten nicht genutzten Kapatität in prozentualer Hinsicht (jedenfalls sagen das Analysten).

Azure bzw. die Microsoft Cloud Devision ist eine Plattform, die einen sehr sehr starken Fokus auf PaaS bzw. SaaS hat. Es gibt viele SaaS und PaaS Produkte (vor allem Enterprise und Hybrid) auf Azure, die AWS nicht hat - was aber auch an dem unterschiedlichen Fokus liegt. Aber ja, AWS hat auch Produkte, die Azure nicht hat (vor allem in Hinsicht Apps, Online Gaming..).
Dahingehend ist die Compute-Power im Gesamten geringer; die prozentuale Nutzung aber höher.

Schaut man den Umsatz der Cloud Devision gegen AWS an oder die Wachstumsraten, oder die Regionen, oder Anzahl Kunden oder Anzahl Fortune 500 Unternehmen oder Anzahl Dax Unternehmen oder... gilt Azure als größer.

Und natürlich ist AWS nicht "der Marktführer"; wieder so ne Stammtischaussage.

  • Im europäischen Markt hat ganz klar Azure die Nase vorn (wobei in Frankreich zB GCP extrem beliebt ist)
  • Um US Markt ist es AWS
  • In Asia ist es Alibaba; wobei der Markt davon ausgeht, dass auch global Alibaba Google überholen wird - heute sind sie bereits "größer" als IBM (auch wenn das IBM nicht hören mag)
    Aber ehrlich gesagt macht die Diskussion immer Müde.. hätte wohl das Wort "groß" vermeiden sollen...weil letzten Endes muss die Plattform technologisch zum Projekt passen; nicht die reine Compute Power. Mit der gewinn ich kein Blumentopf.

Ich finde einige Produkte in AWS viel besser umgesetzt (zB. Lambda und .NET Core funktioniert viel besser in meinen Augen als Azure's Function v2); auch ist der IO höher.
Die SDKs für AWS und .NET Standard finde ich qualitativ besser als bei Azure... Kubernetes auf AWS ist viel angenehmer...einige Deployments brauchen auf Azure viiiiel zu lang.
So hat jede Plattform seine Vor- und Nachteile und seinen Fokus.

3.003 Beiträge seit 2006
vor 5 Jahren

Ich bezog mich auf die Reports von synergy. Laut denen ist aws mit großem Abstand Marktführer, und zwar a) weltweit und b) besonders bei PaaS. Dort haben sie etwa den vierfachen Marktanteil von MS, die allerdings schneller wachsen. Dass Azure deutlich größer als AWS und GDP zusammen sei, ist jedenfalls das Gegenteil von dem, was alle mir zugänglichen Quellen sagen. Aber was weiß ich schon, bin ja nur Stammtisch-Brabbler.

LaTino

"Furlow, is it always about money?"
"Is there anything else? I mean, how much sex can you have?"
"Don't know. I haven't maxed out yet."
(Furlow & Crichton, Farscape)

Hinweis von gfoidl vor 5 Jahren

Bitte wieder zum Thema "REST-API mit Request-URL-Check" zurückkehren.
Die "Größe" eine Cloud-Anbieters kann ggf. in einem gesonderten Thread stattfinden.