Azure

Microsoft выпустила плановые обновления безопасности, закрывающие 114 уязвимостей, включая 6 уязвимостей в Microsoft Edge и 4 уязвимости в Exchange Server. 19 уязвимостей были классифицированы как Критические и 88 как Важные. Среди закрытых уязвимостей две были обнародованы публично, а эксплуатация одной из этих уязвимостей была зафиксирована в реальных атаках (0-day).

В данной статье я расскажу о самых главных моментах этого выпуска.

Сводная информация по количеству и типу уязвимостей в соответствующих продуктах приведена на графике.

На следующие уязвимости и обновления безопасности следует обратить особое внимание.

Была закрыта критическая уязвимость удаленного исполнения кода CVE-2021-28329 в компонентах среды исполнения RPC), которой подвержены все поддерживаемые версии Windows и Windows Server. Рейтинг CVSS составил 8.8, а согласно индексу эксплуатации у атак с использованием данной уязвимости низкий уровень вероятности.

Апрельские обновления также исправляют важную уязвимость повышения привилегий CVE-2021-28313 в компонентах Windows Diagnostics Hub. Данная уязвимость затрагивает последние версии Windows 10 и Windows Server 20H2, 2004, 1909. Рейтинг CVSS составил 7.8, а согласно индексу эксплуатации у атак с использованием данной уязвимости низкий уровень вероятности.

Также была закрыта важная уязвимость повышения привилегий CVE-2021-28347 в компонентах среды исполнения Windows Speech. Уязвимости подвержены все поддерживаемые версии Windows 10. Рейтинг CVSS составил 7.8, а согласно индексу эксплуатации у атак с использованием данной уязвимости низкий уровень вероятности.

Устранена важная уязвимость удаленного исполнения кода CVE-2021-27091 в компонентах службы RPC Endpoint Mapper, которая была обнародована публично. Данной уязвимости подвержена только ОС Windows Server 2012. Рейтинг CVSS составил 7.8, а согласно индексу эксплуатации у атак с использованием данной уязвимости низкий уровень вероятности.

Также обновления закрывают критическую уязвимость удаленного исполнения кода CVE-2021-27095 в видео-декодере Windows Media, которой подвержены все версии Windows. Рейтинг CVSS составил 7.8, а согласно индексу эксплуатации у атак с использованием данной уязвимости низкий уровень вероятности.

