Как создать облачную программу

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

Как вы могли заметить в предыдущих постах в блоге , я фанат Spring Boot и его простоты при создании приложений Java.

Spring Cloud — один из проектов Spring, основанный на Boot и быстро развивающийся за последний год . Общая цель проекта Spring Cloud — позволить вам создавать облачные нативные приложения с помощью Spring Boot. Вот хорошая диаграмма (любезно предоставленная слайдами Дейва Сайера и Спенсера Гибба), которая объясняет, как Spring Cloud вписывается в общую архитектуру Spring.

Как подключить все облачные хранилища, как сетевые диски?

Вот некоторые из функций, включенных в Spring Cloud:

• Распределенная / версионная конфигурация
• Служба регистрации и обнаружения
• Маршрутизация
• Сервисные звонки
• Балансировки нагрузки
• Автоматические выключатели
• Глобальные замки
• Лидерские выборы и кластерное государство
• Распределенный обмен сообщениями

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

Одним из наиболее интересных проектов под эгидой Spring Cloud является Spring Cloud Netflix . Spring Cloud Netflix использует ряд проектов Netflix OSS предоставить некоторые из функций, перечисленных выше. Есть ряд причин, по которым я считаю проект Spring Cloud Netflix полезным. Прежде всего, Netflix стал детищем того, почему микросервисы являются хорошим способом создания облачных приложений.

Одна из причин этого заключается в том, что они открыли большое количество кода, который они написали для запуска одного из самых больших и надежных приложений для микросервисов под зонтиком Netflix OSS. Это означает, что код от Netflix, как доказывают, работает в реальном случае использования, и мне всегда нравится использовать код, который, я знаю, работает. Чтобы упростить использование проектов Netflix, команда Spring взяла некоторые из этих проектов и превратила их в «стартовые», которые можно просто включить в приложение Spring Boot, как если бы вы хотели использовать JPA или AMQP.Некоторые из проектов Spring Cloud Netflix настолько просты в использовании, что им просто нужно добавить пару аннотаций в приложение Spring Boot, реализация будет действительно приятной и чистой. Некоторые проекты Netflix OSS, используемые в Spring Cloud Netflix, включают

• Эврика — для открытия сервиса
• Hystrix — для всех ваших потребностей автоматического выключателя
• Feign — позволяет определять декларативные REST-клиенты
• Лента — балансировка нагрузки на стороне клиента
• Zuul — для маршрутизации и фильтрации

Если вы хотите узнать больше о Spring Cloud, вы можете прослушать несколько хороших записей сессий. Вот один от Джоша Лонга и другой от Спенсера Гибба .

Как создать свое облачное хранилище Windows?

Начать работу с Spring Cloud относительно легко, особенно если вы уже знакомы с Spring Boot. Если вы перейдете на start.spring.io, вы попадете на страницу, которая в основном загрузит ваше приложение Spring Boot, просто заполнив форму. Команда Spring интегрировала проекты Spring Cloud в этот инструмент, что позволяет вам использовать их в своем приложении Spring Boot, если вы выберете.

В этом посте и в нескольких последующих постах мы создадим базовое приложение для микросервисов, используя Spring Boot и Spring Cloud. Один из моих интересов вне технологий — гонки на препятствиях Итак, в духе этого интереса, давайте создадим веб-приложение, в котором перечислены некоторые предстоящие гонки с препятствиями и участники этих гонок. Будет три «службы», которые составляют приложение, одна, создающая список рас, одна, которая производит участников этих гонок, и одна, которая обслуживает клиентов (браузеры) интерфейсный код. Давайте начнем создавать три службы.

Создание Сервиса Рас

Сначала перейдите на start.spring.io и заполните форму, как на картинке ниже. Единственный флажок, который вам нужно будет пометить, — «Веб».

