Местни данъци в помощ на семействата, а не на инвеститорите

Post Syndicated from Боян Юруков original https://yurukov.net/blog/2026/mestni-danaci-2/

На 18-ти юни премиерът Радев споделил, че се обмисля прогресивен данък сгради. Това мимолетно изказване се разви в следващите дни с протестни становища на анализатори, строителни инвеститори и финансисти. Беше допълнено от хора в кабинета му с това, че не е ясно как точно ще стане, но се обсъжда актуализирането на данъчните оценки. Преглед както всъщност каза и какво е състоянието в момента може да прочетете от Цветелина Соколова в Медиапул и Таня Петрова в Сега.

Опипване със задни помисли

По същността си, това е политически ход. Никой няма съмнение, че е опит за ухажване на кметове и общински съветници като подготовка за изборите догодина. Години преди да подаде оставка водеше активна кампания за събиране на метни кандидати на постове. С това, както и кадруването в съдебната система се опитваше да следва моделът на идване на власт на Орбан. Не се получи, но сега отново има нужда от тях, за да оцелее това, което ще е не само ефективно втори вот на доверие към кабинета в края на 2027-ма, но и следващата голяма битка за страната с Борисов и Пеевски. Повече доходи за общините значи повече средства за преразпределяне от общинските съвети на фона на все по-трудни за крадене еврофондове.

Това изказване също е и опипване на почвата. Колко ще се приеме, какви идеи ще има, каква политическа цена ще трябва да плати. Аналогичното видяхме при идеите му за въвеждане на прогресивен подоходен данък. Там се опита да внуши, че ще се прави заради задължение от Европейския съюз прехвърляйки негативите върху лошия Брюксел. Доколкото има препоръчки за такава стъпка от международни наблюдатели като МВФ и Световната банка, същото има и за имотните данъци. Не му се получи особено и почти универсално беше отхвърлено от икономистите. Тук препоръчвам да прочетете коментара на Лъчезар Богданов по темата.

Моето мнение за подоходните данъци е, че наистина не е честна сегашната система и следва да са прогресивни. Против съм въвеждането им обаче заради негативните ефекти от самата промяна. Понякога се взираме твърде много в желаният резултат от промените в регулации и данъци – било то намаление или увеличение. Не се разбира и внимава обаче как точно се правят тези промени и дали пътят до този желан резултат не носи повече краткосрочни и дългосрочни щети. В случая – при липса на добър контрол над събираемостта, лесно пране на пари и укриване на доходи, анемични вътрешни инвестиции и лесна мобилност на капитали ще видим намаление на данъчните приходи при отлив на работни места с висока добавена стойност или регистрирането им под друга форма.

При имотните данъци обаче съм на мнение, че е отдавна закъсняла мярка и може да се направи повече, за да не се повишат наемите и цените на имотите. Дори обратното – има шанс да се намалят.

Данъчната оценка като политическа дъвка

Последната реална актуализация в данъчната оценка на имотите в България е през 2007 г. – преди почти 20 години. За този период пазарните цени в цяла България са скочили няколкократно. Когато се върнах в България през 2020-та, купих апартамента си на цена три пъти и половина по-висока от данъчната оценка. Шест години по-късно разликата е вече пет пъти и половина. Актуализацията на тези оценки към пазарни цени е предлагана в парламента многократно, но отпада по политически причини. От една страна никой не иска да изглежда, че вдига данъците, но от друга – строителното лоби работи активно срещу такава мярка, защото ефективно им бърка в джоба.

В момента има хиляди сгради в страната, които стоят на груб строеж или са готови и в тях се живее, но нямат акт 16. Последното понякога е заради бюрокрация в общините, но по-често е заради нарушения при строежа, фалит на строителя или нарочно нежелание да се довърши процеса. В миналото това беше начин да се избягват данъци, но тази дупка беше затворена и след две години на акт 14 вече се дължи местен данък. Това е особен проблем за строителите, които са взели парите на купувачи и са зарязали строежите си. Наскоро получих справка, която показва, че само в София има поне 2500 сгради – предимно жилищни блокове – които са на акт 14 повече от две години, но не са пуснати в експлоатация. Дали са изоставени или се живее в тях не може да знаем – чакам още данни, за да разбера.

Актуализирането на данъчната оценка обаче не е нещо спорно. Винаги се е знаело, че се блокира нарочно. Въпросът е единствено дали някой ще има смелостта и гласовете в парламента, както и дали ще се направи формула за автоматично актуализиране, за да е предвидимо за купувачите и бизнеса, а не зависимо от политически прищявки.

Данък сгради като социален инструмент

Вторият компонент тук е данъчната ставка. В момента законът позволява общините да го слагат между 0.1 и 4.5 на 1000 като за основно жилище има намаление от 50%. София, например, слагат данък сгради на 1.875 на 1000. Не е ясна каква е дефиницията на „основно жилище“ и съществува проблем с декларирането на такова в различни общини. Това означава, че ако сте купили апартамент за 100 хиляди евро преди 10 години, за да живеете в него, то данъчната му оценка ще е не по-малко от 50 хиляди и данъка на година ще е около 45 евро на година. Ако сте купили още няколко такива апартамента като инвестиция, годишният данък ще е по-малко от вечеря в ресторант в София със семейството ви. Това важи както за семейства с деца, така и за инвеститори купуващи десетки апартаменти и цели комплекси.

Смятам, че това е не е редно и трябва да се промени. Предложението ми цели запазване на данъчната тежест при първо жилище и на жилища на частни лица отдадени законно под наем, но драстичен скок при едрите инвеститори, схемите с жилища и това, което аз наричам криптобетон. Има три компонента:

  • Драстично вдигане на границата на ставката не в промили, а в проценти – от 0.3% до 1.5% от данъчната оценка
  • Намалението за основно жилище скача на 90%.
  • Местният данък платен за жилище отдадено под наем се зачита като данъчно облекчение към данъците на физическите лица, но не повече от 75% от дължимите данъци за приходите от наем

С първата точка се вдига между два и три пъти ставката. С втората точка не само се запазва сегашната ефективна ставка за основно жилище, но и в някои случаи се намаля. Например, в момента София е избрала 1.875 на 1000 или 0.1875%. Дори да реши да вдигне ставката пет пъти на .9375%, при новото облекчение няма да има промяна в платения данък за това семейство.

Третата точка позволява да не се вдигне данъка на физическите лица, които отдават апартаменти под наем. При тях ставката ще остане висока, тъй като не е основно жилище, но ще могат да я приспаднат от данъците си. Разбира се, тук доста ще посочат, че мнозинството от хазаите не плащат данъци и няма от какво да приспадат. Тази мярка ще помогне да се изсветли сектора, което е също в полза на наемателите. Не следва да се прави данъчна политика, която пази или по някакъв начин се опитва да не засегне сивата икономика и укриването на доходи.

Ще забележите, че говоря само за собственици физически лица. Тази мярка цели неколкопластов ефект. Първо, много често се пишат имоти на фирми независимо, че се използват изцяло за лични цели, с цел избягване на данъци и изписване на фактури за тях. Второ, много жилища са необитавани – между 25 и 40 по различни оценки – с цел паркиране на капитали. Трето, вече настъпват едри капитали, които строят или изкупуват жилища с цел отдаване под наем. В доста страни в Европа бизнес моделът на последните е довел до пагубни последствия за имотния пазар.

Всичко това води до концентрация на жилища в малък кръг от лица и влошава значително възможността на млади семейства да се сдобият с жилище. Последното води до отлив на свободен финансов ресурс за друга дейност като образование и пътуване. По-важното обаче е че доказано липсата на достъп до по-голяма жилищна площ и добри условия влияе негативно на демографската обстановка. Семействата се решават по-трудно на деца като не могат да си позволят наем или жилище.