Была закрыта важная уязвимость удаленного исполнения кода CVE-2021-28445 в компонентах Windows Network File System (NFS. Данной уязвимости подвержены все ОС Windows кроме Windows 10 и Windows Server 1803. Рейтинг CVSS составил 8.1, а согласно индексу эксплуатации у атак с использованием данной уязвимости низкий уровень вероятности.

Устранена важная уязвимость удаленного исполнения кода CVE-2021-28451 в приложении Microsoft Excel. Данной уязвимости подвержены Microsoft Office 2019 for Windows/Mac, Microsoft Excel 2013-2016, Microsoft 365 Apps for Enterprise, Microsoft Office Online Server, Microsoft Office Web Apps Server 2013. Рейтинг CVSS составил 7.8, а согласно индексу эксплуатации у атак с использованием данной уязвимости низкий уровень вероятности.

Замыкает команду лидеров апрельского выпуска уязвимость нулевого дня, уже использующуюся в атаках это важная уязвимость повышения привилегий CVE-2021-28310 в компонентах Win32k. Данная уязвимость затрагивает версии Windows 10 и Windows Server 20H2, 2004, 1909, 1809, 1803. Рейтинг CVSS составил 7.8.

Отдельного внимание заслуживают ряд уязвимостей в почтовом сервере Microsoft Exchange. На этот раз затронуты все поддерживаемые версии Exchange Server 2013, 2016, 2019.

Примечание: помимо плановых обновлений в марте был внеплановый выпуск обновлений безопасности для локальных версий Microsoft Exchange Server 2010, 2013, 2016, 2019. Подробности об этом выпуске можно получить в нашем блоге.

Все 4 уязвимости в апрельском выпуске CVE-2021-28480, CVE-2021-28481, CVE-2021-28482, CVE-2021-28483 были классифицированы как Критические, и потенциально позволяют злоумышленнику удаленно выполнить произвольный код на почтовом сервере.

Информация о данных уязвимостях не была обнародована публично и на данный момент не было зафиксировано использование рабочих эксплоитов в реальных атаках. Максимальный рейтинг CVSS среди уязвимостей составил 9.8 из 10 (самый низкий рейтинг 8.8) и согласно индексу эксплуатации у атак с использованием этих уязвимостей высокий уровень вероятности.

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

• Exchange Server 2013 CU23

• Exchange Server 2016 CU19/CU20

• Exchange Server 2019 CU8/CU9

Все подробности вы можете узнать в блоге команды Microsoft Exchange.

Остальные уязвимости были исправлены в компонентах Microsoft Edge (на движке Chromium), Microsoft Office (приложения и веб-сервисы), SharePoint Server, Visual Studio, VS Code, Azure DevOps Server, Azure Sphere, GitHub Pull Requests and Issues Extension и Maven Java Extension.

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

Также хочу напомнить, что в марте закончилась поддержка старой версии браузера Microsoft Edge (на движке EdgeHTML). При установке апрельского накопительного пакета старый браузер будет заменен новой версией Microsoft Edge на движке Chromium. Подробности - в нашем блоге.

Обновления стека обслуживания

Обновления Servicing Stack Updates (SSU) были выпущены для всех поддерживаемых ОС: Windows 10 версии 1809, 1909, 2004, 20H2 и Windows Server версии 2019, 1909.

А для версий 2004, 20H2 обновления SSU теперь поставляются в едином накопительном пакете вместе с остальными обновлениями. О том, как установить сразу и SSU, и обновления безопасности ОС в одном накопительном пакете, автоматически, соблюдая правильную последовательность, читайте в нашем блоге.

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

Вы также можете посмотреть запись нашего ежемесячного вебинара "Брифинг по безопасности" с более подробным разбором этого выпуска обновлений безопасности Microsoft.

А для того, чтобы быть в курсе самых актуальных новостей информационной безопасности Microsoft, подписывайтесь на канал https://aka.ms/artsin.

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

Автор: Артём Синицын CISSP, CCSP, MCSE, MC: Azure Security Engineer
старший руководитель программ информационной безопасности в странах Центральной и Восточной Европы
Microsoft

Twitter: https://aka.ms/artsin
YouTube: https://aka.ms/artsinvideo

*Vulnerability Review Report by Flexera

Microsoft и Group-IB, международная компания, специализирующаяся на предотвращении кибератак и расследовании высокотехнологичных преступлений, сообщают об успешной интеграции Azure Sentinel, облачного решения дляуправления информационной безопасностью, с системой исследования и атрибуции кибератак Group-IB Threat Intelligence & Attribution (TI&A). Компания Group-IBсталапервым разработчиком, прошедшим интеграцию своей платформы в Azure Sentinel в России и СНГ.

Group-IB Threat Intelligence &Attribution является частью экосистемы высокотехнологичных продуктов Group-IB, предназначенных для сбора данных окиберугрозах иатакующих, проактивного выявления деятельности киберпреступников изащиты сетевой инфраструктуры. Каждый специалист, использующий TI&A, получает доступ ккрупнейшей коллекции данных даркнета, продвинутой модели профилирования хакерских групп, атакже полностью автоматизированному графовому анализу, который засекунды помогает провести корреляцию данных иатрибутировать угрозы доконкретной преступной группы. TI&A объединяет уникальные источники данных и накопленный опыт в расследовании преступлений в сфере высоких технологий и противодействии сложным многоступенчатым атакам по всему миру. Система хранит данные о субъектах угроз, доменах, IP-адресах и инфраструктурах, собранные за 15 лет, в том числе о тех, которые преступники пытались скрыть. Функциональные возможности системы позволяют настраивать ее с учетом специфики угроз не только для конкретной отрасли, но и для конкретной компании в конкретной стране.

Задачей разработчиков Group-IB и Miсrosoft в рамках проекта была загрузка баз знаний Group-IB TI&A в Azure Sentinel для автоматического сканирования и обнаружения соответствующих индикаторов TI в журналах источников данных организации для дальнейшего изучения и анализа.

В рамках реализации этого проекта мы решили задачи по автоматизированной доставке из Group-IB TI&A в Azure Sentinel актуальных индикаторов компрометации для дальнейшего изучения и анализа угроз, подчеркивает Станислав Фесенко, руководитель департамента системных решений Group-IB. Такой подход позволит компаниям увеличить скорость реагирования внутренних команд на потенциальный инцидент и усилить защиту инфраструктуры за счет широких возможностей хантинга для предотвращения киберпреступлений еще на этапе их подготовки.

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

Напомним, ранее Forrester Consulting провелаопроссреди компаний, использующих Azure Sentinel, согласно которому, использование Azure Sentinel обеспечивает 201% рентабельности инвестиций за три года.

DevOps-инженера ищут многие, но находят не все. Специалисты, умеющие внедрять DevOps-практики, последние 3 года являются одними из самых востребованных на IT-рынке. Спрос на них постоянно растёт. Заработная плата, несмотря на кризис, тоже не падает. Хорошие причины, чтобы задуматься, как прийти в эту профессию и каким образом в ней развиваться?

Специальность DevOps-инженера действительно появилась в IT-индустрии относительно недавно и быстро вырвалась в топ. Development Operations это, в первую очередь, набор практик, призванный улучшить и автоматизировать процесс доставки продукта до конечного пользователя, и он может быть полезен везде, где речь идёт о разработке приложений или управлении большим количеством серверов. Пожалуй, только небольшие команды могут позволить себе не выделять DevOps в отдельную функцию и обходиться исключительно своими силами.

Итак, какие задачи решает DevOps-инженер?

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

• Обеспечение полного жизненного цикла продукта;

• Подготовка различных окружений (разработка тестирование production) и обеспечение поставок продукта на эти окружения;

• Обеспечение автоматического прохождения продукта через различные стадии непрерывной интеграции (CI) и непрерывной доставки (CD);

• Виртуализация и управление инфраструктурой, мониторинг.

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

Исходя из направлений деятельности, на практике DevOps-инженер используют следующие инструменты:

• CI/СD и интеграцию (Jenkins, TeamCity, GitLab, Bamboo);

• Автоматизацию (Terraform, Puppit, Ansible);

• Облачные платформы (AWS, Google Cloud Platform, Microsoft Azure, Huawei Cloud, Яндекс Облако, Mail.ru Cloud Solutions);

• Мониторинг (Prometheus, Grafana, Zabbix, Nagios);

• Системы логирования, трассировки (ELK Stack, Graylog, Gafana, Jaeger);

• Контейнеризация и орекстрация (Docker, Kubernetes, Nomad).

Карьерная карта

В DevOps приходят из разных профессий. Основные доноры - это System administrator, Automation engineer, QA automation, Build Engineer/ Release Engineer, Developer. Представители этих специальностей уже обладают рядом навыков, которые необходимо развить и расширить.

Андрей Синицын, Head of IT Optimisation Departmen в ECommPay, рассказывает: Я занимаюсь компьютерами с середины 90-х я из того времени, когда эта профессия выбирала тебя. Передо мной никогда не стояло вопроса, чем заниматься по жизни. Сначала я работал программистом, потом понял, что мне интереснее эксплуатация, и ушел в DevOps. Живой продакшн это всегда интересно. И, на мой взгляд, интереснее, чем написание программы: ты видишь, как код эволюционирует, как он работает, как он выполняет (или, как это часто бывает, не выполняет) ту задачу, для решения которой был написан.

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

Сертификаты AWS, GCP, Azure, Kubernetes (CKA, CKAD) могут рассказать работодателю о том, что соискатель имеет навык работы с конкретными платформами, но, как правило, DevOps-инженером становятся только на практике.

Составляя идеальное DevOps-резюме, важно отразить в нём навыки, которыми вы владеете, задачи в рамках уже реализованных проектов, их особенности, зону ответственности; используемый стек технологий и, конечно, не забыть о soft-skills. Андрей Синицин подчёркивает, что для DevOps очень важны хорошие коммуникативные навыки, знание английского, обучаемость и out-of-box thinking стандартный набор для любой специализации в IT. Еще я бы добавил, что большое преимущество в DevOps дает понимание бизнеса (или стремление к этому). Эксплуатация никогда не зарабатывает деньги напрямую, и осознавать business value того, что ты делаешь, очень важно.

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

Кстати, нам вы также можете прислать резюме по этой ссылке.

Перспективы сегодня и завтра

DevOps-инженеры действительно зарабатывают больше всех в отрасли. В США, Канаде, UK заработная плата колеблется между 90 и 122 тысячами долларов в год. Что касается России, то в Москве работодатели готовы предложить такому специалисту в среднем 260 тыс. рублей в месяц (верхняя планка доходит до 350 тыс. ), в Санкт-Петербурге средняя зарплата составляет 200 тыс. рублей.

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

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

Что касается возможностей карьерного роста, то для DevOps-инженера открыт путь к следующим позициям: Devops Team Lead, DevRel (Developer relations), Delivery Manager, Devops architect, Head of Engineering.

DevOps 2021: основные тренды

Анализируя 2020 год, можно заметить, что в центре внимания стала, прежде всего, безопасность. В том числе, безопасность IT-продуктов, поэтому одним из самых заметных трендов является DevSecOps и в целом SDLC (Security development lifecycle). DevSecOps подразумевает встраивание процесса безопасной разработки в процесс DevOps, интеграцию парадигм безопасности в каждый из этапов разработки.

Внедрение таких подходов, как DevSecOps, невозможно без следующего тренда автоматизации, одного из основных китов DevOps-практики. Скрипты, автоматизация, внедрение подхода IaC (инфраструктура как код) все это обеспечивает гибкость, скорость процессов разработки и поставки продукта.

Стоит также выделить глобальный тренд, который существует уже несколько лет это переход в cloud-native-среду и разработка приложений с учетом особенностей облачных платформ, считает Элиса Данильсон, консультант направления IT&Telecoms в Санкт-Петербурге.

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

Страны начинают восстанавливаться после эпидемии, и такие аномалии, касающиеся присутствия на рабочих местах, мы видим в собственных филиалах по всему миру. Например, в Китае 81% наших сотрудников присутствуют на рабочих местах три и более дней в неделю, тогда как в Австралии посещаемость офисов составляет всего 19% от того, что было до пандемии.

Гибридная работа стала крупнейшим сдвигом в том, как работает наше поколение. И такая работа потребует новой операционной модели, включающей людей, рабочие места и процессы. Мы опубликовалируководство, в котором рассказываем о том, что нам удалось узнать на сегодняшний день, включая данные, исследования и рекомендации, призванные помочь организациям ориентироваться в этих меняющихся обстоятельствах работы.

В этой статье основные моменты.

Люди

Если говорить о подготовке наших сотрудников к гибридной работе, то мы отдаем приоритет трем аспектам: социальному капиталу, капиталу знаний и человеческому капиталу.

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

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

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

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

И наконец человеческий капитал и благополучие. В Microsoft мы используем подход, основанный на данных. Например,наши последние исследованияподтверждают то, о чем многие догадывались: совещания, идущие одно за другим, плохо сказываются на нашем самочувствии, а решением этой проблемы могут стать короткие перерывы. Опираясь на полученные данные, мы добавили в Outlook новые параметры настройки, которые позволяют автоматически делать короткие перерывы между совещаниями. Рекомендуем нашим сотрудникам включить эти параметры.

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

Места

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

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

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

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

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

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

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

Процессы

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

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

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

Microsoft,сосредоточена на трех направлениях. Во-первых, мы выводим всех сотрудников из корпоративных сетей и опираемся на использование Интернета. Такой подход снижает риск заражения и позволяет сотрудникам работать одинаково из дома и офиса.

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

В-третьих, для обеспечения безопасности устройств управление всеми корпоративными ресурсами будет построено так, чтобы доступ был защищенным и надежным. Независимо от того, где находятся сотрудники дома или в офисе, мы будем требовать, чтобы каждое мобильное устройство, которому необходим доступ к корпоративным ресурсам, было управляемым. Это включает развертывание Microsoft Defender for Endpoint в масштабах всей компании.

**

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

Подробнее об этом можно узнать вблоге, который ведет корпоративный вице-президент по современным методам работы Джаред Спатаро (на английском языке). Полное руководство читайте здесь:microsoft.com/hybridwork.

Привет, Хабр! Сегодня рассказываем о наших трех крутых мероприятиях для разработчиков в марте, которые связаны с технологиями Microsoft Azure. Среди тем: основы искусственного интеллекта, DevOps с GitHub и основы работы с данными. Ну и без бесплатных возможностей по сдаче сертификационных экзаменов Microsoft как обычно не обойдется. Заглядывайте под кат за подробностями!

1. Основы искусственного интеллекта

9 марта, на английском с субтитрами на русском

Откройте для себя решения, которые можно создавать с помощью ИИ, и службы Azure, которые помогут вам создать эти решения. Присоединяйтесь к бесплатному дню виртуального обучения Microsoft Azure: основы искусственного интеллекта, чтобы изучить основные концепции искусственного интеллекта и узнать, как начать работу с искусственным интеллектом в Azure.

Посетите день виртуального обучения, чтобы:

• Получить обзор основных концепций и приложений искусственного интеллекта

• Создавать модели прогнозирования без кода с помощью машинного обучения Azure

• Узнать больше о диалоговом ИИ, обработке естественного языка и компьютерном зрении в Microsoft Azure

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

Подробности и регистрация.

2. DevOps с GitHub

17-18 марта, на английском с субтитрами на русском

Продвигайте свою карьеру, имея прочный фундамент в DevOps. Посетите это бесплатное обучение под руководством инструктора, предназначенное для разработчиков и ИТ-специалистов. Узнайте, как использовать GitHub для управления рабочими процессами и сокращения времени цикла. Получите пошаговые инструкции по добавлению элементов управления качеством и безопасностью в процесс сборки, а также по улучшению уведомлений и ответов для обеспечения согласованной и повторяемой автоматизации.

Изучите эти темы на мероприятии:

• Использование GitHub для улучшения совместной работы и производительности команды

• Интеграция средств контроля безопасности и качества в конвейеры автоматизации, непрерывной интеграции и непрерывной доставки (CI/CD) и среды выполнения

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

Подробности и регистрация.

3. Основы работы с данными

22-23 марта, на русском

Изучите основные концепции баз данных в облачной среде. Присоединяйтесь к нам на мероприятии Microsoft Azure Virtual Training Day: основы данных, чтобы получить базовые знания об облачных сервисах обработки данных. Изучите предложения для работы с реляционными и нереляционными данными, а также решения для аналитики больших данных и современных хранилищ данных в Azure.

Посетите это учебное мероприятие, чтобы:

• Изучить роли, задачи и обязанности, связанные с управлением данными в облачной среде.

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

• Изучить средства обработки данных, используемые при создании решений для аналитики данных, включая Azure Synapse Analytics, Azure Databricks и Azure HDInsight.

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

Подробности и регистрация.

Около десяти лет назад микросервисы получили первое признание. (Однако есть альтернативное мнение, что микросервисам уже пятнадцать лет). С тех пор масса фирм воспользовалась услугами облачных провайдеров и перенесла свои сервисы к ним. А некоторые из них даже успели разочароваться в облачных технологиях и вернулись к традиционной схеме монолита (или почти к ней, см. например [TB]).

Эта статья - не попытка уговорить вас на перенос вашего монолита в облако или отговорить от этого. Это попытка развеять возможно сидящие глубоко в вашем сознании необоснованные опасения или ожидания (другими словами - мифы и заблуждения) по поводу такого переноса.

Но вначале нам необходимо договориться о том, что же это такое - монолит.

Развивая идею из публикации [SN], я предлагаю ввести пять частичных метрик для измерения монолитности той или иной программной системы:

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

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

3. Монолитность времени исполнения (run time). Один исполняемый артефакт может использоваться у вас многократно (параллельно), с балансировкой каким-либо балансёром или диспетчером.

4. Монолитность хранения данных. Эта величина измеряется количеством разных систем хранения ваших данных. Хранит ваше приложение данные в одной базе данных или в нескольких? Если система использует файловую систему в качестве хранилища данных - в скольки файлах и папках она это делает?

5. Функциональная монолитность. В отличии от предыдущих величин, которые вычисляются более или менее однозначно, вычислить эту величину часто бывает очень трудно. Более того, разные специалисты при её вычислении могут прийти к разным результатам. Для её вычисления необходимо проанализировать входные и выходные интерфейсы приложения, его функциональность, и решить, на сколько независимых процессов можно было бы (не вдаваясь в детали текущей реализации) разбить основную функциональность приложения.

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

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

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

Миф 1: Всё или ничего

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

На самом деле это не так. Архитектурный паттерн, известный под именами Призма( см. [PR]), схожий с Canary deployments[CD] и A/B Testing, позволяет разрабатывать новые микросервисы постепенно, независимо от основного приложения и сбоку от него. Идея паттерна показана на рисунке внизу.

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

Если ваша система общается с внешним миром с помощью HTTP-протокола, оба треугольника могут быть реализованы в виде одного простого proxy-сервера. Различные Service Mesh инструменты типа Istio предоставляю такую возможность на уровне конфигурации.

Первая (красная) призма направляет все входные данные на монолит, дублируя при этом данные интересные заново имплементированному сервису и посылая дублированные данные на него. Вторая призма перехватывает выходные данные вашего монолита, дублирует результаты запланированного к замещению сервиса и посылает дубликаты на сравнение в Comparator. Ну а Comparator сравнивает результаты нового варианта с результатами монолита.

Таким образом, монолит работает как и раньше (синие элементы на рисунке).

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

Миф 2: Просто расщепим на части и докенизируем

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

Нередко миграция монолита в облако представляется как простое расщепление монолита на несколько частей и перенос каждой части сначала в Docker/Kubernetes, а возможно потом - в одну из облачных сред типа AWS или Azure.

Увы, в большинстве случае так просто решить проблему не получается.

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

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

1. Финансы (например, Data Warehouse)

2. Reports

3. Рекламации

4. Ручные обрывы процессов в определённых ситуациях

5. Коррекция неверных данных

6. Evaluation (Периодическая оценка ситуации)

7. Настройка системы

8. Audit

9. Workarounds

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

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

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

Не вдаваясь в детали, отметим пунктиром, над чем в этом случае следует подумать и что постараться сделать:

1. Использование паттерна SAGA (см. [SA])при реализации распределённых транзакций.

2. Использование паттерна QCRS (см. [QC])при работе с распределёнными данными.

3. Использование идемпотентных функций (см. [IF]), позволяющих при возникновении проблем просто вызывать их заново без опасения за состояние сохранённых данных).

