Co to jest MACH i kto go zdefiniował

MASZ to skrót wymyślony przez Sojusz MACH, stowarzyszenie dostawców technologii założonych w 2020 roku przez commercetools, Contentful, EPAM Systems i innych. Nie to produkt — to zbiór zasad architektonicznych dla systemów budowlanych nowoczesne przedsiębiorstwo.

  • M — Mikrousługi: każda funkcja biznesowa jest niezależną usługą
  • A — Najpierw API: każda usługa udostępnia dobrze zdefiniowane interfejsy API jako swój podstawowy interfejs
  • C — Natywna chmura: stworzona dla chmury publicznej, z elastycznym skalowaniem i usługami zarządzanymi
  • H — Headless: frontend i backend są oddzielone

Podstawową ideą jest najlepszy w swojej klasie: zamiast kupować pojedynczy apartament który robi wszystko (przeciętny), wybierz najlepszą usługę dla każdej funkcji i skomponuj platformę szyte na miarę. Najlepsza wyszukiwarka produktów (Algolia), najlepsza kasa (Stripe), najlepszy CMS (Contentful), najlepszy PIM (Akeneo).

Cztery wymiary MACH w szczegółach

Mikrousługi: dekompozycja dla ograniczonego kontekstu

W architekturze MACH domena handlowa jest rozkładana na dopasowane, niezależne usługi AI ograniczony kontekst projektowania opartego na domenie: 

// Esempio di decomposizione in microservizi commerce

const MACH_SERVICES = {
  // Servizi core commerce
  catalog: 'Gestione prodotti, categorie, attributi, varianti',
  pricing: 'Regole di prezzo, sconti, tier pricing, valute',
  inventory: 'Stock real-time, warehouse, backorder',
  cart: 'Sessioni di carrello, regole di promozione',
  checkout: 'Checkout flow, address validation, ordine',
  payments: 'Processing pagamenti, rimborsi, split payments',
  fulfillment: 'Gestione spedizioni, tracking, resi',

  // Servizi supporto
  search: 'Full-text search, filtri, ranking (Algolia)',
  recommendations: 'Prodotti correlati, personalization',
  cms: 'Contenuto editoriale, landing page (Contentful/Sanity)',
  pim: 'Product Information Management (Akeneo)',
  loyalty: 'Punti, rewards, programmi fedeltà',
  notifications: 'Email, SMS, push notifications',
};

API-First: Umowa przed wdrożeniem

W systemie opartym na interfejsie API interfejs API jest zdefiniowanym kontraktem Zanim wdrożenia. Każdy zespół może samodzielnie rozwijać własną usługę w ramach kontraktu API jest już zdefiniowane. 

// OpenAPI spec per il Catalog Service
openapi: 3.1.0
info:
  title: Catalog Service API
  version: 2.0.0

paths:
  /products:
    get:
      summary: Lista prodotti con paginazione e filtri
      parameters:
        - name: cursor
          in: query
          schema:
            type: string
        - name: category
          in: query
          schema:
            type: string
        - name: priceMin
          in: query
          schema:
            type: number
      responses:
        '200':
          content:
            application/json:
              schema:
                $ref: '#/components/schemas/ProductPage'

  /products/{id}:
    get:
      summary: Dettaglio prodotto singolo
      responses:
        '200':
          content:
            application/json:
              schema:
                $ref: '#/components/schemas/Product'
        '404':
          $ref: '#/components/responses/NotFound'

Natywna chmura: elastyczne skalowanie i usługi zarządzane

Natywny w chmurze nie oznacza „działa w chmurze” — oznacza zaprojektowany specjalnie do wykorzystania możliwości chmury: automatyczne skalowanie poziome, tolerancja błędów, obserwowalność zintegrowane:

  • Kontenery Docker zaaranżowane przez Kubernetes (lub funkcje Lambda w przypadku obciążeń sterowanych zdarzeniami)
  • Zarządzane bazy danych (Cloud Spanner, RDS, DynamoDB) zamiast samodzielnie zarządzanych instancji
  • Zarządzana magistrala zdarzeń (AWS EventBridge, Google Pub/Sub) do komunikacji asynchronicznej
  • Globalny CDN do dostarczania frontendu
  • Automatyczny wyłącznik automatyczny i ponowna próba pod kątem odporności

Headless: Frontend wolny od backendu

