Nos nossos últimos artigos, falamos de time-to-market sendo influenciado pela receptividade às mudanças, destacamos temas como testes e estratégias de delivery como aceleradores de entregas para o negócio. Contudo, sabemos que o time-to-market também é alavancado pela escolha tecnológica que as equipes de TI fazem, para ser mais preciso, pelas novas possibilidades que estas escolhas trazem. Negligenciar o potencial de acelerar entregas, pode fazer com que seu negócio fracasse em obter o feedback do mercado antes de um concorrente, ou que seja perdida uma oportunidade única de lançamento de serviço (como o que pode ocorrer com LGPD em 2020 no Brasil).

Pense que mudanças no negócio e na proposta de valor, passam eventualmente por novas aplicações que ficam limitadas em arquiteturas legadas, sendo a experimentação uma oportunidade de evolução. Como contraponto, a experimentação pode assustar os gestores, sendo até mesmo classificada como “capricho das equipes de TI”.

Temos aqui o dilema de utilizar a experimentação para alavancar entregas para o negócio, acelerando o time-to-market.

A capacidade de evolução das Clouds

Em 2018, os três maiores provedores de Cloud anunciaram juntos mais de 2300 novos serviços ou melhorias de serviços ativos. Este número fica ainda mais impressionante se analisarmos o crescimento destes anúncios ao longo dos últimos 15 anos, onde vemos que o número de anúncios dobra, aproximadamente, a cada 1,5 ano.

Fontes: AWS, Azure e GCP. No final deste artigo, detalhamos como obtivemos estes dados. O número de anúncios de cada ano está relativizado à 2018.

Inicialmente, acho que vem à mente da maioria das pessoas, tal como aconteceu comigo, que este crescimento exponencial de funcionalidades é fruto exclusivo dos investimentos em P&D, mas este raciocínio não é necessariamente verdade (pense em empresas como a Tesla e as gigantes farmacêuticas). Se analisarmos os relatórios da AWS de 2017 (by Bloomberg), vemos que apesar do significativo ($22.6 bi) e crescente investimento, há um descompasso entre o investimento e o anuncio de funcionalidades (dobram em 2,5 ano e 1,5 ano, respectivamente). Sem dúvida, estamos diante de uma equação complexa com diversos fatores, tais como: a migração para AWS de clientes de outros provedores, ou a migração de novos clientes que buscam serviços disruptivos. Talvez seja esta a mágica que a AWS conseguiu fazer, como sinaliza a sua VP na reflexão abaixo. Aparentemente, eles encontraram uma dinâmica de equilíbrio entre inovação e evolução de seus produtos (veja o histórico de investimento de outros provedores de Cloud).

“Nosso modelo de negócio encoraja simultaneamente pesquisa, arquitetura, desenvolvimento e manutenção de produtos e serviços, sejam eles novos ou existentes. Por exemplo, nossos times trabalham constantemente em novas funcionalidades para Alexa, e simultaneamente mantem as funcionalidades atuais […]” (Shelley L. Reynolds, AWS VP –  em tradução livre)

Fonte: https://www.bloomberg.com/opinion/articles/2018-04-12/amazon-doesn-t-believe-in-research-and-development-spending

Mas como a experimentação em cloud pode ajudar no time-to-market?

Suponha que um novo conjunto de funcionalidades seja mapeado, a pressão do negócio para ter tudo “rodando” será grande. Eventualmente, estas novas funcionalidades podem encontrar restrições na arquitetura atual, havendo a necessidade de uma revisão. Com isso em mente, vamos listar condições que podem ser favoráveis a experimentação em cloud:

• Curva de aprendizado: muitos serviços podem ser encontrados no marketplace dos provedores de clouds, ou pelo menos, arquiteturas pré-configuradas que facilitam os primeiros passos;
• Serviços especializados: atualmente, os provedores cloud são muito mais do que o tradicional IaaS, tanto que algumas tem se diferenciado pela especialização em alguns serviços quando comparados aos concorrentes;
• Agilidade: elaborar um MVP com serviços de cloud é mais simples do que em ambientes on-premises, especialmente pela característica on-demand dos serviços;
• Disponibilidade: normalmente, os serviços cloud tem a disponibilidade como requisito básico, distribuindo seus serviços em múltiplas regiões e zonas de disponibilidade;
• Opções: enquanto se experimenta, não há nada melhor que opções para a arquitetura analisada. As clouds têm alternativas, seja dentro delas ou entre elas, que permitem que a arquitetura evolua quando necessário;
• Menor esforço operacional: as opções de SaaS ou PaaS são excelentes alternativas para reduzir o volume de trabalho operacional, apesar de aumentarem a dependência do provedor de cloud. Este trade-off pode ser interessante especialmente em fases iniciais dos projetos;

Apesar da ideia de acelerar a entrega sugerir que a resiliência seja tratada num segundo momento, percebemos que a experimentação pode facilitar a busca por estabilidade, especialmente nas empresas que têm a experimentação incorporada em sua cultura.

“[…] Simplificando, um usuário de sistema de telefonia de 99% de disponibilidade não é capaz de diferenciar entre 99,99% e 99,999% de disponibilidade de serviço. Com isso, mais do que maximizar disponibilidade, SRE buscam o equilíbrio entre o risco da indisponibilidade com os objetivos de inovação rápida e operação eficiente, de maneira a manter os usuários felizes com funcionalidades, serviços e performance otimizados.” (SRE book, by Google –  em tradução livre)*

Conclusão

De fato, observamos que novos serviços aparecem com frequência nos provedores de Cloud, sendo assim, utilizar esta capacidade para alavancar a evolução do nosso negócio pode ser um diferencial. Promover a experimentação além de uma vantagem competitiva (fail fast, learn fast!), é uma excelente oportunidade para validar planejamento de gastos em serviços on-demand.

Na prática

Pense no caso onde você deseja abstrair a infraestrutura para reduzir o esforço operacional da sua empresa, inevitavelmente, você passará por discussões como o uso de IaaS, o potencial de containers e orquestradores para adoção de workloads imutáveis (PaaS que aumentam a resiliência), e até que eventualmente, você se depare com funções (FaaS como o AWS Lambda ou Google Cloud Functions). Durante a avaliação, você se considerará inúmeros desafios e vantagens em cada abordagem, até que decida experimenta-la. Neste processo, você pode acabar conhecendo uma nova funcionalidade ou abordagem que pode transformar seu negócio.

Se pensássemos no caso acima, poderíamos falar em transformar a arquitetura atual para usar funções se baseando na premissa de redução de esforço operacional, e como vantagem se deparar com a possibilidade de adotar uma arquitetura event-driven baseada em AWS Lambda, como o caso Netflix vídeo encoding.

Fonte dos dados

Para mostrar a evolução dos anúncios, a gente usou alguns comandos em Bash bem simples, para que qualquer pessoa com um Linux possa acompanhar estes números.

Curiosidades sobre os números:

• Os números estão relativizados a 2018, ou seja, todos os provedores tem o mesmo valor em 2018 (queremos ver só o comportamento);
• Na média, os anúncios dobram a cada 19 meses (aprox. 1,5 ano);
• Na Azure, conseguimos chegar apenas até 2014 no blog;
• No GCP, vemos um comportamento anômalo entre 2013 e 2015, o que ocorre após o lançamento do Cloud Compute Engine em 2012;

Apesar da resistência que alguns têm de misturar o tema SRE e DevOps, isto foi feito propositalmente neste artigo e neste ponto.

Artigo elaborado por Marcus Camillo, sólida experiência em design e operação de TI.