Миф 3: Переносить надо только функциональность, всё остальное предоставит провайдер

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

Реальность облачной жизни иная. По крайней мере, следующие проблемы вам наверняка придётся решать самостоятельно:

1. Мониторинг

2. Аудит

3. Desaster Recovery

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

Миф 4: Облачные сервисы очень дёшевы

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

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

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

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

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

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

Миф 5: Микросервисы должны быть маленькими

То, что микросервисы должны быть маленькими, явствует из самого их названия, не правда ли? Поэтому при миграции в облака монолит надо разбить на большое число маленьких частей, разве не так? Примеры ландшафтов со многими сотнями и даже тысячами микросервисов, как например в банке Monzo ( см. [MB]), вроде бы также говорят в пользу такого подхода.

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

К счастью, отрасль уже накопила достаточное понимание проблемы и выработала конструктивные рекомендации по вопросу расщепления монолита на микросервисы. Детали вы найдёте в работах [HS], [ST], [HS1]. Здесь же короткий перечень основных критериев, когда такое расщепление возможно стоит делать:

1. Выделять в отдельный сервис функциональность с объективно повышенной вероятностью ошибок в run time.

2. Реализовывать компоненты с заведомо разным жизненным циклом в разных сервисах.

3. Разделять на сервисы компоненты с заведомо разными ожидаемыми частотами внесения изменений и обновлений.

4. Выделять в отдельный сервис функциональность, требующую повышенной скалируемости.

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

А иногда различные микросервисы появляются на свет просто из-за организационных причин (необходимость реализовать их разными командами).

Миф 6: Затраты на миграцию монолита непредсказуемы

Хорошо это или плохо, но последние годы многие маленькие команды и большие коллективы разрабатывают программные системы в рамках агильного подхода. Часто, особенно у относительно молодых специалистов, это приводит к формированию убеждения, что среднесрочное и долгосрочное планирование в рамках агильного подхода невозможно. Следовательно, затраты на миграцию монолита в облако достоверно оценить (предсказать) нельзя.

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

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

Миф 7: Раз все так делают, значит так можно

Сервис мега-провайдера типа AWS или Azure отличается низкой латентностью, высокой надёжностью и доступностью по всему миру за счёт их собственных Data Centers. Неудивительно, что многие фирмы и государственные службы пользуются их услугами.

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

Мега-провайдеры усиливают эту аргументацию обещанием, что вы можете для хранения ваших данных выбрать географически подходящий Data Center , например для европейцев - во Франкфурте.

Увы, это не соответствует действительности.Все мега-провайдеры соблюдают законы США, в том числе - CLOUD Act [CA], позволяющий американским службам без судебного решения потребовать от провайдера любые данные. А это противоречит многим национальным и европейским законам о защите данных их граждан.

Но это в теории, на практике-то ничего неприятного не происходит?, возможно спросите вы. Нет, происходит. Например, в Германии уже рассматривались случаи наложения штрафов на образовательные учреждения и отдельных преподавателей за использование облачных продуктов типа Microsoft Office 365, Zoom и т.п.( см. [ MO]). В апреле 2021 года немецкая служба защиты приватных данных (Datenschutz-Aufsichtsbehrde) потребовала от многочисленных немецких фирм обоснования хранения данных у американских облачных провайдеров в связи с решением Европейского Суда по вопросу соглашения Privacy Shield (см. [DF]).

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

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

Что же касается американских спецслужб - я очень советую вспомнить про Сноудена, а ещё лучше прочитать (если не читали) его книгу [ES]. Лично меня в ней поразили две вещи.

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

Вторым поразившим меня в этой книге был эпизод с вербовкой абсолютно невиновного молодого человека, который в будущем мог занять в иерархии своей страны интересующую спецслужбы позицию. Сноуден в деталях рассказывает о попытках подставить этого человека под судебную ответственность. Знание некоторых деталей его биографии, его привязанностей и слабостей им в этом очень помогло. Собственно, в этом нет ничего нового. Мы все много раз видели это в кино про КГБ, ЦРУ и т.д. Но воспоминания Сноудена как участника операции показывают, что это всё не выдумки. Как мы видим, спецслужбы иногда охотятся и за абсолютно невиновными людьми. Хотите вы с вашим сервисом в этом участвовать (осознанно или неосознанно), особенно, если этого можно не делать?

Наверное нет. Так что же делать?

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

Постарайтесь сами обойтись без излишних приватных данных. Возможно, ваш бизнес может обойтись без обратной связи с некоторыми категориями пользователей через Email или телефон. Если ваш бизнес ориентирован на профессионалов, вы можете поддерживать в учётных записях (accounts) только логин, пароль и серию контрольных вопросов.

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

Ну и как самый крайний вариант - не используйте специализированные фичи мега-провайдеров, а используйте решения на базе открытых решений типа Docker/Kubernetes/Kafka, что позволит вам при необходимости развернуть бизнес в облаках локальных провайдеров интересующей вас страны.

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

Вместо заключения

Изложенное в этой статье не претендует на роль истины в последней инстанции. Процесс миграции монолитов в облака находится в полном разгаре. Накопленный опыт миграции неплохо обобщён и осмыслен в книге [MM].

Автор признателен дочитавшим эту статью до конца и с интересом ожидает ваших суждений, возражений и мнений.А с какими мифами сталкивались вы?

Ссылки и литература

Иллюстрации автора.

Привет, Хабр! Сегодня, как и обещали*, делимся подборкой самых интересных для разработчиков конференции Microsoft Build 2021. Их получилось 11, но это не значит, что это все. Чтобы узнать еще больше, изучайте сайт конференции.

* пообещали это мы во вчерашней подборке 8 анонсов конференции Microsoft Build 2021, которую подготовила наша бизнес-команда.

1. Представлен Windows Terminal Preview 1.9

Поздравляем с Microsoft Build 2021 и вторым днем рождения Windows Terminal! Этот выпуск представляет версию 1.9 для Windows Terminal Preview и переносит Windows Terminal в версию 1.8. Как всегда, вы можете установить обе сборки из Microsoft Store, а также со страницы выпусков GitHub.

Среди новинок:

• Дефолтный терминал

• Quake mode

• Обновления Cascadia Code

• Обновления интерфейса настроек

• Другие улучшения

Подробнее здесь.

2. Представляем Visual Studio 2019 v16.10 и v16.11 Preview 1

Мы рады объявить о выпуске Visual Studio 2019 v16.10 GA и v16.11 preview 1. Этот выпуск делает нашу тему продуктивности и удобства разработчиков общедоступной для пользователей Visual Studio! Мы добавили функции C ++ 20, улучшили интеграцию с Git, улучшили инструменты профилирования и множество функций, повышающих продуктивность.

Подробнее здесь.

3. Представляем .NET 6 Preview 4

Мы рады выпустить .NET 6 Preview 4. Мы почти наполовину закончили выпуск .NET 6. Это хороший момент, чтобы еще раз взглянуть на .NET 6 в полном объеме, как и в первом Preview. Многие функции находятся в близкой к окончательной форме, а другие появятся в ближайшее время, когда основные блоки будут готовы к выпуску. Предварительная версия 4 создает прочную основу для выпуска в ноябре финальной сборки .NET 6 с готовыми функциями и возможностями. Она также готова к тестированию в реальных условиях, если вы еще не пробовали .NET 6 в своей среде.

Говоря о финальном выпуске, у нас теперь запланирована дата! Добавьте в календарь даты с 9 по 11 ноября и .NET Conf 2021. Мы выпустим .NET 6 9-го числа с множеством подробных докладов и демонстраций, которые расскажут вам все, что вы хотите знать о .NET 6.

Подробнее здесь.

4. Представляем .NET MAUI Preview 4

Сегодня мы рады объявить о доступности .NET Multi-platform App UI (.NET MAUI) Preview 4. Каждая предварительная версия представляет больше элементов управления и функций для этого многоплатформенного инструментария, который станет общедоступным в ноябре этого года на .NET Conf. .NET MAUI теперь имеет достаточно блоков для создания функциональных приложений для всех поддерживаемых платформ, новые возможности для поддержки запуска Blazor на настольных компьютерах и впечатляющий прогресс в Visual Studio для поддержки .NET MAUI.

Подробнее здесь.

5. Обновления ASP.NET Core в .NET 6 Preview 4

Версия .NET 6 Preview 4 уже доступна и включает много новых крутых улучшений в ASP.NET Core.

Вот что нового в этой предварительной версии:

• Добавлены minimal APIs

• Async streaming

• HTTP logging middleware

• Использование Kestrel для профиля запуска по умолчанию в новых проектах

• IConnectionSocketFeature

• Илучшенные шаблоны single-page app (SPA)

• Обновления .NET Hot Reload

• Ограничения generic type в компонентах Razor

• Blazor error boundaries

• Компиляция Blazor WebAssembly ahead-of-time (AOT)

• Приложения .NET MAUI Blazor

• Другие улучшения производительности

Подробнее здесь.

6. Представляем Entity Framework Core 6.0 Preview 4: Performance Edition

