Скучный технологический стек интернет-компании из одного человека

Автор оригинала: Wenbin Fang
  • Перевод

Поисковая выдача на ListenNotes.com

Listen Notes — это поисковая система и база данных подкастов. Технология на самом деле очень скучная. Никакого ИИ, глубокого обучения или блокчейна. «Если вы должны объявлять о внедрении ИИ, то вы не используете Настоящий ИИ» :)

После прочтения этой статьи вы сможете повторить мой проект или легко сделать нечто подобное. Не придётся нанимать много разработчиков. Помните, когда Instagram привлёк $57,5 млн и отошёл к Facebook за $1 млрд, у них было всего 13 сотрудников — и это не только разработчики. Покупка Instagram произошла в начале 2012-го. Сейчас 2019 год, и сегодня как никогда просто создать что-то значимое с крошечной инженерной командой — даже из одного человека.

Если вы ещё не видели Listen Notes, попробуйте прямо сейчас:



Обзор


Начнём с требований или особенностей проекта.

Listen Notes предоставляет две функции:


Всё работает на AWS, всего 20 серверов в продакшне (на 5 мая 2019 года):


Серверы, на которых работает Listen Notes

По имени хоста можно легко догадаться, что делает каждый сервер.

  • production-web обслуживает веб-трафик для ListenNotes.com.
  • production-api обслуживает трафик API. Мы поддерживаем две версии API (по состоянию на 4 мая 2019 года): v1api (устаревшая) и v2api (новая)
  • production-db запускает PostgreSQL (master и slave)
  • production-es запускает кластер Elasticsearch.
  • production-worker запускает автономные задачи обработки, чтобы всегда поддерживать базу данных подкастов в актуальном состоянии и предоставлять некоторые волшебные функции (например, ранжирование результатов поиска, рекомендации по эпизодам/подкастам и т.д.).
  • production-lb — балансировщик нагрузки. Для удобства я также запускаю на этом сервере Redis и RabbitMQ. Знаю, что это не идеально. Но я не идеальный человек. :)
  • production-pangu — производственный сервер, на котором я иногда запускаю одноразовые скрипты и тестирую изменения. Что такое паньгу?

Большинство серверов можно горизонтально масштабировать. Вот почему я называю их production-что-то1, production-что-то2 и т. д… Очень легко добавить в кластер production-что-то3 и production-что-то4.

Бэкенд


Весь бэкенд написан на Django/Python3. Операционная система — Ubuntu.

Для обслуживания веб-трафика используется uWSGI. Перед процессами uWSGI я поставил nginx, он также работает балансировщиком нагрузки.

Основное хранилище данных — PostgreSQL, с которой у меня большой опыт разработки и эксплуатации на протяжении многих лет. С проверенной технологией спокойно спится по ночам. Redis применяется для различных целей (например, кэширование, статистика...). Нетрудно догадаться, что где-то используется и Elasticsearch. Да, я применяю его для индексирования подкастов и для обслуживания поисковых запросов, как и большинство скучных компаний.

Celery используется для автономной обработки, а Celery Beat предназначен для планирования задач, которые похожи на задания Cron, но немного приятнее. Если в будущем Listen Notes станет популярным, а Celery и Beat вызовут проблемы с масштабированием, я, вероятно, переключусь на два проекта, которые сделал для предыдущего работодателя: ndkale и ndscheduler.

Supervisord управляет процессами на каждом сервере.

Погодите, а как же Docker, Kubernetes и бессерверная архитектура? Ничего такого. С опытом вы учитесь не делать лишнего. На самом деле я немного работал с Docker ещё в 2014 году на предыдущей работе: что было хорошо для среднего стартапа ценой миллиард долларов, кажется излишним для крошечной компании из одного человека.

Фронтенд


Веб-интерфейс в основном построен с помощью React + Redux + Webpack + ES. Довольно стандартно в наши дни. При развёртывании в рабочей среде пакеты JS загружаются в Amazon S3 и выдаются через CloudFront.

