A Pixar usa uma estrutura consistente para desenvolver todas as suas histórias. Basicamente, ela segue o padrão de:
Era uma vez, havia...
- Todos os dias,...
- Um dia,...
- Por causa disso,...
- Por causa disso,...
- Até que, finalmente,..."
Pensei em usar esse estilo para contar uma história sobre bancos de dados multimodais.
Era uma vez os aplicativos eram criados quase que exclusivamente em um estilo monolítico, em que o aplicativo era criado como uma unidade única e indivisível. Essa abordagem foi criada há muito tempo, quando a capacidade de dados era limitada, os bancos de dados eram projetados para uma única caixa e ninguém tinha dispositivos móveis.
Todos os dias as equipes de desenvolvimento trabalhavam usando uma abordagem linear e sequencial em cascata. Dadas as demandas dos aplicativos, bancos de dados e infraestrutura da época, esse método funcionou bem para desenvolver alguns aplicativos bem-sucedidos. Dito isso, ele também tinha suas próprias desvantagens, como o fato de os aplicativos ficarem muito grandes e complicados com o tempo para que uma equipe pudesse entender o que estava acontecendo e como gerenciá-los. Fazer alterações era mais difícil em um aplicativo tão grande e complexo com um acoplamento altamente rígido. Dimensionar os componentes de forma independente não era uma opção e as alterações no código poderiam afetar todo o sistema, portanto, cada alteração precisava ser cuidadosamente coordenada. Em geral, isso tornava o processo de desenvolvimento muito mais longo. E, por fim, poderia ser muito difícil aplicar uma nova tecnologia, pois então todo o aplicativo teria que ser reescrito.
Então, um dia A Internet nasceu e isso mudou tudo. (OK, não foi em um dia, mas fique comigo.) Cada vez mais pessoas estavam se conectando usando navegadores da Web e, eventualmente, telefones celulares, e estavam fazendo isso com mais frequência e em mais lugares. O que veio em seguida foi o aumento da demanda desses usuários por uma experiência mais rica com seus aplicativos. As empresas também queriam oferecer experiências melhores, tanto digitalmente quanto na vida real, aprimoradas pela tecnologia. Mais aplicativos foram criados para interagir com usuários e clientes. Ao mesmo tempo, o armazenamento e a capacidade de processamento tornaram-se muito mais acessíveis. Isso levou a uma explosão de dados.
Por causa disso, novas abordagens para o desenvolvimento de aplicativos começaram a surgir e a crescer em popularidade. Termos como ágil, scrum, kanban, produto mínimo viável e muitos outros entraram em nossa linguagem à medida que essas coisas se tornaram mais populares. Isso levou a uma grande tendência macro do que hoje chamamos de desenvolvimento de microsserviços, que divide as necessidades dos aplicativos em um conjunto de unidades menores e independentes. Essas unidades executam cada processo do aplicativo como um serviço separado. Portanto, todos os serviços têm sua própria função, lógica e banco de dados específicos.
Por causa disso, as equipes de desenvolvimento agora podem criar aplicativos com muito mais rapidez. Como todos os serviços podem ser implantados e atualizados de forma independente, isso proporciona mais flexibilidade aos desenvolvedores. Em segundo lugar, um bug descoberto em um microsserviço tem impacto apenas em um serviço específico e não influencia todo o aplicativo. Também é muito mais fácil adicionar novos recursos a um aplicativo de microsserviço do que a um aplicativo monolítico. Ao separar um aplicativo em componentes menores e mais simples, os microsserviços são mais fáceis de entender e gerenciar. Além disso, a abordagem de microsserviços oferece a vantagem de cada elemento poder ser dimensionado de forma independente. Muitas vezes, o processo é mais econômico e eficaz em termos de tempo do que dimensionar todo o aplicativo monolítico.
No entanto, os microsserviços não são perfeitos e trazem seus próprios desafios. As equipes precisam escolher e configurar as conexões entre todos os módulos e bancos de dados, portanto, todas as conexões devem ser tratadas com cuidado; há preocupações transversais como registro, métricas, verificações de integridade e muito mais. E o teste/solução de problemas pode ser difícil em todos os serviços. E o mais importante é que esse tipo de arquitetura pode levar a grandes desafios com a proliferação de dados.
A proliferação de bancos de dados traz problemas com dados duplicados, movimentação de dados, segurança, integração de dados, inconsistência de informações, latência e aumento de custos. As equipes precisam ter conhecimento do domínio e habilidades de programação em vários idiomas e, em seguida, licenciar e dar suporte a mais tipos de bancos de dados, o que causa desafios técnicos e operacionais que resultam na desaceleração do desenvolvimento.
Até que finalmente, Algumas empresas de banco de dados decidiram consolidar vários métodos de acesso a dados e outros serviços integrados em seus bancos de dados para reduzir os efeitos negativos da dispersão de dados.
O Couchbase armazena dados de forma flexível em documentos JSON, permite acesso rápido a dados de chave/valor na memória, utiliza SQL para consulta, tem pesquisa de texto completo integrada, eventos no lado do servidor e análise em tempo real. Além disso, ele pode retransmitir e sincronizar dados de, para e entre dispositivos móveis e outras coisas conectadas. Isso significa que os desenvolvedores podem aproveitar esses serviços em um único banco de dados, evitando a proliferação de dados e os problemas decorrentes dela. Isso significa que os desenvolvedores e as organizações podem ter um tempo de retorno mais rápido para novos aplicativos e novos requisitos. Não há problemas de latência entre serviços, pois eles estão usando o mesmo conjunto de dados. A análise em tempo real pode ser executada em dados operacionais, não precisa de processamento ETL e pode ser feita de forma a não afetar os processos operacionais. A administração do banco de dados é simplificada, pois está tudo em uma única plataforma. Além disso, com o Couchbase, os serviços podem ser dimensionados de forma independente, como os microsserviços. Os clientes podem querer um hardware otimizado para computação para um serviço e um hardware otimizado para memória para outro, o que os ajuda a adequar o desempenho das necessidades do aplicativo ao banco de dados e à infraestrutura. Nosso cache gerenciado de valor-chave na memória oferece desempenho de milissegundos, sem a necessidade de um produto de cache separado para aprender. O resultado final: Um banco de dados multimodelo que reduz o tempo gasto antes, durante e depois do desenvolvimento do aplicativo, além de reduzir o custo total de propriedade.
Felizes para sempre
Os recursos de vários modelos são necessários em todos os casos de aplicativos? Não, é claro que não, mas eles são aplicáveis em muitos casos, e tê-los implementados ajuda a preparar um aplicativo para o futuro. Portanto, agora as organizações podem obter o melhor das abordagens monolíticas e de microsserviços com o suporte de um único banco de dados.
E os aplicativos podem viver felizes para sempre.
Saiba mais sobre o banco de dados multimodelo do Couchbase
Experimente o Couchbase hoje mesmo com nosso teste gratuito.