Группа Entity Framework Core анонсировала четвертый предварительный выпуск EF Core 6.0. Основная тема этого выпуска - производительность.

Что нового:

• Производительность EF Core 6.0 теперь на 70% выше в стандартном для отрасли тесте TechEmpower Fortunes по сравнению с 5.0.

• Улучшение производительности полного стека, включая улучшения в тестовом коде, среде выполнения .NET и т. д. Сам EF Core 6.0 на 31% быстрее выполняет запросы.

• Heap allocations уменьшены на43%.

Подробнее здесь.

7. Представляем .NET Hot Reload для редактирования кода во время выполнения

Рады представить вам возможность горячей перезагрузки .NET в Visual Studio 2019 версии 16.11 (предварительная версия 1) и с помощью инструментария командной строки dotnet watch в .NET 6 (предварительная версия 4). В полной статье коллеги познакомят вас с тем, что такое .NET Hot Reload, как вы можете начать использовать эту функцию, каково наше видение будущих запланированных улучшений и проснят, какой тип редактирования и языки в настоящее время поддерживаются.

Подробнее здесь.

8. SecretManagement Module v1.1.0

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

Подробнее здесь.

9. Новый бесплатный курс: создание бессерверных приложений с полным стеком в Azure

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

Подробнее здесь.

10. .NET Framework May 2021

Выпущена предварительная версия накопительного обновления для .NET Framework за май 2021 года.

Подробнее здесь.

11. Представляем сборку OpenJDK от Microsoft

Объявлена общая доступность сборки OpenJDK от Microsoft, нового бесплатного дистрибутива OpenJDK с открытым исходным кодом, доступного бесплатно для всех, с возможностью развертывания его где угодно. Корпорация Майкрософт активно использует Java, внутри компании работает более 500 000 JVM. Группа разработчиков Java очень гордится тем, что вносит свой вклад в экосистему Java и помогает управлять такими рабочими нагрузками, как LinkedIn, Minecraft и Azure!

Сборка включает двоичные файлы для Java 11, основанные на OpenJDK 11.0.11 + 9 x64 server и настольных средах в macOS, Linux и Windows. Мы также публикуем новый двоичный файл раннего доступа для Java 16 для Linux и Windows на ARM, основанный на последней версии OpenJDK 16.0.1 + 9.

Этот новый выпуск Java 16 уже используется миллионами игроков Minecraft с последней версией Minecraft Java Edition Snapshot 21W19A, которая была обновлена для объединения среды выполнения Java 16 на основе сборки Microsoft OpenJDK.

Посетите страницу, чтобы узнать подробности.

Подробнее здесь.

Привет, Хабр! Сегодня делимся подборкой наших крутых вебинаров и митапов по Azure в Июне. В этот раз их четыре, и один из четырех эвентов может вас заинтересовать, даже если вы не работаете с Azure: встреча разработчиков, работающих с любыми технологиями Microsoft. Присоединяйтесь!

1. Перенос локальной инфраструктуры и данных

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

Во время мероприятия:

• Обнаружьте и оцените рабочие нагрузки в своей среде перед миграцией с помощью Azure Migrate и других инструментов.

• Выберите стратегию миграции, которая лучше всего соответствует вашему бизнесу и техническим потребностям.

• Перенесите традиционные локальные рабочие нагрузки идентификации Windows Server и защитите от угроз с помощью Azure Active Directory (Azure AD), доменных служб Azure AD, Azure AD Connect и контроллеров домена Windows Server IaaS.

• Перенесите свои локальные вычислительные нагрузки Windows Server в Azure, включая физические серверы и виртуальные машины, работающие на VMware или Windows Server Hyper-V.

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

Подробности и регистрация.

2. Основы ИИ

Откройте для себя решения, которые можно создавать с помощью ИИ, и сервисы Azure, помогающие в разработке этих решений. Присоединяйтесь к нам на бесплатном мероприятии Microsoft Azure Virtual Training Day: основы ИИ, чтобы получить общее представление о том, что такое ИИ, и узнать, как начать работу с ИИ в Azure.

Посетите виртуальное обучающее мероприятие, чтобы:

• Изучить основные концепции и области применения ИИ.

• Создать прогнозные модели, не требующие написания программного кода, с помощью сервиса машинного обучения Azure.

• Подробнее узнать о разговорном ИИ, обработке естественного языка и компьютерном зрении в Microsoft Azure.

После завершения этого бесплатного обучающего курса вы сможете сдатьсертификационный экзамен по основам Microsoft Azure AIбесплатно.

Вот, что мы вам предлагаем:

• Введение

• Введение в ИИ

• Машинное обучение

• Перерыв 10минут

• Компьютерное зрение

• Перерыв 10минут

• Обработка естественного языка

• Виртуальный собеседник

• Завершающий сеанс вопросов и ответов

Подробности и регистрация.

3. Microsoft Developers Meetup

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

На мероприятии вы узнаете от лучших экспертов в области разработки о том, какие технологии предлагает GitHub и Microsoft для разработчиков и DevOpsa. Специалисты и архитекторы Microsoft покажут, как размещать в Azure приложения с использованием контейнеров, а также какие возможности имеет предлагает GitHub для обеспечения безопасной и эффективной работы команд.

Партнёры Microsoft поделятся своим опытом и практикой реализации проектов трансформации процессов разработки и улучшения качества кода. Мероприятие ориентировано на разработчиков и руководителей разработки, а также ИТ-специалистов, специалистов по безопасности и ИТ-менеджеров, которые участвуют в процессе разработки программного обеспечения, а также занимаются выведением программных продуктов на рынок.

Программа

Подробности и регистрация: регистрация приостановлена.

4. Основы Microsoft Azure

Чтобы представить будущее, вам необходимо понять, какие возможности перед вами и вашей организацией открывает облако сегодня. В рамках этого вводного курса День виртуального обучения Microsoft Azure: основы рассказывается о концепциях, моделях и сервисах облачных вычислений. Рассматриваются такие темы, как публичное, частное и гибридное облако, а также инфраструктура как услуга (IaaS), платформа как услуга (PaaS) и программное обеспечение как услуга (SaaS).

Во время обучения вы узнаете, как:

• начать работать с Azure;

• интегрировать Azure с существующими сетями;

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

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

Подробности и регистрация.

Добро пожаловать в современный интернет, где большая часть взаимодействия приходится на интерфейсы прикладного программирования API. На API держится цифровой бизнес: с ними стало возможным предоставлять и получать услуги через приложения и подключённые к Сети устройства. Платёжные системы? Работают через API. Интерактивная карта, показывающая, как добраться от метро до офиса? Снова API. Даже бэкенд строится на API.

Похоже, мы окружены значит, придётся разбираться. Что такое API, на Хабре уже рассказывали, а я предлагаю рассмотреть поподробнее реализацию API Gateway на облачных платформах.

Зачем вообще нужны Gateway API

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

Представьте себе: у вас есть интернет-магазин по продаже реплик молота Тора. Для удобства пользователя имеется как сайт под десктоп и мобильные устройства, так и приложения для Android и iPhone, которые взаимодействуют с сервером через REST API.

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

API Gateway выполняет множество задач: принимает, обрабатывает и распределяет запросы, контролирует трафик, осуществляет мониторинг и контроль доступа.

В микросервисной архитектуре паттерн API Gateway появился в качестве службы, обеспечивающей единую точку входа для веб-приложений и API, эдакой серверной части для клиентской части. В чём польза именно для микросервисов?

Например возможность повторного использования компонентов, упрощение бэкенда приложения, обеспечение доступа к статическим веб-страницам и документам, удобная проверка авторизации и подбор оптимального для каждого типа клиента API как это делает Netflix API Gateway.

Что такое облачные API Gateway

Облачные структуры заимствуют многие паттерны микросервисов в том числе API Gateway и необходимость в их применении. API Gateway упрощает интеграцию приложения с сервисами облачной платформы и позволяет в полной мере использовать её возможности.

Классический API Gateway представляет собой шлюз между пользователями и любым количеством сервисов (API), выполняющий функцию обратного прокси, как Nginx и HAProxy. В то же время облачная версия API Gateway уже полноценный сервис для разработчиков, который простым в исполнении не назовёшь.

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

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

Как облачные API Gateway облегчают жизнь

Итак, в разработке всё чаще применяются облачные технологии и закономерно возникает вопрос об облачных шлюзах API, их особенностях и преимуществах. Стоит ли их применять или лучше как-нибудь по старинке?

Для чего разработчики вообще выбирают облачные API Gateway?

• Чтобы сократить время разработки API Gateway создаётся в несколько кликов, а интеграция с облачными сервисами выбранной платформы занимает пару минут.

• Чтобы обеспечить минимальную задержку ответа на запрос об этом позаботится система автоматического масштабирования.

• Чтобы лучше контролировать трафик к примеру, с помощью ограничения нагрузки на количество запросов в секунду для каждого HTTPметода. А при необходимости можно сформировать кеш с настраиваемыми ключами и указанием жизненного срока в секундах.

• Чтобы отлаживать API встроенными средствами меньше головной боли.

• Чтобы генерировать клиентские SDK.

• Чтобы одновременно использовать нескольких версий одного API, а также управлять стадиями выпуска от альфы до релиза.

• Чтобы контролировать доступ к API и управлять его жизненным циклом от создания до публикации.

• Чтобы уведомление приходило от сервиса, а не от разозлённого клиента, если что-то идёт не так.

• Чтобы настраивать авторизацию удобным методом с помощью средств Lambda или токенов OAuth.

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

• Чтобы платить только за количество запросов в месяц или пользоваться сервисами бесплатно, если не выходить за рамки определённой цифры.

Как используют облачные API Gateway

Виртуальная доска

Простое приложение, состоящее из двух конечных точек POST для записи сообщений и GET для извлечения трёх последних сообщений. Реализовано с помощью AWS Gateway, AWS DynamoDB, AWS Serverless Application Model и Lambda.

Голосовой сервиc

Рецепт сервиса записи к врачу и регистрации в поликлинике, разработанный коммуникационной платформой Voximplant и Yandex.Cloud.

Бот для телеграма

Запуск бота на Python внутри одного из облачных сервисов, а именно Yandex.Cloud.

Трекер пульсометрии

Один из вариантов решения для сбора данных пульсовой оксиметрии для нескольких пользователей, отслеживания этих данных и обмена ими. Фронт написан на VueJS, бэкенд реализован с применением Amazon API Gateway.

Статический сайт в облаке

Пошаговая инструкция по деплою статического сайта в облако, прикрутке к нему сертификата Lets Encrypt, домена второго уровня и настройке API-шлюза в системе Yandex.Cloud.

Блог