Тези мерки правят неизгодно да се държат жилища на мазилка или да се концентрират такива за наем в големи конгломерати диктуващи пазара. В същото време физически лица наемодатели, каквито са огромното мнозинство в България, няма да видят особена промяна в данъчната ставка. Тази мярка ще създаде стимул многото празни апартаменти да бъдат пуснати на пазара, което би качило предлагането и свалило цената на наемите. Основна пречка пред това е недостигът на майстори, които да преведат тези жилища във вид за живеене. Това и сега е проблем покрай бума на пуснатите в експлоатация жилища. Затова някои жилища ще бъдат пуснати в продажба, което ако не да свали, то ще забави и дори спре ръста на цените на имотите.

Отдавна чуваме от архитекти, строители и инвеститори, че цените на имотите били високи, защото не се строяло достатъчно. Настояват, че в градовете ни имало предостатъчно междублокови пространства и градинки, където нямало проблем да се уплътнява повече. В същото време броят на жилищата пуснати в експлоатация надвишава не само населението, но и броят на домакинствата. В този контекст и предвид броят на започналите строеж жилища виждаме не само цените, но и наемите да скачат с бързи темпове. Проблемът тук не е, че няма достатъчно жилища на пазара, а че последният не се ръководни от пазарни принципи. Пратено на пари, липсата на защита на инвестициите и като цяло лошата бизнес среда в България, както и прилива на спекулативни капитали изкривяват пазара до степен, в която създава трудност за семейства да намерят адекватно жилище.

Това създава социален проблем и следва да се разглежда данъчното облагане като инструмент за влияние върху тази социална функция. Виждаме, че свободния пазар, свободията в строителството, неефективността на регулаторите и липсата съдебен контрол над нарушителите довежда до огромни проблеми в градската среда. Предложената горе промяна не цели и не може да адресира това. Инвеститори и спекуланти обаче в немалка степен се радват на същите привилегии замислени като социални, както младо семейство очакващо първото си дете. Това не следва да е така и ако декларираната сега воля не е просто политическа пиратка, имат шанс да се случи.

Разбира се, говорейки за спекула и пране на пари следва да се осъждат с лека ръка всички, които са намерили за добре да инвестират спестяванията си във втори или трети апартамент. Точно обратното – присъдата тук е за държавата, която не е осигурила предвидимост, сигурност на инвестициите, намалена бюрокрация и корупционен риск. В такава среда и липса на прозрачност за рисковете в имотния пазар, подобен избор си е логичен. Не следва обаче подобни инвестиции, дори когато става дума за физически лица, да се приравняват към жилище за обитаване. В единия случай говорим за рискова капиталова инвестиция, а в другия – критичен за съществуването актив. Инвестициите следва да се третират като такива данъчно и ефектът им върху градската среда е достатъчно значителен, за да обоснове предложените мерки.

Възможни ефекти и мерки

Всяка такава промяна – дори само актуализация на данъчните ефекти – могат да имат неочаквани ефекти. Всяка намеса в пазара на строителството, наемите и имотите може да има нежелани ефекти. Дори с по-голяма сила важи същото, когато не се прави нищо. Виждаме го в момента. Нямам съмнение, че дори така въведени мерки ще бъдат намерени начини за заобикаляне на закона, укриване на данъци и други схеми. Такива има и в момента.

В изказванията на хора от кабинета стана ясно, че виждат техническа трудност в липсата на свързаност в местните данъци на общините. Тяхната идея е за прогресивен данък, което значи, че трябва да има споделени данни за броя жилища и кой какво е декларирал някъде. Затова моето предложение не прави такова разграничение и не изисква никаква синхронизация между общините. Последното би било изключително трудно предвид опита от подобни инициативи в миналото. Дори техническата част да се случи, ще има нужда от значителен административен ресурс да се следи къде какво се декларира и проверки след това. Отделно недостатък на мярката е, че поставя юридическите лица на същото ниво като семействата с деца, което е нередно.

Затова за основно жилище следва да се води там където човек има настоящ адрес. Знам, че системата за адресна регистрация не работи добре и причината е контрола. Понякога има и злоупотреби – например се сменя настоящ адрес, за да се гласува другаде или за да се трупат точки за различно училище и детска градина. Това ще стане неизгодно, ако като резултат се увеличи данъчната ставка за жилището. Ако то е съсобственост на няколко души, то всеки ще получи намалението от 90% за жилището, където живее основно. Ако живее под наем на едно място, но притежава жилище на друго, то не може да се каже, че второто е основно жилище така или иначе. Ако имота е приписан на юридическо лице като формалност, то отново говорим за взаимоотношения аналогични на наемодател независимо дали собственик на фирмата живее в него.

Има аргумент, че следва да се направи облекчение за второ жилище. Причината за това е, че има много хора с наследствени такива или вили. Това би било по-сложно административно и изисква отново централизация на информацията, тъй като трябва да се декларира кое жилище се води като почивно. Възможно е да се осъществи и общините биха имали стимул да обменят информация дали другаде няма така подадени декларации, което би било укриване на данъци.

В миналото се обсъждаше друг вариант – данъчната ставка да зависи от това дали някой живее в жилището било то като собственик или като наемател. Това би спестило въртележката с данъчните облекчения, би осветлило пазара на наемите и би извадило много празни жилища на пазара. Тази промяна обаче беше отхвърлена от Конституционния съд с доста спорно решение, че не може да се обвързва данък върху имущество с това как се използва. Всъщност, именно Радев обжалва тогава промените в местните данъци, част от които вероятно ще предложи сам сега. Описаните горе мерки дават възможност за данъчно облекчение, което не попада в обсега на това решение.

Очаквам съпротива срещу тази или подобни мерки, тъй като засягат пряко пазара на нови жилища. В момента излиза практически безплатно да се държат неизползвани вече построените или ако се нанесе в тях – това, което са освободили. Строителите разчитат на това, защото така на пазара излизат предимно това, което са започнали да строят. Разчитат и че остават скрити измеренията на фалити в сектора, изоставените строежи, невъведени в експлоатация и въобще рисковете в имотния пазар. Конкретни предложените данъчни промени няма да променят особено последното, но имат потенциал да раздвижат пазара на имоти създавайки стимул да се освободи паркирания в бетон капитал.

Финансово ще има повече постъпления за общините, от където започна предложението на Радев. Ще има и повече приходи за държавата покрай изсветляването на наемите, ако то се случи. Ако не – поради данъчното облекчение ще има намаление на приходите към хазната. Това обаче е в рамките на децентрализацията, за която Радев говори. Разбира се, ще значи увеличена данъчна тежест най-вече за хората и фирмите инвестирали в множество имоти. Няма да има засегне обаче мнозинството от хората, които притежават жилището си или тези отдаващи няколко такива. Общините могат да изберат ставка, с която дори на намалят данъчната тежест за мнозинството докато в същото време увеличат приходите си от това, което наричам криптобетон.

Технически и административно нищо от тези промени не изисква свързаност на системите на общините. Такава е добра идея по принцип, но би блокирала мерки като споменатите от Радев с години. Една промяна би била справка за настоящ адрес при изчисляването на данъците от общините. Това обаче вече се прави от тях постоянно и всъщност именно те отговарят за този процес. От страна на НАП ще трябва да се предвиди ново данъчно облекчение и промяна на декларацията каква част от приходите са от наеми в страната.

Добре за семействата, зле за инвеститорите