На ListenNotes.com большинство веб-страниц наполовину рендерятся на стороне сервера (шаблон Django), наполовину на стороне клиента (React). С сервера поступает шаблон веб-страницы, а на стороне клиента в основном рендерится интерактивное веб-приложение. Но несколько веб-страниц полностью готовятся на сервере из-за моей лени и некоторых потенциальных преимуществ SEO.

Аудиоплеер


Я использую сильно модифицированную версию react-media-player. Он работает на веб-сайте как встроенный плеер в твиттере и встроенный плеер на сторонних сайтах:


Встроенный плеер на сторонних сайтах

API


Мы предоставляем разработчикам простой и надёжный API с подкастами. Построение API аналогично созданию веб-сайта. Здесь тот же стек Django/Python для бэкенда и ReactJS для интерфейса (например, панель инструментов API, документация...).


Панель инструментов Listen API


Документация Listen API

Для API нам нужно отслеживать, сколько запросов использует клиент в текущем цикле биллинга, и взимать оплату. Нетрудно представить, что здесь активно используется Redis :)

DevOps


Подготовка машины и развёртывание кода


Для подготовки системы (provisioning) применяется Ansible. По сути, я написал кучу файлов yaml для указания, какие файлы конфигурации и какое программное обеспечение должно быть на каждом типе серверов. Я могу одним нажатием кнопки развернуть сервер со всеми правильными файлами конфигурации и всем установленным софтом. Вот структура каталогов для этих файлов Ansible yaml:


Я мог бы грамотнее назвать директории. Но опять же, этого сейчас достаточно

Ansible также помогает деплоить код в продакшн. В принципе, у меня есть скрипт-обёртка deploy.sh, который работает на macOS:

./deploy.sh production HEAD web

Этот скрипт принимает три аргумента:

  • Окружение: продакшн или staging.
  • Версия репозитория listennotes: HEAD означает «просто задеплоить последнюю версию». Если указан SHA коммита, то он развернёт определённую версию кода — это особенно полезно, когда мне нужно откатиться назад после плохого деплоя.
  • Тип серверов: веб, воркер, API или все. Мне не нужно деплоить сразу на все серверы. Иногда я делаю изменения в коде Javascript, тогда нужно развернуть его только в вебе, не трогая API или воркеры.

Процесс деплоя в основном организован файлами Ansible yaml, и, конечно же, предельно прост:

  • На моём Macbook Pro, если это деплой для веб-серверов, затем создаются пакеты Javascript и загружаются в S3.
  • На целевых серверах git клонирует репозиторий listennotes в папку с именем timestamp, проверяет конкретную версию и устанавливает новые зависимости Python, если таковые имеются.
  • На целевых серверах символическая ссылка указывает на вышеупомянутую папку с именем timestamp, затем перезапускаем серверы с помощью supervisorctl.

Как видите, я не использую эти причудливые средства CI. Только самые простые и надёжные инструменты, которые реально работают.

Мониторинг и оповещение


Мониторингом и оповещениями занимается Datadog. В простой панели мониторинга демонстрируются некоторые высокоуровневые показатели. Всё здесь предназначено для того, чтобы повысить мою уверенность при возне с серверами в продакшне.


Панель мониторинга Datadog для Listen Notes, по состоянию на декабрь 2017 года

Datadog подключён к PagerDuty. Если что-то пойдёт не так, PagerDuty пришлёт мне оповещение по телефону и SMS.

Я также использую Rollbar, чтобы отслеживать состояние кода Django и ловить неожиданные исключения, уведомляя меня по электронной почте и Slack.