И снова приложение на микросервисах реализация клиентской части на VueJS, взаимодействие настроено через REST API и gRPC, а в качестве базы данных используется MongoDB.

Реализация на разных облачных платформах

Сервис API Gateway предлагают несколько облачных платформ и все они предоставляют более-менее схожий пакет услуг. Так в чём же разница?

Azure API Management

Платформа гибридного кросс-облачного управления через API Позволяет в том числе самостоятельное размещение шлюза в своей среде и управление им через API Azure. Мультиклауд для отважных.

Amazon API Gateway

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

Документация включает подробные инструкции от развёртывания RESTful API при создании бессерверного веб-приложения до работы с HTTP API, поэтому не придётся искать примеры по всей Сети, чтобы разобраться.

Особенности:

• Создание API RESTful при помощи API HTTP или API REST.

• Интерфейсы API WebSocket для разработки приложений, которым требуется двусторонняя связь в режиме реального времени.

• Частная интеграция с AWS ELB и AWS Cloud Map.

• Ключи API для сторонних разработчиков.

• Генерирование клиентских SDK на многих языках, включая JavaScript, iOS и Android.

• Внедрение подписи четвёртой версии для API REST и API WebSocket при авторизации и проверке запросов API к другим сервисам AWS API Gateway.

• Авторизация с помощью AWS Lambda.

• Amazon API Gateway можно пользоваться бесплатно целый год пока ваши потребности не превышают один миллион вызовов API, полученных для API REST, один миллион вызовов API, полученных для API HTTP, и один миллион сообщений и 750 000 минут подключения для API WebSocket в месяц.

• Обучение с помощью пошаговых учебных пособий, а также доступ к более чем 500 бесплатным онлайн-курсам.

Oracle API Gateway

Сервис Oracle API Gateway стал доступен любому пользователю в конце 2019 года и уже пытается активно конкурировать с Amazon API Gateway. Получится ли у него отвоевать хотя бы часть аудитории у AWS, нам только предстоит увидеть а сравнивать всегда интереснее на собственном опыте. Почитать про создание своего Gateway API можно вот в этой статье.

Особенности платформы:

• RESTful API в комбинации с Oracle Functions, а также возможностями Kubernetes и Compute.

• Каждая служба в облачной инфраструктуре Oracle интегрируется с IAM для аутентификации и авторизации (консоль, SDK или CLI и REST API).

• Интеграция с системой управления доступом Oracle Cloud Infrastructure.

• Бесплатный период длительностью в тридцать дней, чтобы опробовать возможности широкого спектра сервисов Oracle Cloud, в том числе к Databases, Analytics, Compute, Container Engine for Kubernetes и т. д.

• Платформа Oracle Cloud позиционирует себя как более экономичное решение, чем AWS, и в качестве примера упоминает, что соотношение цены и производительности в 2 раза выше, а стоимость исходящей пропускной способности составляет только 1/4 от стоимости у AWS.

Google API Gateway

Сервис перешёл на стадию публичного бета-тестирования 18 сентября 2020 года, так что пока о нём известно довольно мало и тем интереснее пронаблюдать за его развитием.Сейчас Google API Gateway позволяет управлять API других сервисов облачной платформы Cloud Functions, Cloud Run, App Enginе, Compute Engine и Google Kubernetes Engine. Настроить работу с Cloud Run, к примеру, можно всего за несколько минут.

Особенности:

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

• До 2 миллионов запросов в месяц бесплатно.

• Наличие пробной версии. Google Cloud предоставляет виртуальный кредит в размере 300 долларов, который необходимо потратить в течение последующих трёх месяцев. После окончания бесплатного периода оплата не начинает взиматься автоматически на платный тариф необходимо перейти вручную.

SberCloud API Gateway

SberCloud API Gateway использует наработки Huawei, а информации об особенностях применении в Сети можно найти немного, но здесь вам поможет Хабр: после недавнего хакатона один из участников рассказал о впечатлениях от SberCloud и сравнил функциональность с более известным AWS.

Особенности:

• Доступ к облачным продуктам для физических лиц возможен только с помощью входа/регистрации через Сбер ID.

• Управление квотами и регулирование запросов пользователей.

• Встроенный инструмент отладки.

• Визуализированная панель мониторинга API.

• Создание каналов VPC для доступа к бэкенд-сервисам в сети VPC и управления нагрузкой путём отправки API-запросов на различные серверы.

• Цифровая подпись, которая вступает в силу только после привязки к API.

• Никакой минимальной или предварительной платы оплачивается только фактическое использование.

• Возможность монетизации API.

Yandex API Gateway

23 сентября 2020 года к четырём сервисам платформы Yandex.Cloud прибавились ещё два Yandex API Gateway и база данных Yandex Database в режиме Serverless.

Yandex API Gateway интегрирован с другими сервисами платформы, благодаря чему возможна отправка HTTP-запросов с помощью функций Yandex Cloud Functions, доступ к статическим данным осуществляется Yandex Object Storage напрямую из хранилища, а запуск произвольных HTTP-сервисов в облаке возможен с помощью Yandex Managed Service for Kubernetes. Так что спектр применения широк к примеру, внутри облака можно запустить приложение на Express.js.

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

Особенности:

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

• Поддержка OpenAPI 3.0.

• Обработка запросов только по протоколу HTTPS. Сервис автоматически перенаправляет все запросы к API-шлюзам по протоколу HTTP на их HTTPS-версии.

• Интеграция с системой управления доменами сервиса Certificate Manager. Для обеспечения TLS-соединения используется привязанный к домену сертификат.

• Система квот и лимитов. Максимальный размер спецификации 3,5 МБ. Количество API-шлюзов в одном облаке 10, но, в отличие от максимального размера спецификации, меняется по запросу в техническую поддержку.

Тарификация по количеству запросов к созданным API-шлюзам и исходящему трафику. При этом запросы к API-шлюзам до 100 000 запросов в месяц не тарифицируются. Как, кстати, и входящий трафик, а также передача данных между сервисами Yandex.Cloud. Больше подробностей можно узнать в сообществе Serverless в Telegram:Yandex Serverless Ecosystem. Мы регулярно встречаемся в виртуальном пространстве и похоже созревает потребность в очной встрече.

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

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

• 3 ресурса с гайдами

• сайт с учебными модулями

• 8 книг

• ресурс с примерами архитектуры

Все это под катом!

Начало работы с облачными приложениями .NET

Если вы новичок, начните создавать простые микросервисы с помощью веб-API ASP.NET, Docker и разверните их в Azure Kubernetes Services (AKS).

• Гайд по .NET - Hello World Microservice содержит пошаговые инструкции по установке .NET и созданию вашего первого микросервиса с помощью Docker

• Гайд по .NET - развертывание микросервиса в Azure содержит пошаговые инструкции по развертыванию микросервиса .NET в службе Azure Kubernetes (AKS)

• Видеоролики по .NET и Docker 101 помогут вам начать работу с .NET, Docker и поддержкой инструментов в Visual Studio

Практические модули обучения Microsoft

У Microsoft есть бесплатная онлайн-платформа для обучения под названием Microsoft Learn. Вы можете получить больше навыков с помощью контента, который в то же время веселый, управляемый, практический, интерактивный и соответствует вашей роли и целям. Мы создали серию модулей, которые помогут вам научиться создавать микросервисы .NET с облачными технологиями, такими как Docker, Container Registry, Kubernetes, Helm и многими другими. Единственная программа, которая вам понадобится на вашем компьютере для запуска этого модуля, - это браузер. Вся магия выполняется за кулисами с помощью Azure CLI, поэтому вы можете полностью сосредоточиться на обучении и забыть про проблемы с инфраструктурой.

Попробуйте их сейчас!

Бесплатные электронные книги по архитектуре

Dapr для .NET разработчиков

Форматы:PDF|Read online

Руководство для разработчиков .NET по пониманию и использованию всей мощи распределенной среды выполнения приложений Microsoft с открытым исходным кодом (Darp). Dapr помогает решать проблемы, возникающие при создании микросервисов, и делает ваш код независимым от платформы.

Cloud-native

Форматы:PDF|Read online

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

.NET микросервисы

Форматы:PDF|Read online

Мы написали это руководство для разработчиков и архитекторов решений, которые плохо знакомы с разработкой приложений на основе Docker и архитектурой на основе микросервисов. В этой книге рассматриваются такие шаблоны, как Domain-Driven Design(DDD), Command Query Responsibility Segregation (CQRS), Database per service, API Composition.

Бессерверные приложения

Форматы:PDF|Read online

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

DevOps: жизненный цикл приложения Docker

Форматы:PDF|Read online

Это руководство содержит общие сведения о Azure DevOps для реализации конвейеров CI/CD, охватывает реестр контейнеров Azure (ACR) и службы Azure Kubernetes (AKS) для развертывания.

Модернизация существующих приложений .NET

ASP.NET Core gRPC для WCF-разработчиков

Форматы:PDF|Read online

Мы написали это руководство для разработчиков, работающих в .NET Framework или .NET Core, которые ранее использовали WCF и стремятся перенести свои приложения в современную среду RPC для .NET 5. В целом, если вы обновляете или рассматриваете возможность обновления до. NET 5, и вы хотите использовать встроенные инструменты gRPC, это руководство поможет.

Миграция приложений .NET в Azure

Форматы:PDF|Read online

В этом руководстве основное внимание уделяется начальной модернизации существующих веб-приложений или сервис-ориентированных приложений Microsoft .NET Framework. Это означает перенос рабочей нагрузки в новую или более современную среду без значительного изменения кода приложения и базовой архитектуры. Кроме того, ознакомьтесь с другими ресурсами по миграции на странице Migrate your .NET app to Azure.

Перенос существующих приложений ASP.NET на .NET Core

Форматы:PDF|Read online

В этом руководстве представлены высокоуровневые стратегии миграции существующих приложений, написанных для ASP.NET MVC и веб-API (.NET Framework 4.x), в .NET Core. В нем также рассматриваются стратегии миграции больших решений на примере проекта.

Примеры архитектуры

eShopOnContainers - один из наших популярных эталонных образцов микросервисов. Это кроссплатформенное контейнерное приложение, работающее на платформе .NET 5. Ознакомьтесь с этим примером для подробной реализации некоторых шаблонов микросервисов, таких как CQRS, DDD, Database per service, API Composition. Не забудьте проверить другие примеры, в том числе "Модернизация ваших приложений .NET" здесь.

WPP и Microsoft объявили о партнерских отношениях для преобразования производства творческого контента, и первым шагом станет запуск Cloud Studio инновационной облачной платформы, которая позволяет творческим командам из глобальной сети WPP проводить кампании для клиентов из любой точки мира.

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