Затем нажмите кнопку «Создать», чтобы загрузить ZIP-файл, содержащий исходный код проекта Spring Boot. Затем вы можете импортировать этот проект в вашу любимую IDE, мне нравится использовать STS , но вы можете использовать обычную Eclipse или любую другую Java IDE, если она поддерживает Maven. Там будет один исходный файл в пакете com.ryanjbaxter.spring.cloud.ocr.races называемых OcrRacesApplication.java . Откройте его и скопируйте в него приведенный ниже код.

Этот код довольно простой, он создает одну конечную точку REST, которая возвращает все расы. Сейчас расы просто хранятся в Списке в классе, это просто базовый пример, очевидно, есть более сложные способы сделать это. Если вы используете STS, вы можете легко запустить это приложение, выбрав «Выполнить» -> «Выполнить как» -> Приложение Spring Boot. Если вы предпочитаете, вы также можете запустить приложение через Maven из командной строки в корне проекта, запустив

$ mvn spring-boot:run

Приложение будет запускаться на локальном хосте с использованием порта 8080, поэтому, если вы откроете браузер и перейдете по адресу http: // localhost: 8080 /, вы должны увидеть список JSON, возвращенный с подробностями гонки.

Разработка в AWS: полезные инструменты и фичи

В статье я расскажу, какие полезные приложения и инструменты разработки приложений можно выбрать из облака Amazon Web Services и почему на них стоит обратить внимание.

The big picture

Корпоративная ИТ-инфраструктура перебирается в облака.

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

В итоге так называемые «глобальные облака» – публичные облачные платформы мировых гигантов Google, Microsoft и Amazon Web Services – способны предоставлять бизнесу специализированную масштабируемую среду для создания широкого спектра ИТ-приложений.

При этом им удается закрыть потребности всех этапов разработки, от создания прототипа и MVP до тестирования и запуска в продуктив.

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

Так, контейнеры поддерживают перенос приложений между всеми типами инфраструктуры, включая общедоступные и частные облака, виртуализированные серверы и серверы с открытым исходным кодом. Бессерверные вычисления (Serverless computing) позволяют снять с разработчиков задачи по управлению масштабированием инфраструктуры и ускоряют внедрение кода в продуктивную среду.

Возможности облака для разработчика

Автоматизация позволяет быстрее и надежнее развертывать и обновлять приложения, а протокол без сохранения состояния (Stateless protocol) снимает привязку приложений к инфраструктуре и позволяет им сохранять свое состояние (state) независимо от базовой инфраструктуры.

Наконец, right-sizing делает возможным перераспределение ресурсов облачной инфраструктуры в зависимости от текущих потребностей приложения в режиме реального времени.

Почему AWS?

Исторически сложилось так, что именно платформа Amazon Web Services предлагает разработчикам наиболее исчерпывающий инструментарий для полноценной поддержки рабочих процессов, необходимых при создании бизнес-приложений.

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

Так, совсем недавно AWS впервые в своей истории запустил поддержку совместимости с macOS. Инстансы Mac mini стали доступны в Elastic Compute Cloud (EC2), позволив разработчикам создавать приложения для iPhone, iPad, Mac в среде AWS.

У разработчиков появился крупный провайдер облачных вычислений, который позволит им запускать инструменты разработки Xcode и Swift в облаке, избавляя их от необходимости обслуживать и настраивать машины Mac.

Неудивительно, что на днях компания сообщила о регистрации всплеска интереса к ресурсам AWS со стороны стартапов в области логистики, финтеха, банковских услуг и e-commerce.

На основе опыта работы в AWS мы сформировали собственный топ инструментов, полезных и востребованных для задач софтверной разработки.

Начнем с инструментов разработчика

AWS Cloud9 – облачная интегрированная среда разработки (IDE) для написания, запуска и отладки кода в браузере. Она включает в себя редактор кода, отладчик и терминал, а также встроенную поддержку языков программирования JavaScript, Python и PHP.

