Custos de comutação e bloqueio

Não é surpresa que as organizações estejam preocupadas em ficar presas ao provedor de nuvem. Afinal, a história da TI está repleta de exemplos de fornecedores que se aproveitaram dos altos custos de troca para impor termos restritivos de licenciamento e aumentar os preços. No entanto, acredito que a nuvem seja diferente – e, na verdade, está tornando cada vez mais difícil para os fornecedores de software, hardware e serviços de TI tirar proveito da alavancagem que tiveram no passado.

Esse é um assunto delicado e, como funcionário da AWS, eu poderia estar arriscando meu pescoço. Mas me parece que muito da conversa sobre estar vinculado a um fornecedor não atinge o cerne da questão, então vou reformular a discussão explicando como eu pensava quando era CIO, antes de ingressar na AWS.

Primeiro de tudo, estava bem claro sobre o porquê de estar mudando para a nuvem. Foi principalmente para ganhar velocidade. Nossos prazos para a produção de novos recursos de TI eram muito longos; minha transformação não foi apenas mudar para a nuvem, mas encurtar lead times por meio do DevOps, simplificando nossos processos de governança e supervisão, e criando microsserviços reutilizáveis que poderiam ser rapidamente recombinados para desenvolver novos recursos. Como CIO dos Serviços de Cidadania e Imigração dos EUA (USCIS), eu sabia que mudanças importantes na política de imigração poderiam acontecer a qualquer momento – e quando elas acontecessem, nossos longos tempos de espera seriam inaceitáveis. Eu tinha motivos para acreditar que a nuvem reduziria nossos custos significativamente (acabou reduzindo cerca de 75% dos nossos custos diretos de infraestrutura), mas a velocidade era a primeira em minha mente.

Quais foram meus maiores obstáculos? O conjunto de habilidades dos meus funcionários, por um lado. A maioria deles nunca havia trabalhado em nuvem e também era novo em DevOps e microsserviços. Um segundo impedimento foi o nosso processo de aquisição – com todo o trabalho legal e o processo de seleção de fornecedores, a contratação de um serviço pode levar de seis meses a três anos. E havia um impedimento cultural (OK, muitos, na verdade) em que tínhamos uma cultura de excepcionalidade – as necessidades de TI do governo eram tão únicas que tínhamos que fazer as coisas de maneira diferente do que o resto da indústria considerava como melhores práticas.

Quando considerei usar vários provedores de nuvem para nossa infraestrutura e plataformas, recuei rapidamente da ideia. Eu temia que isso retardasse nossa transformação, e a velocidade era o fator mais importante para mim. Construir nossos sistemas para serem implantados em várias nuvens iria nos custar tempo, mesmo se usássemos containers e ferramentas agnósticas em nuvem. Como eu estava incentivando minhas equipes a aprender a usar a infraestrutura como código, não queria que as complexidades do gerenciamento da infraestrutura em nuvens diferentes atrapalhassem. Com uma abordagem multi-nuvem, eu também teria que reter o uso de serviços específicos para um determinado provedor de nuvem que, de outra forma, poderia nos acelerar. Como as habilidades eram um problema, não queria que meus funcionários perdessem tempo aprendendo diferentes plataformas de nuvem e compatibilidade entre nuvens. Finalmente, para superar nossa cultura de “necessidades especiais”, queria que meus funcionários começassem com o caminho mais simples e direto, assim como outras organizações estavam fazendo.

Por todas essas razões, eu sabia que apostar em mais de um provedor de nuvem teria um grande custo para o que eu estava tentando realizar. O que restou para mim foi considerar os riscos de escolher um único provedor de nuvem e encontrar maneiras de mitigá-los.

Minha linha de pensamento foi: o termo “bloqueio” é enganoso. Na verdade, estamos falando sobre custos de mudança. Os custos de mudança existiram ao longo da história da TI. Assim que você se comprometer com uma plataforma ou com um fornecedor, você terá custos de troca se posteriormente decidir mudar. Se você escolher Java e depois migrar para o Node.js, você terá um custo. Se você escolher o Maven e depois migrar para o Gradle, você terá um custo. Se você decidir sobre um mainframe e, em seguida, passar para o hardware de commodity escalável horizontalmente, isso vai lhe custar. Em nenhum desses casos você está realmente “bloqueado” – você simplesmente tem custos de troca, que podem ser grandes ou pequenos dependendo da situação.

E sempre consideramos esses custos, pelo menos implicitamente, quando tomamos decisões. Se optarmos por usar Oracle como banco de dados para um determinado aplicativo, geralmente não criamos o aplicativo no SQL Server para garantir que não fiquemos bloqueados. Não o fazemos simplesmente porque acreditamos que os custos de ter dois bancos de dados alternativos para o mesmo aplicativo superam os benefícios do gerenciamento de riscos.

Então, eu me perguntei: (1) Quais serão meus custos de troca se eu precisar sair da AWS? (2) Qual é a probabilidade disso ocorrer? (3) E como posso reduzir de forma econômica esses riscos? Com os serviços de nuvem que você paga à medida em que vai usando (com algumas exceções, como instâncias reservadas), você não está desperdiçando dinheiro caso decida trocar de fornecedor. Eu decidi que não fazia sentido, no nosso caso, fazer todo esse trabalho inicial para tornar nossos aplicativos multi-cloud; Como eu disse antes, seria um custo muito grande e eu julguei que a probabilidade de eu precisar deixar a AWS não era tão alta. Em vez disso, eu aceitei que haveria um custo de mudança mais tarde se, por algum motivo, decidíssemos deixar a AWS, então que pudéssemos trabalhar para mitigá-lo.

