Quando o seu alvo é o mercado de SaaS e compete com soluções nativas web, a quantidade de recursos de hardware necessárias para o seu software torna-se um componente extremamente importante para o custo total da solução. Vamos considerar que essa quantidade de recursos é a Envergadura de Hardware necessária para manter o seu ERP voando.
Quanto mais pesada a aeronave, maior a envergadura e mais combustível é necessário para carregar os passageiros. Isso não é necessariamente um problema se você consegue acomodar centenas de passageiros no mesmo avião com passagens acessíveis.
Quer saber mais sobre as diferenças entre aplicações locais, ambiente cloud e o SaaS para o seu ERP? Continue acompanhando a nossa publicação!
Modelos On-Premise versus Nativos Web
No mundo ERP (do inglês, Enterprise Resource Planning), uma solução nativa em cloud é como um enorme avião carregando milhares de passageiros no mesmo voo comercial. A envergadura de hardware é grande mas trata-se de um voo comercial com passageiros de todo lugar compartilhando o mesmo avião. Isso resulta em uma envergadura por passageiro muito menor e, portanto, uma passagem muito mais acessível.
As soluções On-Premise são muito diferentes. A aeronave necessária para os seus clientes se assemelha a um jato privado designado exclusivamente para um cliente. O time de desenvolvimento geralmente assume que cada passageiro ocupa um espaçoso assento com um enorme bagageiro se comparado a um voo comercial. Dessa forma a envergadura por passageiro torna-se muito maior, resultando em custos bem mais altos. Além disso, não se trata de um voo mais confortável, uma vez que o avião é construído com material antigo e processos ultrapassados.
Para oferecer o equivalente a uma passagem competitiva nesse mercado, os tradicionais fornecedores de ERP devem adotar um caminho evolutivo que permita reduzir a envergadura de hardware de suas soluções. Segundo previsão da Gartner, cerca de 50% das soluções de ERP estarão em cloud até o ano de 2023 ainda que, hoje, mais de 80% desses softwares funcionem em ambientes locais. Existe uma oportunidade enorme para os atuais provedores de software criarem seus próprios caminhos para a nuvem sem a necessidade de desenvolver uma solução nativa de cloud. Trocar de ERP, ainda que dentro do mesmo fornecedor, é uma tarefa extremamente árdua que qualquer organização prefere evitar. Entretanto, o provedor de software deve se mover rapidamente para adotar os benefícios do modelo SaaS que os seus clientes esperam.
Base de dados
Um dos componentes mais pesados de um ERP é o seu banco de dados. Você não pode removê-lo da solução mas existem diversas alternativas para deixá-lo mais leve. A primeira delas é trabalhar com alguma forma de multi tenancy na camada do banco de dados. O compartilhamento dos serviços de banco de dados não reduz a envergadura do hardware, mas permite o compartilhamento das caras licenças dos bancos de dados comerciais que podem consumir até 40% do custo total da infraestrutura. Esse custo é ainda mais relevante para soluções do mercado PME com clientes de até 50 usuários, nas quais o custo do servidor de banco de dados é desproporcionalmente alto em relação a solução completa.
A segunda alternativa para aliviar o peso do banco de dados é abandonar as soluções de banco de dados comerciais. Como provedor de software você tem o fornecedor de banco de dados como um parceiro que recebe uma parcela significativa do negócio toda vez que você executa uma venda do seu produto. Companhias como a SAP já se deram conta que grande parte das despesas que o cliente tem com a sua solução estava parando nas mãos da Oracle e da Microsoft sob forma de licenças de banco de dados. Esse modelo funcionou bem por muitos anos, mas a recente pressão de competidores entregando ERP como SaaS está mudando o cenário. ERPs nativos de cloud utilizam uma infraestrutura muito mais eficiente baseada em soluções open source ou pelo menos altamente compartilhadas sobre bancos de dados comerciais. Atualmente, soluções como AWS Aurora apresentam alto desempenho com escalabilidade sem precedentes por uma fração do custo de uma solução comercial tradicional.
Entretanto, sabemos que abandonar soluções com Oracle e Microsoft pode representar um enorme desafio de desenvolvimento. Alguns ERPs confiam uma parte significativa de processamento aos banco de dados e não existe uma saída fácil exceto desenvolver essa camada dentro do próprio ERP. Essa pode ser uma tarefa trabalhosa mas é executada sobre uma tecnologia e ambientes bem conhecidos e pode representar uma redução de até 30% no custo total da infraestrutura. É uma enorme margem que se move do fornecedor de banco de dados para o fornecedor do ERP.
Fat Client
A interface de usuário do cliente também é um ponto de atenção. Ao migrar o servidor de software do cliente para a nuvem, nós devemos executar esta interface dentro do ambiente da nuvem. A abordagem de “Fat Client”, (ou “Cliente gordo” em tradução livre) que é usada pela maioria dessas soluções, requer uma comunicação intensa na camada do servidor, e um pequeno delay no processo pode ser esperado. Não é possível separar o sistema e mover somente o servidor para a nuvem. Migrar o sistema inteiro para a nuvem significa que as especificações de hardware da aplicação cliente se tornam extremamente importantes no custo de infraestrutura. Muitos fornecedores de ERP nunca se preocuparam muito com essas especificações, e estavam acostumados a criar o planejamento assumindo que qualquer usuário possuiria uma grande quantidade de GB de RAM disponível a qualquer momento. A nuvem certamente consegue lidar com isso, mas o custo associado a essa envergadura de hardware se torna uma desvantagem competitiva comparada com as soluções nativas em nuvem.
A camada de apresentação das soluções nativas em nuvem é simplesmente um browser de web bastante leve e com processos simples. O processo mais pesado de carga é realizado pelo servidor em um sistema otimizado de compartilhamento de tarefas para multi tenant. O processo de eficiência é muito mais alto, considerando o elevado número de usuários compartilhando os mesmos recursos.
Com o objetivo de melhorar a eficiência destes “fat clients”, o ISV deve revisar as premissas sobre o ambiente do usuário e adotar uma abordagem mais enxuta. Bibliotecas mais leves, separação em módulos, “garbage collection“, otimização do uso de memória e processos mais eficientes se mantêm em alta nas prioridades do desenvolvimento. Os recursos nativos de nuvem, como por exemplo, armazenagem de arquivos, cachê de sistemas e mecanismos de arquivo mais eficientes/maiores, podem facilmente serem integrados ao sistema com melhor desempenho e custo-benefício, se comparada com a abordagem tradicional on-premise. Temos observado uma redução na envergadura destes “fat clients” em mais de 30%, com impacto direto no custo de infraestrutura, ao mesmo tempo em que se melhora a experiência do usuário.
O Auto.Sky também lida com a virtualização dos “fat clients”. O monitoramento constante permite que a plataforma consiga escalar os recursos da aplicação clientes para cima e para baixo, reduzindo a envergadura média dessa camada da solução. Os recursos da nuvem são cobrados por cada hora utilizada, desta forma, qualquer hora economizada em recursos não utilizados durante períodos noturnos e finais de semana possuem um impacto positivo nos gastos, o qual é automaticamente gerenciado pelo Auto.Sky. Mais de 60% dos recursos de “fat clients” podem ser otimizados quando se utiliza Auto.Sky, comparado a uma simples abordagem de “hosting” tornando essa plataforma uma solução muito mais eficiente para virtualizar qualquer ERP.
Existem alguns desafios para levar uma solução original on-premise ao mesmo nível de eficiência de hardware que uma solução ERP nativo em nuvem. Porém, a fidelização do cliente e o valor das soluções customizadas que esses sistemas oferecem irão manter essas soluções client-server relevantes por um bom tempo. O primeiro passo para oferecer uma passagem de ida para a nuvem é encontrar a envergadura de hardware ideal, desta forma, eles poderão voar levemente por esse novo ambiente.