Slack применяется очень активно. Да, это компания с одним человеком, поэтому он нужен не для общения, а для мониторинга интересных событий на уровне приложений. Кроме интеграции Datadog и Rollbar с Slack, в код бэкенда Listen Notes интегрированы входящие веб-хуки Slack, чтобы уведомлять о регистрации пользователя или выполнении некоторых интересных действий (например, добавлении или удалении элементов). Это очень распространённая практика в технологических компаниях. Если вы почитаете книги о первых годах Amazon или PayPal, то узнаете, что у обеих компаний был аналогичный механизм уведомлений: всякий раз, когда регистрировался пользователь, раздавался звук «динь», чтобы уведомить всех в офисе.

С момента запуска в начале 2017 года у Listen Notes не было серьёзного даунтайма (более 5 минут), кроме этого. Я всегда очень осторожен и практичен в работе DevOps. Для серверов предусмотрен серьёзный оверхед на случай какого-то огромного всплеска посещаемости из-за попадания в прессу или чего-то ещё.

Разработка


Я работаю в коворкинге WeWork в Сан-Франциско. Некоторые могут задать вопрос, почему бы просто не работать из дома или из некоторых случайных кафе. Ну, я очень ценю производительность и готов инвестировать в неё деньги. Не верю, что домашний бардак способствует разработке программного обеспечения (или любой работе в сфере знаний/творчества). Я редко работаю более 8 часов в день (извините, люди 996). Хочется, чтобы каждая минута была на счету. Таким образом, хороший и относительно дорогой частный офис — то, что мне нужно. Вместо экономии денег в ущерб времени, я оптимизирую время, чтобы тратить его с пользой и зарабатывать деньги.


Мой офис в WeWork

Я работаю на MacBook Pro. Почти идентичная инфраструктура запускается внутри Vagrant + VirtualBox. Для среды разработки внутри Vagrant используется тот же набор файлов Ansible yaml, описанный выше.

Я поддерживаю философию монолитного репозитория. Таким образом, есть один и только один репозиторий listennotes со скриптами DevOps, кодом фронтенда и бэкенда. Он размещён как приватный репозиторий на GitHub. Вся разработка идёт в главной ветке. Я редко использую бранчи.

Я пишу код и запускаю dev-серверы (Django runserver и dev-сервер webpack) с помощью PyCharm. Да, знаю, это скучно. В конце концов, это не Visual Studio Code или Atom или какие-то крутые IDE. Но для меня PyCharm работает просто отлично. Старая школа, что же поделаешь.


Мой PyCharm

Разное


Есть куча полезных инструментов и сервисов, которые я использую для создания Listen Notes как продукта и компании:

  • iTerm2 и tmux как терминалы.
  • Notion для списков TODO lists, вики, заметок, записей по проектированию…
  • G Suite для почты @listennotes.com, календаря и других сервисов Google.
  • MailChimp для ежемесячной почтовой рассылки.
  • Amazon SES для служебных и некоторых маркетинговых рассылок.
  • Gusto для выплат себе и некоторым подрядчикам, если они не с Upwork.
  • Upwork для поиска подрядчиков.
  • Google Ads Manager для управления рекламой и отслеживания эффективности.
  • Carbon Ads и BuySellAds для резервных объявлений.
  • Cloudflare для управления DNS, CDN и файрволом.
  • Zapier и Trello для упрощения рабочих процессов в разделе интервью с подкастерами.
  • Medium для блога компании.
  • Godaddy и Namecheap для доменных имён.
  • Stripe для приёма денег от пользователей (в основном, за API).
  • Google speech-to-text API для расшифровки подкастов.
  • Kaiser Permanente для медицинской страховки.
  • Stripe Atlas для юридической регистрации Listen Notes, Inc.
  • Clerky: генерация юридических документов для венчурных инвесторов (SAFE) и найма подрядчиков, если они не с Upwork.
  • Quickbooks для бухгалтерии.
  • 1password для управления паролями в куче сервисов
  • Brex как платёжная карточка — вы можете получить дополнительные $5000 кредитов AWS, используя их поверх кредитов AWS от WeWork или Stripe Atlas.
  • Bonvoy Business Amex Card — можете накапливать баллы Marriott Bonvoy на люксовые отели и полёты. Это лучшая бонусная программа для путешействий/
  • Capital One Spark для текущего банковского счёта.

