Идеальное облако: AWS, GCP и Azure «все в одном»

В мои обязанности сетевого программиста в начале моей карьеры входила поддержка корпоративной реализации Novell NetWare. Это была середина 1990-х, и Novell доминировала на рынке сетевых операционных систем. Я решил, что в моих интересах стать сертифицированным инженером Novell (CNE). Спустя несколько месяцев и несколько интенсивных экзаменов я получил свою собственную версию этого сертификата:

Самый сложный экзамен в этой серии был посвящен сетевым концепциям и модели OSI, которая обеспечивает семь уровней для использования компьютерными системами при общении по сети.

Этот конкретный экзамен пробудил во мне любопытство, которое не покидало меня более 25 лет спустя.

Опыт сертификации CNE научил меня заглядывать «под капот» при рассмотрении новых технологий, решений и платформ.

После очень положительного опыта работы с моим «Потрать нулевое время на DevOps с Render PaaS» публикация, я почувствовал, что мне нужно погрузиться глубже, чтобы понять структуру сервиса, который обещает Zero DevOps.

Что такое рендеринг?

Render предлагает унифицированное облако, предназначенное для разработчиков программного обеспечения, стремящихся к быстрому развертыванию. Платформа живет в экосистеме, которая хорошо масштабируется.

Представьте себе, что вы можете получить преимущества AWS, GCP и Azure с простотой использования таких решений, как Heroku.

Этот базовый дизайн продвигается в тандеме с обещанием Zero DevOps, что делает каждое развертывание таким же простым, как показано ниже:

В этой трехэтапной модели разработчик сначала выбирает тип службы, а затем указывает некоторую базовую информацию для начального развертывания. Нажатие кнопки Развернуть запускает процесс запуска службы на платформе Render.

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

Поскольку эта предпосылка звучит потрясающе, моя сторона, сдающая экзамен CNE, должна знать, как Render выглядит «под капотом».

Архитектура и дизайн

В разговоре с командой инженеров Render я узнал, что они предоставляют услуги хостинга от нескольких облачных провайдеров. Все сервисы используют Cloudflare для защиты от DDoS и CDN.

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

Внутри единого облака Render команда инженеров использует контейнеры, PostgreSQL, Kubernetes, Go, JavaScript, Git, Redis и Let’s Encrypt для внутреннего проектирования. Для поддержки развертываний push/merge на основе Git между Render и GitHub/GitLab существуют коннекторы.

Для пользовательского интерфейса Render Dashboard команда инженеров Render использует React и GraphQL, чтобы клиенты могли настраивать и поддерживать свои службы, работающие на платформе.

Где Render обеспечивает ценность

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

Чтобы уточнить, если бы я рассмотрел последние пять крупных проектов, над которыми я работал в составе инженерной группы CleanSlate Technology Group, все они превысили наиболее возможную реализацию с сервисом Heroku.

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

Для приложений большого размера Heroku может представлять следующие проблемы:

• Потребности в горизонтальном масштабировании могут иметь нелинейное влияние на ваш бюджет.

• Внедрение надстроек типа Marketplace может привести к более высоким, чем ожидалось, расходам по мере роста использования.

• Эволюция архитектуры решения может потребовать опций, которых нет на платформе, что приведет к созданию дизайна «круглый штифт в квадратном отверстии».

В отличие от этого, Render предлагает решение, которое устраняет проблему градации независимо от размера проекта, предоставляя гибкие и доступные решения на каждом уровне оборудования и услуг.

Некоторые дополнительные преимущества Render по сравнению с конкурентами:**

• Рендер дает каждому клиенту частную сеть между их услугами. Это то, что часто предлагается для «корпоративных» клиентов, которые подписывают контракт, и с них взимается огромная ежемесячная плата за каждое личное пространство. По мере того как развернутая система сервисов становится все более сложной, частные сети становятся все более важными как для задержки между сервисами, так и для снижения риска утечки данных из сетевого трафика.

• Рендер предлагает опцию постоянного диска. Хотя это «ломает» философию 12 факторов (12factor.net), некоторые службы не могут работать без подключенного диска.

• Render предлагает бесплатные статические сайты, в то время как конкуренты требуют нового приложения для обслуживания статического сайта или используют GitHub Pages или аналогичное стороннее предложение.

Но подождите... есть еще

Инженеры-программисты Render также поняли, что клиенты часто ищут для своих приложений нечто большее, чем просто клиентские и API-сервисы (например, в стиле JAM-stack). Рассмотрим эти функции, которые уже доступны в унифицированном облаке Render:

• Частные сервисы: сервисы, которые не публикуются публично, но доступны через автоматическое обнаружение. Они могут прослушивать любой не-HTTP-порт. Пример: службы кеша или базы данных.

• Фоновый рабочий: аналогичен частным службам, но без открытого порта. Примеры включают потребителей и обработчиков очередей сообщений.

• Cron Jobs: запланированные задания, которые находятся в репозитории на основе Git.

• Чертежи: инфраструктура как код, позволяющая поддерживать каждый аспект вашей сервисной инфраструктуры в репозитории на основе Git.

Эти четыре пункта действительно меняют правила игры при сравнении Render с их конкурентами.

Заключение

Я начал заглядывать «под капот» в технологические решения более 25 лет назад, чтобы обрести уверенность в продукте, решении или фреймворке. Я всегда буду помнить, как впервые выполнил это упражнение с помощью Spring Boot, уйдя с высокой степенью удовлетворенности микрофреймворком на основе Java от Pivotal.

Теперь, выполнив то же упражнение с Render, я чувствую тот же уровень уверенности — не только для приложений уровня прототипа, но и для решений корпоративного уровня. Это сильно отличается от моего предыдущего опыта, когда я всегда понимал, что мне в конечном итоге придется мигрировать, как только моя «проблема с выпускным» станет реальностью.

С 2021 года я стараюсь жить в соответствии со следующей миссией, которую, как мне кажется, можно применить к любому ИТ-специалисту:

«Сосредоточьте свое время на предоставлении функций/функций, которые повышают ценность вашей интеллектуальной собственности. Используйте фреймворки, продукты и услуги для всего остального».

**
**- Дж. Вестер

Я действительно чувствую, что Render придерживается моей личной миссии по двум причинам. Во-первых, он соответствует обещанию Zero DevOps, позволяя специалистам по функциям и обслуживанию сосредоточиться на создании надежных решений. Во-вторых, это избавляет от долговременного бремени, связанного с «проблемой выпуска», с которой вы столкнулись бы с любым другим конкурентом на этом рынке.

Если вы инженер-программист и интересуетесь альтернативными вариантами работы с вашим поставщиком облачных услуг, я настоятельно рекомендую попробовать Render… что вы можете сделать бесплатно, просто посетив следующий URL-адрес:

https://dashboard.render.com/register

Хорошего дня!

Также опубликовано здесь