микросервисы что это такое
Микросервисы: что это, зачем это и когда нужно их внедрять
Закон Конвея и связь между бизнесом, организацией и информационной системой
«Любая организация, которая проектирует какую-то систему (в широком смысле) получит дизайн, чья структура копирует структуру команд в этой организации»
— Melvyn Conway, 1967
На мой взгляд этот закон скорее соотносится к целесообразности организации бизнеса, нежели напрямую к информационной системе. Поясню на примере. Допустим, у нас есть достаточно стабильная бизнес возможность с жизненным циклом такой длительности, чтобы имело смысл организовать предпринятие (это не опечатка, но мне очень нравится этот термин, который я утащил) Естественно, что обеспечивающая система этого бизнеса будет организационно и процессно соответствовать этому бизнесу.
Бизнес-ориентированность информационных систем
Все течет, все изменяется или микросервисы — средство борьбы со сложностью?
Прежде чем продолжить, рассмотрим некоторые заблуждения касательно микросервисной архитектуры.
Сторонники использования микросервисного подхода часто говорят о том, что разбиение монолита на микросервисы упрощает подход к разработке за счет уменьшения кодовой базы отдельных сервисов. На мой взгляд это утверждение является полнейшим бредом. Серьезно, очевидное взаимодействие в рамках монолита и гомогенного кода кажется сложным? Если бы это действительно было так, все проекты бы изначально строились как микросервисы, в то время как практика показывает, что миграция из монолита в микросервисы является куда более распространенной. Сложность никуда не исчезает, она просто переходит из отдельных модулей в интерфейсы (будь то шины данных, RPC, API и иные протоколы) и оркестрирующие системы. И это — сложно!
Преимущество использования гетерогенного стека тоже является сомнительным. Я не буду спорить, что такое тоже возможно, но в реальности редко встречается (Забегая вперед — это должно иметь место быть — но скорее как следствие, нежели преимущество).
Жизненный цикл продукта и жизненный цикл сервиса
Взгляните еще раз на диаграмму выше. Я не случайно отметил уменьшающийся жизненный цикл отдельной версии бизнеса — в современных условиях именно ускорение перехода бизнеса между версиями является определяющим для его успеха. Успешность продукта определяется скоростью проверки бизнес-гипотез в нем. И вот здесь на мой взгляд и закопано ключевое преимущество микросервисной архитектуры. Но пойдем по порядку.
Перейдем на следующую ступень эволюции информационных систем — на сервис-ориентированную архитектуру SOA. Итак, в какой-то определенный момент мы выделили в своем продукте долгоживущие сервисы — долгоживующие в том смысле, что при переходе между версиями продукта есть шансы что жизненный цикл сервиса будет дольше, чем жизненный цикл очередной версии продукта. Логично было бы не изменять их вообще — нам важна именно скорость перехода к следующей версии. Но увы, мы вынуждены вносить постоянные изменения в сервисы — и здесь у нас все годится, и практики DevOps, и контейнеризация, и прочее — все что в голову придет. Но это все еще не микросервисы!
Микросервисы как средство борьбы со сложностью… управления конфигурацией
И вот тут мы можем наконец-то перейти к определяющей роли микросервисов — это подход, упрощающий управление конфигурацией продукта. Детальнее говоря, функция каждого микросервиса описывает именно бизнес-функцию внутри продукта согласно доменной модели — а это уже вещи, которые живут не в короткоживущей версии, а в долгоживущей бизнес-возможности. И переход к следующей версии продукта происходит буквальным образом незаметно — вы изменяете/добавляете один микросервис, а возможно и просто схему их взаимодействия и внезапно оказываетесь уже в будущем, оставляя за бортом плачущих конкурентов, продолжающих прыгать между версиями своих монолитов. Теперь представьте себе, что имеется достаточно большой объем микросервисов с заранее определенными интерфейсами и бизнес-возможностями. И вы приходите и строите структуру вашего продукта из готовых микросервисов — просто рисуя диаграмму например. Поздравляю — у вас появилась платформа — и теперь вы можете себе бизнес накликать. Мечты, мечты.
Микросервисы для начинающих
Оглядываясь примерно на пять лет назад в прошлое, можно заметить, насколько сильно с тех пор изменилось отношение к архитектуре микросервисов. Поначалу они были чрезвычайно популярны. После успеха Netflix, Amazon и Gilt.com разработчики решили, что де-факто разработка микросервисов не отличается от разработки приложений. Теперь же все поняли, что микросервисы представляют из себя новый архитектурный стиль, который эффективен для решения определенных задач, имеет свои плюсы и минусы.
Чтобы понять, что такое микросервисы и в каких случаях их следует использовать, мы обратились к Джейме Буэльта (Jaime Buelta), автору книги «Hands-On Docker for Microservices with Python». Он рассказал о преимуществах этой архитектуры, а также поделился рекомендациями для разработчиков, планирующих перейти на нее с монолитов.
Преимущества и риски
Традиционное монолитное приложение объединяет все свои возможности в едином связанном модуле. В случае микросервисов все наоборот. Приложение делится на более мелкие автономные службы, которые можно независимо развертывать, обновлять и заменять. Каждый микросервис создается для одной бизнес-цели и может взаимодействовать с другими микросервисами с помощью простых механизмов.
Буэльта объясняет: «Микросервисная архитектура — это способ структурирования системы, при которой несколько независимых сервисов общаются друг с другом определенным образом (обычно это происходит с помощью web-сервисов RESTful). Ключевая особенность состоит в том, что каждый микросервис способен обновляться и развертываться независимо от остальных».
Архитектура микросервисов определяет не только то, как вы создаете свое приложение, но и то, как организована ваша команда.
«Одна независимая команда может полностью отвечать за микросервис. Это позволяет организациям расти, не сталкивая разработчиков друг с другом», — объясняет Буэльта.
Одно из основных преимуществ микросервисов заключается в том, что они позволяют внедрять нововведения без особого влияния на систему в целом. С помощью микросервисов вы можете выполнять горизонтальное масштабирование, иметь четкие границы модулей, использовать разнообразные технологии и вести параллельную разработку.
На вопрос о рисках, связанных с микросервисами, Буэльта ответил: «Главная сложность при внедрении архитектуры (особенно при переходе с монолита) заключается в создании дизайна, в котором сервисы действительно будут независимыми. Если этого не удастся добиться, то межсервисные связи станут сложнее, что приведет к дополнительным расходам. Микросервисам нужны профессионалы, которые сформируют направления развития в долгосрочной перспективе. Я рекомендую организациям, которые хотят перейти на такую архитектуру, назначить кого-то ответственным за «общую картину». На микросервисы нужно смотреть более широко», — считает Джейме.
Переход от монолита к микросервисам
Мартин Фаулер, известный автор и консультант по программному обеспечению, советует придерживаться принципа «сначала — монолит». Это связано с тем, что использовать микросервисную архитектуру с самого начала разработки рискованно, поскольку в большинстве случаев она подходит только для сложных систем и больших команд разработчиков.
«Основной критерий, который должен побуждать вас к переходу на новую архитектуру — это численность вашей команды. Небольшим группам не стоит этого делать. В подобных условиях разработчики и так понимают все, что происходит с приложением, и всегда могут задать уточняющий вопрос коллеге. Монолит отлично работает в этих ситуациях, и поэтому практически каждая система начинается с него», — считает Джейме. Это подтверждает «правило двух пицц» Amazon, согласно которому команду, ответственную за один микросервис, можно прокормить двумя пиццами — иначе она слишком большая.
«По мере роста компании и увеличения команд разработчиков может потребоваться лучшая координация. Программисты начинают часто мешать друг другу. Понять цель конкретного фрагмента кода становится сложнее. В таких случаях переход на микросервисы имеет смысл — это поможет разделить обязанности и внести ясность в общую картину системы. Каждая команда может ставить свои собственные цели и работать в основном самостоятельно, выдавая понятный внешний интерфейс. Однако, чтобы такой переход имел смысл, разработчиков должно быть много», — добавляет Буэльта.
Рекомендации по переходу на микросервисы
Отвечая на вопрос о том, какие практические рекомендации могут использовать разработчики при переходе на микросервисы, Буэльта заявил: «Ключом к успешной архитектуре микросервисов является то, что каждый сервис должен быть максимально независим».
Возникает вопрос: «Как вы можете сделать сервисы независимыми?». Лучший способ обнаружить взаимозависимость системы — подумать о новых возможностях: «Если вы хотите добавить новую функцию, можно ли будет ее реализовать, изменив лишь один сервис? Какие виды функций потребуют координации нескольких микросервисов? Они будут использоваться часто или редко? Невозможно создать идеальный дизайн, но, по крайней мере, с его помощью можно принимать правильные и обоснованные решения», — объясняет Буэльта.
Джейме советует переходить на архитектуру правильно, чтобы потом все не переделывать. «После завершения перехода изменить границы микросервисов будет тяжелее. Стоит уделить побольше времени на начальную фазу проекта», — добавляет он.
Переход с одного шаблона проектирования на другой — это серьезный шаг. Мы спросили, с какими проблемами Джейме и его команда сталкивались во время миграции на микросервисы, на что он ответил:
«На деле основные трудности связаны с людьми. Эти проблемы, как правило, недооценивают, но переход на микросервисы фактически меняет способ работы разработчиков. Задача не из легких!». Он добавляет: «Я лично сталкивался с подобными проблемами. Например, мне приходилось обучать и давать советы разработчикам. Особенно важно объяснять, почему необходимы те или иные изменения. Это помогает людям понять причины внедрения всех нововведений, которые могут прийтись им не по душе.
При переходе от монолитной архитектуры много сложностей может возникнуть при развертывании приложения, которое раньше выпускалось в виде единого модуля. Оно требует более тщательного анализа для обеспечения обратной совместимости и минимизации рисков. Справиться с этой задачей порой очень нелегко».
Причины выбора Docker, Kubernetes и Python в качестве технологического стека
Мы спросили Буэльту, какие технологии он предпочитает для внедрения микросервисов. Касательно выбора языка ответ оказался прост: «Python для меня — лучший вариант. Это мой любимый язык программирования. Этот язык хорошо подходит для микросервисов. Его удобно читать и легко применять. Кроме того, Python обладает широким функционалом для веб-разработки и динамичной экосистемой сторонних модулей для любых потребностей. К этим потребностям относится подключение к другим системам, например, к базам данных, внешним API и т.д.».
Docker часто рекламируется как один из самых важных инструментов для микросервисов. Буэльта объяснил, почему:
«Docker позволяет инкапсулировать и копировать приложение в удобных стандартизированных пакетах. Это уменьшает неопределенность и сложность среды. Также это значительно упрощает переход от разработки к производству приложений. Вдобавок ко всему, уменьшается время использования оборудования. Вы можете разместить несколько контейнеров в разных средах (даже в разных операционных системах) в одной физической коробке или виртуальной машине».
«Kubernetes позволяет развертывать несколько контейнеров Docker, работающих скоординированным образом. Это заставляет разработчиков мыслить кластеризованно, помня о производственной среде. Также это позволяет определять кластер с помощью кода, чтобы новые развертывания или изменения конфигурации определялись в файлах. Все это делает возможными методы наподобие GitOps (о них я писал в своей книге), при этом сохраняя полную конфигурацию в системе управления версиями. Каждое изменение вносится определенным и обратимым образом, поскольку оно представляет из себя регулярное git-слияние. Благодаря этому можно очень легко восстанавливать или дублировать инфраструктуру».
«Придется потратить время, чтобы обучиться Docker и Kubernetes, но это того стоит. Оба инструмента очень мощные. К тому же, они поощряют вас работать таким образом, чтобы избежать проблем при производстве», — считает Буэльта.
Многоязычные микросервисы
При разработке микросервисов можно использовать разнообразные технологии, поскольку за каждый из них в идеале отвечает независимая команда. Буэльта поделился своим мнением о многоязычных микросервисах: «Многоязычные микросервисы — это здорово! Это одно из основных преимуществ архитектуры. Типичный пример многоязычного микросервиса — перенос устаревшего кода, написанного на одном языке, на новый. Микросервис может заменить собой любой другой, который предоставляет тот же внешний интерфейс. При этом его код будет совершенно иным. К примеру, я переходил со старых приложений PHP, заменяя их аналогами, написанными на Python». Джейме добавил: «Работа с двумя или более платформами одновременно поможет лучше разобраться в них и понимать, в каких случаях их лучше использовать».
Хотя возможность использовать многоязычные микросервисы — это большое преимущество архитектуры, оно также может увеличить операционные издержки. Буэльта советует: «Надо знать меру. Нет смысла каждый раз использовать новый инструмент и лишать команды возможности делиться знаниями друг с другом. Конкретные цифры могут зависеть от размера компании, но, как правило, нет смысла использовать больше двух или трех разных языков без серьезной на то причины. Не надо раздувать стек технологий — тогда разработчики смогут делиться знаниями и начнут использовать имеющиеся инструменты наиболее эффективно».
Об авторе
Джейме Буэльта (Jaime Buelta) — профессиональный программист и Python-разработчик, который за свою многолетнюю карьеру познакомился со множеством различных технологий. Он разрабатывал программное обеспечение для различных областей и отраслей, включая аэрокосмическую, сетевую и коммуникационную, а также промышленные системы SCADA, онлайн-сервисы для видеоигр и финансовые сервисы.
В составе различных компаний он имел дело с такими функциональными областями, как маркетинг, менеджмент, продажи и геймдизайн. Джейме является ярым сторонником автоматизации и хочет, чтобы всю тяжелую работу выполняли компьютеры, позволив людям сосредоточиться на более важных вещах. В настоящее время он живет в Дублине и регулярно выступает на конференциях PyCon в Ирландии.
Что такое микросервисы: особенности архитектуры, примеры использования, инструменты
Авторизуйтесь
Что такое микросервисы: особенности архитектуры, примеры использования, инструменты
Архитектурный стиль микросервисов — это подход, при котором система строится как набор независимых и слабосвязанных сервисов, которые можно создавать, используя различные языки программирования и технологии хранения данных. Концепция микросервисов позволяет поддерживать слабую связанность сервисов в процессе работы над системой, что определяют паттерны Low Coupling и High Cohesion.
Подробности — в видео и текстовой расшифровке ниже.
Монолит vs микросервисы
При монолитной архитектуре система обычно состоит из 3 блоков: пользовательский интерфейс, хранилище данных и серверная часть. Серверная часть обрабатывает запросы, выполняет бизнес-логику, работает с БД, заполняет HTML-страницы. Любое изменение в системе приводит к обновлению версии серверной части приложения.
В случае с микросервисной архитектурой обновляется только изменённый сервис. Если изменения затрагивают интерфейс сервиса, это потребует координации всех его клиентов. Цель хорошей микросервисной архитектуры — максимально уменьшить необходимость координации сервисов.
Что такое контракт
Контракт — это формализация возможностей взаимодействия с микросервисом. В случае с REST API эндпоинты сервиса и схема данных являются контрактом. Первоначальная разработка архитектуры — это декомпозиция системы на слабосвязанные сервисы, создание интерфейсов и связей между ними, поддержка целостности данных без потери производительности. Помочь с решением данной задачи могут шаблоны Tolerant Reader и Consumer-Driven Contracts.
Микросервисная команда
Команда не должна включать в себя больше людей, чем можно насытить двумя пиццами. Такое правило использовала компания Amazon при распиливания своего монолита в 2002 году. Вполне допустимо и правило developer per service, то есть один разработчик на один микросервис.
3–5 декабря, Онлайн, Беcплатно
Когда большая система разбивается, часто происходит так, что образовываются команды на базе технологий. При такой ситуации команды размещают логику на тех слоях системы, к которым имеют доступ. Закон Конвея в действии:
«Любая организация, которая проектирует какую-то систему (в широком смысле) получит дизайн, чья структура копирует структуру команд в этой организации»
Микросервисный подход предполагает разбиение системы на сервисы по бизнес-требованиям. Сервисы включают в себя полный набор технологий: UI, storage, backend. Это приводит к созданию кросс-функциональных команд, имеющих достаточно компетенций для реализации всех необходимых сервисов, покрывающих 100% бизнес-функционала. Команды должны отвечать за все аспекты ПО, которое они разрабатывают, включая поддержку его в режиме 24/7. В таком случае возможность проснуться от звонка в 3 часа ночи — это очень сильный стимул писать хороший код.
Насколько большим должен быть микросервис
Логика работы сервиса должна полностью уместиться в голове одного разработчика, независимо от количества кода и людей. Проектируя систему, мы имеем выбор, как разработать каждый микросервис. Например:
Архитектура микросервиса даёт полную свободу в выборе технологий и инструменария.
Инструментарий для реализации микросервисов
В процессе реализации микросервисной архитектуры существенным упрощением будет использование систем CI/CD, системы оркестрации, Service Discovering, мониторинга и сбора логов.
Необходимо быть уверенным в том, что приложение работает правильно. Для этого запускаются автоматические тесты, при этом система разворачивается в отдельной среде (Automated Deployment).
Цепочка синхронных вызовов микросервисов приведет к ожиданию ответов от всех сервисов по очереди. Поэтому используйте правило «Один синхронный вызов на один запрос пользователя», как это сделали в The Guardian, либо полностью асинхронный API, как в Netflix. Один из способов сделать асинхронный API — использовать систему обработки очередей, например, RabbitMQ, Apache Kafka или ActiveMQ.
Микросервисы и микросервисная архитектура
Узнайте о плюсах и минусах микросервисов и об их отличиях от монолитных решений.
Что такое микросервисы?
Термин «микрослужбы» используется для описания традиционной схемы «разделения интересов» в рамках распределенного сетевого проекта. Идея микрослужб берет свое начало в зрелой философии системы UNIX, основой которой являются «маленькие, но острые инструменты». Обе эти концепции основаны на еще одной фундаментальной модели информатики, называемой композицией, согласно которой сложные системы представляют собой совокупность составных сущностей более низкого уровня.
Статьи о микросервисах
Три секрета разработки микросервисов
Первое правило создания микросервисов: не стоит браться за проекты «с нуля». Пока вы создаете продукт, бизнес-требования меняются.
Что такое контейнеры?
Узнайте, что такое контейнеры, как они работают и какие контейнерные платформы доступны.
Учебное руководство по непрерывному развертыванию
Из этого учебного руководства вы узнаете, как начать использовать непрерывное развертывание с Bitbucket Pipelines.
Композиция используется на всех уровнях проекта по разработке ПО. На самом низком уровне, т. е. уровне модулей, отдельные независимые функции кода взаимодействуют друг с другом через общий интерфейс и создают таким образом коллекции, или библиотеки, кода. На уровне оболочки операционной системы можно сочетать команды оболочки и таким образом создавать конвейеры, обладающие функциональностью более высокого уровня. Микрослужбы — это уровень композиции, возникающей между веб-службами. Микрослужба — это веб-служба, отвечающая за один элемент логики в некой предметной области. Микрослужбы взаимодействуют друг с другом через простые сетевые протоколы, например REST, и совместно выполняют некоторые действия, но при этом ни одна из них не имеет сведений о внутреннем устройстве других служб. Такое согласованное взаимодействие между микрослужбами называется архитектурой микрослужб.
Архитектура микрослужб (MSA) позволяет командам, разрабатывающим программное обеспечение, оптимизировать рабочие процессы выпуска релизов. В число компаний, которые открыто выбирают этот метод разработки программного обеспечения, входят Amazon, Netflix и eBay. Стремясь внести свой вклад в работу сообщества, они поделились своим опытом и инструментами разработки, чтобы помочь другим внедрить данный метод.
Основной принцип микросервисной архитектуры — создание приложения путем разделения компонентов его бизнес-логики на небольшие сервисы, которые можно развертывать и использовать независимо друг от друга.
При таком подходе разработчики могут разделиться на небольшие команды и работать над разными службами, использовать разные стеки технологий и независимо выполнять развертывание. Такое разделение интересов и независимая эксплуатация позволяют использовать оптимизированные agile-подходы к разработке ПО, например непрерывную поставку и интеграцию.
Ориентированная на службы архитектура (SOA) или микрослужбы?
Ориентированная на службы архитектура (SOA) и микрослужбы — это две разновидности архитектуры более высокого порядка (архитектуры веб-служб). Микрослужбы можно назвать облегченной версией SOA. Разница между двумя типами архитектур заключается в формальной классификации типов служб. SOA включает четыре базовых типа служб: бизнес-службы, корпоративные службы, службы приложений и инфраструктурные службы. В соответствии с типом службы определяется ее ответственность, связанная с конкретной областью. В свою очередь, архитектура микрослужб включает лишь два типа служб: функциональные и инфраструктурные.
В обеих архитектурах используется один и тот же набор стандартов, действующих на разных уровнях компании. Модель MSA обязана своим существованием успеху модели SOA. Следовательно, модель MSA является подмножеством модели SOA. В ней основное внимание уделяется автономному выполнению каждого сервиса.
Монолитное приложение или микрослужбы?
Микрослужбы разделяют крупные задачи, характерные для конкретного бизнеса, на несколько независимых баз кода. Монолитная архитектура приложений является противоположностью микрослужб. Монолит — это единая база кода, в которой объединены все бизнес-задачи. Использовать монолиты удобно на начальных этапах проектов для сокращения умственных усилий по управлению кодом и облегчения развертывания. Это позволяет сразу выпускать все, что есть в монолитном приложении.
Многие проекты начинаются как монолитные, а затем, по мере развития, переходят к архитектуре микрослужб. По мере добавления в монолитный проект новых возможностей рано или поздно возникают сложности при работе нескольких разработчиков с единой базой кода. Учащаются конфликты в коде и увеличивается риск того, что при обновлении одной возможности появятся баги в другой, несвязанной возможности. Если такие нежелательные ситуации возникают, возможно, настало время обсудить переход на микрослужбы.
Как работает микросервисная архитектура
Давайте в качестве примера рассмотрим гипотетический проект разработки программного обеспечения для электронной коммерции. В этой сфере существуют некоторые четко определенные области. Сайты электронной коммерции имеют систему аутентификации для входа пользователей в систему и выхода из нее. Предусмотрена также корзина для сохранения списка товаров, заинтересовавших пользователя. Биллинговая система позволяет пользователям оплачивать свои покупки.
В архитектуре микрослужб указанным областям соответствовали бы независимые службы. В качестве конкретного примера можно привести биллинговую систему. При условии достаточного большого числа сотрудников в компании может быть сформирована «биллинговая команда», которая отвечает за разработку и контроль качества этой биллинговой микрослужбы. Для биллинговой микрослужбы составлялись бы графики релизов и планы развертывания. Для биллинговой службы также был бы создан задокументированный API с поддержкой разных версий, чтобы службы могли подключаться к ней и использовать ее функциональные возможности.
Плюсы и минусы микрослужб
+ Горизонтальное масштабирование
Микрослужбы являются изначально распределенными, их развертывание можно выполнять в кластерах. Это позволяет осуществлять динамическое горизонтальное масштабирование за пределы границ служб. Когда микрослужба достигает предельной нагрузки, можно быстро выполнить развертывание новых экземпляров данной службы в сопутствующем кластере.
+ Независимая работа команд
Команды, ответственные за микросервисы, могут работать независимо от других функциональных команд в организации. Это обеспечивает условия для ускоренной реализации и поставки новых функциональных возможностей.
+ Более пристальное внимание к качеству
При разделении бизнес-задач по независимым микросервисам команда, владеющая каждым сервисом, будет ориентирована на результат высшего качества.
— Экспоненциально растущие расходы на инфраструктуру
Каждый новый микросервис, развертываемый организацией в рабочей среде, предполагает отдельные расходы на комплект тестов, инструкции по развертыванию, инфраструктуру хостинга, инструменты мониторинга и т. д.
— Дополнительные организационные расходы
Для координации обновлений и интерфейсов необходим дополнительный уровень коммуникации и совместной работы между командами, разрабатывающими архитектуру микросервисов.
— Сложность среды разработки
Разделение проекта на множество микросервисов создает дополнительную проблему воспроизведения распределенной архитектуры во время настройки локальной разработки.
Будущее микрослужб
Контейнеризация и развертывание контейнеров — это новая модель распределенной инфраструктуры. Чтобы упаковать службу в полноценный контейнер, для которого развертывание и отключение выполняются очень быстро, применяются такие инструменты, как Docker и Kubernetes. Эти новые инфраструктурные инструменты дополняют архитектуру микрослужб. Микрослужбы можно помещать в контейнеры и легко развертывать, а также управлять ими с помощью системы управления контейнерами.
К процессу внедрения микросервисов нужно относиться скорее как к долгому путешествию, а не как к ближайшей цели команды. Начините с малого, чтобы понять технические требования распределенной системы, каким образом можно элегантно исправлять ошибки и как масштабировать отдельные компоненты. После этого, по мере накопления опыта и знаний, вы сможете постепенно использовать все больше и больше сервисов.
Микросервисная архитектура — методика довольно новая, но она представляет собой перспективный способ разработки приложений, на который обязательно стоит обратить внимание. При этом, однако, следует помнить, что она может (пока) не подходить вашей команде.
Клэр — опытный специалист по маркетингу, которая за время своей карьеры в Atlassian успела поработать в различных направлениях, включая growth-маркетинг, performance-маркетинг и маркетинг продуктов. В настоящее время она отвечает за стратегию бренда компании, контент-стратегию и стратегию вывода продукции на рынок для продуктов Confluence Cloud. На досуге Клэр любит кататься на волнах, заниматься бегом и пробовать что-нибудь новенькое в еще неизведанных ресторанах Сан-Франциско и других городах по всему миру.