В течение следующих трех лет WPP развернет Cloud Studio для 5000 сотрудников по всей своей сети, а особенно в творческом подразделении WPP Hogarth, что даст возможность обращаться к производственным инструментам и службам со стандартных подключенных к Интернету устройств через Azure без необходимости использовать традиционное или специализированное физическое оборудование. В долгосрочной перспективе WPP планирует более широкое распространение платформы с потенциальным развертыванием до 25 000 пользователей.

Цифровые технологии стремительно меняют индустрию СМИ и рекламы, в том числе способ производства контента, сказал Сатья Наделла, генеральный директор Microsoft. Вместе с WPP мы применим возможности масштабируемой интеллектуальной инфраструктуры Azure, чтобы поддержать производство контента следующего поколения, обеспечить гибкость и создать условия для сотрудничества и творчества тысячам сотрудников WPP, где бы они ни находились.

Технологии вот что движет творчеством WPP. Они позволяют нам воплощать наши замыслы, находить новые идеи и применять новаторские методы работы. Пандемия показала, что команды WPP могут успешно сотрудничать и предоставлять клиентам потрясающие результаты, при этом находясь друг от друга физически далеко, сказал Марк Рид (Mark Read), генеральный директор WPP. Партнерство с Microsoft для работы над Cloud Studio это следующий шаг на нашем пути к тому, чтобы вооружить творческие команды новейшими передовыми производственными инструментами и привлекать лучших специалистов, независимо от того, где они находятся.

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

Кроме этого, Cloud Studio, в соответствии с более широкой повесткой WPP в области устойчивого развития, поможет выполнить недавновзятые обязательства: обеспечить максимальную эффективность и минимизировать энергопотребление, сократив потребности творческих групп в традиционных производственных студиях для доставки крупномасштабного высококачественного маркетингового контента. Способы использования платформой контента и поиска цифровых активов также помогут сократить потери материалов и задействовать ресурсы, оставшиеся от предыдущих проектов. Обе компании WPP и Microsoft взяли на себя амбициозные обязательства в отношении устойчивого развития и уже сотрудничали в этом направлении.

Сервисы Azure обеспечат основу для Cloud Studio, включая использование вычислительных ресурсов и хранилища Azure для более быстрой и эффективной передачи контента в руки творческих профессионалов. Azure позволит WPP увеличивать и уменьшать объемы хранилища в зависимости от потребностей, меняющихся с началом и завершением новых клиентских проектов, и при этом сократит расходы за счет использования более экономичного облачного хранилища после архивации проекта. Azure DevOps и GitHub позволят WPP при необходимости быстро подготовить новые экземпляры Cloud Studio. Наконец, чтобы творческие специалисты могли работать где угодно, WPP будет использовать передовые устройства Surface, включая Surface Pro 7, Surface Go 2, Surface Book 3 и Surface Duo.

Повышение производительности и доступности

WPP и Microsoft имеют давние отношения, не ограниченные виртуальным производством, что позволяет создавать технологические решения, помогающие WPP улучшать взаимодействие с сотрудниками и клиентами. Например, благодаря Microsoft Teams 100 000 сотрудников WPP смогли беспрепятственно перейти на гибридную рабочую среду за последние 18 месяцев, что улучшило совместную работу и общение внутри компании и с клиентами. Кроме того, недавно WPP с помощью Microsoft сделала свою творческую продукцию более инклюзивной и доступной для людей с ограниченными возможностями, создав решение, котороеиспользует сервисы Azure AI, чтобы внедрять проверку доступности и инклюзивности в работу клиентов по мере ее создания.

*Gateway шлюз

Azure Active Directory Gateway это обратный прокси-сервер, который работает с сотнями служб, входящих в Azure Active Directory (Azure AD). Если вы пользовались такими службами, как office.com, outlook.com, azure.com или xbox.live.com, то вы использовали шлюз Azure AD. Шлюз присутствует в более чем 53 центрах обработки данных Azure по всему миру и обслуживает ~115 миллиардов запросов ежедневно. До недавнего времени шлюз Azure AD работал на платформе .NET Framework 4.6.2. С сентября 2020 года он работает на .NET Core 3.1.

Мотивация для перехода на .NET Core

Масштаб результатов шлюза приводит к значительному потреблению вычислительных ресурсов, что, в свою очередь, стоит денег. Поиск путей снижения стоимости работы сервиса был ключевой целью для команды, стоящей за ней. Шумиха вокруг производительности .NET Core привлекла наше внимание, тем более что TechEmpower назвал ASP.NET Core одним из самых быстрых веб-фреймворков на планете. Мы провели собственные тесты прототипов шлюза на .NET Core, и результаты позволили нам принять очень простое решение: мы должны перенести наш сервис на .NET Core.

Обеспечивает ли .NET Core реальную экономию средств?

Безусловно, обеспечивает. Благодаря шлюзу Azure AD мы смогли сократить затраты на CPU (ЦП) на 50%.

Раньше шлюз работал на IIS с .NET Framework 4.6.2. Сегодня он работает на IIS с .NET Core 3.1. На изображении ниже показано, что использование ЦП сократилось вдвое на .NET Core 3.1 по сравнению с .NET Framework 4.6.2 (фактически удвоив пропускную способность).

В результате увеличения пропускной способности мы смогли уменьшить размер нашего сервера с ~40 тыс. до ~20 тыс. ядер (сокращение на 50%).

Как произошел переход к .NET Core?

Он происходил в 3 этапа.

Этап 1: Выбор пограничного сервера

Когда мы начали работу по переходу, первый вопрос, который мы должны были задать себе, был: какой из трех серверов в .NET Core мы выберем?

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

Kestrel:

Когда мы инициировали наш переход (ноябрь 2019 года), Kestrel не поддерживал ни согласование клиентских сертификатов, ни их аннулирование для каждого имени хоста. В .NET 5.0 поддержка этих функций была добавлена.

Как и в .NET 5.0, Kestrel (благодаря использованию SslStream) не поддерживает CTL-хранилища для каждого имени хоста. Поддержка ожидается в .NET 6.0.

HTTP.sys:

Сервер HTTP.sys столкнулся с несоответствием между конфигурацией TLS на Http.Sys и имплементацией .NET: Даже если привязка настроена так, чтобы не согласовывать клиентские сертификаты, обращение к свойству Client certificate в .NET Core вызывает нежелательное повторное согласование TLS.

Например, выполнение простого null check в C# приводит к повторному согласованию TLS handshake (рукопожатия TLS):

if (HttpContext.Connection.ClientCertificate != null)

Это показано в https://github.com/dotnet/aspnetcore/issues/14806 в ASP.NET Core 3.1. В то время, когда мы делали переход в ноябре 2019 года, мы были на ASP.NET Core 2.2 и поэтому не выбрали этот сервер.

IIS:

IIS отвечал всем нашим требованиям к TLS, поэтому мы выбрали именно этот сервер.

Этап 2: Миграция приложения и зависимостей

Как и многие крупные службы и приложения, шлюз Azure AD имеет множество зависимостей. Некоторые из них были написаны специально для этой службы, а некоторые другими специалистами внутри и вне Microsoft. В некоторых случаях эти библиотеки уже были нацелены на .NET Standard 2.0. В других случаях мы обновили их для поддержки .NET Standard 2.0 или нашли альтернативные имплементации, например, удалили нашу устаревшую библиотеку Dependency Injection и вместо нее использовали встроенную в .NET Core поддержку для внедрения зависимостей. На этом этапе большую помощь оказал .NET Portability Analyzer.

Для самого приложения:

• Шлюз Azure AD имел зависимость от IHttpModule и IHttpHandler из классического ASP.NET, которой нет в ASP.NET Core. Поэтому мы переработали приложение, используя конструкции промежуточного ПО в ASP.NET Core.

• Одной из вещей, которая действительно помогла в процессе миграции, является Azure Profiler (служба, которая собирает трассировки производительности на виртуальных машинах Azure). Мы развертывали наши ночные сборки на тестовых площадках, использовали wrk2 в качестве агента нагрузки для тестирования сценариев под нагрузкой и собирали трассы Azure Profiler. Эти трассировки затем информировали нас о следующей настройке, необходимой для получения пиковой производительности нашего приложения.

Этап 3: Постепенное развертывание

Философия, которую мы придерживались во время развертывания, заключалась в том, чтобы обнаружить как можно больше проблем с минимальным или нулевым влиянием на работу.

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

• После завершения кода мы развернули сборку .NET Core на одной производственной системе в единице масштабирования. Единица масштабирования это пул виртуальных машин с балансировкой нагрузки.

• В единице масштабирования ~100 машин, где на 99 машинах все еще работала наша существующая сборка .NET Framework и только на 1 машине была установлена новая сборка .NET Core.

• Все ~100 машин в этом масштабном блоке получают точный тип и количество трафика. Затем мы сравнили коды состояния, количество ошибок, функциональные сценарии и производительность одной машины с остальными 99 машинами, чтобы обнаружить аномалии.

• Мы хотели, чтобы эта единственная машина вела себя функционально так же, как и остальные 99 машин, но имела гораздо более высокую производительность/пропускную способность, что мы и наблюдали.

• Мы также "перенаправили" трафик с действующих производственных устройств (работающих с .NET Framework build) на устройства с .NET Core, чтобы сравнить и сопоставить их, как указано выше.

• Как только мы достигли функциональной эквивалентности, мы начали увеличивать количество единиц масштаба, работающих на .NET Core, и постепенно расширили их до целого центра данных.

• После миграции всего центра обработки данных последним шагом было постепенное распространение по всему миру на все центры обработки данных Azure, где присутствует служба шлюза Azure AD. Миграция завершена!

Полученные знания

• ASP.NET Core внимателен к RFC. Это очень хорошая особенность, так как она способствует распространению передовой практики. Однако классические ASP.NET и .NET Framework были более снисходительны, что вызывает некоторые проблемы с обратной совместимостью:

• Веб-сервер по умолчанию разрешает только значения ASCII в заголовках HTTP. По нашей просьбе поддержка Latin1 была добавлена в IISHttpServer: https://github.com/dotnet/aspnetcore/pull/22798

• HttpClient на .NET Core раньше поддерживал только значения ASCII в HTTP-заголовках.

• Команда .NET Core добавила поддержку Latin1 в .NET Core 3.1: https://github.com/dotnet/corefx/pull/42978

• Возможность выбора схемы кодировки добавлена в .NET 5.0: https://github.com/dotnet/runtime/issues/38711.

• Формы и cookies, не соответствующие RFC, приводят к исключениям при проверке. Поэтому мы создали "запасные" парсеры, используя классический исходный код ASP.NET, чтобы сохранить обратную совместимость для клиентов.