Сохраняй спокойствие и не дёргайся…


Как видите, мы живём в прекрасное время для запуска своего бизнеса. Так много готовых инструментов и сервисов, которые экономят время и деньги, повышая вашу производительность. Сейчас самое лучшее время за всю историю, чтобы создать что-то полезное для человечества с крошечной командой (или только силами одного человека), используя простые и скучные технологии.

С течением времени компании становятся всё меньше и меньше. Уже не нужно нанимать тонны штатных сотрудников. Чтобы сделать всю работу, можно воспользоваться сервисами SaaS и подрядчиками под заказ.

В основном, главное препятствие в создании проекта — излишние размышления. Что, если это, что, если то. Парень, ты никому не нужен. Каждый занят собственными делами. Никому не интересен ты и твой проект, пока ты не докажешь, что достоин внимания. Даже если вы запорете запуск, никто этого не заметит. Думайте масштабно, начинайте с малого, действуйте быстро. Абсолютно нормально использовать скучные технологии и начать с чего-то простого (даже уродливого), если вы действительно решаете проблему.


Сейчас так много людей с карго-культом. Не обращай внимания на шум. Сохраняй спокойствие и не дёргайся.

Средняя зарплата в IT

113 000 ₽/мес.
Средняя зарплата по всем IT-специализациям на основании 10 037 анкет, за 2-ое пол. 2020 года Узнать свою зарплату
Реклама
AdBlock похитил этот баннер, но баннеры не зубы — отрастут

Подробнее