Убеден съм, че много хора ще са срещу това предложение и като цяло срещу всяка актуализация. Чуват се вече аргументи как един и същи доход се облага многократно, как не получаваме нищо срещу тези данъци, как се крадат и как трябва да бъде оправена събираемостта, а не да се вдигат ставките за всички останали. Има различни философии как да се облага икономическата активност и собствеността. Част е подоходна, част е на потреблението, а част е на акумулираните активи. Колкото и абстрактно и наивно да звучи думата, целта винаги е била да е честно.

Събираемостта на данъци, такси и глоби, сивата икономика, неработещата прокуратура са проблеми, за които говорим всеки ден. С местните данъци не може да се решат, но това не значи, че данъчните оценки не са крайно остарели, а спекула, тъмни капитали, а в последно време и хищнически бизнес практики не създават социален проблем допринасящ към демографската криза. Предложените мерки имат потенциал да раздвижат пазара достатъчно, за да променят поведението на играчите в нея, да направят оценката за риска по-консервативна и първото жилище по-достъпно.

Надявам се, че сред псевдо-либертарианските възгласи ще се чуят достатъчно разумни аргументи против предложението ми. Не се съмнявам, че има недостатъци както всяка друга промяна или настоящото положение. Да не се прави нищо често е по-зле, а привидната ненамеса е форма на заемане на страна. В настоящия случай – тази на едрия капитал и инвеститорите.

MiTAC Computex 2026 Booth Tour: Diamond Cooling, 52U Racks, and More

Post Syndicated from Ryan Smith original https://www.servethehome.com/mitac-computex-2026-booth-tour/

While wandering the Computex 2026 showfloor, we visited MiTAC’s booth. The prolific server vendor had numerous products on display, including racks of GPU systems, storage, and even diamond cooled servers

The post MiTAC Computex 2026 Booth Tour: Diamond Cooling, 52U Racks, and More appeared first on ServeTheHome.

Chesterton’s middle finger

Post Syndicated from arp242.net original https://www.arp242.net/chestersons-finger.html

The Chesterton’s fence analogy says that you need to be careful to change
things if you don’t understand why things are the way they are, because there
may be good reasons you haven’t considered yet. This is broadly good advice in
many different contexts, including programming where it can be easy to “fix”
some weird code only to discover there was a reason for the weirdness later on
when things break.

This is Chesterson’s middle finger:

# List all commit body content (but not the subject line)
% git log --no-merges --format=format:'%b' | sed '/^$/d' | wc -l
295

That’s 295 lines of commit text over the last 13 years. In total. The commit
subjects are usually just “fix page A” – even for huge changes – and are
pointless. If I manually remove some dependabot, “revert commit”, and “fix typo”
commit bodies it’s just 167 lines. That’s about one line a month.

There is no other documentation. There are barely any comments in the code.

This is Chesterson’s middle finger: “Yes, we did all these weird things and
we’re not telling anyone why. Haha fuck you.”

This is not the first time I’ve seen a less-than-useful commit log, but it is
the first time I’m hired after everyone else left. There is no one to ask.

In theory there was a three week handover period from the previous developer,
but that was just as communicative as the commit log. Never have I sympathized
more with Jack Bauer’s methods to extract information and I regret not employing
some of them.

There are unfinished refactors. There are left-overs from removed features.
There are features that were added but never linked/used but are still in the
code. There are features no one seems to be using. Overall it seems to suffer
quite badly from Chesterton’s gap (“There isn’t a fence yet? Lets build
fences!” without asking if a fence is actually needed).

Everything is just a big fat middle finger.

Writing well is hard. Writing something vaguely passable is not. By and large
there are three questions to answer: “What are you changing?”, “why are you
changing it?”, and “why is this a good solution?”

Sometimes “Implement new feature X” is enough, although it’s rare there is
nothing more to say – most of the time there is something to say about how/why
it’s added as it is.

If you’re fixing a bug, refactoring or changing things, or making some other
substantial change then it’s very rare there isn’t at least a paragraph or two
to comment on the “what’s changing, why change it, and why is this good?”
questions.

Writing this is not an optional extra; it’s part of the job. If you’re not doing
it then you’re not doing your job as a software developer. It doesn’t need to be
eloquent. It doesn’t need to be perfect English. It doesn’t need to be a
comprehensive essay on the nature of reality. It’s okay to forget something
(although better if you don’t). It just needs … something. Any half-way
serious attempt will be infinitely better than nothing at all.

If you do nothing at all then you’re just giving everyone after you the
finger.

Изкуственият интелект и пазара на труда в ИТ сектора

Post Syndicated from Bozho original https://blog.bozho.net/blog/4595

Изкуственият интелект навлиза в много сектори, но един от тези, в които повишаването на ефективността има най-голям потенциал и технологията е най-развит вид, е ИТ секторът. Изкуственият интелект пише код сам, и макар писането на код да е само част от работата, това може да има сериозен ефект върху пазара на труда. Има и едно усещане сред хора в сектора, че тъсренето се охлажда и има съкращения извън обичайното.
Затова поисках от НАП данни за динамиката на трудовия пазар в ИТ сектора (можете да ги свалите тук) – брой трудови договори по месеци, за всяка от многото длъжности в ИТ сферата.

Резултатът е, че поне на този етап не се вижда ясна негативна тенденция – общият брой на заетите във всички длъжности за последните 3 години расте – от 84 хиляди през юни 2023 до 90 хиляди през май 2026 г., като ръст има всеки месец спрямо предходния. С изключение на последния – май спрямо април 2026 г, с 200 заети по-малко. Ще следя дали това е начало на негативен тренд или временна флуктуация.

Когато влезем на ниво отделни длъжности, картината е същата – ръст навсякъде в последните три години, и спад в последните 1-2 месеца. Спадът в последните 2 месеца на основните 2 позиции: „програмист софтуерни приложения“ и „разработчик софтуер“ е около 100 заети (от общо над 22 хиляди). Разбира се, това не са всички длъжности за програмисти – има „програмист уеб сайтове“, „експерт по проектиране и програмиране“, „програмист-аналитик“ и др. – можете да ги видите в качения по-горе файл.

Разбира се, данните не включват някои други начини на наемане в ИТ сектора – напр. консултанти чрез B2B договор, в който случай експертът е управител, и съответно не влиза в статистиката. Не влизат и граждански договори, и някои freelance отношения през платформи като upwork. Данните не включват и нетехнически персонал на ИТ компании (т.е. самият сектор е по-голям от 90 хиляди). Но дори без тези данни, трудовите договори са достатъчни, за да се отбележи тенденция. Разбира се, гражданските, freelance и консултантските договори в повечето компании се прекратяват първо (тъй като е по-лесно), а чак след това – трудовите. Така че кривата вече може и да е тръгнала надолу, просто през трудовите договори това се отчита със закъснение.

Изкуственият интелект е и възможност, и риск. Но секторът е гъвкав и силен и смятам, че ролята на държавата на този етап трябва да е единствено в облекчаването на регулаторната тежест, за да могат компаниите да са по-конкурентни на тези от други държави (дългосрочните политки по подготовка на кадрите са отделна важна тема)

Материалът Изкуственият интелект и пазара на труда в ИТ сектора е публикуван за пръв път на БЛОГодаря.

Palana (Part 2): Architecting isolation, identity, and auditability for AI agents

Post Syndicated from Grab Tech original https://engineering.grab.com/part-2-palana-architecture

Introduction

In Part 1, we introduced Palana, Grab’s Kubernetes-native secure execution platform for autonomous AI agents. We discussed the underlying need for isolated environments and covered its core design principles: treating isolation as the unit of trust, keeping credentials out of agent hands, and mediating all network access. In this second part, we’ll dive under the hood into Palana’s architecture, look at the agent lifecycle, and share the key lessons we learned from putting this system into production.