AWS Cloud Development Kit (AWS CDK) – среда разработки программного обеспечения с открытым исходным кодом для моделирования и предоставления ресурсов облачных приложений с использованием привычных языков программирования.

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

В AWS CDK задачи моделирования приложения упрощаются за счет использования высокоуровневых компонентов (так называемых «структур»), выполняющих предварительную конфигурацию облачных ресурсов с настройками по умолчанию.

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

AWS X-Ray – помогает разработчикам анализировать продукты и распределенные приложения, например, приложения на базе архитектуры микросервисов, а также устранять ошибки.

Инструмент оценивает производительность приложения и сервисов, на которых основана его работа, выявляя первопричины снижения производительности и сбоев.

X‑Ray также обеспечивает комплексное отслеживание маршрутов запросов в приложении и формирует карту внутренних компонентов. X-Ray одинаково эффективен при анализе продукта на разных стадиях разработки и развертывания, а также вне зависимости от уровня сложности архитектуры.

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

Сервис моделирует визуализацию и автоматизирует процесс выпуска релизов программного обеспечения. Может использоваться с графическим интерфейсом или с интерфейсом командной строки. Поддерживает комбинацию автоматического и ручного режима управления.

Автоматически останавливает конвейер релизов в случае инцидентов, которые могут представлять собой сбои в блочном тестировании. CodePipeline использует AWS Identity и Access Management для управления доступом сотрудника, который имеет доступ к управлению рабочим процессом.

AWS Lambda – вычислительный сервис, который позволяет разработчикам запускать код без необходимости управлять серверами. Он выполняет код только при необходимости и автоматически масштабируется. Оплате при этом подлежит только фактическое время выполнения вычислений.

С помощью Lambda можно запускать практически любые виды приложений и серверных сервисов, просто загрузив программный код в Lambda. Инструмент позволяет настроить автоматический запуск программного кода из других сервисов AWS или вызывать его непосредственно из мобильного или интернет‑приложения.

AWS Fargate – программное ядро для бессерверных вычислений на базе контейнеров, которое работает как с Amazon Elastic Container Service (ECS), так и с Amazon Elastic Kubernetes Service (EKS).

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

Избыточное выделение вычислительных ресурсов и переплата за них полностью исключаются.

Для интеграции приложений

AWS Step Functions – позволяет координировать несколько сервисов AWS в бессерверных рабочих процессах, быстро создавать и обновлять приложения. Также можно объединять сервисы, такие как AWS Lambda и AWS Fargate, в многофункциональные приложения.

Amazon EventBridge – серверная шина событий, предназначенная для простого соединения облачных нативных приложений с использованием данных из собственных приложений пользователя, интегрированных приложений SaaS и сервисов AWS.

Мобильная разработка

AWS AppSync – управляемый сервис, который использует GraphQL, чтобы обеспечить простой доступ приложений к нужным данным. Это упрощает разработку, позволяя создавать гибкий API для безопасного доступа, манипулирования и объединения данных из нескольких источников.

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

AWS Amplify – платформа для разработки безопасных, масштабируемых мобильных и веб-приложений.

Помогает аутентифицировать пользователей, надежно хранить данные и метаданные пользователей, разрешать выборочный доступ к данным, интегрировать машинное обучение (machine learning), анализировать метрики приложений и выполнять код на стороне сервера.

Охватывает весь рабочий процесс разработки приложений от контроля соответствия используемых версий ПО до развертывания в продуктивной среде и легко масштабируется от тысяч пользователей до десятков миллионов.

Amazon Pinpoint – маркетинговая и аналитическая служба, размещенная в общедоступном облаке AWS, которая позволяет организациям взаимодействовать и отслеживать показатели, связанные с использованием приложений конечными пользователями.

Разное полезное

Amazon Cognito облегчает контроль аутентификации пользователей, а также доступ к любым мобильным приложениям на устройствах, подключенных через Интернет.

Amazon CloudFront – глобальный сервис CDN (content delivery network), который помогает в безопасной доставке данных, видео, приложений и API.

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

