Сървърлеса ис нумбер уан. Сложи си го отзад(в бекенда имам предвид, че като те знам, а не почнеш да правиш някакви изродщини) и ще видиш колко ще ти хареса и на теб
от
многото Последно редактирано на 28.05.2021 от Един
от
многото, видяно: 3896 пъти. #39771
Понеже съм водил едно събитие "за serverless" в DEV.BG-то и съм го research-вал и цъкал доста - не е точно така. Яко е, ама си има "бая подводни камъни".
Освен това няма IT архитектура на сериозна компания изградена изцяло на "serverless принцип". За некви малки и средни бизнеси можеш да направиш доста интересни архитектури с добро количество услуги (без да плащаш за server-и, и въпреки това да обслужиш доста потребители), ама ако се опиташ да го скалираш "като за голяма компания" с 30+ системи, интеграции и т.н. ще се озориш доста.
Та "serverless" все още е на ниво "яката технология" - т.е. намира малко практика в сериозните корпорации.
Хипотезата е че лесно може да се скалира фром зиро то хиро касателно ресурсното обезпечение в глобален контекст
Да се скалира какво? Hello world? Всяко приложение? 50% от приложенията? В коя област?
от
многото Последно редактирано на 28.05.2021 от Един
от
многото, видяно: 3879 пъти. #39789
Ще ме накараш да си "извадя презентацията". Ето ти само няколко подводни камъни на serverless.
Един от основните проблеми идва от това, че дори просто Web API приложенийце ти възлиза на 5-10+ Azure Functions. Умножи това по 100 за предприятие с 10+ системи и интеграции и по 1000 за голяма корпорация (с 30-100+ системи, интеграции, 3rd party app-ове и др. циганийки) и сам ще си отговориш "защо serverless не скалира добре?".
Ако ми изградиш "работеща архитектура базирана само на serverless" за компания от рода на SAP, Facebook или др. голяма корпорация, ще те обявя за "Бог на Архитектите".
Единствения тип приложения, за които това може би работи, е такива с кратко живеещи данни в паметта и обмен да информация през базата данни. Т.е. някакви уебаджийски истории.
Понеже съм пълен профан в областта, може и да греша.
За събирачки на данни от mqtt-та и прочее iotaджийски истории също става там особено ако трябва да се попреправят нещо преди да влезнат у базата или където там се пазят.
Аз на тоя етап бих се възползвал от модела за международна експанзия на сравнително нишов събскрипшън сървис тип just below the radar, достатъчно малък за да нема некви лоши хищници около мене и достатъчно благ за да си щракам безгрижно и същевременно да не се занимавам с неизбежните инфрастуктурно административни глупости свързани с растеж отвъд ниво квартална кабеларка.
Вече там евангелистите на модела кво лъжат не ме интересува, секи си има глава и си прави сметката :)
от
многото Последно редактирано на 28.05.2021 от Един
от
многото, видяно: 3863 пъти. #39796
Да, общо взето си покрил основните случаи. По-принцип има "workaround" за да се използва за повече неща, но той не е чисто "serverless". Основно се използват 2 плана за създаване на Azure Functions - Consumption plan (където developer-a плаща само за използваните ресурси) и App Service plan (където се използват "остатъчните ресурси" на сървър/виртуалка заделена за други "основни цели" - което реално погледнато "не е serverless" в истинския смисъл).
Ето и слайд от презентацията дето показах (който пък е копиран от едно курсче в Udemy):
Реално с App Service plan, значителна част от подводните камъни на serverless могат да бъдат избегнати, ама това е "замазване на очите" (т.е. използват се ресурсите на "недоизклатени виртуалки", за които се плаща така или иначе). Т.е. за 100% serverless архитектура (само с Consumption plan) някой яко ще се озори да реализира архитектура на голяма корпорация.
| File | Size | Uploaded | Downloads | MD5 hash |
|---|---|---|---|---|
| azure functions.PNG | 31363 bytes | 28.05.2021 | 201 | d9dd3de997f1d89cf867644c0d1229ba |
На тия нива това би било груба СТРАТЕГИЧЕСКА грешка това понеже даваш на трети страни ШАЛТЕР, не е въпрос на дали а на кога щи го дръпнат или поне изнудват за да не го дръпнат
В това няма нищо лошо, но когато някой започне да ми обяснява как нещо е намбър уан за скалиране на embarrassingly parallel неща, ми става доста смешно.
от
многото Последно редактирано на 28.05.2021 от Един
от
многото, видяно: 3852 пъти. #39800
Ее и това го има - мисля, че няма сериозни корпорации дето да си бутнат critical системите в нечий cloud. Там се градят hybrid cloud-ове, ала бала.
Иначе въпреки, всичките негативи на serverless, аз се радвам, че нещата вървят в тая посока, щото за колкото повече системи може да се плаща само "за ползването", а не за цялата система, толкоз по-добре? Примерно, аз съм писал add-in-и за Outlook и съм виждал повече shit-ни на туй приложение дори от Power User-ите, но и аз съм ползвал едвам 30% от цялата фунционалност (average user-a да ползва 5-6% най-много - имейли, контакти, срещи, task-ове и др.).
Та според мен, със "serverless технологии" нещата на теория ще стават "по-евтини" и "по-автоматизирани", което е добре.
Засега комодитизирането (което е лошо ако бонго го комодитизират) покрай облаци/сървърлеси изглежда засяга основно сисадмини и свързани с това техничари но се наблюдава ясна тенденция за желание за комодитизиране на програматорите. Засега е предимно желание но the writing's on the wall :)
Аз тея лайна като Azure functions ги ползвам за някви парченца тип пращач на emails. Ръгам им в едно queue някви неща и онова праща мейли когато успее. Също имам подобна функция дето рови в базата и решава че трябва да прати някво summary с няква логика. Scheduled tasks общо взето. Също в един друг проект дето от време на време идва някой и казва "а можете ли да се интегрирате с ЕдиКоеСи?" където аз за първи път чувам за ЕдиКоеСи пускам нашите web hooks (това ако не знаете е когато системата позволява да въведеш URL и да ти праща на него съобщение като се случи нещо) и ги насочвам към Azure Function в който пиша там 20тина реда код да обърна нашия формат данни в този дето приема ЕдиКоеСи и после праща на API-то на ЕдиКоеСи. Сега ако поддръжката на ЕдиКоеСи наистина стане важна ще я интегрирам като опция на нашия web hook обаче досега съм го правил това за 6-7 системи и само 1 път наистина станаха клиенти и почнаха да го ползват обилно. Тоест щях да имам супер много ненужен код в системата ако всичко го ръгах в основния проект.
от
многото Последно редактирано на 28.05.2021 от Един
от
многото, видяно: 3842 пъти. #39803
Аз не се притеснявам от тоя процес. Ще цитирам "великия мислител" Вучков - "Другите да му мислят. Ще ме вземат другаде."
Едно, че много от тея технологии са "бъгави" и некой требва да ги support-ва (което си става нова работа вече - DevOps), второ - тоя процес и сега е бавен (в най-бързия случай ще отнеме едно 5 годинки минимум), а дотогава и аз лично ще съм "IT специалист" и ще казвам на хората "Ай ти направи това, ай ти направи онова." А за Гани винаги ще се намери работа.
Реба Създадено на 28.05.2021, видяно: 3834 пъти. #39804
ааа това ли боло ве! аз все се чудех каква е тая нова дума, ей, научих и от тая тема нещо!
Мда, гледам търсенето и заплатите на ДевОпс значително нараснаха покрай клауда. В България стигнаха заплатите за Java.
от
многото Създадено на 28.05.2021, видяно: 3811 пъти. #39806
Най-общо казано е това, макар че DevOps-a включва и др. неща.
Помня едно време дето немаше "преден/front-end", "заден/back-end" и "общак/fullstack" разработчик, а всичко беше "леб разработчик", а сега се навъдиха 50 титли, коя от коя по-сложни и по-безсмислени.
С нетърпение чакам, middleware-a в back-end-a до такава степен да се усложни, че да се появи позиция "middleware developer" и да чета обяви "Търсим middle middleware developer".
Напоследък и AI developer-и почнаха да се появяват (дето пишат некви ботове). Представям си като дойдат "терминаторите" как върху тях ще рънва "CS Bot v1.5" и ще викат "I'm in position... The bomb has been planted." докато трепат хората.
Чай ся, аз винаги съм вярвал че тея фулстек са некакви елфи дето се оправят еднакво добре и с бекенда и с фронтендските чекии, не че реално познавам такива (познавам де ама не се водят фулстек), а ся какво ще излезе че всъщност се справят еднакво зле, а не еднакво добре, бахмааму току-що представите ми се сбъркаха зловещо.