Architecture overview

The core request path looks like this:

Figure 1. Palana architecture overview.

The agent pod runs in a namespace owned by one user and one agent. It gets default-deny style network policy, domain name system (DNS), access to required platform services, and a persistent /data volume. Browser traffic enters through Traefik. LLM traffic goes to the LiteLLM wrapper in the gateway namespace. General Hypertext Transfer Protocol (HTTP) and Hypertext Transfer Protocol Secure (HTTPS) egress goes through the proxy namespace. Secrets are read from Vault only by the component authorized to use them.

The operator is responsible for turning a user request into the concrete Kubernetes shape:

  1. The user creates an agent through pcli (Palana command-line interface) or the portal.
  2. Palana writes a UserAgent or Agent custom resource with the raw user identity.
  3. The operator creates the user and agent namespaces, service accounts, role bindings, storage, network policies, and ingress.
  4. The user runs a template or container image.
  5. Admission webhooks inject proxy environment variables and enforce pod-level restrictions.
  6. Logs, policy decisions, and activity signals are emitted to observability systems.

Agent lifecycle

From a user’s perspective, the basic workflow is intentionally small:

./pcli login
./pcli create demo
./pcli secrets add demo GRABGPT_API_KEY token=<token>
./pcli run demo --template claudecodeui

Behind those commands, Palana provisions an isolated execution environment:

  • Namespace: agent-{sanitized-user}-{agent}
  • Service account: bound only to that namespace
  • Storage: an Amazon Elastic File System (EFS)-backed persistent volume claim (PVC) mounted at /data
  • Ingress: an agent-specific hostname protected by Concedo-backed browser auth
  • Egress: forced through platform proxies, except for approved internal platform services
  • Secrets: split between agent-readable and proxy-only Vault paths
  • Policies: proxy egress, network egress, and optional inter-agent peering rules

The same lifecycle is exposed in the portal for users who prefer a browser user interface (UI).

How Palana handles identity

Human authentication uses Concedo OpenID Connect (OIDC). pcli login performs a browser-based authorization code flow with Proof Key for Code Exchange (PKCE) and stores the resulting identity in an isolated kubeconfig. Browser access to agent UIs is protected by OAuth2-Proxy through Traefik forward auth.

The important detail is that Palana keeps the raw user identity, such as an email address, as the authoritative owner on the custom resource. That raw identity is used for Kubernetes role-based access control (RBAC) subject matching. Sanitized forms are used only where Kubernetes object names, labels, namespaces, or Vault paths require safer strings.

This split prevents a common class of identity bugs: the display-safe or path-safe version of a user ID should not accidentally become the authorization subject.

In the future, we will integrate Palana via SPIFFE (Secure Production Identity Framework for Everyone) and SPIRE (SPIFFE Runtime Environment) with the rest of our service mesh, to provide an agentic identity — a combination of user and agent instance id — that can then be controlled as a subset of a user’s capabilities. This gives us a first step into “agents on behalf of users” with cut-down permissions while the wider industry firms up the approaches via Open Authorization (OAuth) and other controls.

How Palana handles secrets

Palana’s Vault layout is designed around least privilege:

kv/agents/{user}/{agent}/{secret}
kv/proxy-secrets/{user}/{agent}/{secret}

The first path is for secrets the agent is allowed to read through its per-agent Vault role. The second path is for credentials the agent can use only through the proxy. For each proxy-only secret, Palana can create an agent-visible placeholder value. The placeholder is inert unless the request goes through the approved proxy path.

This gives teams a practical migration path. Existing clients can often be configured with a token-looking value, while Palana keeps the real token out of the runtime.

How Palana handles LLM access

LLM calls go through litellm-proxy-wrapper, which sits in front of LiteLLM and GrabGPT. The wrapper derives agent identity from Kubernetes context rather than trusting client-provided headers. It then looks up the per-agent GrabGPT credential in Vault and forwards the request to the correct upstream route.

The agent config uses internal base URLs such as:

http://litellm-proxy.gateway:4000/aws/v1
http://litellm-proxy.gateway:4000/unified/v1

That design gives us three useful properties:

  • Agents do not need raw upstream LLM credentials.
  • LLM traffic is attributable to a specific agent.
  • Provider routing and credential handling can evolve centrally.

How Palana handles network access

Network control is split into two layers.

At Layer 3 and Layer 4, Kubernetes NetworkPolicy and Cilium enforce which pods can talk to which namespaces, services, and classless inter-domain routing (CIDR) blocks. Agent namespaces are locked down to the platform paths they need: DNS, Vault, the egress proxy, the LLM gateway, and the Kubernetes application programming interface (API) patterns the platform explicitly supports.

At Layer 7, the proxy policy controls HTTP and HTTPS destinations by host, method, and agent identity. Open Policy Agent (OPA) evaluates per-agent policy. The proxy logs allow and deny decisions in structured form.

This split is deliberate. NetworkPolicy is good at containment. The proxy is good at application-aware decisions and audit. This allows us to be very expressive in the restrictions we place on our agents — by default, they get nothing; if they should have access to an internal service they get only that service, and cannot be used as an entry point to the wider internal environment.

Observability and operations

Palana treats observability as part of the safety model, not a nice-to-have. The platform emits structured logs for proxy decisions, Git activity, LLM requests, agent lifecycle, and idle-shutdown decisions. Operators can query activity by namespace, user, host, decision, or component.

One example is idle shutdown. Long-running agents are useful, but idle workloads consume cluster resources and expand the surface area that platform teams must monitor. Palana’s reaper records the most recent observable activity for each UserAgent. It combines signals from gateway/proxy logs, Git activity, Slack-routed agent messages, and Prometheus network activity. After a configurable idle threshold, it can warn the user and stop the workload while preserving /data, RBAC, namespace, and Vault state.

This is a good example of the platform philosophy: stop the compute, keep the state, and make resumption easy.

In addition, as we move into agentic operations, we use the many signals generated by Palana itself to aid our agents. For example, we have an agent that can monitor user workloads and provide advice and assistance if it spots issues — say, an agent is consistently out of memory (OOM), the ops agent can see that and message the user with instructions on how to increase the allocated memory. We don’t need to special-case every possible issue; instead we have agents that understand Palana logs and are able to communicate with the users themselves.

What we learned

Agent platforms need security controls at the platform layer

Prompt-level guardrails and model policies are useful, but they are not enough. Agents call tools, tools call services, and services use credentials. Palana puts controls where the action crosses a trust boundary: identity, egress, secrets, ingress, Git, and Kubernetes API access.

The user experience matters as much as the control

If the secure path requires every team to learn Terraform, Vault policy syntax, Kubernetes RBAC, and proxy configuration before they can try an agent, teams will work around it. Palana uses pcli, templates, and the portal to make the safe path the easy path.

Separating “can read a credential” from “can cause a credentialed request” is powerful

Proxy-only secrets are one of the highest-leverage design choices. They let agents perform authenticated work without turning the agent filesystem, logs, process environment, or prompt context into a credential store.

A namespace boundary is simple, but it compounds

Per-agent namespaces give us a consistent place to apply RBAC, storage, network policy, logging labels, resource quotas, and lifecycle controls. The pattern is easy to reason about during incidents: identify the namespace, identify the owner, inspect the policy, and isolate if needed.

Long-running agents need lifecycle management

Once agents persist for days or weeks, “run a container” becomes an incomplete product. Users need resume semantics. Operators need idle cleanup. Security teams need audit history. Platform teams need a way to rotate credentials, update images, and stop workloads externally.

What’s next

