Сучасна диджитал-освіта для дітей — безоплатне заняття в GoITeens ×
Mazda CX 5
×
  • Методи масштабування реляційних баз даних: переваги, недоліки та кейси використання

    Вона не призначена дати відповідь на це питання. кейс який там вирішується — вдосконалення механізму failover для сиквельних баз(запис там не відскейлений або out of scope статті просто — один instance і багато реплік у різних регіонах) те що зробив перехід від semi sync replication під блокуванням до raft дало покращення у плані автоматизації, latency, reilability і тому подібне. це уже говорить що стандартна реплікація працює не ідеально по багатьох пунктах для їх скейлу і географії. Тобто вони не могли досягнути failover з необхідними їм атрибутами.

    To help guarantee safety and avoid data loss during the complex promotion and failover operations, several automation daemons and scripts would use locking, orchestration steps, a fencing mechanism, and SMC, a service discovery system. It was a distributed setup, and it was difficult to accomplish this atomically. The automation became more complex and harder to maintain over time as more and more corner cases needed to be patched.

    Але цей кейс доволі стандартний для багатьох rdbms — автоматичний фейловер на read replicas і обов’язковий для hot stand by сценаріїв.

    Відповідаючи на питання, чому вони не взяли NoSql і не викинули SQL щоб вирішити це — скоріше за всех знаходиться у площині задач які вони вирішують з ним, підходами, кодовую базою що вони мають на ньому(грубо кажачу це історично так склалалося).
    Взагалі розглядит ці кейси під призмою потреб індустрії розробки не варто — будь-який розробник, що керуються типовими потребами, буде в останню чергу розглядати допрацювання rdbms engine на рівня ядра, щоб подтіягнути його до рівня інструментів які вже доступні в альтернативних рішеннях out-of-the box, це начебто очевидний момент.

    Підтримав: Tim Vlasyuk
  • Методи масштабування реляційних баз даних: переваги, недоліки та кейси використання

    висновки багаторічного практичного досвіду, якщо маєш сумніви — спробуй подискутуй.

  • Методи масштабування реляційних баз даних: переваги, недоліки та кейси використання

    Реально працює із коробки певно тільки сетап c з рід репліками і скейлом на читання без суттєвого геморою. Все інше виглядає як недо-nosql на стороні database клієнта і купою геморою на стороні менеджменту інфраструктури.

    Не уявляю причин взяти сіквел відскейлити запис, у той час коли будь-яка конкуренція нормально вирішується через версіонування(optimistic) в наш час і є купа баз які можуть самостійно зробити партиціонування, фейловер, решардинг.. нашо то все треба крутити і ще й приймати якісь обмеження самому з сіквелом який історично не пристосованний для distributed обчислень, не зрозуміло...

    Підтримали: Владислав, Tim Vlasyuk
  • Реліз Java 21: Long live a new LTS!

    насправді задача про те що тягнути в serverless spring не рекоммендує сам amazon.

    Minimize the complexity of your dependencies. Prefer simpler frameworks that load quickly on execution environment startup. For example, prefer simpler Java dependency injection (IoC) frameworks like Dagger or Guice, over more complex ones like Spring Framework.

    ідеологічно lambdas це про максимально просту інтеграцію готових різних cloud рішень/сервісів і багатоступінчаті workflow(що і формують складну архітектуру що там буде з 10-ок різних aws сервісів що взаєимодіють між собою) — а не про розробку api на базі фреймворків котрі мають величезний власний code base для різних задач.

    docs.aws.amazon.com/...​de/design-principles.html
    Serverless applications usually comprise several AWS services, integrated with custom code run in Lambda functions.

    Немає сенсу тулити це в lambda — якщо потрібен spring що буде кверяти якийсь postgress і роздавати json-и, беріть просто Beanstalk і диплойте туди свої веб апки.

  • Реліз Java 21: Long live a new LTS!

    В найгіршому випадку, CPU-задача запущена на віртуальному потоці призведе до блокування потоку-носія (carrier thread, аналогічно до концепту в Golang) що виконує віртуальний поток. Тому треба бути уважним який потом за замовчуванням створюється в Structured Concurrency.

    ну якщо в java на 10к віртуальних тредів задієються 20 тредів OS то це не виглядає на проблему взагалі — навідміну від дотнету з їх thread pool де вони крутять фактично OS треди і задіюють окремий тред на кожну задачу, хоча формально це і .net абстракція і там треба паритися з цими блокуванням постійно в клієнтському апі щоб не почало лагать.

    Підтримав: Oleksandr Suvorov
  • Реліз Java 21: Long live a new LTS!

    Зовсім не схоже — .net використовує асинхронний неблокуючий api що ранить все на thread pool(по дефолту там де не має ui треду) і заточений чисто під i/o (для cpu bound у них там купа іншого інструментарію), натомість java наче пропонує цей інструмент для cpu bound/i/o bound одночасно і ранить все на lightweight тредах(яких у дотнеті немає) і блокує у місцях синхронізації — що більше насправді зручно бо прокидувати асинхронну сигнатуру по стеку виклику це вже вчорашній день, але дотнету це змінити виявилось складніше(нещодавно там заморозили роботу над green threads що мали замінити типовий асинхронний апі на більш простий до того що є у go і тут у java). як результат жити з цим кривим async/await дотнетчикам до кінця днів схоже.

    Підтримали: Oleksandr Suvorov, Dmitry Bugay
  • Як відрізнити версію Macbook?

    В будь-яких реселарах і в apple store є можливість вибрати розкладку завжди — ansi(us), iso(eu)

  • Helm vs. Operator: приклад Hazelcast

    Все змішались люди, коні..

    однак це рішення не підходить для stateful аплікейшенів.

    learn.microsoft.com/...​urable-functions-overview

    Якщо порівнювати контейнери і serverless вони вміють все те саме іноді готове іноді кастомне.. те що робить serverless cloud native — саме повна готова інтеграція з экосистемою cloud комплнентів, у випадку контейнерів вам або треба буде розгортати oss рішення , або інтегруватись через підключення ліб сторонніх, розробки потрібного системного дизайну і т.д. Простіше кажучи витрачати додатковий час на все починаючи з інфраструктури і розгортанню коду, закінчуючи імплементацією потрібного рішення , замість готового запропонованого cloud provider.

  • Helm vs. Operator: приклад Hazelcast

    The Cloud Native Computing Foundation (CNCF) is a Linux Foundation project that was founded in 2015 to help advance container technology[1] and align the tech industry around its evolution.

    Це організація просто розвиває впровадження рішень на контейнерах і щоб вони отримували в тому числі кращу нативну підтримку (а не стандарт рішень ansi/iso якийсь який варто булоб референсити чи хоча б architecture reference від cloud providers).
    Якщо ви дійсно хочете робити cloud native рішеня, то там serverless буде набагато попереду контейнеризованих рішень в наборі готових фіч для вирішення різних бізнесс задач, а ніж контейнери розгорнуті в клауді. у тому контексті що ви використовуєте цей термін і назва організації — це просто маркетинговий buzzword.

  • Helm vs. Operator: приклад Hazelcast

    Cloud agnostic як раз таки суперечить поняттю cloud native оскільки вимагає абстрагування від рішень конкретного вендора — як програмних так і інфраструктурних де треба більше менеджити інфраструктуру, дизайнити інтеграцію компонентів через різні oss клієнти/бібліотеки, полягатися на протоколи і інструментарій, що не може на повну використовувати готові фічі конкретного cloud (якщо вони не стандартизовані).
    Cloud native передбачає що ви максимально і наповну використуваєте все готове, а не лімітуєте себе у фічах і імплементите те саме або шукаєте в oss рішеннях якщо його поставляє cloud provider обраний , а інший — ні.

    Підтримав: Serhii
  • Helm vs. Operator: приклад Hazelcast

    Kuber це не cloud native аж ніяк навіть якщо managed, а навпаки cloud agnostic.
    Cloud native рішення буде на противагу контейнерам якийсь багатостеповий serverless обмазанний з різних сторін in/out різними хмарними компонентами.

    Підтримали: Serhii, Денис Макогон
  • Як дорости до Solution Architect — і що в цій ролі доведеться робити

    В західних компаніях продуктових є така позиція і навіть фангах , але це наче сейлова , а не інженерна позиція.

  • На співбесіді мене попросили написати «костиль»

  • На співбесіді мене попросили написати «костиль»

    тому краще взяти не підходящі під задачу технології і думати як вирішити проблему цим породжену. Best engineering practices in action

  • На співбесіді мене попросили написати «костиль»

    Легко може бути транзакційним, якщо обидва хендлери складають данні в одну базу наприклад. Цих деталей не має у варіанті компанії.

    Підтримав: Victor Musienkо
  • На співбесіді мене попросили написати «костиль»

    А чого не можна створювати івент після запису у базу?

    Бо запис в базу і відсилка івенту нетранзакційні

  • На співбесіді мене попросили написати «костиль»

    Взяти кафку.

  • Що таке NoOps і як це вплине на DevOps-інженерів

    Я, наприклад, працював на Cisco і дуже добре знаю, хто такі Release Engineers і що вони там робили, деякі навіть сиділи біля мене ;)

    Працював з різними продуктами їх — одні з найгірших software рішень з якими доводилось інтегруватись нажаль, таких рішень як у них не бачив навіть в кривавому энтерпзайі, а позиціонують себе як серьезна організація(при всій повазі до їх hardware рішень).

    Лише питання — хто захоче робити девпосову роботу без додаткової оплати (мова про аутсорс, в продукті чи напряму ситуація через більшу зарплатню може відрізнятись).

    Ваша постановка питання виглядає для мене трохи наївною, якщо у вас дійсно я серйозний досвід комерційнох розробки — що ви можете прийти і просто попросити надбавку к зарплаті(без пропорційного збільшення відпрацюваних людино-годин), якщо вам дадуть готовий фреймворк для розгортання вашого коду і попросять автоматизувати його розгортання і супутньої інфраструктури\моніторингу.

  • Що таке NoOps і як це вплине на DevOps-інженерів

    Окрім девопсів ще взагалі є купу ролей з суфіксом *ops у великих компаніях.

    Я думаю що для нашого кейса це зовсім не суттєво, не думаю що девопс у великій компанії відмовится робити пайплайни якщо його попросят щоб коміти в бранчі тригерили CI/CD, або додати SAST/DAST щоб сканив артефакти, поки таку роль не відкрили у компанії.

    Без додаткової фінансової мотивації CI/CD пайплайни розробник писати не буде, вчити кубернетес та що таке хелм чарти не буде, як і розбиратись із терраформ конфігами.

    Працюють абсолютно нормально і це норма для індустрії особливо якщо ви хочите розвиватись і промоутитись по sde грейдам, хоча звичано робота це більш натуральна для девопса. І першочергово ми розмовляли взагалі про розгортання кода, а не iac, а це переважно білд інструментарій специфічний для сбірки і дуже часто platform specific і прив’язаний до конкретного SDK(саме тому його куди більш натурально знати саме девелоперу, а ніж девопсу). btw недавно як раз читав в твіті одного distinguished engineer з технологічних фангів стосовно того, що якщо ви не проводите 50% свого часу в yml, то ви не робите чогось cloud native взагалі. Можна напевно сказати, що це стосується в першу чергу девелоперів саме, адже очевидно що навряд це можна сприймати як рекоммендацію якщо ви в cloud, беріть девопсів і девелоперів навпіл.

    Загалом такий скрипт буде або писати DevOps (Development + Operations) або у великих компаніях є так звані Release Engineers (Build Engineers) котрі відповідають за написання таких скриптів чи на баші, чи на будь чому іншому в контексті дженкінс пайплайнів чи будь чого іншого, що буде збирати код в котрісь пакети під різні дистрибутиви лінукса (олдскул), чи просто білдити, тестити та деплоїти в клауд чи on-prem.

    Release engineers це така збірна солянка в яку кидають частіше навіть мануальщиків і менеджерів, і ніж автоматизаторами. А от девелопери сидять і пишуть скрипти, готують різні xml специфікації, якщо треба — беруть бібліотеки що гарно це інкапсулюють навколо якось більш просто api і готовлять сбірку свого коду. Те ще ви нічого крім кубера не бачили де все на готових helm чатрах і не впевнений, що робили колись dockerfile хоч якись без девопсів, скоріше за все вказує на вашу обмежену проф пригодність — інакше я не уявляю як ви дебажите свій код на контейнерах, щось там діагностуєте коли до вас приходить баг репорт де необхідно провести інтеграційне тестування.

  • Що таке NoOps і як це вплине на DevOps-інженерів

    з рівнем айк"ю вище кімнатної температури на таке погодиться, особливо в аутсорсі.

    ну девопса наймають бо він дійсно зробить це швидше, правильно організує щоб це було пітримувано, безпечно і т.д. власне тому йому і заплатять за свою роботу. Але розробникам наче і не треба цього робити:

    На практиці NoOps-підхід не означає, що розробники візьмуть на себе всі функції, які зазвичай виконують DevOps/SRE. Це означає, що команда DevOps розробить певний фундамент, задокументує та надасть його розробникам ПЗ.

    за що тут доплачувати, щоб ви як розробник свій код скриптом інсталювали десь і запустили його?

    а) Це ідеологічно не являється відповідальністю розробника по замовчуванню

    э таке питання дійсно, а що являється відповідальністю розробника?

    Я просто не зрозумів як ви продаєте себе якщо у вашу ставку не входить навіть автоматизована поставка/інсталяція кастомеру вашого, по ідеї, робочого коду і ви за це ще доп гроші хочете. Це в Soft-servе є попит на такі послуги?:) Я розумію що у вас є девопси скоріш за все, але я сильно сумніваюсь, що якщо до тебе прийдуть і скажуть — напиши мені bash скрипт що запаблішить код кудись і збере все до купи, ви зможете аргументовано пояснити що це не ваша робота(навіть на галєрі типу Soft-serve).

← Сtrl 123456...92 Ctrl →