Service Mesh — подход, который еще вчера был на вершине хайпа, а сегодня становится стандартной технологией для Backend. В этой части посмотрим, как теория накладывается на практику и на что обратить внимание, выбирая Service Mesh для своих задач.

Меня зовут Максим Чудновский, я занимаюсь развитием интеграционной платформы Platform V Synapse в СберТехе. В платформе реализован RPC и Service Mesh, которым я и занимаюсь. В этой статье продолжу рассказывать о технологии и поделюсь соображением о том, как выбрать конкретное решение для ваших задач.

Уже на следующей неделе Сбер проведёт One Day Offer для специалистов двух профилей.

12 марта мы приглашаем DevOps‑инженеров уровня Middle/Senior с опытом от 1,5 лет, работающих с инструментами k8s/openshift, ansible, kafka, Atlassian, TeamCity, Jenkins, nexus, gitlab, sonarqube.

13 марта — QA-инженеров с опытом автоматизации и/или нагрузочного тестирования от 1,5 лет.

Оба мероприятия пройдут онлайн и начнутся в 11:00 по Москве.

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

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

Программа воркшопов:

✔️ 7 апреля разберём функционал Functions и DataSpace на примере приложения для виртуального ассистента Салют;
✔️ 14 апреля рассмотрим DataSpace как полноценное BaaS-решение.

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

Заявку на участие можно отправить здесь.

Знакомство с командами и руководителями, технические интервью и итоговая обратная связь — всё проходит в онлайне. Регистрация на One Day Offer уже началась.

21 мая приглашаем Java-разработчиков.

22 мая — DevOps-инженеров.

В рамках сотрудничества со СберТехом IТ-компания Digital Design предложит клиентам варианты замещения решений иностранных вендоров продуктами цифровой облачной платформы от Сбера Platform V, а также технологии платформы в рамках заказной разработки.

1. Содержимое кэшей
2. Журнал упреждающей записи (Write Ahead Log, далее просто WAL)

• Snapshots (Резервное копирование)
• Трэйсинг
• Новые возможности тонких клиентов
• Режим работы кластера «Только чтение»
• Запуск пользовательского кода в «песочнице»
• Прозрачное шифрование данных: ротация мастер ключа
• Инструменты для прерывания пользовательских задач и запросов
• Кэширование на стороне платформы (.NET)
• Подключение клиентских узлов к серверным через NAT

Год назад, в сентябре 2020 года команда SberDevices выпустила семейство виртуальных ассистентов Салют. В семействе три персонажа — Сбер, Афина и Джой. Они доступны на умных устройствах Sber, устройствах под управлением Салют ТВ и в мобильных приложениях СберБанк Онлайн и Сбер Салют.

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

Иван Смирнов, руководитель NLP-Platform и SmartMarket рассказывает, как мы собрали вместе инструменты и технологии Сбера и к чему удалось прийти за год.

После такого несколько кликбейтного заголовка сразу раскроем карты: IT просто однажды «осмелились» сказать «нет» потоку сверхсрочных задач от бизнеса, и разработка стала успевать входить в график. На этом можно было бы и закончить, но тогда лайфхак остался бы лишь теорией, которую вы наверняка не раз встречали в книгах на тему «умей говорить “нет”». Однако реально применять этот совет в разработке даже сложнее, чем в жизни. Да и вырванный из контекста этот совет — «так себе».  

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

Как и обещали в первой части кейса, рассказываем о том, какой стек использовала IT-команда Сбера при работе над проектом с большими данными. Для тех, кто её не читал: благодаря этому проекту разработчики научились эффективно взаимодействовать с «бизнесом», пройдя через кризисные точки. Но в этой части речь пойдёт не об оптимизации работы IT-отдела, а о технической изнанке проекта.

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

Подумайте о проблеме, которую вы можете решить с помощью Big Data, и задайте себе вопрос: «Что будет, если мы захотим увеличить масштаб в 100 000 раз?» Ответ прост: producer продолжит закачивать сообщения, в итоге на диске закончится место для их хранения.

Log Compaction (сжатие журнала) – стратегия, с помощью которой вы можете решить эту проблему в Apache Kafka – программном брокере сообщений, используемом для ведения журналов событий, чтения данных в непрерывном режиме с периферийных устройств, сбора информации о поведении посетителей на сайте. Большинство систем, использующих Kafka, являются распределёнными и обрабатывают большие объёмы сообщений в реальном времени.

Здесь я постараюсь описать некоторые нюансы работы compacted topic. Если вы хотите разобраться с механизмом log compaction, эта статья для вас.