Palana is increasingly becoming a substrate for larger autonomous systems rather than only a place to run individual agents. Emerging patterns include:

  • Supervisor systems that route work to a pool of scoped agents.
  • Slack-native agents that wake up, handle a task, and scale back down.
  • Remote development environments backed by persistent cloud state.
  • Agent swarms where each worker has a separate namespace and credential scope.
  • Operational agents that investigate platform health and propose or apply small fixes under policy.
  • Security experiments around supply chain monitoring, token rotation, transport layer security (TLS) inspection, and automated isolation.

The north star is not “let every agent do anything”. It is to make useful autonomy boring to operate: attributable, inspectable, revocable, and recoverable.

Conclusion

AI agents are most valuable when they can act in real environments. That is also when they become risky. Palana gives Grab a way to keep both sides of that tradeoff in view: teams can move quickly with self-service agent environments, while the platform keeps isolation, identity, secrets, network access, and auditability as defaults.

We expect the underlying tools and models to keep changing. The platform primitives are more durable. Agents will vary, but they will still need a place to run, a way to authenticate, a boundary around their actions, and a record of what happened.

That is the role Palana is designed to play.

Join us

Grab is Southeast Asia’s leading superapp, serving over 900 cities across eight countries (Cambodia, Indonesia, Malaysia, Myanmar, the Philippines, Singapore, Thailand, and Vietnam). Through a single platform, millions of users access mobility, delivery, and digital financial services, including ride-hailing, food delivery, payments, lending, and digital banking via GXS Bank and GXBank. Founded in 2012, Grab’s mission is to drive Southeast Asia forward by creating economic empowerment for everyone while delivering sustainable financial performance and positive social impact.

Powered by technology and driven by heart, our mission is to drive Southeast Asia forward by creating economic empowerment for everyone. If this mission speaks to you, join our team today!

Minisforum’s Upcoming MS-03 SFF PC Brings More of a Good Thing

Post Syndicated from Ryan Smith original https://www.servethehome.com/minisforums-upcoming-ms-03-sff-pc-brings-more-of-a-good-thing/

At Computex 2026 Minisforum was showing off their upcoming MS-03 mini-PC, the successor to their popular MS-01 and aiming to bring more of a good thing with Intel’s new Panther Lake platform

The post Minisforum’s Upcoming MS-03 SFF PC Brings More of a Good Thing appeared first on ServeTheHome.

Upgrading Lambda function runtimes at scale with AWS Transform custom

Post Syndicated from Brian Krygsman original https://aws.amazon.com/blogs/compute/upgrading-lambda-function-runtimes-at-scale-with-aws-transform-custom/

When you create an AWS Lambda function, you choose the runtime that Lambda will use to run your code. This includes the base language version and supporting libraries. Lambda runtimes follow a published deprecation schedule. This means that you must periodically upgrade your function’s runtime.

Running on a deprecated runtime means potential security exposure, loss of AWS Support, and compliance challenges. For teams managing dozens of functions, this is a manageable maintenance task. For teams managing hundreds or thousands, it becomes a significant engineering effort that competes with feature work.

You can modernize your code and configurations with AWS Transform custom, an Agentic AI service purpose-built for code modernization. It fits into each stage of a runtime upgrade: surfacing risk, confirming test coverage, code transformation, and validation. The same workflow scales from a single function to an entire organization. You can use AWS-provided transformations or create your own, for compliance or compatibility. You can give it feedback to enforce your standards. You’re charged only for active agent work during server-side operations, not for user idle time or client-side processing.

This post addresses two audiences. If you work in an application team, you will learn how to use AWS Transform custom to upgrade your functions with confidence. If you’re part of a centralized platform team, you will see how to orchestrate Lambda upgrade campaigns at enterprise scale.

The upgrade challenge

Python and Node.js are two of the most widely used Lambda runtimes, and both have important recent or upcoming deprecation timelines.

Runtime Deprecation date
Node.js 20 April 30, 2026
Node.js 22 April 30, 2027
Python 3.9 December 15, 2025
Python 3.10 October 31, 2026

Sometimes a runtime upgrade requires changing your functions’ configuration in your infrastructure-as-code template or in the Lambda console. Other times, you also need to upgrade dependencies or even make code changes.

For example, in Node.js 24 AWS removed support for callback-based function handlers, in favor of the more modern async/await pattern which Lambda has supported since Node.js 8. Functions using the old pattern must be refactored. This is a behavioral change which affects every callback-based handler in the code base.

Before:

exports.handler = function(event, context, callback) {
    const result = processEvent(event);
    callback(null, result);
};

After:

exports.handler = async function(event) {
    const result = await processEvent(event);
    return result;
};

Applying this type of transformation across multiple Lambda functions used to require manual code changes. With AWS Transform custom, you can automate the upgrade to free your team’s capacity and focus for differentiated work.

AWS Transform custom for application teams

We assume you have AWS Transform custom already set up. For guidance, see the AWS Transform custom documentation. You can also use AWS Transform custom through the Kiro Power.

Prerequisites

Make sure you have the following configured locally:

Run a documentation transform

For your first transform, you can run the AWS-provided “AWS/comprehensive-codebase-analysis” transformation on a representative function or code base. This produces a prioritized view of the upgrade effort before a single line of code is changed, helping you plan your upgrade. Better-documented functions are easier to assess, maintain, and hand off. Running a documentation transform is a low-risk first step: it doesn’t change function behavior and lets you build familiarity with the AWS Transform custom workflow.

When you run the code analysis transformation, add additionalPlanContext to inform AWS Transform custom that you plan to upgrade your Lambda function runtimes. It can flag functions most likely to require code changes. For example, functions with callback-based handlers, complex async/callback code, or low test coverage.

atx custom def exec \
    --code-repository-path . \
    --transformation-name AWS/comprehensive-codebase-analysis \
    --configuration additionalPlanContext="Include analysis of Lambda function runtime upgrade to Node.js 24"

The following figure is a screenshot from running the preceding command on a sample code base.

Example AWS Transform output from documentation transform

Validation planning

Before an upgrade, you must verify correctness. This provides the confidence that you haven’t introduced new issues by upgrading. Test coverage from unit and integration tests helps with verification. A passing test suite can enforce the behavioral contract for the transformed code and help prevent problems.

Observability tools like metrics and alarms can help you validate your changes after they’ve been deployed. They can help you detect when breaks happen and are critical for finding the underlying cause.

If you’re not comfortable with your test or monitoring coverage, you can use AI agents to help. You can create a custom transformation definition in Transform custom to add or improve your tests or add alarms to your infrastructure as code (IaC) template. You can also use Kiro or other agents to generate tests from function specs, covering expected inputs, outputs, and error paths.

Transform

Now that you’ve used the documentation transformation to familiarize yourself with the tool and confirmed you have a way to validate your upgrade, you can use AWS Transform custom to upgrade your functions to a new runtime.

To apply the transform, use the AWS Transform custom CLI or Kiro Power. The example command below runs the “AWS/lambda-nodejs-runtime-upgrade” transformation against the code in the current directory. You can use additional switches to automatically trust all tools and run non-interactively.

atx custom def exec \
    --code-repository-path . \
    --transformation-name AWS/lambda-nodejs-runtime-upgrade \
    --configuration additionalPlanContext="Target Node.js 24"

Transform custom follows the instructions in the transform definition and additional plan context you specify. You can tell it to focus on a specific Lambda function in your code repository or upgrade all the functions it finds. Transform custom identifies callback-based handlers and refactors them to async/await. It handles edge cases including callbackWaitsForEmptyEventLoop and mixed async/callback patterns.

