Solutions Architect at GlobalLogic
  • ІТ-спільното, купимо армії «літачок»? Збираємо $ 1 000 000 на сучасний комплекс PD-2

  • Централизованый и автоматизированный DDoS рашки с автобалансировкой

    вы делаете на коленке то что уже существует... тулзеней много... старые — Chef, Puppet... новее — Ansible, SaltStack... лучшее на сейчас для не клаудных задач по массовому управлению нодами — SaltStack... я уже поднял себе ) планирую довести количество управляемых серверов до сотни... если есть лишние серваки — принимаю в кластер для праведных задач — порчи жизни москалям...
    резюме — забей на тулзу — нужны серваки у разных хостеров в разных регионах...

    Підтримав: Вова
  • 2000 доларів на кожного: GlobalLogic надала фінансову допомогу своїм спеціалістам

    Як консультант компанії GlobalLogic, підтверджую широку підтримку від компанії — додаткові гроші, допомога з розселенням біженцям, інформаційна підтримка. За це люди дуже вдячні...
    Більшість людей пробують продовжити роботу, підтримуючи країну матеріально та волонтерством. Також є ті хто добровільно мобілізувався.

  • 150 технических специалистов, собственная ОС и 6 патентов. Как работает R&D команда Ajax Systems

    ну реально, если прочесть — цитата полна треша более чем полностью ))) вот что случается когда технический текст пишет тот, кто не шарит )))

  • Как использовать Terraform для управления сложными многокомпонентными инфраструктурами в Azure

    не, все правильно ;)
    Salt Stack — он как Ansible, только сделан правильнее(например апдейт 10к серваков будет идити одновременно. на Ansible, вероятно, и пробовать не стоит...)
    Salt Stack — Initial release 19 March 2011 — 9 лет назад, поэтому что б быть крутым, Ansible должен был появиться 10 лет назад ;)

  • AWS CloudFormation: найкращі практики та способи їх використання

    для тех кто читает по диагонали — CF стал читабельным когда они смогли в yaml(только так его и рекомендуется использовать сейчас)

    Використовуйте YAML замість JSON
    Підтримав: Yuri Maksimov
  • AWS CloudFormation: найкращі практики та способи їх використання

    когда что-то сделано не так как это подразумевает клауд, вы точно так же наступите на грабли из любой друг тулзы — да хоть через бото сами все запускайте... так что это не

    CF

     специфичная проблема — скорее из серии «клауд это прикольно, но есть нюансы» ;)

  • AWS CloudFormation: найкращі практики та способи їх використання

    откройте для себя вполне читаемій yaml(поддерживается в CF более 3х лет) и перестаньте работать переводчиком на Terraform ;)
    вот тут могу понять в чем проблема ) пока был только json — да, было сильно менее прятно...

  • AWS CloudFormation: найкращі практики та способи їх використання

    ну вот — www.terraform.io/...​ws/r/iam_role_policy.html
    типа решили мы сделать все красиво, начали наши IAM Role/Policy/.. документировать/версионировать, т.е имплементить не как попало руками, а терраформ и гит например... учим синтаксис Terraform, читаем доки амазона, где примерры на Claudformation(т.е минимально вам его понимать все равно придется), делаем ментальное усилие — переводим yaml Claudformation в Terraform... а потом — БАЦ!!! и кусок джейсона копипастой!!!
    тут парсер подсветки PyCharm’a у меня ломался... в более сложных случаях на это без слез даже суровые девопсы смотреть не могут ;)
    итого — вы читаете доки амазона, переводите их в терраформ и ради чего?
    меня на переход в Claudformation окончательно подтолкнуло отсутствие на тот момент поддержки AWS Kinesis, Firehose, Glue в террформе... а потом оказалось что и роли/полиси можно создавать без содрогания :)

    P.S. LOL, dou parser тоже не одобряет терраформ с кусками джейсона — убрал пример )

  • Как использовать Terraform для управления сложными многокомпонентными инфраструктурами в Azure

    Ansible

    был крутым 10 лет назад ;) теперь он древний ;) и его использование для локального сетапа на каждой ноде еще можно как-то оправдать, но менеджить им клауд — костыль еще хуже терраформа ;) но лучше чем «рукам», да...

  • Как использовать Terraform для управления сложными многокомпонентными инфраструктурами в Azure

    еще наброшу ;)
    Infrastructure as code — это здорово... но как все знают — код пишут девелоперы, значит DevOps не нужен? ;)

  • Как использовать Terraform для управления сложными многокомпонентными инфраструктурами в Azure

    народ, хватит уже полумер — используйте нативную автоматизацию ;)
    Terraform лучше чем ничего, но когда будете использовать клауд по полной — упретесь, начнете обрастать новыми костылями...

  • AWS CloudFormation: найкращі практики та способи їх використання

    удивлен, что у хорошей обзорной статьи/перевода мало просмотров и нет комментов(мой первый ;)
    использование

    CloudFormation

    в AWS — это то, без чего использование AWS полноценным назвать нельзя. ни одна тулза кроме CloudFormation не поддерживает всех сервисов в AWS(и даже он отстает немного — мы начали юзать AWS Secrets Manager за 3 месяца до его интеграции с CloudFormation). лично я как девелопер (которому часто было больше всех надо) писал автоматизацию деплоев/енвайронментов на cmd/bash/Ant/Ansible/SaltStack/Terraform/Cloudformation... так что гарантирую — с CloudFormation костылей будет меньше ;)
    с точки зрения архитектуры Ansible проблемный — уж лучше SaltStack... с той же точки зрения Terraform так же сливается рядом с Cloudformation... Ansible и Terraform выполняют команды удаленно что делает их работу зависимой от сети, отсутствие роллбэков можно не заметить на маленьком кол-ве сущностей и неприятно удивиться на большом...
    аргументы против CloudFormation, которые приходилось слышать — сложно, не крос клауд... про сложно не буду — скорее просто(попробуйте в Terraform IAM Roles насетапать — психологическая травма гаранитрована). то что люди хотят крос клауд это понятно, но нет — его полноценного пока не предвидится... как говорится если бы каждый раз когда люди говорят про «не хотим вендор лок а хотим крос клауд», мне бы давали доллар...

    Підтримав: Roman Banakh
  • Создаем приложение: Docker, VueJs и Python-Sanic. Часть 2

    1. воу, воу, полегче ) вы пишете про обычный веб апи, в котором сколько бы реквест времени ни потребовал, вы все равно что-то ответите клиенту... то что сервер при этом асинхронный, помогает только когда реквесты сильно зависят от ввода-вывода... что никак не заменяет celery в вашем деплое, если вам нужны будут какие-либо бекграунд таски...
    2.1.

    микросервисной архитектуре

    вы тут себе идола не сотворили? ;) панацеей это считалось 10 лет назад, но нет не все так просто )
    2.2.

    нужно оптимизировать по максимум всё что можно

    вот тут хочется узнать критерий оптимизации :) если по кол-ву написанного кода, то вы сольетесь любому ORM. если по безопасности использования — тоже, потому как sql injection никто не отменял, параметры приводить в нужно типу — будут не покрытые тестами велосипеды(банально, как вы boolen будете из базы в веб преобразовывать и обратно? true/True/1??? а тот кто будет писать с вами точно выберет такой же вариант как вы? и вы же задокументируете все корнер кейсы? ))) Про скорость запросов тоже не надо — дочитав доку по вашему орму вы должны понимать какой запрос получится в базу уйдет(в крайнем случае под дебагом посмотрите), что в итоге сводиться к следующему — или вы понимаете как с базой работать или не в орме дело ))) в общем, ваш критерий не очевиден...
    3.

    Лучше деплоиться при помощи ansible

    это очень смело ))) как человек, деплоивший через ansible и SaltStack 5 лет назад, ответственно заявляю — в клауде они не нужны, оба ))) ансибл вообще, тупо замена баша архитектурно, что естественно большой шаг вперед, если до этого было на баше или вообще «руками» на сервере... но как бы в 3м тысячелетии это несколько устаревший подход... для деплоя «не в клауде» оно явно лучше, чем ничего, но осилившие SaltStack знают, что ансибл на пару тысяч серваков не заскейлится ))) большая его беда — он держит коннект во время всех операций, которые транзакционными не являются и когда коннект таки порвется, то что делать? куда бежать? ;) в общем, ансибл — тулза для оптимистов с 10-20ю серваками :) в AWS клауде я лично попробовал Terraform(так сяк, но для AWS не все запилено и мы его выкинули из своих проектов) и Cloudformation(его сильно допилили за последние пару лет, и если еспользовать yaml а не дефолтный ранее json, то на него можно без слез смотреть). Ваша фраза про докер намекает, что вам показалось, будто я не осилил эту эврику ))) но начав возиться с ним 5 лет назад, я претендую на некоторое понимание ))) и моя заметка была про то что docker-compose является базовой вещью для «наколеночных тестов» и на 100не нод вам не поможет... а вот всякие кубернетисы и жменя вариантов в клауде — вполне...

    P.S. прошу не считать данный опус критикой :) все выше написанное IMHO, за которым стоят некоторые аргументы но, возможно,не всем они важны...

    Підтримали: Vitaliy Kolesov, Andrew Druchenko
  • Создаем приложение: Docker, VueJs и Python-Sanic. Часть 2

    спасибо за статью. но как человек, считающий что асинхронность — это паралельность для «бедных», не могу не спросить ;)
    1. зачем асинхронность на сыром фреймворке вместо фласк или даже джанго? в чем польза от велосипедов с тем же рестом(если для обучения — не вопрос, но если вы это хотите в прод...)
    2. у вас примере ручные миграции бд... возникает вопрос — что опять?!!! т.е мы и не такое видели, но смысл? код вида

                _user = await conn.fetchrow('''
                SELECT * FROM users WHERE email=$1
                ''', res['email'])
    
    отдает мхом из 90х ;)
    3. docker-compose.yml это все забавно для локалхоста, но чисто интересно, как это в «продакшен» деплоить?

    в общем не понял, где плюсы такого решения... если они есть, с интересом о них узнаю :) а пока видиться только переусложненная схема вида «смотрите, как я могу» )))

    Підтримали: Andriy Kupchanko, Vitaliy Kolesov
  • Архитектура видеосервиса Megogo: варианты решений и переход от монолита к микросервисам

    все таки хочется спросить, почему CIO пишет в заголовке про

    Архитектура

    , а в статье история вашего хождения по граблям? ;) Если поменять заголовок на «как мы его слепили из того что было, но почитали стандарты индустрии и хотим исправиться» то вопрос снимается ))) и когда таки решите что-то кроме «воды» поведать про архитектуру, позовите пожалуйста вашего CAO с нормальными диаграммами и конкретными кейсами, почему тут так а не иначе, вдруг там и правда есть что-то интересное )

  • Архитектура видеосервиса Megogo: варианты решений и переход от монолита к микросервисам

    а еще на самсунге 7й серии при уже купленной макс подписке с автопродлением при каждом запуске предлагает, внезапно, продлить подписку, но потом соглашается что все ок... год назад такого не было но прилетел апдейт... в общем, задумайтесь над судьбой

    Smart TV team

    ;)

  • Наш опыт внедрения ClickHouse — аналитической CУБД

    упереться в

    максимальное значение PK

    это прикольно )
    присоединюсь к вопросу выше — при таких объемах почему не Goggle BigQuery/ AWS Athena?
    там обещают отсутствие проблемы с объемами...

  • Наш опыт внедрения ClickHouse — аналитической CУБД

    Всегда было интересно, почему первичный ключ некоторые делают «естественным», а потом DBA страдает в ситуации «особенно когда нужно было изменить первичный ключ»... Как я понял из статьи, вы и дальше так делаете... Почему?

  • Почему Java все еще не торт. Yet

    Дмитрий, будь мужиком! признавайся что ниасилил все вышеперечисленное и пишешь как можешь :) Тогда у людей вопросов не будет )

← Сtrl 123 Ctrl →