A primeira área que consideramos para reduzir de riscos de altos custos de mudança foi a arquitetura. Usamos contêineres Docker que esperávamos que fossem implantados virtualmente em qualquer lugar. Criamos microsserviços, em parte com o pensamento de que poderíamos mais tarde decidir colocar alguns serviços em uma plataforma e outros, em outra. Também sabíamos que poderíamos reduzir o “raio de explosão” de alterações em um único microsserviço e testar cada um deles independentemente, caso precisássemos começar a mudar em grande escala. Nós trabalhamos ativamente para acoplar os nossos serviços, especialmente quando se utiliza um serviço específico para AWS, criando uma fachada para cada um deles, para que pudéssemos trocá-lo da forma mais transparente possível.

Uma coisa que não fizemos, mas que você pode querer considerar, é escrever um plano de saída ou de reversão. Dependendo do nível de risco existente, esse plano poderia ser mais ou menos detalhado. No plano, você pode especificar quais seriam os principais custos de mudança se tivesse que sair da AWS e quais etapas você está tomando para gerenciá-los. Também seria possível criar um plano de projeto de alto nível sobre como a saída seria realizada, incluindo uma estimativa de custos. Com esse plano em mãos, você pode tomar decisões embasadas sobre o risco que está assumindo ao se comprometer com um fornecedor de cada vez.

Como mencionei, a nuvem, DevOps e outros desenvolvimentos contemporâneos estão enfraquecendo a influência que os fornecedores tradicionais tiveram em você. Se você está fazendo as coisas que descrevi – acoplamento frouxo, criando fachadas, usando contêineres etc. – você não está só facilitando a troca de provedores de nuvem, está também facilitando a troca de qualquer tipo de provedor de plataforma. Quando você soma o impacto do código aberto aos custos reduzidos de desenvolver suas próprias soluções personalizadas e às ofertas da AWS em plataformas de pagamento conforme demanda (por exemplo, RDS, DynamoDB, e Aurora), seus riscos (ou seja, seus potenciais custos de mudança e a probabilidade de você querer mudar) diminuem rapidamente. Mas não é apenas risco – você também está se beneficiando da inovação que os fornecedores trazem quando precisam competir pelo seu negócio.

Já chega de falar sobre meu processo de tomada de decisão como CIO – falo agora da minha perspectiva como estrategista de empresas na AWS por um momento. Quando você avalia o risco de trabalhar com a AWS, considere que construímos nossa plataforma de nuvem deliberadamente em padrões abertos, como Xen, SQL e Linux, e cada vez mais contribuímos para projetos de open source. Reduzimos os preços 67 vezes, em grande parte na ausência de pressão competitiva para isso. Nossas ferramentas que ajudam você a migrar para dentro da AWS também podem ser usadas no sentido inverso para ajudá-lo a migrar para fora. Tentamos fazer com que seja o mais fácil possível sair da AWS, caso seja sua escolha. Para ser honesto, essa facilidade faz sentido do ponto de vista de negócios, porque também é do nosso interesse reduzir o risco de se trabalhar conosco.

Nosso ritmo de inovação lhe assegura que pretendemos continuar conquistando seus negócios, com o conhecimento de que é possível mudar para outro provedor de nuvem se você optar por isso. Cerca de noventa a noventa e cinco por cento de nosso roadmap é direcionada pelo que nossos clientes nos dizem que querem. A AWS foi pioneira na computação em nuvem e continua a impulsionar seu desenvolvimento.

Está bem. Chega de propaganda. Mas, falando sério, como estrategista da empresa, gostaria de fazer as seguintes sugestões. Primeiro de tudo, se você acredita que o risco de usar um único provedor supera os custos de usar mais de um provedor, vá em frente e trabalhe com vários provedores. Nesse caso, sugiro que você reduza os custos de sua decisão colocando cargas de trabalho separadas em nuvens diferentes, em vez de tentar fazer uma única carga de trabalho implementável em várias nuvens. Se você concordar com meu raciocínio e decidir optar por um único provedor, sugiro que você reduza seus possíveis custos de mudança por meio de uma boa arquitetura, práticas de implantação padrão e um pouco de planejamento prévio.

Há custos de mudança ao escolher uma plataforma em vez de outra e isso sempre ocorreu. Não existe essa coisa de ‘bloqueio’, exceto quando você concorda com isso contratualmente, mas os custos de mudança podem ser altos ou baixos. Por meio de um bom design, e um bom planejamento futuro, você pode reduzir seus custos de troca (de um software tradicional ou de um provedor de nuvem). Em vez de pagar de forma antecipada esses custos de mudança, aceitando uma penalidade de velocidade e custos mais altos (em várias nuvens), talvez você queira reduzir seus possíveis custos de troca e ver se seu fornecedor continua a atendê-lo de forma adequada.

–Mark

@schwartz_cio
A Seat at the Table: IT Leadership in the Age of Agility
The Art of Business Value
War and Peace and IT: Business Leadership, Technology, and Success in the Digital Age

Mark Schwartz

Mark Schwartz é um estrategista de empresas da Amazon Web Services e autor de “The Art of Business Value” e “A Seat at the Table: IT Leadership in the Age of Agility”. Antes de ingressar na AWS, foi CIO do Serviço de Cidadania e Imigração dos Estados Unidos (parte do Departamento de Segurança Interna), CIO da Intrax e CEO da Auctiva. Ele tem um MBA da Wharton, um bacharel em Ciência da Computação de Yale, e um mestrado em Filosofia da Yale.