Dependency analysis flags packages with known incompatibilities with Node.js 24 and replaces them. Configuration updates change the Lambda runtime from nodejs22.x to nodejs24.x. AWS Transform custom self-debugs on build or test errors and commits changes to git incrementally on a separate transformation branch. You can also share feedback along the way, which is captured as Knowledge Items that can be applied to future transformations.

The following figures are screenshots from running the preceding command on a sample code base.

Screenshot of AWS Transform custom CLI output. It shows a sequence of tasks relating to Node.js upgrade. AWS Transform explains each task in natural language and states which tools are being used.

Screenshot of AWS Transform custom CLI output. It shows a transformation summary report at the end of the documentation transformation run. The report describes the status of each stage in the process (all ‘Yes’) and the summary summarizes the files to be upgraded.

Validate

AWS Transform custom validates defined exit criteria before marking the transformation complete.

Exit criteria can include:

  • All handlers run without errors on Node.js 24.
  • All tests pass, including generated callback behavior tests.
  • All dependencies confirmed compatible with Node.js 24.
  • Runtime configuration updated to nodejs24.x.
  • Additional requirements added with additionalPlanContext.

The newly transformed code remains in the transformation branch until you’re ready to merge and deploy. You can review logs of the transformation process captured by Transform. You can also run additional validation on the new code, including security scans or more complex test suites like performance or penetration tests. Because the changes are on a separate git branch, you can follow your standard code review, testing, and deployment processes. For extra safety, you can deploy using Lambda traffic shifting with Versions and Aliases, which you can use to roll back.

AWS Transform custom for platform teams

The preceding workflow works well for application teams managing tens or hundreds of functions across a few repositories. But what if you’re a platform team coordinating upgrades across thousands of functions in multiple AWS accounts?

In that case, you must orchestrate upgrades across teams and repositories. In some cases, you might apply the upgrades yourself. In other organizations, you focus on coordination and keep ownership of the upgrades distributed. In both approaches you need visibility to the breadth of the challenge, and tools to monitor progress. Transform custom campaigns can help.

Initiating and tracking an upgrade campaign

Platform teams create campaigns through the AWS Transform custom web application. Log in to the web application, create a workspace, and describe your goal. For example, “I want to upgrade all Lambda functions from Node.js 22 to Node.js 24.” AWS Transform custom displays matching transformation definitions and generates a campaign with a unique campaign ID and CLI command. Note: the command includes --trust-all-tools and --non-interactive switches, meaning it will run without tool prompts or user assistance.

atx custom def exec \
    --code-repository-path <path-to-repo> \
    --non-interactive \
    --trust-all-tools \
    --campaign <campaign-id> \
    --repo-name <repo-name> \
    --add-repo

You can identify candidate functions in your organization with AWS Trusted Advisor, the AWS CLI, Amazon CloudWatch, or AWS Config. To distribute upgrade responsibility, map the functions to owners using Tags or deployment metadata in AWS CloudTrail or your continuous integration and delivery (CI/CD) pipeline. Then share the campaign command with them.

Run the command against each target repository. When the command runs, it automatically registers the repository with the campaign. It then begins the upgrade based on the configuration the platform team chose when creating the campaign.

The AWS Transform web application dashboard tracks campaign progress at a glance. It shows total repositories registered in the campaign and how many are completed, in progress, or not started. It also reports success and failure rates along with transformation results and validation summaries.

The following figures show examples of dashboard visualizations.

AWS Transform console screenshot showing progress of a transformation campaign. The pie chart shows 10 of 10 repositories upgraded. The data shows 73 files and 407 lines of code modified, and the validation rate is 100%.

AWS Transform console screenshot showing a breakdown of files changed and lines of code modified for each of 10 repositories in the upgrade campaign.

AWS Transform report showing estimated saved time of 326 hours.

Scaling with cloud infrastructure

AWS also provides Open Source infrastructure that can automate parallel transform execution using AWS Batch and AWS Fargate. This solution moves processing to the cloud from individual developer machines to help you move more quickly, and includes:

  • REST API: submit single transformations or batches of thousands.
  • Serverless compute: AWS Batch with Fargate runs transformation jobs in parallel.
  • Automatic credential management: AWS Identity and Access Management (IAM) credentials auto-refresh, avoiding long-lived access keys.
  • Multi-language container: pre-built container supporting Java, Python, and Node.js with build tools included.

The default configuration supports up to 128 concurrent transformation jobs, with automatic queuing and resource management. For detailed implementation guidance, cost information, and code, see Building a scalable code modernization solution with AWS Transform custom.

Note: AWS Batch and Fargate incur additional charges beyond AWS Transform custom. See README for cost details.

Clean up

AWS Transform custom charges for active agent work during server-side operations. To avoid ongoing charges, stop any running transformations. See the AWS Transform pricing page for details.

If you deployed the scaling infrastructure, follow the cleanup instructions.

Conclusion

You can streamline Lambda runtime upgrades with AWS Transform custom, an Agentic AI service purpose-built for code modernization.

Customers with a backlog of existing functions to upgrade can use Transform custom to coordinate and streamline bulk upgrades across their organization. Transform custom also helps you move from the tail of the release cycle to the leading edge. By making runtime upgrades faster and more straightforward, you can stay ahead of the challenges of deprecation and take advantage of better performance and new features from newer runtimes.

AWS Transform custom fits into each stage of the software development lifecycle: surface risk early, confirm validation coverage, transform, validate, deploy. It can work with your existing code management, build, test, and deployment, giving you control over changes using your existing processes and tools.

Start with the documentation transform on a function today to get hands-on with AWS Transform custom. Review the currently-deprecated runtimes and make a plan to upgrade.

For more information, see AWS Transform custom documentation and Getting Started topic in the AWS Transform User Guide.

For more serverless learning resources, visit Serverless Land.

About the authors

Brian Krygsman

Brian Krygsman

Brian is a Senior Solutions Architect at Amazon Web Services. He has an application development background and technical depth in event-driven architectures and serverless development. He works with enterprise customers to effectively leverage cloud when building scalable, fault-tolerant, high-performant, cost-effective solutions.

Jonathan Tuliani

Jonathan Tuliani

Jonathan is a Principal Product Manager with AWS Lambda. Based in Dublin, Ireland, Jonathan is responsible for Lambda’s programming language runtimes. He bridges between customers and engineering teams to define strategy, prioritize investments, and design features that solve real-world customer problems.

Седмицата (15–20 юни)

Post Syndicated from Йовко Ламбрев original https://www.toest.bg/sedmitsata-15-20-yuni/

Седмицата (15–20 юни)

Въпросът на седмицата, който вълнува политическите наблюдатели в целия свят, е загуби ли Тръмп войната в Иран. Оценките са далеч от еднозначни, но дори сред привържениците на президента в Републиканската партия се чуха твърдения, че това развитие е най-тежката външнополитическа грешка на САЩ от десетилетия насам. Разбира се, тези оценки щяха да имат значение, ако и подписаният меморандум имаше значение – а в това никой не изглежда да е сигурен.

У нас също малко неща изглеждат сигурни. Все още няма представен бюджет, а почти преполовихме годината. Затова пък парламентът позволи на правителството да изтегли до 3,8 млрд. евро допълнителен държавен дълг за финансиране на бюджетен дефицит. Съвсем несигурни изглеждат и реформите, очаквани от кабинета Радев – и тези в държавната администрация, и тези в съдебната система. За сметка на това обаче доскорошният президент е пределно ясен по отношение на новия пакет санкции срещу Русия… с православни аргументи. Приоритети!

