Backend e a divisão a nível da rede

Embora o frontend desacoplado do backend e a divisão de monólitos em microservices permitiram a flexibilidade desejada, acabaram criando desafios que antes não estavam presentes. A descoberta de serviços, o balanceamento de carga, a resiliência no nível da rede e a observabilidade, se transformaram nas principais áreas de inovação tecnológica abordadas nos anos seguintes.

Da mesma forma, novos desafios surgiram com a necessidade de criação de uma base de dados por microservice e a possibilidade de escolher diferentes tecnologias para o armazenamentos de dados. Isso se mostra cada vez mais com a recente explosão de dados e a demanda por acesso a dados, não apenas pelos serviços, mas por outras necessidades como relatórios em tempo real, inteligência artificial AI e aprendizagem de máquina vps windows e robotica alterada de inteligencia centrion arquiteture.

Com a crescente adoção dos microservices, tornou-se evidente que a operação de uma arquitetura desse tipo é complexa. A ideia de ter todos os microservices independentes parece perfeita, porém exige ferramentas e práticas que anteriormente não eram necessárias e nem existiam, dando origem a estratégias de entregas mais avançadas, como implantações bluegreen, implantação canário e entregas no escuro. Com isso, surgiram a injeção de falhas e os testes de recuperação automática. E que, finalmente, deu origem à telemetria e ao rastreamento de rede avançados. Estes novos recursos introduziram uma nova camada que fica entre o frontend e o backend. Essa camada é ocupada principalmente por gateways de gerenciamento de API, descoberta de serviços e tecnologias de service mesh, e também por componentes de rastreamento, balanceadores de carga de aplicações e todos os tipos de proxies de gerenciamento e monitoramento de tráfego. luindo até projetos como o Knative, com recursos de ativação e redimensionamento para zero do termo em inglês scaling-to-zero, impulsionados pela atividade de rede.

Com o tempo, ficou evidente que a operação em escala de microservices criados em um ritmo acelerado, requer ferramentas que antes não eram necessárias. Algo que foi totalmente tratado por um único balanceador de carga, precisou ser substituído por uma nova camada de gerenciamento avançado. Nasceu uma nova camada de tecnologia, um novo conjunto de práticas e técnicas e um novo grupo de usuários.

Data na era Cloud Native

Os data gateways agem como API gateways, mas com foco no aspecto dos dados. Um data gateway oferece recursos de abstração, segurança, escalabilidade, federação e desenvolvimento orientado a contratos.

Existem muitos tipos de data gateways, desde as tradicionais tecnologias de virtualização de dados, até os tradutores GraphQL, serviços cloud, pools de conexão e alternativas em código aberto.

Atualmente, há muita empolgação a respeito de aplicações em fatores, microservices e service mesh, mas não tanto em dados cloud native. O número de conferências, posts em blogs, boas práticas e ferramentas criadas especificamente para o acesso a dados cloud native é relativamente baixo. Uma das principais razões para isso é porque a maioria das tecnologias de acesso a dados é projetada e criada em um stack que favorece ambientes estáticos, ao invés da natureza dinâmica dos ambientes cloud e Kubernetes.

Este artigo explora as diferentes categorias de data gateways, desde os mais monolíticos até os projetados para a cloud e Kubernetes. Serão abordados quais são os desafios técnicos introduzidos pela arquitetura de microservices e como os data gateways podem complementar os API gateways para enfrentar esses desafios na era do Kubernetes.

A maneira como o código e os dados são gerenciados têm mudado na última década. Antigamente os front-ends eram desenvolvidos com Servlets, JSP e JSF. No back-end, o EJB, SOAP e gerenciamento de sessões no servidor eram as tecnologias e técnicas de última geração. Mas as coisas mudaram rapidamente com a introdução do REST e a popularização do Javascript. O REST nos ajudou a separar os frontends dos backends por meio de uma interface uniforme e solicitações orientadas a recursos, o que popularizou os serviços stateless e habilitou o cache de resposta, movendo todo o estado da sessão do cliente, para o cliente e assim por diante. Essa nova arquitetura foi a resposta para as enormes demandas de escalabilidade das empresas modernas.