Платформа приложения что это
Платформы мобильной разработки
Russian (Pусский) translation by Ellen Nelson (you can also view the original English article)
Когда вы впервые сталкиваетесь с мобильной разработкой, бывает трудно определить с платформой. Ещë хуже то, что у каждой платформы свой набор языков и инструментов, из которых тоже нужно выбирать. Так как выбрать?
Этот урок поможет вам выбрать подходящую платформу мобильной разработки, чтобы вы могли сразу перейти к написанию приложений.
Платформы и как они делят рынок
Платформа — экосистема мобильных устройств, инструментов и приложений — это обычно определяется её операционной системой (ОС). Изготовители платформ это большие компании, такие как Google, Apple, Microsoft, и т.д. Каждый из них разрабатывает ОС, на которую они выдают лицензию изготовителям устройств. Иногда, они могут также быть разработчиками устройств. Производители устройств разрабатывают и собирают устройства (в основном смартфоны и планшеты) с соответствующей предустановленной ОС. Затем эти девайсы продаются потребителям (пользователям).
Несколько базовых приложений, разработанных изготовителем устройства или даже производителем платформы, может быть предустановлено на устройстве. Однако поставщик и производитель устройств не могут удовлетворить постоянно растущие потребности пользователей этих устройств. Поэтому они полагаются на «сторонних» разработчиков, таких как вы! — чтобы заполнить пробел спроса и предложения.
Для поддержки разработчиков, которые хотят продавать приложения для платформы, они публикуют SDK, API и другие инструменты, чтобы упростить разработку приложений. Кроме того, может быть запущен официальный «магазин приложений» (app store), на котором разработчики могут публиковать свои приложения и откуда пользователи могут просматривать и загружать их. Таким образом, вокруг платформы построена экосистема приложения.
В настоящее время Android OS от Google имеет самую большую долю на мировом рынке с колоссальными 86,1%. Apple iOS имеет 13,7% и занимает вторую позицию. Оставшаяся часть около 0,2% разделяется всеми другими поставщиками вместе. Это включает Windows Mobile от Microsoft, BlackBerry OS, Tizen OS, Sailfish OS и Ubuntu Touch.
Глобальная композиция может значительно измениться в некоторых странах. Например, в США доля рынка Android составляет 53,4%, а доля iOS — 44,5%, что является заметной разницей по сравнению с общей долей рынка. Если вы нацелены на определённый рынок, было бы неплохо исследовать целевую демографию, чтобы выяснить, какую платформу они используют больше всего!
Архитектура ЦП
Хотя все эти платформы поддерживают архитектуру процессора ARM, Android расширяет свою поддержку ещë больше, охватывая архитектуры x86 и MIPS. Tizen, Sailfish OS и Ubuntu Touch также поддерживают архитектуру x86. Однако, если вы не программируете чипы пользовательского ROM, архитектуры CPU, поддерживаемые каждой платформой, не повлияют на ваш выбор.
Как выбрать платформу
Ваше знакомство с языками программирования
Вам нужно будет написать много кода в роли разработчика мобильных приложений. Существуют определенные инструменты, которые позволяют избежать ввода в редактор текстового кода, например, Android и iOS имеют инструменты перетаскивания для создания графических пользовательских интерфейсов. Однако они не позволят вам полностью использовать функции и возможности платформы. Чтобы создавать сложные приложения, вам нужно научиться языку программирования для этой платформы.
Поэтому вам, возможно, придется приложить некоторые усилия, чтобы изучить новый язык программирования или освоить тот, который вы уже знаете. Все основные платформы используют популярные языки программирования с большими сообществами разработчиков. Поэтому убедитесь, что вы используете свои знания и навыки в этих языках.
Если вы знакомы с Java, вам будет проще разрабатывать приложения для Android на Android SDK (Software Development Kit). Однако некоторые расширенные функции приложения потребуют от вас навыков C и C++ для Android NDK (Native Development Kit). Кроме того, теперь можно программировать для Android на альтернативных языках, такие как Kotlin.
Чтобы разрабатывать для BlackBerry или Tizen, просто изучите HTML, CSS и JavaScript.
Освойте QML или Python и вы готвы разрабатывать приложения для Sailfish.
Если вы любите Ubuntu Touch, вы должны изучить QML или HTML и JavaScript.
Наконец, если вы уже знаете веб-языки, такие как JavaScript и CSS, вы можете использовать их для разработки для любой платформы с межплатформенным мобильным фреймворком.
Постоянно предлагаются и продвигаются новые языки программирования. Хотя не всегда ясно, имеют ли эти новые языки большое преимущество перед старыми, хорошей идеей будет оставаться в курсе последних тенденций. Некоторые языки программирования могут стать устаревшими с введением новых. Например, Swift является заменой Objective-C, а некоторые старые языки могут найти новое существование в совершенно новом применении.
Родная разработка или гибридная
У вас есть два варианта, когда дело доходит до разработки приложений для смартфонов: родные приложения и гибридные. Родное приложение, предназначенное для одной платформы, не будет работать на другой платформе. Например, вы не можете установить (родное) Android приложение на устройство с iOS. Вам необходимо выпустить отдельную версию для конкретной платформы, созданную с использованием соответствующих средств разработки, ориентированных на iOS. Напротив, гибридное приложение представляет собой веб-приложение, разработанное с помощью HTML, CSS и JavaScript, и завернутое в оболочку приложения (или пользовательский интерфейс).
Что замечательно в отношении родных приложений, так это то, что они превосходят по производительности и полностью используют возможности устройства. Кроме того, они более безопасны. Недостатком является то, что разработчик должен поддерживать несколько кодовых баз для каждой из платформ. Поскольку гибридные приложения имеют только посредственный доступ к родным API, их производительность и уровень пользовательского опыта (UX) несколько отстают. Ключевым преимуществом гибридных приложений является то, что разработчик может издавать для нескольких платформ с тойже кодовой базой.
Если вы хотите создавать собственные приложения, вы можете ознакомиться с нашими полными курсами по началу работы с приложениями для Android или iOS.
Ionic 2 это популярная платформа для разработки кросс-платформенных гибридных мобильных приложений. Он основан на веб-структуре Angular 2. Если вы хотите узнать больше, ознакомьтесь с некоторыми из наших курсов или уроков.
Родные кросс-платформенные приложения
Недавно появилась новая серия мобильных кросс-платформенных фреймворков. Они сочетают в себе лучшие возможности родных и гибридных приложений — они быстрые и легкие, и могут получить доступ ко всей мощности родного устройства, а ещë они закодированы с использованием JavaScript и других веб-языков, поэтому множество кода можно повторно использовать между платформами.
React Native и NativeScript являются популярными встроенными кросплатформенными фреймворками. Если вы хотите узнать больше об этом, ознакомьтесь с нашим полным курсом для новичков или некоторыми из наших многочисленных руководств.
Ваша способность к обучению
Если вы быстро обучаемы, вы можете легко освоить собственный путь разработки. Вам необходимо понять основные понятия программирования, такие как объектно-ориентированное программирование (ООП), и вы должны научиться чувствовать себя комфортно с техническими концепциями платформы, например такими как Application Lifecycle Management в Android.
Чтобы начать работу, просто загрузите необходимые инструменты и SDK у поставщика платформы и попробуйте. Большинство из этих инструментов с открытым исходным кодом, в них есть множество примеров кода и шаблонов приложений, которые помогут вам быстро начать работу.
Если вы являетесь веб-разработчиком и хотите исследовать пространство разработки для смартфонов, то вам может быть удобнее начинать с гибридной или кросс-платформенной разработки.
Настройка системы & простота кодирования
Ещë один фактор, который следует учитывать, это платформа ОС, а иногда и аппаратная настройка компьютера для разработки.
Если вы хотите разрабатывать собственные приложения для iOS, вы не сможете сделать это на обычном компьютере под управлением Windows. Вам нужен Mac с macOS и Xcode, IDE от Apple для разработки на iOS. Аналогично, родные приложения Ubuntu Touch лучше всего разрабатываются на компьютере Ubuntu. Хотя Android SDK работает на всех трёх основных платформах ОС, всегда рекомендуется проверить, соответствует ли ваша система рекомендованным спецификациям, прежде чем начинать разработку.
Политика App Store & распределение доходов
Магазины приложений Google и Apple взимают номинальный регистрационный взнос. Хотя оба предлагают одинаковый процент распределения доходов (70% от цены продажи в настоящее время), разработчики могут теоретически получать больше доходов, публикуя на Apple. Это связано с тем, что количество приложений относительно невелико и конкуренция среди подобных приложений меньше. Кроме того, вам необходимо знать, что не для всех географических местоположений разрешено публиковать платные приложения в Play Маркете Google. Поэтому вы должны заранее подумать о способе монетизации своего приложения.
Помимо продажи самого приложения, ещë один способ монетизации вашего приложения это показывать рекламу или предлагать разблокировать дополнительные функции.
Целевые потребители
Это важный фактор, потому что успех вашего приложения зависит от того, насколько хорошо вы обращаетесь к своей аудитории или насколько эффективно решаете их проблемы. В то время как большинство пользователей смартфонов, как правило, принадлежат к молодым поколениям, есть приложения для смартфонов, предназначенные для пожилых людей и людей с ограниченными возможностями. Поскольку доля рынка платформы изменяется по странам и возрастным группам, неплохо исследовать демографику платформы, если вы хотите нацелится на определенную демографику.
Поддерживаемые функции устройства на платформе
Не все устройства поддерживают каждую функцию платформы. С одной стороны, есть высокопроизводительные устройства, часто называемые «флагманскими продуктами», поддерживающие большинство функций. С другой стороны, есть недорогие устройства начального уровня, поддерживающие только основные функции. А потом уже всё остальное.
Поэтому при разработке приложений вы должны быть очень избирательными и принимать обоснованные решения. Разработка приложения, которое нуждается в функциях, поддерживаемых только высокопроизводительными устройствами, может серьезно повлиять на продажи вашего приложения.
С другой стороны, это может быть возможностью, если вы можете предложить пользователям расширенного устройства функцию приложения, которая недоступна где-то ещë.
Заключение
В этой статье я рассмотрел все основные мобильные платформы разработки и попытался дать вам несколько советов, которые помогут вам выбрать между ними. Применение этих знаний поможет вам стать успешными в деле разработки приложений.
Как выбрать мобильную кросс-платформу в 2021 году
Новый развивающийся бизнес зачастую в первую очередь ориентируется на мобильные технологии: социальные сети, необанкинговые решения, приложения для электронной коммерции, такси и другие. Новый бизнес ориентирован на экономическую эффективность, поэтому переход на кросс-платформенность для разработки мобильного приложения кажется правильным выбором. Посмотрим, что будет в 2021 году и как выбрать правильную технологию.
Познакомимся с Женей
Евгения — солюшн-архитектор. Она должна решить, как построить новое мобильное приложение для изучения английского языка не носителями: людьми из Турции, Италии или России. Давайте посмотрим, как Женя подходит к этой задаче.
Приложение должно включать в себя богатую анимацию, уметь воспроизводить и записывать аудио, показывать видео с субтитрами, а также статические и динамические изображения.
В компании — владельце приложения также ожидают, что разработкой будет заниматься единая команда — как для Android- и iOS-приложений, чтобы свести к минимуму усилия по передаче знаний и максимизировать скорость команды. В будущем также планируют запустить веб-приложения. А еще в компании хотели бы упростить будущий найм.
Прогрессивные веб-приложения
Женя начинает свои исследования. Она гуглит «мобильные веб-приложения» и находит статью. В ней упоминаются «Прогрессивные веб-приложения» (PWA). Что это такое?
Прогрессивные веб-приложения — это, по сути, веб-сайты, которые используют специальные API для доступа к определенным возможностям устройства. Эти API позволяют получить доступ к памяти на устройстве, интегрируются с Push Notifications (на Android) и, что самое важное, работать в отдельной вкладке браузера. Еще их можно установить на устройство «иконкой», как настоящее приложение. Звучит неплохо! Давайте посмотрим на плюсы и минусы PWA:
Натив или кроссплатформа? Детальный разбор простым языком
Немного знаний терминологии не повредит, чтобы иметь больше совместного контекста. Постараюсь не быть занудой.
SDK — software development kit — инструментарий разработчика. Говорят например, — AppStore SDK — набор инструментов для реализации платежей и подписок в приложении. Или Android SDK — совокупность более мелких SDK для разработки под всю платформу.
API — это программный интерфейс, (тяжело объяснять простыми словами оказывается). Руль — физический интерфейс к колёсам, коробка передач — к двигателю, мы дергаем за них, чтобы машинерия внутри сделала для нас более сложную работу через простой для восприятия интерфейс. Программные интерфейсы — наборы функций, объектов, используя которые программисты выполняют сложную работу более простыми действиями.
Поскольку сухой разбор преимуществ и недостатков той или иной технологии — пустая трата времени, будем честны, из любой технологии можно сделать какашку и конфетку, вопрос лишь какой ценой, поэтому для развития осознанного понимания, зайдем чуть издалека.
Так или иначе, клиент любого бизнеса, пожелавшего открыть для себя вожделенную айтишечку, доступен через 3 окошка:
Также мы не рассматриваем устройства носимой электроники, интернета вещей, экранов холодильников, различных embedded систем — уж очень они специфичны.
На заре широкого коммерческого успеха мобильных гаджетов, некто по фамилии Джобс, отстаивал идею о том, что персональный смартфон — это всего лишь окошко к всемирной паутине, которое всегда с собой. Круто же звучит! Вот что он говорил:
Полноценный движок Safari уже присутствует внутри iPhone. То есть, вы можете создавать изумительные Web 2.0 и Ajax приложения, которые выглядят и ведут себя так же, как родные программы iPhone. И они способны прекрасно взаимодействовать с его сервисами: звонить, отправлять электронные письма, разыскивать местоположение в Google Maps. И знаете, что? Для этого не нужен SDK! У вас уже все есть для написания невероятных приложений для iPhone, если вы знаете, как создавать программы, используя современные веб-стандарты.
Есть предположение, что изменить взгляд Джобсу помог Джонни Айв, убедив его в том, что устройства эппл без нативных сторонних приложений не будут доступны для создателей контента, плюс от этого платформа потеряет эксклюзивность. В тоже время, в кулуарах Гугл зрел андроид и у менеджмента не было особого мнения на этот счет.
Собственно, к чему эта лирика. Исторически, мы имеем два основных способа доставки приложения пользователю:
-Нативное приложение — созданное с использованием инструментов разработки вендоров: Apple/Google и распространяемое через магазины приложений. Для разработки под Apple актуальны технологии: UIKit, SwiftUI + богатый iOS SDK, язык программирования Swift (и для особых случаев старичок Objective-C)Для Андроид соответственно — Android SDK, Jetpack Compose, языки: Java 8, Kotlin
Веб-приложение, использующее браузер в качестве среды выполнения и ограниченного доступа к ресурсам девайса (я специально не называю веб-приложение сайтом, так мы в терминах отделяем статические странички от динамичных, наполненных различной бизнес-логикой, приложений). К ним же относятся так называемые WebView — приложения, обернутые тонким слоем нативного кода, использующего SDK браузера для открытия веб-приложения, также распространяются через сторы.На ладан дышащие представители этого вымирающиего семейства — Apache Cordova и Ionic. Они не скрывают свое основное назначение — быстрое прототипирование приложений. Для них актуальны классические веб технологии — HTML, CSS, Javascript. Сюда же попадают поделки из no-code конструкторов типа GlideApps и его аналогов.
Оба подхода стоят диаметрально противоположно друг другу по ряду критериев:
Промеж первых двух, с недавних пор, расположись гибридные технологии, которые в настоящий момент чаще всего подразумеваются как кроссплатформенные:
Гибридные, компилируемые в нативный код — приложения написанные с использованием сторонних инструментов разработки, языков программирования, которые имеют свой набор библиотек, связывающих программные интерфейсы платформенных SDK с собственными интерфейсами или полностью заменяющие их.
Типичные представители этого семейства: React Native, Native Script, Electron.
Пока мы не убежали далеко, хочу немного шокировать нетехническую публику — самая кроссплатформенная технология, он же язык программирования, внимание, — C++! Та-да-а-ам! И как ни странно, он очень широко используется для создания полностью нативных кроссплатформенных модулей. Никаких компромиссов! Только хардкор! Ведь наши приложения, это не только кнопочки и списки. Обработка сотен точек на картах, базы данных с особыми возможностями синхронизации совместного доступа к данным, криптография, доставка и обработка видео в реальном времени, ежесекундные данные котировок, которые мы хотим доставлять молниеносно для десятков биржевых тикеров одновременно и многое другое. Никто не пишет эту логику дважды или трижды под каждую платформу.
Главный вопрос при выборе технологии (безотносительно иных бизнес целей) — опыт какого качества мы хотим подарить пользователю. И вот несколько критериев, влияющих на пользовательский опыт:
Говоря образно, по степени абстрактности к конечной мобильной платформе, технологии можно разделить так:
Кроссплатформенные технологии, в первую очередь, хотят завлечь нас преимуществами единой кодовой базы. С этим трудно спорить:
Сравните 2 кусочка кода, описывающих карточку с картинкой:
Команды нативных разработчиков часто разбавляют C/C++ программистами. Они пишут кроссплатформенные модули для разных задач в основном не связанных непосредственно с бизнес логикой.
На старте с нуля ему нет равных в качестве продукта к скорости разработки. 2-3 разработчика способны наковырять безумное количество фич в кратчайшие сроки и выпустить продукт. При этом look-and-feel, производительность будут более чем приемлемыми. Большое количество библиотек решат множество задач типовой функциональности. Я бы назвал flutter серебряной пулей, но. надо кое-что иметь в виду.
Технология предназначена для создания UI! Как и язык программирования Dart.
Выдержка из википедии в доказательство о том, что есть флаттер на самом деле:
Flutter is an open-source UI software development kit created by Google.
Разработка с этим SDK мне всегда напоминала письмо из Простоквашино:
На личном опыте проверено, что в процессе развития продукта скорость нативной разработки со временем возрастает, а кроссплатформенной убывает. Это обусловлено тем, что в начале требуется больше усилий для сборки архитектуры и наработке кода для 2х проектов, нежели для одного. Пока умудренные в особенностях своих платформ, кодеры скрупулезно собирают базовые джентельменские наборы для любого нативного приложения, их коллеги по кроссплатформенному цеху возможно уже готовятся выпускать MVP. Всё меняется на зрелой стадии продукта.
Вот список бед на кроссплатформе, которые на поздней стадии сожрут больше денег, чем на старте:
Дайте знать, если хотите продолжение про KMM и Xamarin, жду вас и ваши мнения в комментариях!
Канала в телеге нет, но если что, пишите в личку
Выбор оптимальной платформы для веб приложения
В нашем мире мобильных гаджетов, сфокусированных на приложениях, уже не принято говорить о веб-сайтах. Классические веб-сайты служат в основном для информационных целей, а для работы с целевой аудиторией бизнес нуждается в веб-приложениях. И тут неизбежно встает вопрос о том, где эти веб-приложения могут работать максимально надежно, быстро и эффективно с точки зрения затрат. Выбор возможных решений достаточно велик и мы рассмотрим достоинства и недостатки некоторых из них ниже. Но все же, забегая вперед, можно с уверенностью сказать, что облачные решения в настоящее время являются наиболее оптимальными.
Проблемы внедрения
Множество возможных решений вызывает головную боль у новичка. Что выбрать? Что дешевле? Что надежнее? Где лучше техподдержка? Где больше возможностей и где лучше перспектива роста? Давайте рассмотрим плюсы и минусы каждого из вариантов.
Dedicated server
Shared Hosting
Если вы решили использовать Shared Hosting, то со стоимостью необходимых затрат наоборот, все хорошо. Это, пожалуй, самое дешевое решение. К тому же часто дополнительно вы получаете бесплатные доменные имена. Ваш сервер настроен и в общем-то не требует специальных технических знаний для использования. Все обслуживается и администрируется службой поддержки сервис провайдера. Но при этом вы крайне ограничены в добавлении и конфигурировании дополнительных возможностей для вашего проекта. Более того, производительность и стабильность вашего веб-приложения может серьезно пострадать из за внезапных и значительных потоков трафика и потребления ресурсов сервера соседними сайтами и веб-приложениями. А таких прожорливых соседей у вас может быть несколько сотен! Оперативности технической поддержки при таком количестве клиентов скорее всего не следует ожидать. Кроме того, остро стоит вопрос безопасности shared hosting-а, ведь если хотя бы один из сайтов или веб-приложений будет взломан злоумышленниками, скорее всего они сумеют получить доступ и к ресурсам других проектов на этом сервере. По этим и другим причинам рынок shared hosting стагнирует в последние годы.
VPS Hosting
Одно из самых популярных решений. У многих на слуху компания DigitalOcean со своими популярными предложениями. Виртуальные приватные сервера дороже, чем Shared Hosting, на за эту разницу в цене вы получаете выделенные только для вас ресурсы на сервере, соседи по серверу не влияют на производительность вашего веб-приложения, конфигурируемость очень высокая поскольку вы имеете полный root доступ к вашей системе и тем самым имеете полное право на выполнение всех без исключения операций. Удобно вертикально масштабировать ваш VPS вручную и с даунтаймом. Достаточно остановить VPS, добавить ресурсов и снова запустить. С физическим сервером такое не пройдет. Но опять же, помимо достаточно ощутимой цены, тут требуется высокая квалификация и серьезные технические знания по управлению серверами. По сути, нужны специалисты такого же уровня, как и для управления физическими серверами, разница только в том, что нет проблем с hardware (не нужен план замен, закупок, монтажа и тому подобное), но инфраструктурно всё то же самое. Поэтому и для VPS hosting нужны высококвалифицированные администраторы. Чтобы сконфигурировать рабочее окружение для вашего веб-приложения и поддерживать его, вам потребуется немало времени.
Managed Hosting
Clouds
Потребляемые ресурсы практически мгновенно могут масштабироваться по вашему требованию в зависимости от изменения нагрузок. Даже при использовании собственных облаков компании на базе внутренней мультисерверной инфраструктуры масштабируемость не достигается так просто, и стоимость ее реализации в этом случае весьма высока.
Капитальные расходы заменяются на операционные, поскольку вместо крупных авансовых платежей на приобретение и установку оборудования и ПО, вы осуществляете регулярные равномерные платежи за доступ своих сотрудников к нужным им ресурсам, причем только по факту их потребления.
Устраняется необходимость в приобретении и установке собственных серверов или аренде серверов у провайдеров/датацентров для работы приложений и хранения информации, что позволяет экономить как офисные площади, так и средства на создание и обслуживание серверных помещений (кондиционирование, безопасность доступа, бесперебойное энергопитание и т.д.)
Исчезает необходимость в собственном штате системных администраторов для обслуживания серверного оборудования.
Усложняет задачу выбора и тот факт, что для использования AWS Cost Forecast или калькулятора для расчета расходов от пользователя требуются специфические знания и навыки. Кроме того, весьма сложно создать описания процессов, структуры и необходимых скриптов. Все это требует наличия высококвалифицированных специалистов, глубоко разбирающихся в облачных технологиях Amazon, Google или Microsoft.
App-specific providers
Если рассматривать услуги App-specific providers, которые рассчитаны в первую очередь на разработчиков, то широко известными примерами таких сервисов являются Google AppEngine, VMWare Pivotal Cloud Foundry, Heroku, Pantheon и другие. Такие сервисы представляют наборы готовых компонентов для создания приложений, а также фреймворки для управления платформой. В данном случае компонентами будут являться сервисы баз данных, репозитории, инструменты автоматизированного деплоя, мониторинга, среды тестирования и тому подобные сервисы.
Предлагаемое решение
Мы предлагаем существенно снизить этот порог вхождения в облачные технологии для компаний при помощи своего нового разрабатываемого продукта WSP. По сути, порог вхождения снижается до наличия всего лишь трех необходимых компонентов:
Ваше приложение должно быть докеризируемым, то есть иметь возможность работать в докер контейнере и собираться через docker build.
Кастомизация и отличия от конкурентов
После развертывания приложения с помощью WSP, вы можете впоследствии кастомизировать его с помощью собственных terraform скриптов, например, или другими методами. При этом те внесенные кастомизации, которые не управляются из WSP, не будут потеряны после последующих развертываний новых версий приложения. Другим преимуществом WSP перед его основными конкурентами, продуктами Pantheon и Heroku, является то, что в них требуется предварительно написать манифест для развертываемого приложения, что требует высокой квалификации и глубокого знания продукта. При этом приложения у конкурентов будут работать только на их собственной инфрастуктуре, а в случае WSP приложения работают на инфраструктуре Amazon и будут продолжать работать на ней даже в случае отказа от дальнейшего использования WSP. В качестве минуса WSP, можно назвать необходимость отдельно оплачивать использование аккаунтов WSP и AWS, тогда как в Pantheon и Heroku вы оплачиваете только их аккаунты.
Масштабируемость
В отличие от решений масштабируемости, которые предлагают сервис провайдеры, WSP предоставляет возможность использовать autoscaling, или, иначе говоря, горизонтальную масштабируемость. Autoscaling легко настраивается в зависимости от потребностей работы вашего приложения. Учитывая, что вы платите только за фактически используемые ресурсы, autoscaling становится очень выгодным решением. Если нагрузка снижается, избыточные серверные мощности высвобождаются, соответственно вы платите меньше.
Autoscaling выгоден в тех случаях, когда нагрузка на ваше приложение имеет четко выраженный пиковый характер. Например онлайн магазины – покупатели массово подключаются к серверам в период распродаж или в предпраздничные дни. Autoscaling обеспечит серверам стабильную работу в часы пиковых нагрузок и отключит ненужные ресурсы тогда, когда потребность в них исчезнет. То же самое можно отнести и к новостным блогам с выраженной пиковой нагрузкой в периоды актуальности горячих тем.
На скриншоте ниже хорошо видно, как просто это можно настроить:
Мониторинг и логи
Настройка систем мониторинга и логирования крайне нетривиальная задача в AWS. В WSP логирование с помощью ELK stack (Elasticsearch, Logstash, Kibana) и мониторинг с использованием Prometheus или Grafana настраиваются и подключаются предельно просто. То есть, они подключаются автоматически к каждому приложению, если при регистрации AWS аккаунта к WSP было выбрано использование этой функциональности. В то же время вы всегда можете отключить мониторинг и логи, например, для экономии. И наоборот, включить их, когда они потребуются.
Так как мониторинг и логирование разворачиваются в AWS аккаунте, то они входят в стоимость AWS. Следовательно эти функции не исчезают даже если вы отказались от использования WSP.
Управление затратами
WSP в процессе развертывания приложения производит детальную разбивку затрат, что позволяет вам сделать точный прогноз по расходам за облачные сервисы, используемые вашим приложением. Эту сформированную разбивку и остальные данные по управлению затратами вы можете посмотреть в AWS Cost Explorer. Там можно увидеть затраты по временным периодам (в день, в месяц, в год) и по сервисам.
Технические домены с сертификатами
Автоматическое развертывание баз данных в Amazon RDS
WSP может автоматически разворачивать экземпляр базы данных типа PostgreSQL, MySQL или MariaDB для вашего приложения в Amazon RDS. Это настраивается непосредственно в «Environment settings» вашего приложения:
Zero downtime
Если в процессе работы с вашим приложением WSP производит развертывание новой версии приложения или откат на предыдущую версию, сессия работы переключается с текущей на новую версию приложения совершенно незаметно для вас. Реализован полный Zero Downtime для таких случаев.
One more thing!
Lift&Shift. Особенное внимание в разработке и концепции WSP уделяется тому, что вам совершенно не нужно как-то адаптировать и переделывать ваше приложение для его работы в облаке. С помощью WSP оно будет работать без каких то дополнительных усилий для его адаптации.
В WSP ограничение доступа к вашим приложениям обеспечивается с помощью Access Rules. Вы можете добавить в них те сети и адреса, с которых возможен доступ. Со всех иных сетей и адресов доступ будет закрыт.
WSP обеспечивает асинхронную работу. Вы можете одновременно выполнять инициализацию, сборку, развертывание приложений. Все будет работать одновременно. Даже закрыв сессию браузера вы не прервете выполнение уже запущенных задач.
Все секретные данные, такие, например, как пароли, логины и т.д. шифруются.
Поддерживается непрерывное развертывание (Continuous Deployment (CD)). То есть, платформа может автоматически собирать и разворачивать приложение по коммиту в GIT репозитории.
В настоящее время в качестве поддержки концепции «Infrastructure as a code» WSP может считывать параметры приложения из специальных файлов из git-репозитория, то есть кроме задания параметров приложения из UI возможно задавать параметры в файле.
Планы дальнейшего развития
В настоящее время WSP работает только с облачной инфраструктурой Amazon. В дальнейшем планируется расширить этот список облачными сервисами Google, Microsoft Azure и DigitalOcean. Для тех потребителей, кто использует инфраструктуру на базе Kubernetes также планируется поддержка.
Другим интересным путем развития WSP видится использование готовых докер образов приложений непосредственно с DockerHub.
Заключение
Как видно из перечисленных выше преимуществ, главной ценностью проекта WSP является максимальное упрощение процесса вхождения в облачные технологии для желающих к ним приобщиться. Для мобильного разработчика, дата-аналитика, девопса, докопса и т.д. достаточно лишь сформулировать свою потребность и можно пробовать реализовать ее достаточно просто в облаке с использованием богатых возможностей WSP.