И Делян Пеевски изглежда непоклатим, макар и черупката на лидерството му в ДПС да се понапука напоследък. Рано е да проличи дали усилията му да обедини партията със законодателни предложения по теми, които са емоционални за мюсюлманската общност, ще спрат разпадането на локални структури и ще поправят слабия електорален резултат. Зависи от това дали „Прогресивна България“ ще успее да измести ДПС в местното управление, или българските турци ще продължават да гласуват както досега. Засега Пеевски олеква, но не достатъчно, за да потъне, смята Емилия Милчева.

Пеевски олеква. Не съвсем, не съвсем

Пеевски изглежда непоклатим, но под повърхността се виждат първите пукнатини. Отцепления в ДПС, битка за смесените райони и амбициите на Радев очертават възможно пренареждане на политическите мрежи, които години наред крепят едни и същи играчи на власт. Но нека не бързаме… От Емилия Милчева.

Управляващата партия обаче не за първи път демонстрира, че прогресивността е само куха част от названието ѝ. Личи от декларацията ѝ в подкрепа на т.нар. Шествие за семейството. Това е онзи тип „подкрепа“, която избира „правилното“ и зачерква „неправилното“. Според Светла Енчева България навлиза в нов етап на отношение към човешките права и демокрацията – и по-точно заглавие на текста ѝ от „Добре дошли в държавния регрес!“ едва ли може да се намери.

Добре дошли в държавния регрес!

Днес езикът на „традиционните ценности“ все по-често измества езика на демокрацията. Как стигнахме дотук и защо отношението към ЛГБТИ+ хората се оказва показателно за по-дълбока промяна в държавата и в обществото? От Светла Енчева.

Съвременните палиативни грижи не са „медицински грижи в края на живота“, а комплексен подход, който цели да направи живота на хората с тежки заболявания по-пълен и достоен, колкото и да остава от него. В България обаче това остава извън фокуса на публичния дебат и обществените политики. Липсват думи като „радост“ и „игра“, когато се обсъжда темата за детските палиативни грижи, а гласовете на самите деца и техните семейства почти не се чуват. Според Надежда Цекулова точно думите, които избираме да не включим в този разговор, показват в коя посока като общество сме решили да гледаме и какво остава извън полезрението ни. Непременно прочетете статията ѝ „Големият отсъстващ. Детските палиативни грижи в публичните политики и в публичния дебат“.

Големият отсъстващ. Детските палиативни грижи в публичните политики и в публичния дебат

Детските палиативни грижи в България остават почти невидими – и в законите, и в обществения разговор. Политиките свеждат темата до болници и терминални състояния, а медиите рядко говорят за качество на живот, достойнство, радост и игра. Цената я плащат децата и семействата им. От Надежда Цекулова.

Как архитектурата се превръща в средство за инструментализиране на властта, е въпросът, който пулсира от всеки абзац на статията на арх. Анета Василева, която има късмета да наблюдава от първо лице началото на вълната от граждански протести против застрояването в Албания. Във фокуса на обществения гняв е лично Еди Рама, министър-председател и бивш кмет на Тирана, превърнал столицата в лаборатория за авангардни архитектурни проекти, но на фона на хаотично градоустройство и изключване на местните професионалисти от процеса. А т.нар. Фламингова революция е, от една страна, отчаян ход на съпротива на обикновените хора, а от друга, разкрива лицемерието на статукво, в което архитектурата е оръжие, но и жертва на политически амбиции.

Протестите в Албания, или как архитектурата отново излезе на терена на политическото

Със сигурност сте чули за масовите протести в Албания срещу инвестиционните апетити на зетя на Тръмп, който иска да застрои защитена територия. Анета Василева беше на място, разкрива ни контекста в дълбочина и споделя защо в Тирана се е срамувала, че е архитектка от чужбина.

За началото на лятото в рубриката ни на „Второ четене“ Антония Апостолова ни връща към един доста различен сборник с разкази. „Да си мъж“ на Никол Краус само на пръв поглед изглежда равен и сякаш безсъбитиен, докато дълбочината на прозата е скрита именно в липсите, празнините и неизказаните неща. Краус майсторски превръща микрокосмоса на семейното и интимното в универсални размисли за паметта, идентичността и времето. „Да си мъж“ е книга за това как човек свиква с непознатото, превръщайки го в част от себе си, и как паметта – и личната, и колективната – оформя същността ни. Според Антония това е сборник на човешкото оцеляване.

На второ четене: „Да си мъж“

Дни преди лятното слънцестоене Антония Апостолова ни препоръчва книга с разкази, която на пръв поглед е безсъбитийна и се занимава с липсите, празнините и пукнатините в историите. Вторият поглед и прочит обаче ще ви отведе на неподозирани места. Никол Краус умее това.

А като говорим за оцеляване чрез изкуство, за мнозина точно с музиката по-лесно се преглъща ежедневието. Как обаче да стане това, ако живееш в свят, в който музиката (особено западната) е „суетно забавление“, че даже отваря и врата към пороците и разврата. В рубриката си „Ориент кафе“ Атанас Шиников сблъска хевиметъла с исляма – два свята, осъдени на вечна раздяла. В първата част на „Къде е шейтанът тук?“ Аллах и тежка музика“ ще научим за корените на това негативно отношение на ислямските авторитети към музиката, но и защо дори в най-консервативните общности тя си пробива път. За втората част Атанас обещава да е запазил повече от същинското „главотръскане“. Нямаме търпение…

„Къде е шейтанът тук?“ Аллах и тежка музика

В сезона на „Хилс ъв рок“ и изобщо на всякакви благини „он дъ рокс“ Атанас Шиников набива спирачка по хлъзгавия терен на исляма и метъла – тези „две субстанции, осъдени на вечна раздяла“. В първата част на статията звучат гласовете на ислямските авторитети; другата седмица е ред на жиците.

Не знам дали вече се разчу, но след множество прожекции и срещи с публиката в цяла България филмът на Лина Кривошиева „Какво е да остарееш в България“ вече е достъпен за свободно гледане в YоuТube канала на „Тоест“.

Качествената документалистика обаче не може да се прави без пари. Този филм беше финансиран по проект, но за следващата тема (и своеобразно продължение на разговора) с Лина имаме нужда от вашата подкрепа. Документалните филми са отделна част от нашата дейност и за тях винаги търсим самостоятелно финансиране, така че да не отклоняваме средства от всекидневната журналистическа работа. Включете се с дарение за краудфъндинг кампанията на „Тоест“ за новия ни филм „Какво е да си млад в България“. Всички средства от нея ще отидат директно за заснемането, озвучаването, историята и екипа, който ще я разкаже.

Краудфъндинг кампания за следващия филм на „Тоест“

Всяко евро, което дарите в тази кампания, отива директно за заснемането, озвучаването, историята и екипа, който ще я разкаже. Подкрепете следващия ни документален филм „Какво е да си млад в България“!

Част от вас може би вече дарявате всеки месец на „Тоест“. Тези средства осигуряват издръжката на медията – журналистическата работа, редакционния процес, комуникацията с публиката, развиването и поддръжката на сайта.

А ако все още не сте регистрирали редовно дарение на „Тоест“, направете го, за да може екипът ни да продължи да прави качествена журналистика за всички.

Станете месечен дарител

The Data Canary: How Netflix Validates Catalog Metadata

Post Syndicated from Netflix Technology Blog original https://medium.com/netflix-techblog/the-data-canary-how-netflix-validates-catalog-metadata-18b699d58e36

By Celina Amados

At Netflix, our catalog metadata is crucial to our member experience, and a single corrupted data state can impact millions of viewers immediately. To protect streaming reliability, we built an automated data canary system that validates data transformations using production traffic. This canary detects issues in under 10 minutes, and blocks bad data from reaching our members.

Intro