Amazon Simple Storage Service (S3) – масштабируемая и недорогая веб-служба хранения объектов, предназначенная для оперативного резервного копирования и архивирования данных и программ приложений.

Amazon CodeGuru – сервис для автоматического анализа кода и рекомендаций по производительности приложения. Основан на машинном обучении, лучших практиках и уроках, извлеченных из миллионов обзоров кода и тысяч приложений, представленных в проектах с открытым исходным кодом и внутри AWS.

Источник: tproger.ru

Ключ к облакам: как сделать свои приложения Cloud-Native

В предыдущем посте мы рассказали, как облачные сервисы превратились в негласный стандарт предоставления ИТ-услуг. Нетрудно догадаться, что компании, которые желают по-прежнему зарабатывать на пользовательских приложениях, должны адаптировать и создавать новые продукты с учетом Cloud-Native подхода. Впрочем, для разработчиков это однозначно позитивная новость, поскольку использование облачных технологий открывает для них огромные новые возможности. Главное уметь ими правильно распорядиться.

Когда приложение заказывает окружение

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

Развитием этой идеи является подход Infrastructure as code (IAC). Его суть в том, чтобы дать возможность разработчикам или службам эксплуатации применять для обслуживания инфраструктуры такие же подходы, которые используются на этапе разработки. Он позволяет готовить общие программные блоки управления заранее и легко осуществлять интеграцию таких компонентов в новых проектах.

Возможности современных ЦОДов уже позволяют переходить к декларативному языку управления инфраструктурой. В идеале, приложение должно само администрировать занимаемый им пул ресурсов в дата-центре. Это позволит разработчику не быть запертым в ограничениях, связанных с процессом работы с инфраструктурой, когда надо заказывать и проектировать наперед или если одни и те же компоненты инфраструктуры повторяются в разных проектах.

Фактически разработчик или инженер делает Pull Request, в котором находится конфигурация виртуальной машины (ядра, память, сеть, шаблон и т.д.), далее менеджер виртуального окружения самостоятельно создает машину или создает новый инстанс базы данных или стартует предустановленный сервис, согласно настройкам в файле. Такой подход — настоящее спасение при работе с большими данными и нейронными сетями. Приложения, связанные с этими технологиями, в некоторых случаях нуждаются в динамически изменяемых объемах памяти и процессорных мощностей.

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

Монолит vs. упорядоченный хаос

Благодаря тому, что облака умеют эластично подстраиваться под потребности разработчика, это, теоретически, упрощает еще одну задачу – проблему масштабирования приложений. Почему теоретически?

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

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

Однако у такой простоты есть цена. Во-первых, это уже упомянутые выше проблемы с масштабированием. В какой-то момент даже самое продуманное монолитное приложение перестает работать эффективнее от апгрейда конфигурации сервера на котором оно исполняется.

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

В поисках идей, как решить эти проблемы была разработана другая концепция – service-oriented architecture (SOA). Она подразумевает, что приложение разделено на несколько модулей, каждый из которых предоставляет другим какую-то функциональность. Между собой модули взаимодействуют через набор веб-служб, и независимо друг от друга могут обращаться к единой или к собственным базам данных.

Такой подход действительно упрощает поддержку программы и не превращает ее обновление «в работу сапера», в которой нет права на ошибку; но и у него есть свои недостатки. Ключевой из них – проблемы с масштабированием разработки таких приложений. По мере роста программы, новые функции становится все сложнее «запихивать» в изначально утвержденные архитектором 5-10 пакетов. Их число становится все больше, что оборачивается проблемами с поддержкой.

Микросервис как элемент эволюции приложения

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