• В методе FileBufferingReadStreams CopyToAsync() наблюдалось снижение производительности из-за нескольких 1-байтовых копий n-байтового потока. Эта проблема решена в .NET 5.0 путем выбора размера буфера по умолчанию в 4K: https://github.com/dotnet/aspnetcore/issues/24032.

• Помните о классических причудах ASP.NET:

  • Автоматически тримятся (auto-trimmed) символы пробелов:

foo.com/oauth ?client=abc тримятся до foo.com/oauth?client=abc в классическом ASP.NET.

• С течением времени клиенты/даунстрим сервисы стали зависеть от этих тримов, а ASP.NET Core не выполняет автоматическтий триминг.

Поэтому нам пришлось убрать пробельные символы (auto-trim), чтобы имитировать классическое поведение ASP.NET.

• Заголовок Content-Type автоматически генерируется, если отсутствует тому:

Когда размер ответа больше нуля байт, но заголовок Content-Type отсутствует, классический ASP.NET генерирует стандартный заголовок Content-Type:text/html. ASP.NET Core не генерирует заголовок Content-Type по умолчанию принудительно, и клиенты, которые полагают, что заголовок Content-Type всегда появляется в ответе, начинают испытывать проблемы. Мы имитировали классическое поведение ASP.NET, добавив Content-Type по умолчанию, когда он отсутствует в нижестоящих службах.

Будущее

Переход на .NET Core привел к удвоению пропускной способности нашего сервиса, и это было отличное решение. Наше путешествие по .NET Core не закончится после перехода. В будущем мы рассматриваем следующие варианты:

• Обновление до .NET 5.0 для повышения производительности.

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

