MACH é o futuro da arquitetura de TI? Veja por que microsserviços, API-first, SaaS nativo da nuvem e headless são princípios de arquitetura de TI que você precisa adotar.
Um panorama do movimento MACH, seus principais benefícios e o provável impacto futuro para os CTOs
As expectativas em torno da engenharia de software mudaram bastante na última década, impulsionadas pelo movimento DevOps e pela ascensão das tecnologias de nuvem e de seus provedores, hoje onipresentes. A migração em larga escala para o trabalho remoto tornou ainda mais urgente reduzir as dependências entre engenheiros, que sempre foram a principal causa de atrasos em projetos de software.
Segundo um novo estudo, líderes de tecnologia veem o MACH (microservices-based, API-first, cloud-native SaaS e headless) como o "futuro da arquitetura", e 80% pretendem aumentar seus investimentos nessa área no próximo ano e além. Vamos ver os benefícios desses princípios de arquitetura de TI: microsserviços, API-first, SaaS nativo da nuvem e headless.
Microsserviços
A arquitetura de microsserviços parte do princípio de que vários componentes menores de software podem gerar o mesmo valor que um único bloco monolítico. A grande vantagem da migração para microsserviços, porém, é o desacoplamento do trabalho de engenharia. Agora, cada engenheiro pode se concentrar em seu próprio componente, em vez de gastar um tempo enorme tentando se coordenar dentro de um projeto gigante.
A DoiT International é 100% remota, então quebrar nossos projetos maiores em pedaços menores que podem ser distribuídos entre times com pouca coordenação traz benefícios e vantagens evidentes. Não é uma tarefa simples, mas, com a expectativa de entregar valor mais rápido do que nunca, não há outro caminho.
API-first
A arquitetura de software API-first é praticamente obrigatória quando se migra para microsserviços. Mais uma vez, ela permite que times pequenos — ou até minúsculos — de engenheiros criem componentes que se encaixam para formar um todo maior, deixando que os colegas consumam o trabalho em um modelo desacoplado, no estilo de consumo sob demanda. Para quem não é da área, dá para explicar com uma analogia: o motor de um carro tem uma entrada por onde o combustível precisa passar, e não importa o tipo de tanque que o carro tenha, desde que o diâmetro do tubo entre o tanque e o motor seja compatível com os dois. Essa é uma forma simples de explicar as APIs: o tanque é fabricado por uma empresa, o motor por outra, e a única coordenação necessária é documentar o diâmetro do tubo.
Software-as-a-Service nativo da nuvem
O Software-as-a-Service (SaaS) nativo da nuvem é outro pilar fundamental no novo mundo da engenharia de software 100% remota. A virada para a engenharia remota obrigou as empresas a repensarem os data centers "engaiolados", que só podiam ser acessados de dentro do escritório, e a deixar que os engenheiros de software trabalhassem de qualquer lugar. Uma vez cruzada essa linha, cada vez mais empresas que precisam desenvolver software perceberam que não fazia mais sentido manter seus próprios data centers — dava para contar com um provedor de nuvem para cuidar da infraestrutura física por elas.
Do mesmo jeito que uma fábrica não precisa gerar a própria eletricidade e geralmente compra de uma companhia elétrica. A migração acelerada para a nuvem permitiu que os provedores contratassem mais gente e lançassem mais serviços em pouquíssimo tempo. E, como cada vez mais tecnologias de TI passaram a ter uma versão -as-a-service na nuvem, os engenheiros conseguem experimentar novas tecnologias muito mais rápido e a um custo muito menor do que antes.
Antigamente, um engenheiro que quisesse testar um novo banco de dados precisava de alguém para comprar o hardware, de outra pessoa para instalá-lo no data center e ainda de uma terceira para instalar o sistema operacional e o banco de dados naquele hardware. Só depois de receber as instruções de acesso é que conseguia testar o tal banco novo. Hoje, isso tudo é feito com um clique. A nuvem evoluiu de entregar infraestrutura para entregar qualquer tecnologia a um clique de distância, dando flexibilidade cada vez maior para escolher as melhores ferramentas conforme as necessidades de engenharia.
Headless
O headless combina perfeitamente com microsserviços e API-first. Muitas ofertas modernas de software são "multi-head" justamente por causa de backends API-first. Enquanto a lógica de negócio mais complexa roda na nuvem, os dados que ela consome ou gera ficam disponíveis via APIs. Isso permite que outros times desacoplados de engenheiros criem experiências para web, mobile ou desktop de forma independente, com pouca ou mínima coordenação entre os times de frontend e backend.
A abundância de ofertas de SaaS nativo da nuvem, ou "tecnologias-as-a-service", permite que essas experiências de frontend sejam complementadas por tecnologias prontas, gerenciadas pelos provedores de nuvem.
O futuro do MACH
A DoiT é uma empresa cloud-first e 100% remota. Toda a nossa infraestrutura está na nuvem, e nossa única infraestrutura física são os laptops que nossos engenheiros usam para tirar proveito das tecnologias de nuvem e criar pequenos componentes de software que se encaixam no grande produto da empresa.
Alguns anos atrás, quando nosso produto era muito menor, ele dependia fortemente das tecnologias SaaS dos provedores de nuvem, o que nos permitia entregar um valor enorme aos clientes com um time muito pequeno de engenheiros em pouquíssimo tempo. Conforme a empresa e a engenharia foram crescendo, fez sentido criar serviços adicionais como pequenos microsserviços que se integram ao produto maior — em vez de acoplar tudo em um monolito gigantesco e bagunçado.
À medida que avançamos na construção de experiências cada vez mais valiosas para nossos clientes, faz sentido reforçar a aposta no MACH e lembrar os engenheiros, sempre que possível, do porquê isso é tão importante para o nosso negócio. Sempre vai aparecer alguém sugerindo dar um ou dois passos para trás — adotando mais uma tecnologia que teremos de manter por conta própria, ou criando mais um serviço com forte acoplamento entre front e back e sem APIs. Esses movimentos só atrasam a gente, então preferimos manter os releases pequenos, frequentes e valiosos, sem ficar atolados em ideias e conceitos que não seguem o MACH.
Nossa empresa ainda não é membro da MACH Alliance, mas apoiamos a iniciativa. Tornar esses conceitos mais populares e aceitos no mercado só tende a gerar uma experiência de software muito melhor para todo mundo.