Микросервисная архитектура подразумевает, что приложение состоит не из какого-то небольшого количества крупных модулей, а из множества независимых друг от друга частей. В отличие от монолита, в микросервисном приложении можно использовать различные способы взаимодействия компонентов между собой. У системы нет единого, заранее определенного состояния. Вместо этого каждый компонент работает «по ситуации»: как только ему поступает событие он начинает работу. Это позволяет делать очень гибкую и независимую архитектуру.
При этом число сервисов в микросервисном приложении постоянно меняется – какие-то добавляются, какие-то удаляются. В новом подходе можно любой микросервис заменить и вместо него встроить цепочку микросервисов. Другие сервисы продолжают стабильно работать, потому что не связаны напрямую между собой. Такова естественная эволюция программы. Благодаря этому у разработчиков и архитекторов появляется возможность быстро что-то менять, чтобы реагировать на изменения бизнес-требований и опережать конкурентов.

Помимо повышения скорости выпуска обновлений использование микросервисной архитектуры позволяет добиться децентрализации управления. Команда, которая отвечает за разработку того или иного сервиса, сама вправе определять его внутреннюю архитектуру и его особенности. Такой подход, кстати, сейчас в Блоке Технологии внедряет Архитектурный совет Сбербанка.

При этом садясь за разработку своего облачного приложения не следует спешить со скорейшим дроблением его на составные элементы. Главный противник подобного бездумного подхода — Мартин Фаулер; он же – один из авторов идеи микросервисной архитектуры. Проще изначально использовать монолитный подход, и потом стимулировать эволюцию приложения «естественным образом», ориентируясь на расшивку узких мест и добавление дополнительных функций.

В результате можно сформулировать следующее правило: задача программиста при работе с микросервисной архитектурой – не просто разбить приложение на максимальное количество составных частей, а разумным образом разграничить их ответственность за получение и обработку данных.

Четыре детали

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

Когда один из компонентов меняет свой интерфейс, он должен поддерживать обратную совместимость, чтобы поддерживать прошлую версию собственного API. Если это правило соблюдается, можно динамично переключаться со старой версии на новую без сбоев работе. Если же поддержка прежней версии API не проработана, то это грозит в лучшем случае, потерей части функциональности приложения, а в худшем – постоянными сбоями в его работе.

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

Третья важная деталь, которую необходимо учитывать, разрабатывая облачное приложение – способ взаимодействия его составных частей между собой. Как и в SOA, для обмена данными сервисы используют веб-службы, но в микросервисной архитектуре появились паттерны взаимодействия, например, как streaming, CQRS, Event sourcing. Обычно разработчики рассчитывают, что время отклика между запросом и ответом в приложении достаточно небольшое. В распределенной системе нельзя полагаться даже на то, что ответ вообще придет.

Так же в архитектуре облачных приложений микросервисы используют различные базы данных, наиболее оптимально подходящие для решения их конкретных задач. Например, гриды могут быстро читать, но с трудом справляются с большим количеством операций по изменениям данных. Такая база хорошо подойдет для ведения счетов вкладов – они редко изменяются. Другой тип операций – процессинг; в нем ежедневно по каждой карте могут быть десятки изменений, а чтений данных наоборот мало.

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

Например: если пользователь делает запрос на получение кредита, то получившая заявку система должна это состояние сохранить, чтобы передать его другим сервисам. А вот сервис, отвечающий за поиск информации во внутренней картотеке кредитных историй, может не сохранять состояние и забыть о том, данные на какого именного пользователя он искал пару минут назад – все равно уже через мгновенье ему придет новый запрос (хотя и в этом процессе может быть различное поведение сервиса).

Все описанные выше примеры и практики уже активно используются лидерами мировой ИТ-отрасли. Например, пионером в развитии микросервисной архитектуры является Netflix. Компания выпустила множество open-source приложений, библиотек и фреймворк для мониторинга, балансировки и логирования запущенных микросервисных приложений.

• облачные технологии
• cloud native

• Блог компании Сбер
• Облачные вычисления
• Облачные сервисы
• Научно-популярное

Источник: h.amazingsoftworks.com