Презентация о сетях для начинающих, рассказывающая об основных понятиях и протоколах.
Presentation about Networks for beginners, describing main terms and protocols.
Автор: Андрей Минкин / Andrew Minkin
Мастер-класс "Микросервисы: удобно, надежно, серебрянопульно" / Евгений Павло...Ontico
В процессе рефакторинга архитектуры мы начали переделывать часть системы на микросервисы, и вышло настолько клево, что мы просто обязаны этим поделиться.
Микросервисы.
Зачем они вообще:
- В простых сервисах легче разбираться и локализовывать проблемы.
- В микросервисной архитектуре проще добиваться отказоустойчивости.
- Хотим выбирать лучший инструмент для каждой задачи. Получаем зоопарк технологий, которые в монолитные сервисы интегрировать сложнее.
- Независимое обновление компонентов.
- Тестирование частей системы.
Как:
- Docker-образы как основа.
- Rancher как система деплоя и оркестрации Docker-контейнеров. High availability.
- Простота сервиса - ключевой момент.
== Критерий: Разработчик должен иметь возможность быстро понять и переписать сервис при необходимости.
== Забавное следствие: такие сервисы пишутся не на века, а под текущие требования. Получается быстро и agile-но, ведь изменения легко сможет внести любой разработчик.
== PEP8.
- HTTP API и поддержка Swagger. Резко упрощают тестирование.
- RabbitMQ pipelines как отказоустойчивая система взаимодействий между сервисами:
== DLX помогает разбираться со врЕменными проблемами.
== HTTP RPC.
- Метрики, метрики и ещё раз метрики.
== service status API.
== Graphite, Zabbix. Может, к ноябрю еще OKmeter успеем попробовать.
- Структурированые логи: JSON stdout => Fluentd => ELK => счастье. Локализация багов и пр. Об этом подробнее в отдельной презентации.
- В любой непонятной ситуации...
== Сервис должен падать, а не зависать.
== Healthchecks.
- Стабильность архитектуры.
== Осознанная деградация! Любой сервис должен быть готов к падению другого. При этом в первом должно быть явно описано, как будет при этом ограничиваться его функциональность. Это ведет к отсутствию эффекта домино, когда один малозначащий сервис, упав, утягивает за собой всю систему.
- Документация.
== Степень критичности каждого сервиса.
== Краткий обзор функциональности (вспоминаем: сервисы _простые_).
== Конфиги.
== drawback: описание архитектуры обязано быть актуальным и полным, иначе беда.
Трудности: Допишу через пару дней.
Сравнение решений по балансировке высоконагруженных систем / Евгений Пивень (...Ontico
+ Функционал разных решений для балансировки.
+ Виды балансировщиков (DNS, hardware, software, облачные решения).
+ Поведение при скачках трафика и возможности скалирования сервиса.
+ Специфика трафика RTB в контексте балансировки.
+ Проблемы, которые возникали у нас, и как мы их решали.
Мастер-класс "Микросервисы: удобно, надежно, серебрянопульно" / Евгений Павло...Ontico
В процессе рефакторинга архитектуры мы начали переделывать часть системы на микросервисы, и вышло настолько клево, что мы просто обязаны этим поделиться.
Микросервисы.
Зачем они вообще:
- В простых сервисах легче разбираться и локализовывать проблемы.
- В микросервисной архитектуре проще добиваться отказоустойчивости.
- Хотим выбирать лучший инструмент для каждой задачи. Получаем зоопарк технологий, которые в монолитные сервисы интегрировать сложнее.
- Независимое обновление компонентов.
- Тестирование частей системы.
Как:
- Docker-образы как основа.
- Rancher как система деплоя и оркестрации Docker-контейнеров. High availability.
- Простота сервиса - ключевой момент.
== Критерий: Разработчик должен иметь возможность быстро понять и переписать сервис при необходимости.
== Забавное следствие: такие сервисы пишутся не на века, а под текущие требования. Получается быстро и agile-но, ведь изменения легко сможет внести любой разработчик.
== PEP8.
- HTTP API и поддержка Swagger. Резко упрощают тестирование.
- RabbitMQ pipelines как отказоустойчивая система взаимодействий между сервисами:
== DLX помогает разбираться со врЕменными проблемами.
== HTTP RPC.
- Метрики, метрики и ещё раз метрики.
== service status API.
== Graphite, Zabbix. Может, к ноябрю еще OKmeter успеем попробовать.
- Структурированые логи: JSON stdout => Fluentd => ELK => счастье. Локализация багов и пр. Об этом подробнее в отдельной презентации.
- В любой непонятной ситуации...
== Сервис должен падать, а не зависать.
== Healthchecks.
- Стабильность архитектуры.
== Осознанная деградация! Любой сервис должен быть готов к падению другого. При этом в первом должно быть явно описано, как будет при этом ограничиваться его функциональность. Это ведет к отсутствию эффекта домино, когда один малозначащий сервис, упав, утягивает за собой всю систему.
- Документация.
== Степень критичности каждого сервиса.
== Краткий обзор функциональности (вспоминаем: сервисы _простые_).
== Конфиги.
== drawback: описание архитектуры обязано быть актуальным и полным, иначе беда.
Трудности: Допишу через пару дней.
Сравнение решений по балансировке высоконагруженных систем / Евгений Пивень (...Ontico
+ Функционал разных решений для балансировки.
+ Виды балансировщиков (DNS, hardware, software, облачные решения).
+ Поведение при скачках трафика и возможности скалирования сервиса.
+ Специфика трафика RTB в контексте балансировки.
+ Проблемы, которые возникали у нас, и как мы их решали.
http://techtalks.nsu.ru
24 сентября 2013. Архитектура Skype (Александр Комиссаров, Microsoft (Москва))
Лекция прочитана в рамках проекта Tech Talks @NSU – серии открытых лекций о разработке ПО и карьере в IT, проводимых в Новосибирском государственном университете.
Подробности: http://techtalks.nsu.ru
Полмиллиона юзеров в онлайне без падений: оптимизация высоконагруженного se...Sergey Xek
Полмиллиона юзеров в онлайне без падений: оптимизация высоконагруженного server-side API десктопного приложения. Сергей Аверин, Badoo.
Доклад рассказывает о реально примененных способах оптимизации производительности API компании Badoo для собственных десктоп-приложений: как специфика «много постоянных соединений/однотипные запросы/большая нагрузка» повлияла на стратегию оптимизации производительности.
Что было сделано:
• Планирование архитектуры изначально (fault-tolerance, адаптивные апдейты и тайм-ауты, отказ от попыток восстановления после ошибок для единичных команд).
• Переехали с redis на handlersocket.
• Rate-limiting запросов к демонам.
• Синхронизация записей.
• Асинхронность.
• Записи при достижении порога изменения параметров.
• Профилирование кода, анализ потребления CPU, времени ответа.
• Статистика, статистика и еще раз статистика.
• Pconnect.
Доклад будет интересен:
• системным архитекторам,
• server-side разработчикам.
Обзор подходов к построению прикладных программных систем на Node.js, анализ и сравнение архитектурных принципов развертывания высоконагруженных прикладных облачных сервисов, масштабирование, тенденции и перспективы в разработке приложений, обзор проблем платформы Node.js и пути их решения.
Путь от монолита на PHP к микросервисам на Scala / Денис Иванов (2GIS)Ontico
В своём проекте мы решали следующие задачи:
+ Скорость разработки задачи;
+ Стоимость поддержки задачи;
+ Возможность распараллеливать вычисления и задачи;
+ Возможность максимально просто масштабировать приложение;
+ CI/CD с минимальными усилиями.
Я расскажу о том, как мы решали эти задачи, на какие грабли мы наступали, что из этого всего получилось, и что делать дальше.
Что получили в итоге:
+ Мощь JVM под капотом Scala;
+ 15 минут от нажатия на кнопку "Merge request" до продакшена в 3 датацентра и 6 серверов с прохождением тестов (юнит + функциональные + интеграционные + нагрузочные);
+ 6 нод с приложениями вместо 18 (по 2 в каждом датацентре для отказоустойчивости) с запасом прочности в 60%;
+ Независимые пофичные релизы без даунтайма всех компонентов приложения;
+ Масштабирование только того функционала и в том количестве, которое необходимо данному сервису.
Работа с геоданными в Go GDGNSK / Work with Geodata in GoMad Devs
Слайды с GDG DevFest Новосибирск про го, геоданные, ненависть к нод.жс и UDP.
Slides from GDG DevFest Novosibirsk about Go, geodata and hatred to Nod.js and UDP.
Автор: Андрей Минкин / Andrew Minkin
Держите одеяло у себя: как общаться с кандидатом и узнавать все, что вам инте...Mad Devs
Маргарита Мысина, рекрутер в Mad Devs поделилась темой «Держите одеяло у себя: как общаться с кандидатом и узнавать все, что вам интересно».
Маргарита начала свою карьеру HR в IT в технологическом стартапе, а пару лет назад присоединилась к команде HR в Mad Devs, в качестве сорсера, а затем рекрутера. За время своей работы в найме Маргарита приобрела огромный опыт, который передаст в своем докладе, рассказывая о том, как общаться с кандидатами и ненавязчиво узнавать всю нужную рекрутеру информацию.
Дружелюбнй онбординг: как с увеличением количества не потерять качество Mad Devs
Клара Абдукова, HR-специалист в Mad Devs презентовала о «Дружелюбном онбординге: как с увеличением количества не потерять качество»
Клара уже несколько лет работает в ИТ и в настоящее время занимает позицию лида онбординга в Mad Devs. Она заонбордила более 100 человек, ее опыт позволил сделать процесс онбординга в компанию не только четким, но и прозрачным. В своем докладе Клара расскажет весь путь выстраивания процесса онбординга и поделилась инсайтами, которые помогут HR-специалистам в создании и проведении этого важного процесса.
More Related Content
Similar to Введение в сети / Introduction to Networks
http://techtalks.nsu.ru
24 сентября 2013. Архитектура Skype (Александр Комиссаров, Microsoft (Москва))
Лекция прочитана в рамках проекта Tech Talks @NSU – серии открытых лекций о разработке ПО и карьере в IT, проводимых в Новосибирском государственном университете.
Подробности: http://techtalks.nsu.ru
Полмиллиона юзеров в онлайне без падений: оптимизация высоконагруженного se...Sergey Xek
Полмиллиона юзеров в онлайне без падений: оптимизация высоконагруженного server-side API десктопного приложения. Сергей Аверин, Badoo.
Доклад рассказывает о реально примененных способах оптимизации производительности API компании Badoo для собственных десктоп-приложений: как специфика «много постоянных соединений/однотипные запросы/большая нагрузка» повлияла на стратегию оптимизации производительности.
Что было сделано:
• Планирование архитектуры изначально (fault-tolerance, адаптивные апдейты и тайм-ауты, отказ от попыток восстановления после ошибок для единичных команд).
• Переехали с redis на handlersocket.
• Rate-limiting запросов к демонам.
• Синхронизация записей.
• Асинхронность.
• Записи при достижении порога изменения параметров.
• Профилирование кода, анализ потребления CPU, времени ответа.
• Статистика, статистика и еще раз статистика.
• Pconnect.
Доклад будет интересен:
• системным архитекторам,
• server-side разработчикам.
Обзор подходов к построению прикладных программных систем на Node.js, анализ и сравнение архитектурных принципов развертывания высоконагруженных прикладных облачных сервисов, масштабирование, тенденции и перспективы в разработке приложений, обзор проблем платформы Node.js и пути их решения.
Путь от монолита на PHP к микросервисам на Scala / Денис Иванов (2GIS)Ontico
В своём проекте мы решали следующие задачи:
+ Скорость разработки задачи;
+ Стоимость поддержки задачи;
+ Возможность распараллеливать вычисления и задачи;
+ Возможность максимально просто масштабировать приложение;
+ CI/CD с минимальными усилиями.
Я расскажу о том, как мы решали эти задачи, на какие грабли мы наступали, что из этого всего получилось, и что делать дальше.
Что получили в итоге:
+ Мощь JVM под капотом Scala;
+ 15 минут от нажатия на кнопку "Merge request" до продакшена в 3 датацентра и 6 серверов с прохождением тестов (юнит + функциональные + интеграционные + нагрузочные);
+ 6 нод с приложениями вместо 18 (по 2 в каждом датацентре для отказоустойчивости) с запасом прочности в 60%;
+ Независимые пофичные релизы без даунтайма всех компонентов приложения;
+ Масштабирование только того функционала и в том количестве, которое необходимо данному сервису.
Работа с геоданными в Go GDGNSK / Work with Geodata in GoMad Devs
Слайды с GDG DevFest Новосибирск про го, геоданные, ненависть к нод.жс и UDP.
Slides from GDG DevFest Novosibirsk about Go, geodata and hatred to Nod.js and UDP.
Автор: Андрей Минкин / Andrew Minkin
Держите одеяло у себя: как общаться с кандидатом и узнавать все, что вам инте...Mad Devs
Маргарита Мысина, рекрутер в Mad Devs поделилась темой «Держите одеяло у себя: как общаться с кандидатом и узнавать все, что вам интересно».
Маргарита начала свою карьеру HR в IT в технологическом стартапе, а пару лет назад присоединилась к команде HR в Mad Devs, в качестве сорсера, а затем рекрутера. За время своей работы в найме Маргарита приобрела огромный опыт, который передаст в своем докладе, рассказывая о том, как общаться с кандидатами и ненавязчиво узнавать всю нужную рекрутеру информацию.
Дружелюбнй онбординг: как с увеличением количества не потерять качество Mad Devs
Клара Абдукова, HR-специалист в Mad Devs презентовала о «Дружелюбном онбординге: как с увеличением количества не потерять качество»
Клара уже несколько лет работает в ИТ и в настоящее время занимает позицию лида онбординга в Mad Devs. Она заонбордила более 100 человек, ее опыт позволил сделать процесс онбординга в компанию не только четким, но и прозрачным. В своем докладе Клара расскажет весь путь выстраивания процесса онбординга и поделилась инсайтами, которые помогут HR-специалистам в создании и проведении этого важного процесса.
Mad Stream продолжается!
Нам повезло пригласить нашего Senior Backend Разработчика, Solution Architect, Нурадила Алымкулова, поделиться знаниями с нами.
Нурадил работал в разработке разнообразных систем банка, телекоммуникационных компаниях - одним словом, в энтерпрайзах. Теперь Нурадил хочет поделиться своими огромным опытом и наблюдением в разработки сложных систем.
На этом стриме Нурадил выступит с темой “Проектирование архитектуры приложения 101” мы начнем с:
описания бизнес-требований с помощью последовательных диаграмм;
разберем классовые диаграммы;
опишем поведение программы с помощью флоу-диаграм.
На данном стриме мы пройдем путь создания приложения от начала до конца! После стрима у нас обязательно будет сессия вопросов и ответов.
Mad Stream начнется в 19.30, в этот четверг 12-го ноября!
Ссылка на трансляцию:
https://youtu.be/tKymOf3O9gc
У нас часто спрашивают, как начать программировать самостоятельно и не “перегореть” во время обучения. Теперь можно спросить об этом напрямую у нашего сотрудника Айбека Ногоева!
До Mad Devs Айбек работал в международной аудиторской компании. Там всего за год он поднялся с Junior позиции до уровня Senior и был тимлидом во многих проектах. Чтобы расширить список своих навыков и круг возможностей, Айбек решил начать программировать. После двух месяцев самостоятельного обучения он попал в Mad Devs, и теперь он наш Android-разработчик.
Программируя под Android, Айбек изучил еще и iOS разработку, без каких-либо курсов и чьей-либо помощи. На Mad Stream Айбек выступит с темой: “Соло-прокачка мобильного разработчика”.
На стриме Айбек затронет несколько тем, важных для любого начинающего “мобильщика”:
Как изучать программирование самостоятельно?
Как быстро освоить мобильную разработку?
Как не “перегореть” в процессе обучения?
Как развивать базовые навыки дальше?
Если собираетесь “войти в айти”, опыт Айбека будет вам очень кстати. Интересно узнать работающие лайфхаки?
Тогда скорее сохраняйте ссылку на стрим!
This document discusses habits of highly effective developers, including: holding daily standup meetings to update teammates on work completed, in progress, and blockers; basing work on documented issues to provide context and accountability; thoroughly documenting code, services, and projects; visualizing project data and events; doing demos to showcase work; following good coding practices like testing and automation; communicating carefully and thanking teammates.
Mad Stream: "Что можно напечатать на 3d принтере, помимо еще одного 3d принте...Mad Devs
Наш специалист по Embedded System Engineering, Антон Козлов, выступит с темой:
«Что можно напечатать на 3d принтере, помимо ещё одного 3d принтера.»
⠀
На стриме вы узнаёте:
1. О том как нам преподносят трехмерную печать и чем она является на самом деле;
2. Трехмерная печать не серебряная пуля, недостатки технологии как: масштабируемость, цена, качество изделий;
3. Основные виды трехмерных принтеров доступных простому обывателю и принцип их работы;
4. Пример проекта в котором трехмерная печать ускорит разработку продукта.
Ссылка на стрим: https://www.youtube.com/watch?v=klHxO9c1d2Y&feature=youtu.be
Maв Stream: "Факт карты на службек у ПМа", спикер – Дмитрий КононенкоMad Devs
Вы когда-нибудь слышали о факт-картах? Если коротко – это особый инструмент, помогающий мышлению решать сложные интеллектуальные задачи. Это методика выстраивания целей и нахождения эффективных решений применимых к любой сфере. В ходе презентации Дима "разжует" основные понятия относящиеся к факт-картам и как обычно даст много полезных советов, что называется "из жизни".
Лайфхаки менеджмента на удаленке от Дмитрия КононенкоMad Devs
В ходе презентации, все заинтересованные узнают о том, как организовать коммуникации и процессы команды разработки в условиях всеобщей изоляции. Дима подкинет классных тулзов для упрощения и улучшения процессов, а также поделится собственным опытом и даст много полезных советов.
Этот Mad Talks о неудачном опыте в живом продакшн проекте. Александр расскажет историю о том, как настроили отказоустойчивость системы бизнес-проекта и жили спокойно, пока не решили чинить поломанную репликацию и в итоге получили split-brain.
Основные преимущества и недостатки нативных и кроссплатформенных приложений: что из себя представляет каждый тип приложений и для каких целей он служит.
Более подробно рассматривается Flutter - набор инструментов, позволяющий разработчикам писать кроссплатформенные приложения. Почему стоит обратить на него внимание и начать инвестировать в изучение Flutter.
Ethereum is a blockchain network that allows developers to build decentralized applications and smart contracts. It uses proof-of-work consensus to validate transactions and add them to immutable blocks. Smart contracts deployed on Ethereum are public and their source code can be viewed by anyone. Ethereum is working to transition from proof-of-work to proof-of-stake consensus.
Ethereum: аспекты разработки смарт-контрактовMad Devs
- Что такое умные контракты (смарт-контракты)?
- Представление смарт-контрактов в Ethereum.
- Смарт-контракты на примере - ERC20 токен.
- Понятие топлива (газа) в Ethereum.
- Инструментарий разработки смарт-контрактов.
- Способы интеграции смарт-контрактов Ethereum с внешним ПО.