Привет! Меня зовут Татьяна Рыжкова. Я руководитель направления в блоке Сбера «Управление благосостоянием», лидер компетенции «Тестирование», участник команды DevOps и релизной мастер-команды. Возможно, сейчас было сложно. Скажу проще: я занимаюсь всем, что связано с разработкой, тестированием и запуском новых страховых продуктов и онлайн-сервисов, а также с доработкой старых.

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

В настоящий момент наш продукт включает в себя следующие сервисы:

Predictive Colocator – размещает связанные между собой приложения на одинаковых нодах, уменьшает задержку при передаче данных;

Discovery R&L – находит начальные лимиты (limit) и реквесты (request) для любых приложений с целью их гарантированного старта при применяемой конфигурации;

Anomaly Detection – выявляет аномалии в работе элементов облачной инфраструктуры;

Predictive Autoscaler – определяет будущую нагрузку на приложения, заранее поднимает или опускает необходимое количество подов.

В рамках этой статьи кратко рассмотрим некоторые аспекты работы двух сервисов: Predictive Autoscaler и Anomaly Detection.

Всем привет! Многие IT-компании, да и мы в Сбере пытаемся принять на работу лучших сотрудников. Часто наши HR-специалисты отмечают, что у кандидата возникают дополнительные вопросы в части задач и технического стека платформенной команды в SBI (Sberbank International). Так вот, данная статья раскрывает немного деталей о SBI Platform Team, чтобы у кандидата сразу было представление о том, над чем мы работаем.

Я Артём Соковец, руковожу платформенной командой в Sberbank International. До этого был TeachLead&ProductOwner продукта Platform V Studio. Прошёл путь от специалиста по автоматизации тестирования до лидера SDETs, а в 2018 году сменил профиль на разработку и двигаюсь в этом направлении дальше с заплывом в смежные области — DevOps и MobileDev.  

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

1.      Адаптация Platform V под дочерние банки в других странах.

2.      Разработка новых бизнес-приложений с использованием Platform V.

3.      Разработка интеграционного слоя с использованием Synapse.

Кому интересно узнать детали, прошу под <cut>.

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

Меня зовут Виктор Бирюков, я главный руководитель IT-направления в СберТехе — компании, которая создаёт основные технологические решения для Сбера. В статье я расскажу, как с помощью PaaS-инструментов упростить и ускорить разработку микросервисов так, чтобы в конечном счёте на создание полноценного продукта у вас уходило не больше 15 минут.

У этой статьи будет продолжение. В этой части мы познакомимся с сервисом Platform V DataSpace и напишем frontend-приложение, используя DataSpace как сервис (Backend-as-a-Service3). Во второй статье разберём Platform V Functions, напишем backend-приложение как облачную функцию и разместим наше frontend-приложение также как функцию (Function-as-a-Services4).

Привет, Хабр! Продолжаем рассказывать, как быстро и просто создавать микросервисные приложения. В прошлой статье мы написали frontend с помощью Platform V DataSpace. В примере был использован TypeScript, но, как мы и говорили, это необязательное требование.

Теперь рассмотрим, как разрабатывать backend-приложения на языке Java с помощью сервиса Platform V Functions и инструмента DataSpace SDK.

Platform V Functions — это FaaS-решение, позволяющее загружать исходный код сервиса в виде функции в OpenShift/k8s без создания docker-образов и настройки окружения.

Но основное внимание в статье уделим даже не Functions, а DataSpace SDK. Это инструмент для удобного взаимодействия с DataSpace по протоколу JSON-RPC. По ходу статьи мы рассмотрим основные фичи, которые DataSpace SDK предоставляет Java-разработчику.

Привет, Хабр!

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

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

Привет, Хабр! Меня зовут Сергей Петровский, я руководитель IT-направления в СберТехе — компании, которая строит цифровой фундамент Сбера.

Мы создаём Platfrom V — облачную платформу с готовой средой разработки, компонентами и инструментами для быстрого создания бизнес-приложений. В этой статье расскажу об одном из сервисов Platform V, который решает проблему подготовки тестовых данных при тестировании сложных интеграционных сервисов.

SyntWork, о котором пойдёт речь, входит в семейство инструментов Platfrom V Works для agile-разработки. Эта статья — первая в цикле материалов о Works. В следующих статьях расскажем про другие инструменты: в Works много сервисов для agile-разработки, и каждый достоин отдельного материала.

Поехали!

Привет, Хабр!

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

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