Zimki PaaS<\/a><\/noindex> im Jahr 2006, und etwa zur gleichen Zeit bot Google App Engine eine sehr \u00e4hnliche L\u00f6sung an.<\/p>\nTats\u00e4chlich ist das, was wir jetzt als \"serverloses\" Modell bezeichnen, \u00e4lter als viele Technologien, die heute als \"cloud-native\" bezeichnet werden und fast dasselbe bieten. Wie bereits erw\u00e4hnt, sind serverlose Modelle im Wesentlichen nur eine Fortsetzung des Gesch\u00e4ftsmodells von SaaS, das seit mehreren Jahrzehnten existiert.<\/p>\n
Es ist auch anzuerkennen, dass das serverlose Modell keine FaaS-Architektur ist, obwohl zwischen ihnen eine Verbindung besteht. FaaS ist im Wesentlichen der rechenzentrische Teil der serverlosen Architektur, stellt aber nicht das gesamte System dar.<\/p>\n
Warum all der Aufruhr? Nun, da die Geschwindigkeit des Internetzugangs in Entwicklungsl\u00e4ndern weiterhin rasant steigt, w\u00e4chst gleichzeitig die Nachfrage nach Rechenressourcen. Viele L\u00e4nder mit schnell wachsenden E-Commerce-Sektoren haben beispielsweise einfach keine Recheninfrastruktur f\u00fcr Anwendungen auf diesen Plattformen. Hier kommen kostenpflichtige serverlose Plattformen ins Spiel.<\/p>\n
Probleme serverloser Modelle<\/h1>\n \nDas Problem ist, dass serverlose Modelle... Probleme haben. Verstehen Sie mich nicht falsch: ich sage nicht, dass sie per se schlecht sind oder keinen wesentlichen Wert f\u00fcr bestimmte Unternehmen in bestimmten Umst\u00e4nden bieten. Aber die Hauptbehauptung der \"Revolution\" \u2013 dass die serverlose Architektur die traditionelle schnell ersetzen wird \u2013 wird niemals erf\u00fcllt werden.<\/p>\n
Deshalb.<\/p>\n
Eingeschr\u00e4nkte Unterst\u00fctzung von Programmiersprachen<\/h3>\n \nDie meisten serverlosen Plattformen erlauben es nur, Anwendungen auszuf\u00fchren, die in bestimmten Sprachen geschrieben sind. Das schr\u00e4nkt die Flexibilit\u00e4t und Anpassungsf\u00e4higkeit dieser Systeme erheblich ein.<\/p>\n
Es wird angenommen, dass serverlose Plattformen die meisten g\u00e4ngigen Sprachen unterst\u00fctzen. AWS Lambda und Azure Functions bieten auch eine Wrapper-L\u00f6sung, um Anwendungen und Funktionen in nicht unterst\u00fctzten Sprachen auszuf\u00fchren, obwohl dies oft mit Leistungseinbu\u00dfen verbunden ist. F\u00fcr die meisten Organisationen ist dieser Einschr\u00e4nkung in der Regel nicht sehr relevant. Aber hier ist das Problem. Es wird angenommen, dass einer der Vorteile serverloser Modelle darin besteht, dass unbekannte, wenig genutzte Programme g\u00fcnstiger genutzt werden k\u00f6nnen, da man nur f\u00fcr die Ausf\u00fchrungszeit zahlt. Diese unbekannten, wenig genutzten Programme werden jedoch oft in... unbekannten, wenig genutzten Programmiersprachen geschrieben.<\/p>\n
Dies untergr\u00e4bt einen der entscheidenden Vorteile des serverlosen Modells.<\/p>\n
Vendor-Lock-in<\/h3>\n \nEin zweites Problem mit serverlosen Plattformen oder zumindest mit der Art und Weise, wie sie derzeit umgesetzt werden, besteht darin, dass sie auf Betriebssystemebene normalerweise nicht \u00e4hnlich sind. Es gibt praktisch keine Standardisierung beim Schreiben von Funktionen, beim Deployment und beim Management. Das bedeutet, dass die Migration von Funktionen von einer Plattform zur anderen \u00e4u\u00dferst zeitaufwendig ist.<\/p>\n
Der schwierigste Teil des Wechsels zu einem serverlosen Modell sind nicht die rechenintensiven Funktionen, die in der Regel einfach Codefragmente sind, sondern die Art und Weise, wie Anwendungen mit angeschlossenen Systemen, wie Objekt-Speichern, Identit\u00e4tsmanagement und Warteschlangen, verbunden sind. Funktionen k\u00f6nnen verschoben werden, aber der Rest der Anwendung nicht. Dies steht in vollem Widerspruch zu den versprochenen kosteng\u00fcnstigen und flexiblen Plattformen.<\/p>\n
Einige behaupten, dass serverlose Modelle erst k\u00fcrzlich entstanden sind und es keine Zeit gab, ihre Funktionsweise zu standardisieren. Aber sie sind nicht so neu, wie ich oben bereits angemerkt habe, und viele andere Cloud-Technologien, wie Container, haben sich bereits erheblich verbessert, dank der Entwicklung und breiten Einf\u00fchrung guter Standards.<\/p>\n
Leistung<\/h3>\n \nDie Rechenleistung serverloser Plattformen ist schwer zu messen, zum Teil weil die Anbieter bestrebt sind, Informationen geheim zu halten. Die meisten behaupten, dass Funktionen auf entfernten, serverlosen Plattformen genauso schnell arbeiten wie auf internen Servern, abgesehen von einigen unvermeidlichen Verz\u00f6gerungsproblemen.<\/p>\n
Einige Fakten deuten jedoch auf das Gegenteil hin. Funktionen, die zuvor auf einer bestimmten Plattform nicht ausgef\u00fchrt wurden oder eine Zeit lang nicht ausgef\u00fchrt wurden, ben\u00f6tigen einige Zeit zur Initialisierung. Wahrscheinlich liegt das daran, dass ihr Code auf ein weniger zug\u00e4ngliches Speichermedium \u00fcbertragen wurde, obwohl \u2013 wie bei Benchmarks \u2013 die meisten Anbieter Ihnen nichts \u00fcber die Daten\u00fcbertragung sagen werden.<\/p>\n
Nat\u00fcrlich gibt es mehrere M\u00f6glichkeiten, dies zu umgehen. Eine davon besteht darin, Funktionen f\u00fcr jede Cloud-Sprache zu optimieren, auf der Ihre serverlose Plattform l\u00e4uft, aber das untergr\u00e4bt ein wenig die Behauptung, dass diese Plattformen \"flexibel\" sind.<\/p>\n
Ein anderer Ansatz besteht darin, sicherzustellen, dass kritische Programme f\u00fcr die Leistung regelm\u00e4\u00dfig ausgef\u00fchrt werden, damit sie \u201efrisch\u201c bleiben. Dieser zweite Ansatz steht nat\u00fcrlich ein wenig im Widerspruch zu der Behauptung, dass serverlose Plattformen kosteng\u00fcnstiger sind, da man nur f\u00fcr die Ausf\u00fchrungszeit seiner Programme bezahlt. Cloud-Anbieter haben neue Wege zur Reduzierung kalter Starts eingef\u00fchrt, aber viele von ihnen erfordern ein \u201eScale to One\u201c, was den urspr\u00fcnglichen Wert von FaaS untergr\u00e4bt.<\/p>\n
Das Problem des \u201ekalten Starts\u201c l\u00e4sst sich teilweise l\u00f6sen, indem man serverlose Systeme selbst betreibt, was jedoch mit eigenen Kosten verbunden ist und weiterhin eine Nischenl\u00f6sung f\u00fcr ressourcenstarke Teams bleibt.<\/p>\n
Sie k\u00f6nnen keine gesamten Anwendungen ausf\u00fchren.<\/h3>\n \nLetztendlich ist m\u00f6glicherweise der wichtigste Grund, warum serverlose Architekturen in naher Zukunft traditionelle Modelle nicht ersetzen werden: Sie sind (in der Regel) nicht daf\u00fcr geeignet, ganze Anwendungen auszuf\u00fchren.<\/p>\n
Genauer gesagt, ist es aus Kostensicht unpraktisch. Ihr erfolgreiches Monolith-System wird wahrscheinlich nicht in ein Set aus vier Dutzend Funktionen umgewandelt, die von acht Gateways, vierzig Warteschlangen und einem Dutzend Datenbankinstanzen verbunden sind. Aus diesem Grund ist serverless besser f\u00fcr Neuentwicklungen geeignet. Praktisch keine bestehende Anwendung (Architektur) kann migriert werden. Sie k\u00f6nnen migrieren, aber Sie m\u00fcssen von Grund auf neu beginnen.<\/p>\n
Das bedeutet, dass in der \u00fcberw\u00e4ltigenden Mehrheit der F\u00e4lle serverlose Plattformen als Erg\u00e4nzung zu internen Servern verwendet werden, um rechenintensive Aufgaben auszuf\u00fchren. Dies unterscheidet sie stark von den zwei anderen Formen der Cloud-Technologie \u2013 Containern und virtuellen Maschinen, die einen ganzheitlichen Ansatz f\u00fcr das Ausf\u00fchren von Remote-Berechnungen bieten. Dies veranschaulicht eine der Herausforderungen beim \u00dcbergang von Mikrodiensten zu serverlosen Systemen.<\/p>\n
Nat\u00fcrlich stellt das nicht immer ein Problem dar. Die M\u00f6glichkeit, gelegentlich enorme Rechenressourcen zu nutzen, ohne eigene Hardware kaufen zu m\u00fcssen, kann f\u00fcr viele Organisationen einen echten und langfristigen Vorteil bringen. Wenn jedoch einige Anwendungen auf internen Servern und andere auf serverlosen Cloud-Architekturen gehostet werden, wird das Management auf ein neues Komplexit\u00e4tsniveau gebracht.<\/p>\n
Es lebe die Revolution?<\/h1>\n \nTrotz all dieser Beschwerden bin ich nicht gegen serverlose L\u00f6sungen an sich. Ehrenwort. Die Entwickler sollten jedoch verstehen - insbesondere wenn sie serverlose Modelle zum ersten Mal erkunden - dass diese Technologie keinen direkten Ersatz f\u00fcr Server darstellt. Stattdessen informieren Sie sich \u00fcber unsere Tipps und Ressourcen zur Erstellung serverloser Anwendungen<\/a><\/noindex> und entscheiden Sie, wie Sie dieses Modell am besten nutzen k\u00f6nnen. habr.com<\/a> <\/p>","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"excerpt":{"rendered":"\u041a\u043b\u044e\u0447\u0435\u0432\u044b\u0435 \u043c\u043e\u043c\u0435\u043d\u0442\u044b \u0412\u043e\u0442 \u0443\u0436\u0435 \u043d\u0435\u0441\u043a\u043e\u043b\u044c\u043a\u043e \u043b\u0435\u0442 \u043d\u0430\u043c \u043e\u0431\u0435\u0449\u0430\u044e\u0442, \u0447\u0442\u043e \u0431\u0435\u0441\u0441\u0435\u0440\u0432\u0435\u0440\u043d\u044b\u0435 \u0432\u044b\u0447\u0438\u0441\u043b\u0435\u043d\u0438\u044f (serverless) \u043e\u0442\u043a\u0440\u043e\u044e\u0442 \u043d\u043e\u0432\u0443\u044e \u044d\u043f\u043e\u0445\u0443 \u0431\u0435\u0437 \u043a\u043e\u043d\u043a\u0440\u0435\u0442\u043d\u043e\u0439 \u041e\u0421 \u0434\u043b\u044f \u0432\u044b\u043f\u043e\u043b\u043d\u0435\u043d\u0438\u044f \u043f\u0440\u0438\u043b\u043e\u0436\u0435\u043d\u0438\u0439. \u041d\u0430\u043c \u0433\u043e\u0432\u043e\u0440\u0438\u043b\u0438, \u0447\u0442\u043e \u0442\u0430\u043a\u0430\u044f \u0441\u0442\u0440\u0443\u043a\u0442\u0443\u0440\u0430 \u0440\u0435\u0448\u0438\u0442 \u043c\u043d\u043e\u0436\u0435\u0441\u0442\u0432\u043e \u043f\u0440\u043e\u0431\u043b\u0435\u043c \u043c\u0430\u0441\u0448\u0442\u0430\u0431\u0438\u0440\u0443\u0435\u043c\u043e\u0441\u0442\u0438. \u041d\u0430 \u0441\u0430\u043c\u043e\u043c \u0434\u0435\u043b\u0435 \u0432\u0441\u0451 \u0438\u043d\u0430\u0447\u0435. \u0425\u043e\u0442\u044f \u043c\u043d\u043e\u0433\u0438\u0435 \u0440\u0430\u0441\u0441\u043c\u0430\u0442\u0440\u0438\u0432\u0430\u044e\u0442 \u0431\u0435\u0441\u0441\u0435\u0440\u0432\u0435\u0440\u043d\u0443\u044e \u0442\u0435\u0445\u043d\u043e\u043b\u043e\u0433\u0438\u044e \u043a\u0430\u043a \u043d\u043e\u0432\u0443\u044e \u0438\u0434\u0435\u044e, \u0435\u0451 \u043a\u043e\u0440\u043d\u0438 \u043c\u043e\u0436\u043d\u043e \u043f\u0440\u043e\u0441\u043b\u0435\u0434\u0438\u0442\u044c \u0432\u043f\u043b\u043e\u0442\u044c \u0434\u043e 2006 \u0433\u043e\u0434\u0430, \u043a\u043e\u0433\u0434\u0430 \u043f\u043e\u044f\u0432\u0438\u043b\u0438\u0441\u044c Zimki PaaS […]<\/p>\n","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"author":1,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[688],"tags":[],"class_list":["post-97706","post","type-post","status-publish","format-standard","hentry","category-administrirovanie"],"aioseo_notices":[],"aioseo_head":"\n\t\t\n\t