🦒
System Analyst | Knowledge base
  • Введение
  • Soft skills
    • 📍Продукт
      • Роли в IT продукте
        • Системный аналитик (SA)
        • Бизнес-аналитик (BA)
        • SA vs BA
        • 📎Другие аналитики
      • Жизненный цикл продукта
      • Методологии разработки
        • Waterfall
        • Agile
          • Scrum
          • Kanban
      • 📎Целеполагание
        • SMART
        • Матрица Эйзенхауэра
        • RICE
        • 🔒HADI
    • 📍Требования
      • Классификация требований
        • Уровень: Бизнес
        • Уровень: Пользователь
          • Use case
          • User story
          • 📎Job story
        • Уровень: Продукт
          • Функциональные требования
          • Нефункциональные требования
      • Качества требований
      • Методы сбора требований
      • Техническое задание (ТЗ)
  • Hard skills
    • 📍Базы данных
      • Реляционные
        • Транзакции
          • 🔒CAP
        • Нормальные формы
        • SQL
          • DML
          • DDL/DCL/TCL
          • 📎Представления VIEW
        • Констрейты
        • 📎Типы данных
        • 🔒Middle+
          • Особенности работы с конкертными реляционными БД
      • Нереляционные
        • Примеры использования
        • 🔒Middle+
          • Колоночные
            • Сlickhouse
          • Ключ-значение
          • Матричные
          • Документо-ориентированные
          • Графовые
            • JanusGraph | Neo4j etc
      • Масштабирование БД
      • Оптимизация БД
        • 📎Типы индексов
        • 📎Уникальные индексы
        • 🔒Анатомия плана запроса
      • 📎Какую СУБД выбрать
      • 📎Хранение и анализ данных
        • ETL
        • DWH
          • DWH vs Data Lake vs Data Mart
        • OLAP
          • OLAP vs OLTP
        • BI-аналитика
    • 📍Интеграции
      • Форматы данных
        • JSON + JSON Schema
          • 🔒AVRO
        • JSON vs XML
      • Виды интеграций
        • Синхронное взаимодействие
          • REST
            • RESTful принципы
              • Отсутствие состояния (Авторизация)
                • 🔒OAuth / OpenID Connect
              • Кеширование
              • Единообразие интерфейса (CRUD)
                • Запрос/ответ
              • 🔒Cтепень зрелости REST API
            • Проектирование API
            • 📎Асинхронный REST
          • SOAP
            • XSD
            • WSDL
          • REST vs SOAP
        • Асинхронное взаимодействие
          • Kafka
          • RabbitMQ
          • Kafka vs RabbitMQ
          • ESB
          • gRPC
            • Правила proto-контракта
            • Protobuf vs JSON
            • Сравнительная таблица
          • Другое
          • 🔒WebSocket API
        • Sync vs Async
      • 🔒Middle+
        • Stateful vs Stateless
        • Apache Flink
        • оркестрация и хореография
    • 📍Проектирование
      • Архитектура
        • Монолит
        • Микросервисы
          • Паттерны реализации
        • Монолит vs Микросервисы
        • 🔒Middle+
          • Бессерверная
          • Сервис-ориентированная (SOA)
          • Другое
      • Нотации и диаграммы
        • UML
          • Диаграмма классов
          • Диаграмма последовательности
            • Фреймы
          • Диаграмма прецедентов (use case)
          • 🔒Middle+
            • Диаграмма деятельности/активности
            • Диаграмма состояний
        • BPMN
          • Основные элементы
        • BPMN vs UML
        • ERD
        • 📎IDEF0
      • Прототипирование
        • Figma vs Axure
      • Мониторинг
        • Логирование
        • Метрики
        • Алерты
        • 🔒Инструменты
          • Grafana
          • Prometheus
          • ELK
            • Elasticsearch
            • Logstash
            • Kibana
      • 🔐Системный дизайн
    • 📎DevOps for SA
      • Основы сетей
        • OSI
        • TCP/IP
        • HTTP
        • DNS
      • Git (VCS)
        • GitHub vs GitLab
      • Развертывание приложений
        • CI/CD
        • 🔒Middle+
          • Виртуализация/контеризация
            • ✍️Docker
            • Kubernetes
              • ✍️Openshift
      • Cloud Native
        • Сервисы облачных вычислений
        • Cloud-native app vs Traditional app
      • Командная строка
    • 📎QA for SA
      • Postman | Insomnia
      • Swagger
      • Верификация vs Валидация
      • Идентификация/Аутентификация/Авторизация
    • 📎PM for SA
      • Метрики
        • Метрики привлечения
        • Метрики вовлечённости
          • ARPU
          • LTV
          • NPV
          • ROI
          • NPS
      • Прокси метрики
      • Дерево метрик
      • Фреймворки
      • Юнит-экономика
      • Модель Кано
  • Другое
    • Литература
    • Советы по составлению резюме
    • Общие вопросы на собеседовании
    • Вопросы которые надо задать интервьюеру
  • Контакты
Powered by GitBook
On this page

Was this helpful?

  1. Hard skills
  2. DevOps for SA
  3. Cloud Native

Cloud-native app vs Traditional app

PreviousСервисы облачных вычисленийNextКомандная строка

Last updated 1 year ago

Was this helpful?

CLOUD NATIVE APPLICATIONS
TRADITIONAL ENTERPRISE APPLICATIONS

Предсказуемость. Облачные приложения предсказуемы, поэтому соответствуют требованиям, разработанным для максимальной устойчивости. Высокоавтоматизированная инфраструктура, управляемая контейнером, определяет, как будет написано программное обеспечение. Хороший пример документа, отражающего методологию создания приложений, это (12-factor principles).

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

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

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

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

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

Уровень взаимодействия. Процесс разработки cloud-native приложений подразумевает совместную работу. Облачная среда упрощает DevOps — объединение людей, процессов и инструментов. Это обеспечивает тесное взаимодействие между разработкой и операционным IT-персоналом, что способствует быстрой и плавной выкатке нового кода приложения в производство.

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

Continuous delivery. Для cloud-native приложений работает непрерывная доставка. IT-подразделения выпускают обновления программного обеспечения по мере их готовности. Это позволяет компании, выпускающей ПО, быстрее получать обратную связь от клиентов и эффективнее реагировать на их потребности. Непрерывная доставка лучше всего работает вместе с другими подходами, в частности разработкой через тестирование и непрерывной интеграцией.

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

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

Зависимая архитектура. Компоненты архитектуры традиционных приложений зависят друг от друга. В монолитной архитектуре множество отдельных сервисов объединены в единый пакет. Из-за ненужных зависимостей между ними разработка и развертывание приложений становятся менее гибкими.

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

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

Источники:

📎
https://cloud.vk.com/blog/cloud-native-prilozheniya-bystro-zagruzhayutsya-snizhayut-riski-stimuliruyut-rost-biznesa
https://denovo.ua/ru/blog/cloud-native-apps
12 факторов разработки приложения