Desenvolver um SaaS não é criar um website

30 de novembro de 2016 Por Ramon Durães

A demanda por aplicações entregues no modelo de serviço (SaaS / Software como Serviço) tem crescido ano a ano sendo impulsionado pela nova dinâmica do mercado que busca soluções mais ágeis, eficientes e que realmente e baseadas em uma precificação justa e proporcional ao uso.

A necessidade de modernização das aplicações imposta primeiramente pela demanda do mercado e na sequência pela dificuldade operacional em manter aplicações legadas com alto TCO (Custo de propriedade) tem provocado longas discussões em empresas sobre como transformar o seu legado de produto em serviço.

As ideias mágicas surgem de todos os cantos sempre com a sugestão de ir para a web como se criar um “WebSite” fosse uma transição de um legado histórico e cultural de produto para “serviço”. A prática tem mostrado que as tais migrações não passam de um transporte de um legado em uma tecnologia para a outra tecnologia “moderna” recriando o legado em um mercado altamente competitivo.

Um “Website” hoje é apenas uma das várias possíveis camadas de apresentação e não necessariamente a prioritária para o consumidor conforme cada cenário de negócio. Injetar o código legado e/ou rescrever o código novo usando práticas legadas apenas vai permitir criar o mesmo “produto” com uma possível cara de “WebSite” e você vai chegar na prática ao fracasso no projeto da mesma forma que a maioria das empresas que iniciaram projetos de migração e interromperam no meio do caminho.

A principal diferença para um “WebSite” e uma estratégia de serviço é o conceito operacional. São pontos de vista completamente diferente. Um produto tem um ciclo de atualização, manutenção e operação bem limitado. O serviço você vai posicionar uma plataforma que será o “coração” em tempo real para milhares de clientes ao mesmo tempo e a sua indisponibilidade comprometerá completamente a sua operação e a operação dos seus clientes.

A velocidade de investigação de um bug em um projeto de produto é de horas a dias e no modelo de serviço é minutos e segundos sendo amparado por estratégia de qualidade continua, monitoramento e análises em tempo real durante toda a operação de forma a garantir o menor tempo possível de queda do serviço. Dificilmente você conseguirá ter uma resposta rápida com o seu legado devido a limitações da arquitetura de software passando a ter sérios problemas à medida que o projeto for conquistando clientes.

Ao conversar com clientes eu nunca uso o termo “migração” justamente para a construir uma evolução embasada em um conceito de transformação digital. A modernização tem que ser guiada em conformidade com a necessidade de transição para um novo momento do mercado aproveitando a inteligência construída ao longo dos anos e desenhando um posicionamento aderente ao momento atual com foco no consumidor e necessidades relacionadas.

Em uma rápida tradução é você olhar como fazia o negócio e como consumidor espera que você faça hoje. Baseado nessa premissa projete a sua nova funcionalidade dentro do novo contexto de serviço.

Uma estratégia de serviço na área da aplicação tem que iniciar com premissas básicas como qualidade, reuso, fácil manutenção, alta disponibilidade e principalmente a capacidade de continuidade do negócio. Hoje praticamente todas as empresas que mantém um software convivem com várias dificuldades em evoluir, manter e até sustentar as aplicações e o nosso desafio é justamente impedir que esses vícios se propagem.

Uma estratégia de separação de responsabilidade no barramento de negócio permitirá ter componentes segmentados em microservices escalando os ciclos de maiores requisições garantindo a possibilidade de atender com mais capacidade os itens de negócio mais requisitados. Não adiantar ter o melhor serviço de Cloud e tentar escalar uma aplicação “elefante”.

Como parte de um projeto de serviço é fundamental planejar as API’s da plataforma permitindo expor o negócio em outros dispositivos e aplicações de terceiros orquestrando um ecossistema escalável onde soluções externas podem complementar a oferta de serviços. O ponto principal é que a sua camada de apresentação não necessariamente é o seu “WebSite”.

O nível de qualidade do software, performance e escalabilidade são requisitos fundamentais em uma estratégia projeto de serviço uma vez que você vai concentrar em uma única plataforma o atendimento a todos os clientes. Nessa transição todo o negócio deverá ser envolvido e não somente a equipe de TI uma vez que muda o modelo de licenciamento para assinatura, muda o suporte, muda o marketing, muda o financeiro, muda toda a organização.

No universo de serviços duas métricas são fundamentais durante o monitoramento. O “Mean time to recovery (MTTR)” é utilizado para medir o tempo para se recuperar de um problema e o “Mean time between failures (MTBF)” mede o tempo entre as falhas.

Na prática se você não implementar uma nova estratégia de arquitetura de software e gestão moderna de aplicação jamais vai conseguir atingir uma meta de MTTR em um serviço visto que é muito difícil investigar um problema em uma aplicação altamente complexa. Quanto mais complexo e desorganizado estiver a codificação do software mais tempo se gasta para encontrar um problema e impedir que outros apareçam.

O projeto fundamental é organizar o negócio e isolar corretamente no projeto de arquitetura de software de forma que consiga implementar o desenvolvimento orientado a testes, reuso, barramento de serviços e usando a automação do DevOps, Cloud, Contêineres consiga orquestrar uma gestão ponta a ponta da aplicação garantindo velocidade e produtividade no desenvolvimento, qualidade continua durante todo o projeto e monitoramento.

O software moderno “serviço” não é mais um ser vivo isolado. O ciclo de evolução será continuo e para ser mais transparente e seguro a base de apoio é justamente usar práticas modernas de forma que consiga rapidamente identificar um defeito e eliminar processos repetitivos seja com detecção automática de defeitos e/ou automação de apoio como a plataforma de DevOps do VSTS que colabora validando o código fonte continuamente.

Eu gosto bastante de tratar esse tema por ser uma dor muito grande no mercado e observando como é tratado de forma tão irrelevante ou até mesmo com ingenuidade me veio várias ideias de escrever sobre o assunto.

A transição para o modelo de serviços afeta não somente as empresas que comercializam software e sim qualquer empresa no mercado. A necessidade de adaptação constante e grande volume de usuários indo para o “digital” tem impulsionado esse movimento tornando o modelo de Software as a Service (SaaS) uma premissa.

Até a próxima !!!

Ramon Durães
CEO, 2PC
MVP, Visual Studio
PSM, CSM, LKU

Esse artigo é um oferecimento da 2PC. Entre em contato para modernização de aplicações, Devops, Visual Studio e arquitetura de software.