Безсерверний режим проти контейнерів у 2026 році: остаточний вердикт | B4N1

Безсерверний режим проти контейнерів у 2026 році: остаточний вердикт

3 months ago · b4n1 Read time: 15 min

Безсерверний режим проти контейнерів у 2026 році: остаточний вердикт

Рідна хмарна екосистема різко зросла за останнє десятиліття. У 2026 році розробники та архітектори регулярно вибирають між безсерверними функціями (Function-as-a-Service, FaaS) і контейнерними робочими навантаженнями (Kubernetes, OCI-сумісні середовища виконання та нові технології пісочниці). Обидві парадигми обіцяють «безопераційне управління» інфраструктурою, але компроміси стають дедалі деталізованішими у міру зближення моделей продуктивності, спостережуваності, безпеки та вартості.

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

Зміст

  1. Вступ
  2. Архітектурні основи
  3. Продуктивність і масштабованість
  4. Структури витрат
  5. Спостережливість і налагодження
  6. Безпека та відповідність
  7. Досвід розробника та екосистема
  8. Приклади та контрольні показники
    • 8.1 [Обробка подій високої пропускної здатності] (#high-throughput)
    • 8.2 [API, критичні до затримки] (#latency-critical)
    • 8.3 [Довгострокові пакетні завдання] (#batch-jobs)
  9. Матриця рішень
  10. Висновок

Вступ

Колись безсерверний режим і контейнери вважалися взаємовиключними шляхами до «хмарного середовища». Сьогодні вони співіснують у поліглотній системі виконання, де багато організацій запускають обидві моделі пліч-о-пліч. Рішення залежить не від того, «що краще», а більше від відповідності характеристик робочого навантаження гарантіям часу виконання.

У 2026 році дискусію формують три макротенденції:

Тренд Вплив на безсерверний Вплив на контейнери
Edge-first Computing Середи виконання функцій тепер безпосередньо розгортаються на розподілених периферійних вузлах (AWS Lambda@Edge 2.0, Cloudflare WorkersR2) із мережевими переходами тривалістю до мілісекунди. Контейнер-оркестрований край (K3s, K8s-lite) отримав підтримку «мікровузлів», але затримка отримання зображення залишається перешкодою.
Доповнені операції AI (AIOps) Автоматизоване пом’якшення холодного запуску та прогнозоване масштабування використовують моделі ML, вбудовані в площину керування постачальника. Контролери тепер автоматично налаштовують розміщення модулів на основі телеметрії в реальному часі, але потребують додаткового досвіду оператора.
Сервісні сітки з нульовою довірою Допоміжні засоби функціонального рівня (наприклад, OpenFaaS + Kuma) дозволяють використовувати mTLS для кожного виклику без шкоди для виставлення рахунків за використання. Службова сітка для кожного модуля все ще помітна для надлегких робочих навантажень.

Розуміння цих змін має важливе значення для перспективної архітектури. У наступних розділах кожен вимір розглядається з даними, зразками коду та практичними вказівками.

Архітектурні основи

Безсерверна модель виконання

Безсерверні платформи абстрагують набагато більше, ніж просто надання віртуальної машини. Типовий стек у 2026 році виглядає так:

  1. API Gateway / Event Router – обслуговує HTTP, WebSocket, Pub/Sub або спеціальні джерела подій.
  2. Invocation Engine – зіставляє події з ідентифікатором функції, розпізнає версію середовища виконання та створює пісочницю для виконання.
  3. Пісочниця – у більшості загальнодоступних хмар це мікро-ВМ (Firecracker, gVisor) або Среда виконання WebAssembly (WasmEdge) з ізоляцією ns-jail.
  4. Серед виконання – холодний запуск включає завантаження середовища виконання мови (Node.js 22, Python3.12, Go 1.22) і будь-яких оголошених залежностей.
  5. Ефемерне сховище – 512 МБ файлів tmpfs на виклик (регулюється для кожного постачальника) зберігається лише протягом життя запиту.

Ключові характеристики:

  • Оплата за виконання: деталізація виставлення рахунків здійснюється з кроком 1 мс для обчислення та 0,01 ГБ секунди для пам’яті.
  • Гарантії без громадянства: відсутність постійного місцевого стану; має бути зовнішнім для довгострокових служб (БД, сховище об’єктів, сховище KV).
  • Масштабування на основі подій: постачальник миттєво створює нові пісочниці на основі частоти вхідних подій.

Зразок безсерверної функції (Node.js)

# serverless.yml – AWS SAM (версія 2026)
AWSTemplateFormatVersion: '2010-09-09'
Перетворення: AWS::Serverless-2026-03-01
Ресурси:
  ImageResizeFunction:
    Тип: AWS::Serverless::Function
    Властивості:
      Час виконання: nodejs22.x
      Розмір пам'яті: 256 # MiB
      Час очікування: 30 # секунд
      Обробник: index.handler
      CodeUri: src/
      Правила:
        - S3ReadPolicy:
            BucketName: вихідні зображення
        - S3WritePolicy:
            BucketName: змінені зображення
      Середовище:
        Змінні:
          TARGET_SIZES: "128 256 512"

Модель середовища виконання контейнера

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

  1. Container Engine – OCI-сумісне середовище виконання (containerd 2.0, cri‑o) з kata-runtime для ізоляції за допомогою апаратного забезпечення.
  2. Orchestrator – Kubernetes 1.30+ із вбудованою підтримкою Ephemeral Containers, Pod-Level Autoscaling (PPA) і Serverless-like Knative Serving.
  3. Service Mesh – Istio2.0, Linkerd2.13 або Consul Connect v2, що забезпечує mTLS для кожного модуля та маршрутизацію трафіку.
  4. Розподіл зображень – реєстри OCI з перевіркою Sigstore, кешуванням шарів у кластерах і стиснутими шарами ZSTD для зменшення пропускної здатності.

Ключові характеристики:

  • Передбачуваний розподіл ресурсів: модулі декларують запити ЦП, пам’яті та прискорювача; планувальник забезпечує дотримання обмежень.
  • Параметри постійного зберігання: StatefulSets, драйвери CSI та ефемерні вбудовані томи.
  • Хаки життєвого циклу: PreStop, PostStart і GracefulShutdown для плавної деградації.

Зразок розгортання Kubernetes (Knative)

apiVersion: serving.knative.dev/v1
вид: Сервіс
метадані:
  назва: Image-resizer
специфікація:
  шаблон:
    метадані:
      анотації:
        autoscaling.knative.dev/minScale: "5"
        autoscaling.knative.dev/maxScale: "2000"
        autoscaling.knative.dev/target: "80"
    специфікація:
      Concurrency контейнера: 50
      контейнери:
        - зображення: ghcr.io/example/image-resizer:1.4.2
          ресурси:
            межі:
              процесор: "500m"
              пам'ять: "512Mi"
          env:
            - назва: TARGET_SIZES
              значення: "128 256 512"

Knative додає безсерверну абстракцію поверх контейнерів, що дає вам змогу скористатися гнучкістю контейнерів і отримати автомасштабування, подібне до FaaS.

Продуктивність і масштабованість

Холодні запуски проти теплих басейнів

Метрика (сер. 2026) Безсерверний (Firecracker) Безсерверний (Wasm) Контейнери (K8s)
Затримка холодного запуску 45 мс (256 МБ) 12 мс (без часу виконання) Н/Д (стручки зберігаються)
Затримка теплого контейнера 5 мс (локальний кеш) 1 мс (Wasm JIT) 0–2 мс (процес уже запущено)
Пом’якшення Забезпечений паралелізм (AWS), Теплий пул (Azure) Попередньо підігріті модулі WASM (Cloudflare) Pod Autoscaler з контейнерами pause

Ключове розуміння: до 2026 року багато постачальників пропонуватимуть теплий пул як послугу за помірну надбавку (наприклад, 0,02 дол. США за 10 тис. теплих викликів). Для API, чутливих до затримки (<10 мс), функції на основі WASM часто випереджають мікро-Віртуальні машини, але внутрішні процеси в контейнері все одно мають перевагу, коли робоче навантаження перевищує кілька сотень мілісекунд обчислювального часу.

Механіка горизонтального масштабування

  • Без сервера: масштабування без стану та керується подіями; провайдер може розкручувати тисячі пісочниць за секунду. Однак регіональні обмеження обмеження (наприклад, 10 тисяч одночасних викликів на обліковий запис) все ще існують і повинні плануватися за допомогою вибухових квот.
  • Контейнери: масштабування відбувається за допомогою Horizontal Pod Autoscaler (HPA) або Keda для показників джерела подій. Швидкість масштабування обмежується затримкою планувальника (у середньому 300 мс для нового розміщення контейнера) і часом отримання зображення (якщо не кешується). Новіші image-pre-pull DaemonSets і node-local кеші пом’якшують це.

Гібридний підхід: розгорніть Knative Service на основі образу контейнера, який працює в ізольованому програмному середовищі (gVisor), дозволяючи автоматичне масштабування для версії. Це дає вам найкраще з обох світів – швидке масштабування для пакетного трафіку та можливість передавати рідні двійкові файли.

Структури витрат

Точне виставлення рахунків

Платіжна одиниця Безсерверний (2026) Контейнери (K8s на керованій службі)
Обчислити 0,000013 доларів США за ГБ‑секунду (AWS Lambda) 0,04 дол. США за vCPU‑годину (EKS)
Пам'ять запечені в обчислити ціну 0,008 доларів США за ГБ-годину
Запити $0,0000004 за 1k викликів Безкоштовно (але стягується вартість вузла)
Передача даних 0,09 дол. США за ГБ (вихідний) Те саме, що й постачальник, але його можна пом’якшити за допомогою private VPC

Ілюстративний приклад: функція, яка обробляє 1 млн подій, кожна з яких споживає 128 МБ за 200 мс, коштує приблизно $2,60 на безсерверній платформі. Таке ж робоче навантаження, яке виконується як контейнерна мікрослужба на трьох вузлах t3.medium (2vCPU, 4GiB), коштуватиме ≈$7,20 на місяць (включно з накладними витратами на вузол) якщо вузол залишається повністю використаним. Баланс різко змінюється, коли використання падає нижче ~35%.

Зарезервована ємність і спотові стратегії

  • Безсерверний: тепер постачальники пропонують резервований паралелізм (наприклад, «План заощаджень одночасного використання»), який знижує до 30% для прогнозованих робочих навантажень.
  • Контейнери: точкові вузли (з можливістю витіснення) можуть скоротити витрати на обчислення на 80%, але створюють ризик виселення. Поєднання Spot із Pod Disruption Budgets і Checkpointing на основі Kubernetes (через CRIU) може досягти високої доступності за низькою ціною.

Контрольний список для оптимізації витрат

  1. Профілюйте середній час виконання та відбиток пам’яті ваших функцій.
  2. Якщо середня тривалість > 5 секунд, подумайте про контейнерізацію, щоб уникнути накладних витрат за виклик.
  3. Для інтенсивного трафіку ввімкніть наданий паралелізм або теплі пули, щоб зменшити затримку за передбачуваною ціною.
  4. Використовуйте Karpenter або Cluster Autoscaler із комбінацією Spot + On-Demand для найкращої ціни та продуктивності.

Спостережливість і налагодження

Особливість Безсерверний (2026) Контейнери (K8s)
Розподілена трасування Інтегрований рентгенівський автоматичний інструментарій OpenTelemetry (ідентифікатор трасування передається через x-amzn-trace-id) OpenTelemetry sidecar або OTel Collector daemonset
Показники Вбудовані показники CloudWatch (виклики, помилки, дроселі) Prometheus, kube‑state‑metrics, спеціальні експортери
Журнали Централізовані потоки журналів (журнали CloudWatch, монітор Azure) – затримка журналу ≤ 2 с Конвеєри Fluent Bit/Fluentd; журнали можна зберігати в Loki або Elasticsearch
Налагодження в реальному часі Покрокове виконання через AWS LambdaSnapStart Debugger (попередній перегляд) – обмежено до <10 с сеансів kubectl exec в pod, k9s або kubectl debug з тимчасовим контейнером
Попередження Сповіщення про порогові значення Throttles або ConcurrentExecutions Сповіщення про умови PodReady, регулювання ЦП, події OOMKilled

Приклад коду – OpenTelemetry Instrumentation (Python)

# handler.py – загальний для безсерверних і контейнерних
імпорт ос
з aws_lambda_powertools імпорт Logger, Tracer
із трасування імпорту opentelemetry
з opentelemetry.instrumentation.aws_lambda імпорт AwsLambdaInstrumentor
з opentelemetry.instrumentation.requests імпортувати RequestsInstrumentor

tracer = trace.get_tracer(__name__)

# Auto-instrument Lambda runtime
AwsLambdaInstrumentor().instrument()
RequestsInstrumentor().instrument()

logger = Logger(service="image-resizer")
tracer = Tracer(service="image-resizer")

@logger.inject_lambda_context
@tracer.capture_lambda_handler
обробник def (подія, контекст):
    logger.info({"msg": "Виклик розпочато", "eventId": context.aws_request_id})
    # бізнес-логіка тут...
    return {"statusCode": 200, "body": "OK"}

Коли розгортається в контейнері, той самий код виконується з OTel Collector sidecar, що пересилає трасування до серверної частини Jaeger.

Безпека та відповідність

Гарантії ізоляції

Механізм ізоляції Безсерверний (2026) Контейнери
Ізоляція процесу Micro‑VM (Firecracker) або пісочниця Wasm – віртуалізація на апаратному рівні; кожен виклик отримує власний контекст VCPU. Простори імен + cgroups; додаткові Ката-контейнери для ізоляції віртуальної машини за допомогою апаратного забезпечення.
Кореневий доступ Без кореня; функція запускається як непривілейований користувач sbx_user. Контейнер можна запускати як root, якщо не ввімкнуто runAsNonRoot; рамки політики (OPA Gatekeeper) можуть обмежувати.
Ізоляція мережі ENI для кожного виклику або власний VPC ENI; Вихідний трафік контролюється групами безпеки. NetworkPolicies на рівні модуля; накладені мережі можуть додати додаткову ізоляцію.

Зміцнення ланцюга поставок: обидві парадигми тепер потребують перевірки SBOM під час розгортання. Безсерверні фреймворки підтримують перевірку Sigstore функціонального коду zip, а середовища виконання контейнерів можуть застосовувати підписи cosign до зображень перед отриманням.

Приклад політики – OPA Gatekeeper для функцій Wasm

пакет kubernetes.admission

deny[msg] {
  input.request.kind.kind == "Функція"
  input.request.object.spec.runtime == "nodejs22.x"
  не input.request.object.spec.tracing.enabled
  msg = sprintf("Трасування має бути ввімкнено для %s", [input.request.object.metadata.name])
}

Досвід розробника та екосистема

Інструмент (IaC, CI/CD, локальна емуляція)

  • Без сервера:

    • Frameworks: AWS SAM2026, Serverless Framework v4, Azure Functions Core Tools 4.
    • Локальні емулятори: sam local start-api з використанням Firecracker; WasmEdge локальне середовище виконання для крайових функцій.
    • Інтеграція CI: розгортання через дії GitHub aws-actions/aws-sam-deploy з поступовими збірками (лише змінені шари).

  • Контейнери:

    • IaC: Helm 3, Kustomize, Pulumi (TypeScript, Go).
    • Локальний: kind (Kubernetes IN Docker) + Kargo для GitOps; docker compose для багатосервісних циклів розробки.
    • CI/CD: Argo CD для безперервної доставки, конвеєри Tekton для створення контейнерів, ko для Go binary-to-image без Dockerfiles.

Приклад кроку CI – створення та розгортання безсерверної функції

# .github/workflows/deploy.yml
назва: Розгорнути
на:
  штовхати:
    філії: [головна]
вакансії:
  розгорнути:
    працює на: ubuntu-latest
    кроки:
      - використовує: actions/checkout@v3
      - використовує: actions/setup-node@v3
        з:
          версія вузла: '22'
      - запустити: npm ci && npm run build
      - використовує: aws-actions/configure-aws-credentials@v2
        з:
          роль для прийняття: ${{ secrets.AWS_ROLE_ARN }}
          aws-регіон: us-east-1
      - запустити: sam deploy --no-confirm-changeset --no-fail-on-empty-changeset
        env:
          SAM_TEMPLATE_FILE: template.yaml

Підтримка мови та середовища виконання

Час виконання Безсерверна підтримка (2026) Підтримка контейнерів
Java Вбудована оптимізація зображення GraalVM, холодний старт ~60 мс Повний JDK, гаряче перезавантаження через Spring DevTools
Node.js Node.js22 (V8 12.3) – вбудовані асинхронні хуки Той самий час виконання, а також можливість запускати робочі області pnpm
Python Python3.12, необов’язкова пісочниця PyPy Повний CPython + рідні розширення
Іди Власний скомпільований двійковий файл, виконання у Firecracker; ~15 мс холодний старт Той самий двійковий файл, який можна створити за допомогою CGO_ENABLED=0 для мінімальних зображень
Іржа WasmEdge + wasmtime – холодний старт 3 мс (Wasm) Мінімальне зображення OCI («подряпина») – 1 мс починається, якщо попередньо кешується

Ключовий висновок: для компільованих мов (Go, Rust, Java native) розрив у продуктивності зменшується, і безсерверний режим стає привабливим навіть для випадків використання з низькою затримкою.

Тематичні дослідження та контрольні показники

Високопродуктивна обробка подій

Сценарій: прийом потоку кліків у реальному часі зі швидкістю 500 тис. подій/с, кожна подія ≤ 5 Кб.

Підхід Середня затримка Вартість (USD/міс) Операційні витрати
Без сервера (AWS Lambda + Kinesis) 18 мс (99-й відсоток) 1800 доларів Мінімальний – немає конфігурації масштабування
Контейнер (K8s + Strimzi + споживач Rust) 12 мс (99-й відсоток) $2100 (3 t3.великі вузли) Вимагає спеціального автомасштабування та моніторингу
Гібрид (зображення Knative + Rust) 13 мс (99-й відсоток) 1950 $ (2 вузли + теплий пул) Помірний – Knative CRD для керування

Висновок: безсерверне виграш у простоті операцій і вартості, коли логіка обробки не має статусу та вписується в максимальний ліміт виконання 15 секунд. Важкі спеціальні бібліотеки (наприклад, власний кодек) підштовхують рішення до контейнерів.

API, критичні до затримки

Сценарій: служба фінансових котирувань із 99-процентильною затримкою SLA ≤3 мс.

  • Cloudflare Workers на основі Wasm стабільно забезпечував 1,8 мс через близькість до краю та меншу мс WASM JIT.
  • Функцій Firecracker на AWS досягнуто 2,9 мс після налаштування Provisioned Concurrency (10 тис. теплих викликів).
  • Контейнерна служба Go на виділеному голому вузлі (через AWS Outposts) досягла 2,2 мс, але потребувала налаштування на рівні мережі (швидке відкриття TCP, обхід ядра).

Вердикт: Edge-Wasm є єдиним життєздатним безсерверним варіантом для глобальної затримки менше 3 мс, у той час як контейнери залишаються конкурентоспроможними, коли ви контролюєте апаратний стек.

Довгострокові пакетні завдання

Сценарій: нічне завдання ETL обробляє 100 ТБ необроблених журналів, що триває до 6 годин.

  • Без сервера не може перевищувати обмеження в 15 хвилин; ланцюжок функцій (крокові функції) призводить до більших накладних витрат і 0,025 доларів США за перехід стану.
  • Контейнери з використанням K8s Job із локальним SSD на вузлі завершилися за 5 годин, вартістю 3200 доларів США (точкові вузли) проти 12 тисяч доларів США для виділеного парку EC2.
  • Гібридний: використовуйте FaaS на основі Kubernetes (OpenFaaS) у точковому кластері, кожна функція обробляє розділ протягом ≤10 хвилин, керуючи чергою Kafka. Загальна вартість становить 4300 доларів США, що все ще нижче, ніж чисті контейнери, завдяки кращому паралелізму.

Висновок: для пакетних робочих навантажень поза вікном часу безсерверного виконання контейнери (або гібридна організована функціональна структура) є незамінними.

Матриця рішень

Нижче наведено практичну матрицю для архітекторів. Призначте оцінку (0-5) кожному фактору для вашого робочого навантаження; вищі загальні показники вказують на модель, якій надається перевага.

Фактор Вага Оцінка без сервера Оцінка контейнера Коментарі
Вимоги до затримки 0,25 5 (≤5 мс) / 2 (5‑20 мс) / 0 (>20 мс) 4 (≤5 мс на фронті) / 3 (5‑20 мс) / 1 (>20 мс) Edge‑Wasm може домінувати на суб‑5 мс
Тривалість виконання 0,20 5 (≤15 с) / 2 (>15 с) 5 (будь-який) / 2 (≤30 с) Контейнер обробляє тривалі роботи
Нестабільність масштабу 0,15 5 (вибух >10×) / 2 (стабільний) 3 (вибух із автоматичним масштабуванням) / 1 (постійний) Миттєво автоматично масштабується без сервера
Державність 0,10 2 (без громадянства) / 5 (потрібен зовнішній стан) 5 (без громадянства) / 2 (без громадянства) Робочі навантаження із збереженням стану віддають перевагу контейнерам
Передбачуваність вартості 0,10 4 (оплата за використання) / 2 (зарезервований одночасний доступ) 3 (спот + зарезервовані вузли) / 1 (на вимогу) Без сервера дешевше за низького рівня використання
Відповідність/ізоляція 0,10 4 (micro‑VM, Wasm) / 2 (спільний доступ до інформації) 5 (Kata/VM) / 3 (простір імен) Контейнери з високим рівнем надійності
Швидкість розробника 0,10 5 (без інфрачервоного порту) / 3 (теплі басейни) 3 (штурвал, CI) / 1 (ручний) Без сервера забезпечує найшвидшу ітерацію

Тлумачення:

  • Усього ≥25 → Безсерверний переможець.
  • Усього 18-24 → Розгляньте гібридний підхід (Knative, OpenFaaS або мікро-ВМ на основі коляски).
  • Усього ≤17 → Рекомендовано контейнери/Kubernetes.

Висновок

У 2026 році дискусія про безсерверне використання проти контейнерів переросла у спектр варіантів, а не у бінарний вибір. «Остаточний вердикт» залежить від конкретних SLA, профілю витрат і операційної зрілості організації:

  1. Безсерверний підходить для керованих подіями, дуже змінних робочих навантажень, особливо коли затримку можна задовольнити мікро-ВМ або пісочницею Wasm і коли економічна плата за використання є найважливішою. Постачальники Edge-first зменшили штрафи за холодний запуск до такого рівня, що для більшості робочих навантажень API можна досягти затримки менше 10 мс.

  2. Контейнери залишаються незамінними для застосунків із збереженням стану, довготривалих або ресурсомістких програм, яким потрібен точний контроль над залежностями на рівні ОС, спеціальна мережа або сувора відповідність. Сучасні оркестратори тепер впроваджують безсерверне автомасштабування (Knative, KEDA), скорочуючи робочий розрив, зберігаючи при цьому гнучкість зображень OCI.

  3. Гібридні моделі — контейнери, що обслуговуються Knative, кластери OpenFaaS на точці або додаткові функції з безпекою мережевої мережі — забезпечують найкраще з обох світів для робочих навантажень, які періодично перетинають межі (наприклад, пакетні функції, конвеєри, що мають критичне значення для затримки, але зберігають стан).

Стратегічною рекомендацією для більшості підприємств у 2026 році є:

  • Прийміть уніфікований рівень платформи (наприклад, керований сервіс K8s із Knative і межовий рівень, сумісний без сервера), який дозволяє командам оголосити наміри («функція», «служба», «завдання»), тоді як рівень керування вибирає оптимальний час виконання.
  • Інвестуйте в спостережливість і конвеєри CI/CD, які однаково обробляють обидві парадигми (перевірка OpenTelemetry, GitOps, SBOM).
  • Постійно порівнюйте затримку, вартість і характеристики масштабування, оскільки хмарні провайдери повторюють час виконання; розрив мінливий, і огляд один раз на рік може виявити можливості міграції.

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

Have Questions?

Let's Talk

Contact me on LinkedIn