Комментарии 54

  • НЛО прилетело и опубликовало эту надпись здесь
      +8
      то есть помнить правила в 25ти разных стратегических игр вы можете, а раз или два в месяц зайти и ткнуть (как часто он меняет что-то в доменных именах или ищет подрядчиков в апворке?) — это уже ужас-ужас?
      • НЛО прилетело и опубликовало эту надпись здесь
          0
          Непростая задача, но даже если оно и умерло — обычно это не так страшно. Зачастую можно ткнуть заново, чтобы оно ожило, а даже если и не получается — то Google в помощь, можно разобраться, чего это оно умерло…
        +2
        Почему бы и нет? Опытный фуллстек-разработчик вполне нормально может с этим справится.
        Про PyCharm, как противопоставление VSCode, Atom или крутым IDE улыбнуло :)
          –1
          Да, при том что Atom вообще не IDE.
            0
            PyCharm это олдскул?
            Вимщики и эмаксеры щас закидают автора яйцами
              0

              vim и emacs все же не IDE. И потом, никто не мешает комбинировать. Я вот использую PyCharm с IdeaVim много лет. Если 10 лет назад в IdeaVim было много шероховатостей, то последние лет 6 вполне комфортно работать.

                0
                vim и emacs все же не IDE.

                Но если сильно постараться...
                  0

                  Я до перехода на PyCharm пытался сделать IDE из Emacs много лет. Не стоит оно того, на мой взгляд. Усилий затрачивается масса, человеко-месяцы, даже человеко-годы. А результат все равно в разы хуже PyCharm по удобству и возможностям.


                  Для себя сделал вывод, что с определенного момента мне проще заплатить за PyCharm, чем тратить человекомесяцы на поддержание франкенштейн-IDE.


                  На vim/IdeaVim перешел не из-за этого, а потому что тунельный синдром запястья стал серьезной проблемой, которая бесследно прошла после смены сочетаний клавиш Emacs на vi.

            0
            Gusto для выплат себе и некоторым подрядчикам, если они не с Upwork.
            Upwork для поиска подрядчиков.

            Судя по вот этому моменту из списка в конце статьи, автор иногда привлекает фрилансеров для какой-то части работы.

            +2
            Этот стек совсем не скучный.
              +1
              Масса полезной информации по организации стартапа.
              Каждый совет заслуживает внимания.

              Я, прежде чем остановился на Gusto, сначала работал с PayChex и ADP.
              Если бы знал раньше о Gusto, сэкономил бы время и деньги.
              Вобщем, внимательно читаю… :)
                +2
                Ну точь в точь стек для моих pet projects. Только у меня с докерами и нормальным CI/CD, который позволяет спокойно и расслабленно кодить, не волнуясь что там что-то пойдет не так. При чем CI бесплатный на gitlab был сделан сразу чтобы не отвлекаться потом на такие вещи, а заниматься только кодом.
                Для серверов предусмотрен серьёзный оверхед на случай какого-то огромного всплеска посещаемости из-за попадания в прессу или чего-то ещё.
                Интересно что это значит. Что сейчас все крутится на больших серверах, используется 1% мощности и за все платится с оверхедом?
                Потому что конструкция автора как-то не выглядит особо scalable. Для пет проджекта это понятно, но походу какой-то рост у автора в планах не предусмотрен.
                production-pangu — производственный сервер, на котором я иногда запускаю одноразовые скрипты и тестирую изменения.

                На продакшне. ОК.
                  +1
                  Непонятно чем ваш подход надежнее: тут запускается скрипт, человек на него смотрит и, в случае ошибки, немедленно что-то сделает. CI/CD — это тот же скрипт только по коммиту — вряд ли запуск отсматривается человеком, а, значит, информация о проблемах (а куда без них время от времени) будет получена позже.

                  > Интересно что это значит. Что сейчас все крутится на больших серверах, используется 1% мощности и за все платится с оверхедом?

                  Да, в статье есть скриншот — там до 10% загрузка CPU.

                  Единственно, если ничего интересного от AWS не используется (ни LB, ни автоскейлинг, ни preemtive vms) я бы переехал на DigitalOcean — должно получиться в 2 раза дешевле.

                  > На продакшне. ОК.

                  В old school это называется install server или jump host, совершенно обычная практика.
                    0
                    Вы серьезно спрашиваете про CI/CD? По-моему вы не имеете представления что это такое.
                    Да, в статье есть скриншот — там до 10% загрузка CPU.
                    Об этом и говорю, просто переплачивает.
                    (ни LB, ни автоскейлинг,
                    Чтобы использовать автоскейлинг нужно строить scalable приложение.
                    В old school это называется install server или jump host, совершенно обычная практика.
                    Замечание было о дебаге на продакшне вообще, а не как это делать. И нет — это не обычная практика, это очень плохая практика.
                  0
                  Респект человеку за то что смог допилить продукт и вывести на рынок в пригодном для пользования виде. Вижу пару возможных проблем:
                  — lb нода 1 и она судя по описанию ec2 инстанc, поменять бы на alb и спать спокойно;
                  — судя по именам и какойто вебморде для ансибла автоскейлинг не используется.
                  Ну и деплой скриптами…
                    +5
                    Очень полезная статья для организации собственного проекта. Понравилось, что автор не идет по пути исключительно хайпа и пропагандирует принцип «Лучше сделать что-то не сильно красиво, но полезное кому-либо, чем полировать идею и так и не воплотить ее». Однако разработка в мастере без веток ИМХО спорный вариант. Даже для одного человека в команде :)
                      0
                      Работаю по аналогичной схеме, тоже одна ветка.
                      Просто привыкаешь постоянно интегрировать все апдейты в одну систему, и всё. Не ради кого поддерживать легаси, ты сам единственный постоянный потребитель своего кода.
                        +3
                        Дело вкуса, как я понимаю. Мне привычнее делать под каждую фичу отдельную ветку с последующим PR-ом. Меня это не напрягает и не тормозит. Зато при возможном расширении команды не придется перекраивать процесс разработки.
                      0
                      Отличная статья, единственное, CI я бы все-таки добавил, с ним жизнь куда «скучнее»))
                        +1
                        Удивило то, как выглядит коворгинг.
                        В нашем городе это больше походило на большой бетонный склад со столами.
                        Гламурными макбуками со смузи там и не пахло.
                        «Бизнесмены» еле сводили концы с концами.
                          0
                          Так это wework — они на инвестициях (вроде бы не прибыльны еще).

                          У нас актуальнее просто снимать комнату в офисном центре (или даже квартиру, особенно если несколько человек). Немного больше проблем (уборка, интернет, обустройство кухонного уголка, мебель), но дешевле и во многом удобнее.
                          0
                          мы живем в крутое время, когда один человек может создать что-то интересное сам или с небольшой помощью. Я пока только в начале этого пути(
                            0
                            Кто работал с DataDog, первый скриншот — тоже оно?
                              +1
                              Вопрос по MacBook Pro. Объясните непосвященному, чем обусловлен такой выбор у огромного числа разработчиков? Экран с Ретиной если только. Что еще привлекает в сравнении не не-эпловыми ноутоами?
                                +8
                                DISCLAIMER. Все что написано ниже — мое личное мнение.
                                — огрызки качественно собраны, легкие, довольно автономные, имеют под капотом весьма качественное железо.
                                — OS X — unix с человеческим лицом. Сочетает в себе плюсы *nix и винды. Да, у современных дистрибутивов linux лицо тоже вполне человеческое, но иногда бывают танцы с драйверами или чем-то подобным. OS X работает из коробки, и умеет то, что нужно разработчикам. Удобный шелл, скрипты, etc…
                                  +1
                                  Сижу на Fedora — все так же работает из коробки, апдейты идут гладко, тот же VSCode имеется. По железу, кроме экрана, все остальное найти можно и помощнее, и намного дешевле.
                                    0

                                    Получается, экономим на экране, то есть на глазах. И зачем?

                                      0
                                      Зачем экономить на экране, когда можно подключить ноутбук к хорошему внешнему монитору, без которого все равно работать не очень удобно?
                                        +2

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

                                          0
                                          Документация им тоже не нужна?
                                            +3

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

                                    –3
                                    — OS X — unix с человеческим лицом. Сочетает в себе плюсы *nix и винды

                                    Убогий интерфейс с вырвиглазным дизайном и невозможность тонкой настройки под свои нужды нивелируют это.
                                    OS X работает из коробки, и умеет то, что нужно разработчикам.

                                    Есть проблема что пока все «просто работает» то всё классно, но если что-то не работает то оно «просто неработает» и хоть ты тресни.
                                    Удобный шелл

                                    Это который недалеко ушёл от xterm?
                                      +3
                                      1) О вкусах не спорят. Кому-то вырвиглазный, кому-то норм.
                                      2) Он ушел далеко от виндовых cmd и powershell (хотя я хз что там в последних версиях windows. Может тоже все неплохо).
                                        0
                                        2) Он ушел далеко от виндовых cmd и powershell (хотя я хз что там в последних версиях windows. Может тоже все неплохо).

                                        все так же плохо, активно пилят github.com/microsoft/terminal но пока еще сырой, может и выстрелит.
                                      • НЛО прилетело и опубликовало эту надпись здесь
                                          0
                                          >iTerm2
                                          Он вроде давно не поддерживается.
                                          Но в последних версиях макоси таки допилили родной терминал.
                                          • НЛО прилетело и опубликовало эту надпись здесь
                                      –6
                                      Это же ЭППОЛ!
                                        +2
                                        Дело не в MacBook, а в macOS. В т.ч. python, ruby, etc: комфортная работа с environment (типа brew и всяких rbenv), как следствие, более высокий КПД и отсуствие траты время на танцы с бубном.
                                          +1

                                          Не знаю, насчет ruby, а в python комфортная работа обеспечивается не средствами ОС, а различными virtualenv, pipenv, и так далее, которые работают в любой ОС. И в Linux вполне комфортно работать с python в каком угодно environment (и, думаю, ничем не отличается от Mac OS).

                                            0
                                            только на винде чтобы поставить софт вам надо найти его сайт в инете, скачать и запустить инсталлятор, параллельно выясняется что какой-то пакет вообще под винду не существует, или есть, но в урезанном виде и т.д. и т.п.
                                            на маке вы просто пишете brew install python и все на этом)
                                              0

                                              К счастью, не знаю, как там на винде. На Linux любой софт я устанавливаю при помощи apt install или pacman -S. Ну и конкретно пакеты для python при помощи pip install.


                                              brew, думаю, был скорее вдохновлен подобным софтом из Linux, нежели первой подобной системой, которую реализовали в Mac OS. К тому же, brew — это вроде бы не официальный пакет и не от Apple. Прошу прощения, если это не так — в жизни не владел техникой Apple, и сужу только по обрывкам информации, которые случайно видел.

                                                0
                                                я и не спорю, что линукс в плане работы в консоли и установки утилит еще лучше чем максось. brew ставится с сайта, а дальше работает почти как линукс из коробки, макось мне как и многим предпочтительнее линукса именно из-за намного более user-friendly UI и полного отстуствия необходимости хоть что-то чинить в самой системе руками. но это уже дело вкуса, в отличие от преимуществ перед windows.
                                                0
                                            0
                                            Как написали уже,
                                            • Обычно это работающий девайс «из коробки» без каких-либо телодвижений.
                                            • Экран действительно хорош и многие дизайнеры в восторге от возможности таскать такой экран с собой и работать везде.
                                            • Инфраструктура и приложения — опять же многие помимо ноутов и компов имеют еще и айтелефоны и айпланшеты и синхронизация между устройствами кому-то да важна.

                                            P.S. Сейчас пользуюсь ноутом с Mint/Win10 (больше для работы), но был когда то мак стационарный и был им весьма доволен.
                                              0
                                              Потому что винда уж порядком задолбала и надоела, особенно после висты. А линукса все еще остерегаются из-за страхов и мифов из девяностых, когда это была сырая система.
                                              Сегодня по-моему любой распостраненный дистр будет как минимум не уступать макоси. С точки зрения удобства разработчика, конечно. Про девопсов, сисадминов и т.д. вообще говорить не приходится.
                                              К тому же в последнее время железо от аппла вызывает очень много вопросов. Ладно еще гнаться за тонкотой в телефонах, но в компах то зачем??
                                                0

                                                Они шустрые, почти никогда намертво не зависают, а если что то в нем и зависает, то оно не вешает перформанс намертво, вы можете посерфить в бразуере пока ваша софтина повисла из за бесконечного цикла. Удобная организация нескольких рабочих столов в дополнение к идеальному тачпаду даёт вам возможность имея один 15 дюймовый экран чувствовать себя приятнее чем, с двумя большими под виндой или линуксом. Ну и на нем можно реально автономно покодить 8 часов.

                                                0
                                                Познавательно, всегда интересно посмотреть, как другие делают свои проекты.
                                                Любопытно, что у автора статьи для всего использованы EC2 инстансы, а не аналогичные сервисы амазона, такие как Elasticsearch Service, RDS, кэш и API от Cloudfront, Lambda, SQS, Cloudformation для разворачивания всего этого, CodeCommit для хранения кода и т.д. Не совсем понятно, с чем это связано.
                                                  0

                                                  Минимальный вендор-лок или тупо дешевле (вариант — предсказуемей) по деньгам

                                                  0
                                                  Всё работает на AWS, всего 20 серверов в продакшне (на 5 мая 2019 года):

                                                  Почти обогнал StackOverflow с его 25 серверами.
                                                    0
                                                    Побольше бы таких статей. Знает кто как искать? Можно и на английском
                                                      0
                                                      Спасибо за перевод, хорошая статья и сервис.
                                                      Оказывается, что-то полезное можно сделать и одному :)

                                                      Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

                                                      Самое читаемое