Catalog metadata is what makes Netflix functional. It defines what titles exist, where they’re available, whether they can be played, and more. This data gets transformed and distributed across our vast infrastructure near-continuously, powering everything that helps members find what they want to watch. Accurate catalog data delivers moments of joy. Corrupted catalog data breaks streaming.

What Went Wrong

A production incident revealed a critical gap in our resilience strategy. No code had been deployed. No configuration had changed. But, a manual mitigation action taken during a previous incident had inadvertently corrupted a data feed, rendering it empty for a subset of titles.

The impact was immediate: missing metadata prevented manifest generation, causing failures in our catalog service and playback issues.

Engineers were alerted immediately, but identifying the root cause took time. After intense triaging, responders pinpointed the corrupted data feed and pinned services back to a known-good state, restoring playback.

The problem? Our sophisticated code canary deployments had caught nothing. No code had changed — the data had.

This incident exposed a fundamental gap in our resiliency capabilities: we can validate code deployments, but we had no equivalent for our high-velocity data pipelines. Our catalog metadata, consisting of titles, artwork, availability, and more, was continuously transformed from multiple upstream sources and published at a regular cadence. Each upstream source had its own validation, but these checks didn’t catch corruption in the final transformed output.

We needed to treat data deployments with the same rigor as code deployments.

The Challenge: Validating Data at Short Intervals

Our catalog metadata service operates as a high-velocity data pipeline: it processes multiple input feeds, transforms them, and publishes the final catalog state that gets distributed across our infrastructure.

This creates unique validation challenges that our traditional canary analysis tools aren’t designed to handle:

Time Constraints: Our existing canary analysis tools require 30–60 minutes to reach statistical confidence. We had a much shorter window between data cycles; we needed to detect issues, make a decision, and block publishing all within a single cycle.

Emergent Issues: While each upstream data source has independent validation, problems often only manifest in the final transformed state. We needed to validate the actual output that clients would consume, not just the inputs, as close to the clients as possible.

Production Traffic is Essential: We initially considered shadow traffic, but quickly realized it was insufficient. Shadow traffic can only replay requests to our catalog metadata service; it can’t simulate the entire playback lifecycle across multiple services and domains. To detect real customer impact, we needed real production traffic.

Limit Blast Radius: Despite using production traffic for validation, we couldn’t allow customers to experience widespread issues during the validation process. Any regression needed to be detected and contained immediately.

Our Solution: The Data Canary Orchestrator Pattern

After evaluating several architectural approaches, we developed a solution built around three key innovations:

1. Dedicated Orchestrator Pattern

We created a dedicated cluster for the purposes of canarying new catalog metadata that separates concerns, avoids self-testing, and provides a pattern for extensibility. Here’s how it works:

Orchestrator Instance: A dedicated orchestrator instance of our catalog metadata service coordinates the data canary flow. When a new catalog version is published to the canary environment, the orchestrator validates that both baseline and canary clusters are healthy and version-synchronized, then triggers a chaos experiment.

Permanent Baseline & Canary Clusters: Two dedicated service clusters run continuously in our canary region. The baseline cluster always serves the latest production catalog version, while the canary cluster receives new versions for validation.

Generic Integration Point: Upon chaos experiment completion, the orchestrator reports results back to the transformer service via a REST endpoint. This generic interface means new data sources can implement their own orchestrator patterns without requiring transformer code changes.

This pattern can now be adopted by other teams at Netflix for validating different data sources, which is exactly the kind of extensibility we designed for.

Data Canary workflow

2. Utilizing and Extending our Chaos Platform

Meeting the 10-minute constraint required not only leaning on our chaos platform, but also extending it to meet our needs:

Custom Threshold Tuning: We worked with our Resilience team to customize experiment thresholds for our use case. Standard chaos experiment thresholds were too conservative for our time constraints.

Multi-Tenant Testing: Our catalog service supports multiple client types with different traffic patterns and downstream dependencies. We ran separate experiments for major client types and discovered that running traffic through the tenant that handles playback requests consistently identified failures fastest.

Sticky Canaries: To isolate experiment traffic, sticky canaries use session affinity to guarantee that once a user’s traffic is routed to the baseline or canary clusters, it stays there for the duration of the experiment window. This prevents cross-contamination from concurrent chaos experiments, ensuring a clean apples-to-apples comparison between data versions.

Behavioral Metrics Over Technical Metrics: We focused on Starts Per Second (SPS), or actual customer playback attempts, as our primary signal. SPS proved more reliable than latency or error rates for detecting catalog corruption because it directly measures customer impact, and data errors may not always manifest as application errors to our catalog metadata service.

Immediate Abort on Regression: Instead of collecting data for post-hoc analysis, we stream metrics in real-time and abort experiments the moment we detect regression. This trades some statistical confidence for speed, but our tight thresholds and clear signal make this not only acceptable, but necessary.

3. Production-Hardened Edge Case Handling

Building a system that runs in production every 10 minutes taught us that the devil is in the details:

In-Flight Experiments During Redeployment: When the orchestrator restarts, it must detect and continue polling any ongoing experiments, as we can’t abandon a validation cycle mid-flight.

Leader Election: During orchestrator deployments, multiple instances might be running simultaneously. We implemented safeguards to ensure only one experiment is triggered per version announcement.

Version Synchronization: In a multi-tenant service where different clients consume data at different cadences, we track version state to ensure baseline and canary clusters are properly aligned before triggering experiments.

Validating the Validator: Controlled Failure Injection

To prove the system worked, we needed to break things on purpose. We ran a series of controlled experiments where we deliberately corrupted catalog data — denylisting high-profile titles and simulating real data corruption scenarios — to validate that the canary could detect issues and block publication.

These experiments were coordinated as proactive incidents during business hours, with product operations teams on standby. We routed approximately 0.2% of global traffic through the validation flow, minimizing blast radius while still generating meaningful signal.

Key Results:

  • Detection Speed: Issues identified in 2.5–4 minutes depending on client type
  • Clear Signal: 10x error differential between canary and baseline
  • Automatic Blocking: Publishing workflow blocked as designed when regressions detected

The experiments validated our end-to-end workflow and revealed important operational insights: different client traffic patterns detect failures at different speeds, and threshold tuning requires careful refinement based on the magnitude of impact we want this system to detect. Most importantly, they proved that even with a 10-minute validation window, far shorter than traditional 30–60 minute canary analysis, we had sufficient signal to catch high-impact catalog corruption.

Bringing Code Validation Principles to Data

This effort wasn’t just about building a validation system, it was about recognizing that data deployments deserve the same rigor as code deployments. Just because something isn’t a binary doesn’t mean it can’t break production. The patterns we landed on aren’t specific to catalog metadata, and can be applied to systems with high-velocity data pipelines more broadly.

If you’re working with data that changes frequently and impacts customers directly, ask yourself:

  • What’s your MTTD for data corruption?
  • Can you validate with production traffic safely?
  • How would you detect emergent issues in transformed data?
  • What behavioral metric most closely indicates customer impact in your domain?

Today, the failure mode that caused the aforementioned incident would be caught and mitigated in under 10 minutes. We all know outages aren’t a question of if, but when. The next time you find yourself faced with bad data, how fast will you be able to respond?

Acknowledgments

This work was a collaborative effort across multiple teams at Netflix. Special thanks to Jongyoon Lee, David Su, and Zubeen Lalani of the Catalog Foundations & Distribution team for their contributions to the design, and to Ales Plsek of the Resilience team for their support in customizing our chaos platform for our unique use case.

The Data Canary: How Netflix Validates Catalog Metadata was originally published in Netflix TechBlog on Medium, where people are continuing the conversation by highlighting and responding to this story.

The collective thoughts of the interwebz