Wymiar H MACH został już omówiony w pierwszym artykule z tej serii: the frontend zużywa API, nie jest generowane przez backend. W architekturze MACH uzupełnia to często oznacza BFF (Backend dla Frontendu) aby zoptymalizować API dla m.in konkretni klienci: 

// BFF Pattern: GraphQL aggregation layer
// Aggrega chiamate a più microservizi in un'unica risposta ottimizzata

type Query {
  productPage(
    category: String
    cursor: String
    filters: [FilterInput!]
  ): ProductPageResult!
}

type ProductPageResult {
  products: [ProductSummary!]!
  facets: [FacetGroup!]!       # da Algolia
  recommendations: [ProductSummary!]!  # da recommendation service
  pageInfo: PageInfo!
}

// Il resolver fa chiamate parallele a catalog, search e recommendations
const resolvers = {
  Query: {
    productPage: async (_, args) => {
      const [products, facets, recs] = await Promise.all([
        catalogService.getProducts(args),
        searchService.getFacets(args),
        recommendationService.get(args.category),
      ]);
      return { products, facets, recommendations: recs, pageInfo: products.pageInfo };
    },
  },
};

MACH kontra Monolit: prawdziwe porównanie

MACH kontra Monolit: kiedy jest lepiej

  • Zarządzany Monolitem (Shopify, WooCommerce): czas wprowadzenia produktu na rynek w ciągu kilku tygodni, mały zespół, niskie koszty — idealne rozwiązanie dla GMV < 5 mln EUR/rok
  • Częściowy MACH (bezgłowy + best-of-breed): stopniowa elastyczność, średni zespół – idealny dla GMV 5-50M EUR/rok ze specyficznymi potrzebami
  • Pełny MACH: maksymalna elastyczność, wysokie koszty, duży zespół – uzasadnione w przypadku GMV > 50M EUR/rok lub specyficznych wymagań przedsiębiorstwa

Zarządzanie MACH i anty-wzorzec

Najczęstszym błędem we wdrożeniach MACH jest zbyt duża fragmentacja bez zarządzania:

Antywzorzec MACH, którego należy unikać

  • Przedwczesne mikrousługi: Rozłóż na 20 usług podczas obsługi 1000 zamówień/miesiąc to czysta przesadzona inżynieria. Zacznij od modułowego monolitu, po prostu rozłóż części, które skalują się inaczej.
  • Brak wersjonowanych umów API: Bez wersji API, każdy zespół złamie innych podczas wdrażania. Zastosuj OpenAPI 3.1 + wersjonowanie semantyczne.
  • Kaskadowe wywołania synchroniczne: Żądanie wywołujące kolejno 5 usług kumulować opóźnienia. Jeśli to możliwe, używaj wywołań równoległych, wzór CQRS w przypadku ciężkich odczytów.
  • Wspólna baza danych: Jeśli dwie usługi MACH korzystają z bazy danych, nie jest to możliwe naprawdę niezależny. Każda usługa musi mieć własny magazyn danych.

Wdrażaj MACH stopniowo

Nie musisz od razu migrować do MACH. Podejście według wzoru figowego dusiciela zalecane jest:

  1. Faza 1: Dodaj warstwę bez głowy na istniejący monolit. Frontend nowe wywołania API, monolit generuje API poprzez warstwę REST/GraphQL. Żadnych zmian w rdzeniu.
  2. Faza 2: pobierz pierwszą mikrousługę dla funkcji o największych potrzebach specyfikacje (często: wyszukiwanie lub inwentaryzacja). Monolit nadal radzi sobie z resztą.
  3. Faza 3: Kontynuuj odsysanie po serwisie, stopniowo usuwając zależność od monolitu.

Wnioski

MACH to aspiracja architektoniczna, a nie lista kontrolna. Zasady API-first i headless wnoszą realną wartość nawet przy częściowych wdrożeniach. Podział na mikrousługi i rozwiązania natywne w chmurze uzupełniają obraz, ale wymagają dojrzałości organizacyjnej.

W kolejnych artykułach omówimy konkretne wdrożenia: Shopify Hydrogen dla tych, którzy chcą headless w infrastrukturze zarządzanej, Medusa.js dla tych, którzy preferują samodzielne oprogramowanie typu open source, np Sprzedaż dla zespołów Python z natywnymi potrzebami GraphQL.

Poprzedni artykuł ← Bezgłowy handel: co to jest
Następny w serii Shopify Wodór i tlen →