• Использовать компоненты/лучшие практики YARP (https://microsoft.github.io/reverse-proxy/) в нашем собственном обратном прокси и также внести свой вклад.

  ---

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

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

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

Южнокорейский рентгенолог Кю-мок Ли говорит, что средства быстрого анализаLunit INSIGHT CXRпозволяют быстро идентифицировать то, что он называет многими обличиями COVID-19, а это дает возможность ускорить лечение пациентов и ограничить передачу инфекции.

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

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

Алгоритмы Lunit обучены анализировать рентгеновские снимки и изначально могли обнаруживать признаки 10 основных заболеваний грудной клетки, включая рак, с точностью 97-99%.

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

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

Ли со своей командой рентгенологов присоединился к борьбе с COVID-19 около года назад, когда первая волна накрыла Сеул.

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

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

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

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

Кроме Южной Кореи, эту технологию стали применять в Таиланде, Индонезии, Мексике, Италии и Франции. В тяжело пострадавшей Бразилии крупная группа медучреждений использует это решение для анализа рентгеновских снимков грудной клетки пациентов с легким течением COVID-19. Медики могут быстрее и эффективнее распределять пациентов, когда заболевших много, а рентгенологов мало.

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

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

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

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

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

Ли говорит, что масштаб обработки и точность технологии Lunit помогают разгрузить занятых рентгенологов.

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

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

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

Даже опытные специалисты из-за напряжения могут упускать важные детали. Ли вспоминает недавний случай, когда алгоритмы Lunit обнаружили связанное с COVID-19 поражение в легком пациента, которое не заметили врачи.

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

По словам Ли, рентгенография грудной клетки по-прежнему лишь дополняет более точное, но гораздо более медленноетестирование полимеразной цепной реакциина COVID. Но решение Lunit помогло остановить вспышку.

Программное обеспечение Lunit постоянно совершенствуется, с его помощью проанализировано уже более 6,5 млн рентгеновских снимков грудной клетки в более чем 80 странах.

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

Технология Lunit получила признание благодаря исследованиям, опубликованным в крупных рецензируемых журналах, таких как Radiology, Lancet Digital Health, JAMA Network Open, Clinical Infectious Diseases и других.

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

Компания Lunit была основана в 2013 году, чтобы сделать медицину, основанную на искусственном интеллекте и данных, новым стандартом лечения.

В первую очередь мы сосредоточены на борьбе с раком, одной из основных причин смерти во всем мире, говорит генеральный директор Lunit Брэндон Су Мы разрабатываем решения на основе искусственного интеллекта для точной диагностики и лечения, чтобы ставить пациентам правильный диагноз по разумной цене и подбирать подходящее лечение.

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

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

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

22 марта и 23 марта, 11.00-14.20 (GMT+3)

Изучите основные концепции баз данных в облачной среде. Присоединяйтесь к нам на мероприятии Microsoft Azure Virtual Training Day: основы данных, чтобы получить базовые знания об облачных сервисах обработки данных. Изучите предложения для работы с реляционными и нереляционными данными, а также решения для аналитики больших данных и современных хранилищ данных в Azure.

Подробности и регистрация.

Посетите это учебное мероприятие, чтобы:

• Изучить роли, задачи и обязанности, связанные с управлением данными в облачной среде.

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

• Изучить средства обработки данных, используемые при создании решений для аналитики данных, включая Azure Synapse Analytics, Azure Databricks и Azure HDInsight.

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

Вот, что мы вам предлагаем:

Подробности и регистрация.

Привет, Хабр! Сегодня у нас последняя в этом месяце подборка крутых мероприятий. В этот раз по Azure. Заглядывайте под кат!

1. День виртуального обучения Microsoft Azure: основы

Чтобы представить будущее, вам необходимо понять, какие возможности перед вами и вашей организацией открывает облако сегодня. В рамках этого вводного курса День виртуального обучения Microsoft Azure: основы рассказывается о концепциях, моделях и сервисах облачных вычислений. Рассматриваются такие темы, как публичное, частное и гибридное облако, а также инфраструктура как услуга (IaaS), платформа как услуга (PaaS) и программное обеспечение как услуга (SaaS).

Во время обучения вы узнаете, как:

• начать работать с Azure;

• интегрировать Azure с существующими сетями;

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

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

Подробности и регистрация.

2. DevOps с GitHub

Продвигайте свою карьеру, имея прочный фундамент в DevOps. Посетите это бесплатное обучение под руководством инструктора, предназначенное для разработчиков и ИТ-специалистов. Узнайте, как использовать GitHub для управления рабочими процессами и сокращения времени цикла. Получите пошаговые инструкции по добавлению элементов управления качеством и безопасностью в процесс сборки, а также по улучшению уведомлений и ответов для обеспечения согласованной и повторяемой автоматизации.

Изучите эти темы на мероприятии:

• Использование GitHub для улучшения совместной работы и производительности команды

• Интеграция средств контроля безопасности и качества в конвейеры автоматизации, непрерывной интеграции и непрерывной доставки (CI / CD) и среды выполнения

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

Подробности и регистрация.

Привет, Хабр! В этот раз у нас немного разбитый анонс мероприятий месяца (в начале мая рассказали про ранние мероприятия точечно, теперь делаем небольшую подборку), все из-за праздников. В этой статье у нас 2 эвента: один полностью на русском, второй с субтитрами. Заглядывайте под кат!

1. Взаимодействие DevOps и GitHub

Продвигайте свою карьеру, имея прочный фундамент в DevOps. Посетите это бесплатное обучение под руководством инструктора, предназначенное для разработчиков и ИТ-специалистов. Узнайте, как использовать GitHub для управления рабочими процессами и сокращения времени цикла. Получите пошаговые инструкции по добавлению элементов управления качеством и безопасностью в процесс сборки, а также по улучшению уведомлений и ответов для обеспечения согласованной и повторяемой автоматизации.

Изучите эти темы на мероприятии:

• Использование GitHub для улучшения совместной работы и производительности команды.

• Интеграция средств контроля безопасности и качества в конвейеры автоматизации, непрерывной интеграции и непрерывной доставки (CI / CD) и среды выполнения.

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

Подробности и регистрация.

2. Основы работы с данными

Изучите основные концепции баз данных в облачной среде. Присоединяйтесь к нам на мероприятии Microsoft Azure Virtual Training Day: основы данных, чтобы получить базовые знания об облачных сервисах обработки данных. Изучите предложения для работы с реляционными и нереляционными данными, а также решения для аналитики больших данных и современных хранилищ данных в Azure.

Посетите это учебное мероприятие, чтобы:

• Изучить роли, задачи и обязанности, связанные с управлением данными в облачной среде.

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

• Изучить средства обработки данных, используемые при создании решений для аналитики данных, включая Azure Synapse Analytics, Azure Databricks и Azure HDInsight.

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

Подробности и регистрация.

Любому бизнесу, особенно крупному, хочется максимально оптимизировать внутренние процессы. В частности, те, которые касаются ИТ. Довольно часто мы встречаем ситуации, когда сугубо цифровые задачи в силу устаревших регламентов или страха сломать работающую систему решаются по старинке, вручную.

Ингосстрах обратилась к нам со следующей задачей: из-за огромного количества ручных операций параметр time-to-market их цифровых продуктов в некоторых случаях был достаточно высоким. Это не устраивало никого: ни разработчиков, ни тестировщиков, ни бизнес. Требовалось как можно сильнее сократить time-to-market, не стесняясь в ресурсах и средствах.

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

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

Подготовка к проекту

Первым делом мы изучили потребности заказчика. Необходимо было понять, какие ресурсы (приложения, ОС и пр.) используются компанией, как они настраиваются и для чего служат. Чаще всего мы встречаемся с полуручными-полуавтоматическими сценариями: ВМ разворачиваются из шаблона и настраиваются вручную. В ряде случаев заказчики используют скрипты автоматизации настройки, чтобы получить на выходе полностью функциональную ОС, иногда даже с готовым набором ПО. В Ингосстрахе было и то, и другое.

Выбор решения: open source против корпораций

После обследования, еще до подготовки окончательного ТЗ, мы составили для заказчика проектное решение. Требовалось согласовать его со службой безопасности а это процесс не из легких. Много времени ушло на то, чтобы убедить суровых безопасников в том, что облако не угрожает существующей инфраструктуре. Мы нарисовали схемы обмена трафиком, сетевого взаимодействия. Описали, как всё это будет защищаться и контролироваться. Скажем прямо, пришлось попотеть. Изначально мы предложили заказчику два возможных подхода:

• open source или OpenStack с последующей доработкой;

• сугубо коммерческое решение от VMware.

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

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

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

Как строился гибрид

На первом этапе инфраструктура не очень большая, но это компенсируется количеством работающих на ней сервисов. Здесь мы развернули все необходимое для облака, в том числе ряд продуктов vRealize: Automation, Operations Manager, Log Insight и NSX-T для сети.

Позже сюда добавился NSX Cloud: он позволяет удобно управлять сетями в публичных облаках, в том числе и в Azure, через NSX. Мы подключили подписку заказчика Azure к vRealize Automation и vRealize Operations Manager последнее нужно, чтобы отслеживать потребление ресурсов.

Общая архитектура гибридного облака

Чтобы обеспечить повышенный уровень сетевой и информационной безопасности, мы использовали CheckPoint. Файрвол заказчика интегрирован с облаком сразу в трех точках. Трафик инспектируется:

• между виртуальными машинами;

• на выходе из облака;

• на входе в сеть заказчика.

На стороне облака развернуты виртуальные аплайнсы для инспекции трафика.

Что касается связанности сегментов облака и локальных машин здесь существует два глобальных варианта. Первый оверлейные сети через NSX. Этим путем мы пойти не смогли, так как между площадкой заказчика и Azure стоит VPN от CheckPoint.

Второй вариант подразумевает, что трафик между облаком и локальной площадкой будет идти через упомянутый выше VPN. При этом трафик внутри локальной площадки и внутри облака (по умолчанию) ходит через оверлейные сети. Если локальной виртуальной машине нужно отправить трафик в облако, он посылается по VPN и снова оказывается в оверлей-сети, но уже на стороне Azure.

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

• Automation оркестрация и автоматизация, плюс портал самообслуживания;

• Operations Manager помимо мониторинга сервисов и использования ресурсов, он осуществляет постбиллинг, определяет стоимость потребленных ресурсов в рамках проекта или конкретного сервиса.

• Log Insight собирает логи/журналы со всех компонентов инфраструктуры и передает логи аудита и аутентификации пользователей всем системам заказчика. Вход-выход, изменения конфигурационных параметров эти данные агрегируются в Log Insight, обрабатываются, очищаются и передаются в SIEM службы безопасности.

В облаке присутствует не только vRealize, но и Ansible для реализации подхода инфраструктура как код. Ansible для первичной настройки ОС, добавления нужных пользователей, установки ПО и настройки всех сервисов. Помимо повышения гибкости и колоссальных возможностей по глубокой настройке ОС и приложений, а также интеграции с другими подсистемами заказчика, Ansible позволяет разделить процессы создания и настройки ВМ. Что позволяет использовать наработки (плейбуки) для разных задач, в том числе, на прямую не связанных с облаком. Или разделить между специалистами или даже отделами задачи по сопровождению облака и автоматизации управления инфраструктурой, как это происходит в Ингосстрах.

Сервисы

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

Каталог сервисов облака

Надо сказать, кое-что стало для нас серьезным челленджем: во время написания ТЗ актуальной была версия vRealize Automation 7.6. К моменту, когда пришло время приступать к работе, появилась новая версия 8.

Минутка истории: вплоть до седьмой версии vRealize Automation развивался так же, как и любой другой продукт. Одни функции добавлялись, другие переходили в статус deprecated и заменялись более совершенными. Фактически, это решение VMware еще в 2012 году приобрела у компании DynamicOps и развивала его под своим брендом. 8-я версия vRA это не логическое продолжение старой версии, а принципиально новый внутри продукт. Да, он стал функциональнее и гибче, но часть функций, присутствовавших в 7.6, попросту исчезла.

Заказчик хотел внедрять именно новую версию. Это вполне логично: использовать продукт, который скоро станет end of life не очень хорошая затея. Но это вызвало массу проблем. Нам пришлось принять на себя некоторые риски, дорабатывать и дописывать недостающие модули своими силами.

Биллинг

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

Когда пользователь заказывает услугу из каталога из каталога самообслуживания, есть возможность увидеть её примерную стоимость в день, месяц и т.д. Проблема в том, что эти функции работают только для локальной площадки. Текущая версия vRA не дает этого функционала в публичном облаке. Обещается, что в одном из будущих обновлений этот функционал добавят, но пока что его даже в road map нет.

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

Предбиллинг позволяет в момент заказа сервиса рассчитать стоимость ресурсов (это может быть ВМ, MS SQL Server и т.п.) как на локальной площадке, так и в облаке. Изначально vRA не позволял делать расчеты для Azure. Конечно, можно было бы докупить SaaS-продукт CloudHealth, который позволяет считать постбиллинг для Azure. Однако он все равно не обеспечивает функционал предбиллинга, да и по бюджету уже не проходил. Пришлось дописывать.

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

Мы сделали так, чтобы можно было рассчитывать не только базовые вещи а-ля IaaS, но и произвольные.

Биллинг работает по двум классическим схемам: Pay-as-You-Go и prepaid.

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

Лирическое отступление: с точки зрения читателя вся эта история может выглядеть как пришли, сделали, протестировали, ушли. На самом деле, всё куда интереснее. Облако живет и развивается итеративно. Сначала реализуется самый важный функционал в случае с Ингосстрах это эффективное развертывание виртуальных машин. Затем прочие нужные и полезные вещи. Аппетит приходит во время еды это как раз про облако. Поэтому классические для сейлзов формулы заложим на разработку сто дней, авось, уложимся это уже дурной тон.

Следующие на очереди стандартные для облаков сервисы.

IaaS

Здесь речь идет о развертывании ВМ с определенными ОС и набором базовых настроек. В наборе заказчика присутствуют и различные версии Windows Server, и Linux (CentOS и RedHat).

Используемые версии Windows Server 2019, 2016 и 2012 R2. Часть систем заказчика до сих пор работают в 2012 R2. Это вызвало некоторые накладки: в Azure готовых образов этой ОС нет, т.к. Microsoft больше ее не поддерживает. Пришлось загружать свой образ. Так как речь идет о гибридной модели, сервисы предоставляются зеркально: можно создавать их как внутри локальной площадки, так и в Azure. При заказе пользователь сам определяет площадку размещения.

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

Что касается развертывания машин здесь возможны два подхода:

• пользователь сам определяет параметры ВМ CPU, RAM, дисковое пространство;

• предварительно заданные конфигурации, между которыми может выбирать пользователь.

После обсуждения с заказчиком мы пришли к выводу, что использование заготовленных конфигураций удобнее. Во-первых, можно четче спланировать инфраструктуру. Мы четко знаем, что можно создать 10 машин типа А или, например 5 машин типа Б. Если давать пользователю полную свободу выбора, никакой стандартизации не выйдет. В конфигурации Ингосстраха изменить можно только объем дискового пространства: есть нижняя граница, есть верхняя, есть размер по умолчанию. Единственный нюанс в Azure минимальный объем диска составляет 127 Гб. Соответственно, и на vSphere нам пришлось в целях унификации сделать такой же нижний порог.

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

Форма заказа сервиса IaaS

У заказчика в облаке есть три контура безопасности, каждый со своим уровнем защиты: test, dev и prod. Соответственно, тот или иной сервис размещается в своем контуре по выбору заказчика, независимо от того, локальная ли это площадка или Azure.

PaaS

Переходим к PaaS, здесь тоже немало интересных моментов. В основе PaaS лежит IaaS, используются заранее подготовленные ОС. Все Windows-сервисы (SQL, Active Directory, IIS) могут быть развернуты в любой версии этой ОС, которая требуется пользователю. Кроме, разве что, Exchange.

Основная заточка сделана под версию 2012: более свежие версии включают новый функционал, но из соображений обратной совместимости ничего из legacy не удаляется. А если бы мы ориентировались на 2019, не исключено, что пришлось бы писать разные скрипты под разные типы ОС.

Веб-сервер как услуга

Заказчик использует IIS от Microsoft. Он представлен в нескольких вариантах, в том числе есть версия с балансировкой, которая автоматически настраивается на NSX.

Чтобы сильно не углубляться, выделим следующие конфигурации, доступные пользователям:

• одноузловая конфигурация сервис с IIS.

• ферма множество веб-серверов IIS.

Пользователь может создать сразу множество серверов IIS и обеспечить балансировку подключений на базе NSX. Можно использовать стандартные порты, можно переопределить их вручную. Всё взаимодействие происходит в веб-интерфейсе.

Active Directory

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

Сервис можно развернуть в двух вариантах:

• standalone одноузловая конфигурация, когда контроллер домена и DNS совмещены;

• отказоустойчивая конфигурация два контроллера домена, между которыми в рамках развертывания настроена репликация (и самого домена, и DNS-зон).

СУБД как сервис

• MS SQL Server можно развернуть по двум типам: standalone и кластерная конфигурация always on, от 2 до 4 узлов. Присутствует возможность выбора версий. Под разные версии СУБД написаны разные скрипты установки.

Exchange как сервис

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

Казалось бы, зачем нужна вторая почтовая система в рамках облака? У заказчика была конкретная цель тестировать актуальную конфигурацию на предмет установки обновлений, масштабирования и прочих изменений. Мы сделали фактически полную (с точки зрения конфигурации) копию боевой почтовой системы. Важный момент продуктив работал на базе сразу 2-х ЦОДов. Мы сымитировали и это.

Часть дизайна сервиса Exchange

Автоматизация предоставления сервисов

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

К примеру, чтобы определить область, где пользователь может развертывать ВМ, администратор должен создать проект, назначить ресурсы и выдать пользователю доступы. Заказчику хотелось разгрузить руки администраторов и позволить пользователям через портал самообслуживания самостоятельно создавать проекты. Чтобы не выдавать права администратора направо и налево, необходим был сервис, который перед созданием проекта запрашивал бы аппрув. Пользователи ограничены квотами на количество ВМ, vCPU, RAM и дисковое пространство.

Всего для этой цели используется 4 связанных сервиса:

• создание проектной области;

• изменение можно добавлять облачные ресурсы к локальным или увеличивать их пул;

• удаление если проект больше не нужен, его можно удалить в целях экономии средств;

• архивация временная деактивация проекта и перенос его на самые бюджетные ресурсы.

Всем, кто задумывается о собственном облаке

В заключение хотелось бы поделиться некоторыми мыслями по итогам проекта:

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

• Коммерческий продукт (в нашем случае VMware) это отличная возможность для коммерческих заказчиков быстро увидеть первые результаты от внедрения облака без взращивания собственной экспертизы в течение многих лет.

• Облако позволяет существенно оптимизировать ИТ-процессы в компании за счет их понимания, переосмысления, описания и только потом уже автоматизации.

• С облаком можно вести прозрачный учет потребления ресурсов и затрат на них, а также упростить планирование и масштабирование инфраструктуры.

• Автоматизация, инструменты самообслуживания, возможности интеграции через API позволяют существенно оптимизировать процессы предоставления ресурсов ИТ-инфраструктуры и, как следствие, сократить time-to-market ИТ-продуктов компании как для внутреннего, так и для внешнего потребления.

На этом все! Если у вас есть какие-то вопросы, буду рад пообщаться в комментариях.