Este post foi originalmente publicado em: https://vctrlima.substack.com/

A figura abaixo é de um estudo sobre convergência estratégica e exemplifica como uma indústria constituída de um conjunto de empresas, após alguma inovação, tende a imitar, copiar ou mimicar os avanços entre si ao longo do tempo e acaba inevitavelmente por convergir, eliminando, mesmo que parcialmente, não apenas a vantagem competitiva introduzida mas também a rentabilidade média nessa mesma indústria.

Essa modelagem e simulação foram feitas em “Strategy Convergence Creates Opportunities for Strategic Innovators”, por Constantinos C. Markides (London Business School), Erik Larsen e Michael Gary. A ideia foi analisar o movimento convergente de uma indústria em direção a estratégias similares, sejam elas de modelo de negócio, posicionamento, desenvolvimento de produto, inovação tecnológica, eficiência operacional ou qualquer outra. O modelo mostra como com o passar do tempo a distância estratégica entre as empresas tende a diminuir e convergir em pontos próximos entre si, ou seja, pouco diferenciada.

A relevância de difusões e convergências como a descrita acima é algo que costuma ocorrer continuamente e, em velocidades diferentes, dependendo da indústria. São diversos os mecanismos pelos quais isso acontece, e aqui vou listar alguns dos mais comuns:

• observação dos competidores diretos e indiretos, seja por engenharia reversa do seu posicionamento estratégico, modelo de negócios, produtos ou aspectos operacionais;
• acompanhamento e compartilhamento de tendências do mercado: com “feiras da indústria”, congressos, eventos, business schools, think tanks ou venture capitalists que replicam modelos de sucesso em novas regiões e mídia especializada;
• a competição por talentos e perda de talentos para competidores que acabam levando também o know-how

Do ponto de vista de estratégia para produtos digitais, vemos o mesmo acontecendo em diversos produtos e empresas. O modelo de negócios da Netflix e da Amazon Prime Video, por exemplo, é bastante similar, apesar de se posicionarem de formas diferentes e para segmentos de mercados diferentes. O Instagram também possui diversos aspectos relacionáveis ao Twitter ou ao Snapchat, assim como as empresas de varejo online possuem abordagens fundamentalmente similares de experiência, atendimento ao cliente, centro de distribuição e logística de entrega.

A convergência também pode acontecer por diversos quesitos, como:

• modelo de receita: a infinidade de empresas com modelo “as-a-service”, ou subscription based, ou freemium, ou capturando um “take rate” em uma transação, por exemplo;
• modelo de aquisição de usuários/clientes: estratégia de member-get-member/invitation-only ou aquisição por anúncios programáticos, entre diversos outros;
• experiência do cliente e/ou interface/usabilidade de alguma funcionalidade: one click check-out, padrão “busca-lista-detalhe” em catálogos de produtos, signup e onboarding em um produto com selfie ou foto de um documento, por exemplo;
• tecnologia aplicada no produto: desenvolvimento nativo para aplicativos mobile ou escalabilidade horizontal da arquitetura utilizando provedores cloud;
• modelo operacional, processos e métodos: utilização de algum sabor de agilidade — scrum ou kanban, product discovery, OKR e equipe multidisciplinares na concepção ou desenvolvimento de produtos digitais;

São muitos os casos relacionados com os quesitos acima. O Instagram e o Snapchat na competição por stories serve como um exemplo recente, assim como a disputa que vai começar entre o Clubhouse e o Twitter Spaces que provavelmente vai ser caso do mesmo experimento.

Na época da controvérsia em relação ao Snapchat Stories e o Instagram Stories, o VP de produto do Instagram disse o seguinte em um entrevista:

“Se formos honestos com nós mesmos, essa é a forma como a indústria de tecnologia funciona, e francamente é assim que todas as indústrias funcionam. Boas ideias começam em um lugar e se espalham ao longo de uma indústria. ‘Kudos’ para o Snapchat por ser o primeiro a conceber o Stories, mas ele é um formato e que vai ser adotado amplamente em diferentes plataformas.”

Muito consciente do fenômeno de convergência e difusão de “boas ideias”, a frase do Kevin Weil pede pelas próximas perguntas:

Quando é melhor você ser o primeiro a se movimentar em um mercado e indústria trazendo uma inovação ou buscando um novo posicionamento estratégico?

Ou quando é melhor que você apenas monitore e siga os seus competidores construindo em cima do que já foi desbravado e se beneficiando de mais informação?

Vamos tentar trazer alguns aspectos de cada uma das estratégias para tentar responder a elas.

A vantagem do first-mover e o papel do follower

Na essência do movimento convergente em uma indústria estão dois papéis: o da empresa que faz um primeiro movimento em direção a algo novo e a(s) empresa(s) que acompanha(m) esse movimento, potencialmente, executando-o da mesma forma.

Entre os mecanismos que determinam as vantagens de ser um first-mover, os dois mais importantes são: o controle de recursos escassos e a relação com o custo de mudança (switching costs) do comprador.

O controle de recursos escassos tem ligação com a capacidade de se estabelecer como o primeiro a explorar recursos que só estarão disponíveis para a empresa que for a primeira a se movimentar para aquele espaço, por exemplo, a garantia de direitos de streaming de eventos esportivos quando concedidos exclusivamente para um player que foi o primeiro a se posicionar naquele segmento. Movimentos como esse fazem com que os ‘followers’ encontrem dificuldade em se posicionar pois tais recursos já estão sob posse exclusiva do ‘first-mover’.

O segundo mecanismo mais importante está ligado ao custo de mudança do comprador, em outras palavras, o quão difícil é para um comprador mudar de produto ou serviço para um competidor depois de ter adquirido a solução do first-mover? Se for custoso para o comprador mudar para outro serviço e produto, a vantagem em ser um first-mover é claríssima.

No entanto também existem aspectos negativos em ser um first-mover. Um deles é o fardo de lidar com toda a incerteza do mercado relacionado ao seu movimento. Por exemplo: esse movimento será aceito pelos clientes e pelo mercado? Quais impactos isso pode ter na sua marca e posicionamento?

Além disso, assim como falamos anteriormente, existem os efeitos de “free riding” e “copy cat”, nos quais os seus competidores se aproveitam do aprendizado obtido no mercado e com os consumidores para se beneficiar, introduzindo potencialmente produtos e serviços melhores, com menos incerteza e cujo o público-alvo já tenha superado parte da curva de aprendizado relacionada ao movimento para um posicionamento diferenciado.

Para os “followers”, ou empresas que se movimentam tardiamente, abordagens como estudo criterioso do seu competidor e engenharia reversa dos seus movimentos, assim como no outro extremo uma posição mais agressiva de aquisição e fusão de empresas, como foi o caso do Facebook com o Whatsapp e Instagram, por exemplo, podem ser alternativas viáveis para se defender de ‘first-movers’.

O ponto central dessa discussão é que a convergência em uma indústria, seja ela em geral ou em âmbitos mais restritos, como o de produtos digitais, é um fenômeno conhecido. Portanto, é essencial ter a habilidade de sistematicamente mapear o mercado, escolher os competidores pertinentes para o seu posicionamento e saber quando o primeiro movimento deve ser seu e da sua empresa ou quando o melhor movimento é esperar e seguir de acordo com o feedback do mercado.

Conclusões

• É natural acontecer um movimento de convergência dentro de uma indústria. Esteja consciente disso.
• As formas como a difusão de uma inovação acontece em uma indústria são diversas, no entanto atente-se à transferência de conhecimento ao perder talentos para competidores, acompanhamento e compartilhamento de tendências da indústria, e faça a observação direta dos seus competidores em diversos quesitos.
• Avalie sistematicamente os seus competidores em quesitos como: modelo de negócio, modelo de receita, modelo operacional, funcionalidade e usabilidade dos seus produtos, tecnologia adotada e outros.
• As vantagens em ser um first-mover ou follower dependem da circunstância, porém aspectos como acesso a recursos escassos e custo de mudança alto para o comprador podem indicar uma vantagem para o first-mover, assim como custo alto para introduzir uma inovação e os seus impactos na marca, curva de aprendizado do cliente, aceitação do mercado e P&D para desenvolvimento da mesma podem indicar uma vantagem para os followers

Escute também =)

A Produto pelo Mundo entrevistou a alguns meses atrás o Marty Cagan, que dispensa apresentações obviamente, mas eu sempre gosto de referenciá-lo quando o tema é produto. Vale a pena ouvir de novo para quem já ouviu, e para quem ainda não ouviu, recomendo. O conteúdo é muito bom!

https://produtopelomundo.captivate.fm/episode/martycagan

Em tempo, saiu recentemente uma versão em português do Inspired, que tive o prazer de participar, junto com uma equipe fantástica do time de produtos digitais da Accenture, na revisão técnica do conteúdo. Foi trabalhoso, mas o resultado foi gratificante porque ajuda a avançar um pouco mais a agenda de produtos no Brasil.

• Agradecimentos pela revisão técnica junto comigo: Gustavo Gontijo, Jessica Panhoca, Luciana Shinohara, Mohamad Jameh, Renata Dias, Renato Monteiro, Theo França.

É isso! Ficou alguma dúvida ou tem algo a dizer? Aproveite os campos de comentários. Até a próxima!

Convergência estratégica em produtos digitais was originally published in Accenture Digital Product Dev on Medium, where people are continuing the conversation by highlighting and responding to this story.

Nossa intenção criando o NextStack é criar uma stack de desenvolvimento rápido, que consiga não só prototipar projetos, mas também entregá-los com ótimo desempenho e excelente qualidade de código.

Exatamente para reduzir custo e tempo, estamos deixando de lado o desenvolvimento nativo. Não por ser pior ou melhor, mas por não contribuir com a agilidade de desenvolvimento mantendo o custo baixo.

Neste post, vamos fazer algumas reflexões rápidas para a escolha desse framework (Flutter) em comparação com os demais.

Popularidade

Existe uma série de frameworks que atendem esse paradigma multiplataforma, porém os mais populares são o ReactNative e o Flutter.

Flutter está em um crescimento acelerado ano a ano e canibalizando parte do mercado do ReactNative exatamente por resolver problemas que o ReactNative não estava conseguindo resolver em tempo hábil.

O grande problema com ReactNative é a forma com que os pacotes finais são criados. Esse resultado é realmente compilado e otimizado com componentes nativos, mas esse processo é uma transpilação que resulta em um código final diferente do que foi criado.

Com isso, temos o problema que de fato não temos uma base de código única e sim uma base de código que é transpilada para múltiplas plataformas. Por isso, a manutenção do ReactNative é algo a se analisar relato a relato. A performance também é algo que varia bastante com o dispositivo e o OS nos quais você está executando. Além disso, até mesmo os componentes gráficos variam, pois eles utilizam os componentes nativos do OS e não os que foram usados no desenvolvimento.

Por que Flutter?

Flutter tem o funcionamento diferente. Ele é parecido com uma engine de jogos que te dá um motor base (SKIA) e nele você realmente executa o mesmo código em todas as plataformas. O Flutter garante a consistência do motor em todas as plataformas e você apenas se preocupa com o código.

Supporte e Ferramentas

Flutter também vem com uma gama de ferramentas para desenvolvimento. Um recurso que parece simples e bobo e vejo poucos comentários é seu suporte web integrado.

Com isso, apenas com o Flutter e o Chrome você consegue começar a desenvolver um aplicativo que depois pode ser compilado para iOS ou Android. Ou seja, para começar uma prototipagem e fazer experimentos não é necessário baixar grandes SDKs do XCode ou do Android Studio com emuladores pesados e lentos. Apenas um VSCode, Chrome e o SDK do Flutter. Leve, simples e direto.

• Hot Reload
• Ambiente replicável, consistente e leve para desenvolvimento
• Linguagem 100% tipada, o que evita erros de runtime
• Auto Complete como Intelisense em vários IDEs

REALMENTE multiplataforma

Diferente do ReactNative, que tem o foco em aplicativos mobile, o Flutter foi criado para rodar em qualquer ambiente, seja celular, desktop e até mesmo um navegador.

Com isso, temos a flexibilidade absoluta de criar uma aplicação móvel otimizada para iOS ou Android e disponibilizar a mesma aplicação em um formato web móvel (sem precisar baixar o app, via navegador) ou desktop!

Imagine uma aplicação de planilha muito pesada que você pode compilar para desktop e ter toda a vantagem de execução nativa no seu computador?

WASM

Uma última cartada do Flutter é o seu suporte prévio ao WASM. Devido a sua arquitetura, com um motor por debaixo do framework, é possível que esse motor seja otimizado para novas tecnologias como WASM que executa o codigo arbitrário com performance similar à nativa no navegador.

As possibilidades disso são infinitas. Como no exemplo da aplicação que carrega planilhas e tem grande processamento, com WASM nem sequer precisaríamos que o usuário baixasse o aplicativo, ele rodaria nativamente no navegador com performance máxima!

Dart

Um dos grandes trunfos ocultos do Flutter é sua linguagem praticamente dedicada chamada Dart. Sua vantagem sobre um ReactNative que utiliza Javascript é a orientação a objetos e ser fortemente tipada em simultâneo, flexível.

Como tudo no Flutter são objetos passados para frente, é possível em tempo de código descobrir problemas bobos de tipagem e de implementação de interfaces além, é claro, de evitar esses problemas em runtime, coisas que Javascript tem evoluído com Typescript mas ainda é pouco adotado em aplicações mobile.

Além disso, Javascript já se consolidou como uma solução não performática para aplicativos em ReactNative em celulares pouco potentes devido ao seu grande overhead de execução. A comunidade se esforça muito criando novas formas de otimização estendendo o Javascript com novas funcionalidades como o ahead-of-time para diminuir o tempo de loading, mas mesmo assim essas ações podem ser consideradas paleativas e não uma escolha de arquitetura robusta.

Performance e Otimização

Atualmente, o Flutter usa SKIA como seu motor base. Porém, no futuro, é possível que esse motor evolua para tecnologias mais modernas, permitindo ainda mais performance sem a necessidade de mudança da base de código das aplicações. Esse processo é bem usual no mundo dos jogos, no qual novas engines mais otimizadas sempre são lançadas. Apenas atualizando o motor, são grandes os ganhos de performance.

Outro ponto importante é que devido à arquitetura do motor do Flutter podemos receber atualizações que melhorem a performance, tamanho final do pacote APK/APP e etc. apenas atualizando a versão.

O Flutter tem como foco oferecer aplicativos que rodem em 60fps e até mesmo 120fps para novos celulares com telas de mais refresh rate.

Novamente todas essas preocupações de performance são centralizadas e unificadas no motor que recebe melhorias não só do Google como da comunidade opensource.

Bala de Prata?

Todos os argumentos que levantamos nos convenceram que o Flutter pode ainda não ser uma bala de prata devido a ser uma tecnologia tecnicamente ainda emergente.

Porém, acreditamos que tenha o potencial de resolver uma grande quantidade de problemas em desenvolvimento de aplicativos de vários tipos. Uma prova disso é o uso do Flutter por parte da Canonical no instalador do seu sistema operacional Ubuntu.

Conclusão

O Flutter atende todas as nossas expectativas de uma tecnologia REALMENTE cross-plataform permitindo criarmos até aplicações nativas desktop com performances incríveis além de possuir toda uma comunidade de ferramentas para desenvolvimento e um futuro não só ao nível de comunidade e novas bibliotecas, mas também ao nível tecnológico. Incrível!

ReactNative pode ser considerada uma plataforma mais antiga e consolidada, porém quando paramos para analisar seu funcionamento vemos falhas grandes na arquitetura que limitam o crescimento (ReactNative pouco mudou nos últimos anos).

Temos certeza que ainda faremos grandes descobertas sobre esse framework e vamos compartilhá-las no futuro.

Referências

• PWA vs. Flutter vs. React Native vs. Native
• Top 10 Reasons Flutter Is Better For Your App Development
• Why I’m choosing Flutter in 2022
• Why Use Flutter for Building Cross-Platform Apps?
• Flutter desktop vs Electron: Why to choose Flutter for your next desktop app | Codemagic Blog
• Flutter vs React Native - What to Choose in 2022?

[NextStack] Por que Flutter? was originally published in Accenture Digital Product Dev on Medium, where people are continuing the conversation by highlighting and responding to this story.

Começamos hoe uma série de posts para ilustrar e defender uma iniciativa chamada de NextStack, que tem por objetivo gerar conhecimento de forma empírica. Como esses posts são preliminares, também vamos usar outras referências na literatura para validar nossos preconceitos.

Haiaku

Haiaku é o nome do pet project que vamos criar para adquirir capacidade técnicas nas tecnologias escolhidas. O projeto é uma aplicação web/mobile que consome uma API com ferramentas para desenvolvimento ágil.

A intenção desse é criar cenários reais de desenvolvimento de software para que consigamos gerar conhecimento das tecnologias de forma empírica. Esse conjunto de tecnologias que vamos utilizar estamos chamando de NextStack.

NextStack

Para desenvolver o Haiaku precisamos de uma stack sólida de tecnologias para criar tanto o back-end quando front-end. No back-end precisamos criar uma API para dar suporte ao aplicativo web/mobile, e, para isso, precisamos, por sua vez, de uma linguagem de programação robusta.

O termo robusto é muito vago e por isso criamos a seguinte lista de itens que precisamos avaliar:

• [ ] Comunidade
• [ ] Aprendizado Rápido
• [ ] Desenvolvimento Rápido
• [ ] Escalável
• [ ] Baixo uso de RAM
• [ ] Tempo de Processamento
• [ ] Ferramentas

A seguir, vamos discutir cada um desses itens:

Suporte e Comunidade

De nada adianta escolhermos uma linguagem com uma comunidade morta. Sem uma comunidade, a resolução de problemas se torna mais difícil e a evolução do ecossistema e manutenção da linguagem é lenta ou inexistente.

Na lista abaixo temos as linguagens mais populares do StackOverflow em 2021. Vamos usá-la como ponto de partida para selecionar linguagens populares, que é um bom indicativo de uma comunidade ativa.

Se fizermos uma limpeza das linguagens que não servem para criar backends (html, CSS, etc) e agruparmos algumas linguagens temos a seguinte lista:

• JS/Node/Typescript
• Python
• Java
• C#/C++/C
• Go
• Rust

Javascript pode ser considerado parte do “Current Stack” dos projetos que mais tenho visto sair aqui nos times de produtos digitais da Accenture. Ela é uma linguagem fácil de aprender, popular e funciona tanto para back quanto front-end.

Apesar disso, Javascript não é uma linguagem bala de prata e possui seus problemas, como grande consumo de memória e baixa performace comparada a outras linguagens mais “modernas”.

Outro problema é a tendência natural dos projetos Javascript ficarem “caóticos”. Apesar do JS ter amadurecido para projetos grandes, principalmente com a criação do Typescript, no fim do dia o Typescript nada mais é que arquivo JS e ele vai sofrer dos mesmos problemas fundamentais.

Por ser considerado parte do “Current Stack”, vamos usar JS como referência para as comparações a seguir.

Uso de recursos e Performance

Nesse projeto queremos utilizar uma arquitetura Serverless afim de simplificar nossa infraestrutura cloud ao mesmo tempo em que reduzimos custo e delegamos (boa parte) a responsabilidade de disponibilidade para o cloud provider.

Uma arquitetura Serverless se beneficia grandemente de execuções rápidas e pouco uso de memória RAM, que influenciam diretamente no custo da aplicação. Por isso precisamos de uma linguagem rápida, leve e performática. Dito isso, mesmo que não fôssemos usar Serverless a escolha da linguagem se mantém válida pelos mesmos motivos.

Para comparar esses valores usamos o site Benchmark Game que compara múltiplos algoritmos rodando em múltiplas linguagens dizendo dentre outras coisas o tempo de execução e de memória. Não consideramos isso uma forma ideal de comparação de linguagens mas é um excelente ponto de partida.

Pelos dados do site conseguimos eliminar algumas linguagens que ficam consideravelmente atrás de um segundo grupo mais performático. Com isso temos a seguinte lista filtrada:

• C#/C++/C
• Go
• Rust

A eliminação de certa forma é meio óbvia: removemos JavaScript, Python e Java. Linguagens compiladas (quase) sempre são mais performáticas que linguagens interpretadas. Java em especial é infamemente conhecida por comer mais RAM do que o Chrome e conseguimos ver isso nas execuções do Benchmark Game.

Algumas comparações que merecem destaque são Go vs JavaScript, na qual podemos ver que em alguns casos Go mostra até 30x menos uso de RAM e até 2x menos tempo de execução em alguns casos. O resultado comparado a Python e Java se mantém na mesma magnitude.

Comparando Go com Rust vemos que Rust tem ainda menos uso de RAM com execução até 3x mais rápida. Esse pulo incremental de performance vem com o custo de uma linguagem mais complexa e com maior curva de aprendizado. Por sua vez, Rust comparado com C se mantém próximo da família C.

Aprendizado e Desenvolvimento Rápidos

A família de linguagens C são globalmente consideradas difíceis de aprender e mais ainda de ter maestria. Por isso, vamos removê-la logo de cara e, assim, restam apenas Rust e Go.

Confesso que gostaria de uma oportunidade para aprender mais Rust, porém, como consultoria, precisamos entender o cenário econômico-social em que as linguagens se encontram.

Em resumo: faltam profissionais de TI, logo precisamos de uma linguagem de fácil acesso que permita que novos desenvolvedores aprendam de forma rápida. Além disso, time-to-market é uma variável cada vez mais crítica, então precisamos de uma linguagem que permita desenvolvimento rápido.

Considerando as duas linguagens restantes, Go ganha no quesito de velocidade de aprendizado e desenvolvimento. Na verdade esse é um ponto de grande divergência entre as linguagens. Go preza pela simplicidade e quase minimalismo, enquanto que Rust possui uma quantidade de ferramentas que muitos desenvolvedores se sentem até overwhelmed.

Escabilidade

Por se tratar de uma linguagem que será usada para criar uma API precisamos que ela seja capaz de escalar, ou seja, de atender uma crescente quantidade de pedidos em um tempo determinado.

Neste link temos um comparativo entre Elixir, Go e Nodejs na visão de escalabilidade e quantidade de chamadas de API e Rede. Nele, vemos que Elixir e Go se comportam de forma muito parecida, mas Nodejs fica a desejar em alguns pontos, como o tempo de latência.

Uma das comparações mais interessantes para este tópico é o gráfico abaixo:

Nele podemos ver que Go e Elixir se mantêm extremamente próximos ao tempo de resposta de 100ms de timeout imposto na aplicação. Isso é mais que 75% menor que a do Nodejs. Também é importante vermos que não só a média é menor como também se mantém super estável ao longo da execução, ou seja, o tempo de resposta do Go é mais consistente, o que indica que o processo roda com mais “folga” que o do Nodejs.

Ferramentas

Um último ponto vital é o ecossistema e ferramentas disponíveis para as linguagens. Comparado com JavaScript, o Go e o Rust possuem bem menos ferramentas disponíveis, porém as que existem já garantem um ecossistema robusto.

Dentre elas temos ferramentas nativas de gestão de pacotes, formatação de código e bibliotecas nativas para uma vasta quantidade de problemas.

Conclusões iniciais

Não foi nossa intenção comparar à exaustão as linguagens disponíveis para o projeto. Neste post apenas tentamos levantar os pontos que consideramos mais importantes para nosso cenário, que apesar de específico engloba boa parte das soluções que trabalhamos. Se quiser saber mais detalhes, recomendo os links de referência no final do post.

No final, Go atende todos os nossos requisitos previamente listados e vamos é por isso que vamos usá-la para criação da API. Fiquem ligados que logo tem mais posts sobre nossa experiência prática no uso da linguagem para criação de APIs. Até lá!

Referências

• Stack Overflow Developer Survey 2021
• Rust vs Go in 2024 - Bitfield Consulting
• The Tao of Go - Bitfield Consulting
• AWS Lambda Go vs. Node.js performance benchmark: updated 🔥 | HackerNoon

[NextStack] Por que Golang? was originally published in Accenture Digital Product Dev on Medium, where people are continuing the conversation by highlighting and responding to this story.

O que é o Terraform?

O Terraform é uma ferramenta para construir, alterar e configurar uma infraestrutura. Isso pode ser feito tanto localmente quanto remoto, e hoje o Terraform trabalha com os principais Cloud Providers do mercado. Se você quiser conferir essa lista, é só clicar aqui.

Neste post, além de apresentar o Terraform, vamos fazer também um pequeno hands-on para você que está tendo o primeiro contato com a ferramenta. Para isso, vamos utilizar a AWS como Cloud Provider, que possui um nível gratuito (free tier) para até 12 meses de uso de alguns de seus recursos com limites pré-estabelecidos, mas o suficiente para o que vamos ensinar hoje. Então vamos?

Para nos comunicarmos com a AWS, vamos precisar de duas chaves: aws_access_key e aws_secret_key. Essas chaves são criadas por você durante a configuração de sua conta (link) e elas devem ser configuradas em seu computador utilizando o aws-cli.

Mãos à obra!

Crie um diretório para trabalhar e, dentro dele, crie os seguintes arquivos:

No arquivo main.tf , vamos incluir o nosso provider AWS.
Estamos declarando também onde nossa infraestrutura será provisionada:

Para saber mais sobre Regiões e zonas de disponibilidade, clique aqui.
E aqui tem um exemplo de como o provider é declarado:

Agora vamos falar um pouco sobre cada arquivo

No arquivo ec2.tf vamos declarar a nossa instância (instance_type). A t2.micro está dentro do free tier, e estamos citando o script.sh que vai instalar o nginx.

Aqui também citamos o security group, que vai se comportar como um firewall para a nossa instância, liberando apenas as portas necessárias.

Abaixo, o conteúdo do arquivo script.sh

O output.tf utilizamos para que no final da execução do nosso código nos seja apresentada alguma informação desejada.

No caso, aqui será uma url para acessarmos a instância via browser.

Por meio do security-group.tf, declaramos as portas abertas de entrada e saída. Também podemos limitar esses acessos via ip.

Estamos utilizando variável, e caso precise alterar o ip de acesso, alteramos em apenas um lugar.

As variáveis citadas acima serão declaras no arquivo vars.tf.
Não se esqueça de incluir o seu ip para poder acessar.

Sobre os comandos que vão ser executados

terraform fmt vai verificar a sintaxe do seu código de acordo com a versão do Terraform que você esta utilizando.

terraform init vai realizar diversas tarefas dentro do nosso diretório. Uma delas é baixar as informações necessárias para nos comunicarmos com a AWS. Ex:

terraform plan aqui criamos um plano de execução e podemos ver o que o terraform vai criar. No final do plano apresentado será exibida a seguinte informação:

terraform apply executamos o plano proposto no terraform apply. Digite yes quando a confirmação for solicitada.

Após a execução, receberemos o que foi proposto no arquivo output.tf.

Para testar, basta executar o comando:

Pronto! Agora vamos logar no console da AWS e verificar o que foi provisionado:

Nossa EC2

Nosso grupo de segurança

terraform destroy como o nome já diz, destruímos o que foi provisionado. O Terraform vai lhe informar o que será destruído e você precisa confirmar:

E é isso!
Se você quiser ver o código completo, o repositório está no Github. E se você tiver alguma dúvida ou comentário, é só aproveitar os campos abaixo. Para trabalhar com um time que está se aprimorando a cada dia, é só dar uma olhada aqui e se candidatar a uma de nossas vagas. Vamos aprender juntos!

Introdução ao Terraform was originally published in Accenture Digital Product Dev on Medium, where people are continuing the conversation by highlighting and responding to this story.

Existem vários Property Wrappers usados para facilitar o desenvolvimento com SwiftUI. Neste tutorial vamos entender de forma simplificada o significado e o caso de uso do @State, @StateObject, @EnvironmentObject, @ObservedObject, @Binding, e @Published (esse último do Combine).

Fluxo de Estados e Informações

O fluxo de informações dentro do App com SwiftUI influencia diretamente no comportamento da interface, pois a mesma sempre se adapta ao estado que estiver.

Como podemos observar a View reage ao estado que possui. O estado por sua vez é alterado por uma ação. A ação pode ser gerada por um usuário que interage com a aplicação ou um evento externo que publica alterações (podendo ser algo assíncrono).

Abaixo vamos entender como podemos utilizar os property wrappers para lidar com os estados dentro de nossas aplicações:

@State & @Binding

Podemos entender de uma forma prática que ambos @State & @Binding, são dedicados a armazenar e referenciar valores respectivamente. A diferença entre esses tipos se dá na forma como referenciam a informação:

• @State = Propriedade que contem (é dona) do valor em si. Possui um valor atribuído diretamente a ela.
• @Binding = Referência (e assiste) uma instância atribuída. Esse tipo de variável, por ser uma referência, possui o comportamento de retornar o valor da variável original atribuída e ao mesmo tempo propagar alterações para a variável original.

Ambas variáveis declaradas como @State & @Binding, podem influenciar no comportamento da View em que estiverem declaradas.

Vamos verificar alguns exemplos:

Exemplo prático: Comunicação entre 2 Views na mesma tela

Vamos verificar na prática, utilizando 2 Views que representam um sistema contador de números inteiros. Essas 2 Views vão representar:

• View Status do Contador: Mostra o número total atual e possui uma outra View (View Ação do Contador).
• View Ação do Contador: Possui um botão para aumentar o número inteiro. Possui um fundo azul (apenas com objetivo didático, para deixar visível a área dessa View).

Abaixo podemos ver o exemplo funcionando na prática:

Como podemos ver, nessa View principal temos um texto com o total, seguido de uma outra View filha (com fundo azul) contendo o botão para incrementar o contador. Visualizando as estruturas das duas Views separadamente temos o seguinte:

O código da primeira View (CounterStatusView) que contem o status é o seguinte:

Referente a CounterStatusView, a variável do tipo Int com Property Wrapper @State é declarada na linha 7. Essa variável recebe um valor da propriedade de fato (no caso o inteiro 0). Essa View possui em sua estrutura vertical (VStack) os seguintes itens:

• Texto de título "Counter"
• Texto informando o total "Total is counter" (sendo counter uma referencia a variável marcada como @State)
• Uma View filha ConterActionView que recebe um parâmetro para assistir com um @Binding referenciando a variável @State. O binding é passado como parâmetro utilizando o "$" na frente da variável, simbolizando que é apenas uma referencia a variável.

O código da View filha (CounterActionView) é o seguinte:

Na struct CounterActionView, podemos observar que a variável counter do tipo Int é declarada na linha 7, possuindo o Property Wrapper @Binding. Dessa forma essa variável passa a ser uma referência, ou seja, um observador da variável passada a essa View em sua inicialização. A referência a variável será obrigatória no momento de inicialização da View (como na linha 27 dentro do preview onde é passado uma constante apenas para visualizar).

Exemplo prático: Comunicação entre 2 Views em telas diferentes

Vamos verificar na prática, utilizando como exemplo a comunicação entre 2 telas que representam um sistema de ativação:

• Tela de Status: Mostra se o estado é ativado ou não e um botão para a tela de gerenciamento do status.
• Tela de Gerenciamento do Status: Mostra uma botão para alterar o status e um outro botão para voltar.

Abaixo podemos ver o exemplo funcionando na prática:

O código da primeira tela, que mostra o status da ativação é o seguinte:

O resultado visual da ActivationStatusView é o segunite:

O resultado da ActivationStatusView é uma view que varia de acordo com o status da variável booleana isActivated que possui o property wrapper @State (declarada na linha 7) da seguinte forma:

• Quando isActivated é verdadeiro: O texto apresenta "Status: ON" e o circulo fica verde.
• Quando isActivated é falso: O texto apresenta "Status: OFF" e o circulo fica vermelho.

Além disso ao clicar em Change, o botão altera o valor de isShowingSheet, que por sua vez apresenta a tela ActivationManagerView, que vamos ver em seguida:

O resultado visual da ActivationManagerView é o segunite:

O resultado da ActivationManagerView é uma view que varia de acordo com o status da variável booleana isActivated que possui o property wrapper @Binding (declarada na linha 7) que esta observando a variável do tipo @State declarada na tela anterior (ActivationStatusView) da seguinte forma:

• Quando isActivated é verdadeiro: O botão apresenta o texto “Update to OFF”.
• Quando isActivated é falso: O botão apresenta o texto “Update to ON”.

Ao clicar no botão Update to ON, o botão altera o valor de isActivated, que por sua vez é apenas uma referência a variável @State declarada na tela anterior (ActivationStatusView).

@StateObject & @ObservedObject

Esses dois Property Wrappers funcionam de forma semelhante aos explicados anteriormente. A diferença é que lidam com objetos customizados. Conforme criamos abstrações para nossa aplicação, podemos fazer que esses objetos sejam "observáveis", permitindo outras Views referenciarem ele como um estado. Para tornar seu objeto "observável", é necessário que ele esteja em conformidade com o protocolo ObservableObject. Dessa forma podemos observar as propriedades marcadas como @Published do nosso objeto. Vamos entender esses dois termos então:

• @StateObject = Associado a variável que contem (é dona) da instância do objeto que conforma ObservableObject. Possui uma instância atribuída diretamente.
• @ObservedObject = Referência (e assiste) uma instância atribuída.

Vejamos alguns exemplos abaixo:

Exemplo prático: Comunicação entre 2 Views na mesma tela

Vamos voltar ao nosso exemplo do sistema contador. Toda interface apresentada anteriormente vai se manter a mesma. Nesse caso para exemplificar o uso do @StateObject e @ObservedObject vamos criar uma nova classe que conforme com o protocolo ObservableObject.

A classe Something conforma com o protocolo ObservableObject e possui uma variável @Published. O funcionamento do @Published pode ser compreendido na documentação da Apple que diz que "quando a propriedade mudar, ocorre uma publicação no block willSet da propriedade, significando que os observadores recebem um novo valor antes de ser de fato setado na propriedade".

"When the property changes, publishing occurs in the property’s willSet block, meaning subscribers receive the new value before it’s actually set on the property."

Dessa forma podemos adaptar nosso projeto do contador para obter seus valores diretamente a partir do objeto do tipo Something. No caso da View que apresenta o status podemos implementar assim:

Podemos notar que na linha 3 a variável something possui a notação @StateObject e a instancia do objeto de fato, ou seja, essa variável é a dona da instância. Além disso, na linha 10 temos um acesso a propriedade counter que está dentro de something. Na linha 11 o objeto esta sendo passada como parâmetro da inicialização da View interna de ação que contém o botão.

Na classe de ação do sistema contador temos na linha 3 uma variável @ObservedObject que é tipada e sem um valor, pois esta será a variável que vai referenciar o objeto Something que receber por parâmetro em sua inicialização. Podemos observar que na linha 10 a propriedade counter é acessada de dentro da something e na linha 7 é alterado o valor da variável interna counter de Something.

É possível também de forma alternativa utilizar a implementação da linha 8 (que esta comentada) executando o método de dentro do objeto Something, o que faz com que ele mesmo se atualize após um delay de 1 segundo (simulando um intervalo de tempo de uma requisição).

Exemplo prático: Comunicação entre 2 Views em telas diferentes

Vamos voltar ao nosso exemplo do sistema de ativação. Toda interface apresentada anteriormente vai se manter a mesma. Nesse caso para exemplificar o @StateObject e @ObservedObject vamos adaptar nossas Views para referenciar corretamente o nosso objeto ActiviationModel que conforma com ObservableObject.

Podemos observar que a variável isActivated agora esta dentro da classe que conforma com ObservableObject e possui @Published, que vai funcionar para notificar todas referencias dessa instancia quando seu valor for alterado.

Adaptado nossa View de status para receber esse novo modelo temos o seguinte resultado:

Na linha 3 que utilizamos o Property Wrapper @StateObject pois essa variável esta lidando com um objeto que conforma com o protocolo ObservableObject. Além disso podemos ver que essa variável recebe de fato a instância do objeto.

A adaptação da View de ação para alterar o status de ativação utilizando objeto que conforma ObservableObject fica assim:

Nesse caso a variável model na linha 3 esta apenas referenciando um objeto que esta na tela anterior. Essa variável utiliza @ObservedObject por estar referenciando um objeto que conforma com ObservableObject. Dessa forma, sempre que houver alguma alteração na variável original, a variável observadora vai refletir as mudanças e consequentemente as Views vão reagir a esse novo estado.

@EnvironmentObject

Esse tipo de PropertyWrapper também é utilizado para referenciar uma classe que conforma o protocolo ObservableObject… Mas qual a diferença?

A diferença é que ao associar um environment object a uma View, esse objeto fica disponível dentro da hierarquia de views (da View que foi adicionado) para ser referenciado em qualquer uma das Views filhas, independente do nível em que a View filha estiver. A view que desejar utilizar o conteúdo, apenas deve criar uma variável utilizando @EnvironmentObject que seja do mesmo tipo do objeto passado para a pilha de Views. Podemos visualizar nesse esquema exatamente essa situação:

Nesse caso vamos entender o que acontece em cada uma das Views:

• View cinza possui a referencia para a instancia de um ObservableObject. A View cinza passou esse objeto para sua filha (a View azul) utilizando o método environmentObject().
• View azul por sua vez não fez nada, nem mesmo referenciou o objeto.
• View amarela (filha da View azul) por estar na pilha de Views, recebeu também o objeto, mas no caso a View amarela referenciou o mesmo com o @EnvironmentObject e utilizou a instância.

O código das 3 Views em sequencia é o seguinte:

Podemos observar que nesse caso a nossa View Azul (IntermidiateView) nem sequer referencia o objeto ObservableObject. Mesmo assim a View Amarela (ChildView) por estar na hierarquia de Views, consegue referenciar utilizando @EnvironmentObject na declaração da variável appModel (linha 30). Dessa forma verificamos que todas as Views que estiverem na pilha da View Azul (que recebeu esse objeto na linha 14) poderão referenciar se necessário o objeto.

Boas práticas

Observe muito bem os casos para usar de forma conveniente esses tipos de Property Wrappers. Se for referenciar em poucos níveis (2 níveis) de Views, podemos aproveitar bem o @StateObject e @ObservedObject. Mas se for necessário referenciar um objeto a 2 níveis ou mais abaixo da View atual pode ficar cada vez mais difícil lidar com @StateObject e @ObservedObject pois seria necessário ficar passando o objeto de View para View… Nesse caso seria interessante considerar a utilização de @EnvironmentObject, que torna mais pratico lidar com esses objetos em 2 níveis ou mais.

Conclusão

Podemos aproveitar muito esses métodos de comunicação entre Views, seja na mesma tela ou em telas diferentes. Mas devemos sempre ficar atentos as boas práticas de utilização para aproveitar as ferramentas corretas nos casos de usos corretos e evitar assim trabalhos desnecessários e ter um código cada vez mais limpo.

Referências

• Apple Documentation State and Data Flow
• Apple Documentation @State
• Apple Documentation @StateObject
• Apple Documentation @EnvironmentObject
• Apple Documentation @ObservedObject
• Apple Documentation @Binding
• Apple Documentation @Published

Contato

• João Padilha - Online CV
• João Gabriel Borelli Padilha - Senior iOS Developer - Concrete Solutions | LinkedIn

SwiftUI Property Wrappers Simplificado was originally published in Accenture Digital Product Dev on Medium, where people are continuing the conversation by highlighting and responding to this story.

Post originalmente publicado em https://vctrlima.substack.com/

A curva S, que representa o comportamento na gestão do ciclo de vida de um produto ou serviço, é um conceito muito poderoso para determinar como entender e abordar a estratégia de lançamento de produtos digitais. O conceito é bastante antigo. Em 1965, por exemplo, um artigo foi publicado na Harvard Business Review com a descrição das diferentes fases pelas quais um produto passa durante o seu ciclo de vida: market development, growth, maturity, decline.

Como o próprio autor cita no artigo, muito se fala do ciclo de vida de um produto e do seu comportamento no formato de uma curva em S, mas pouco se discute sobre as aplicações práticas disso para o pensamento estratégico. O objetivo deste post é debater um pouco sobre este conceito. Em primeiro lugar, por que a curva tem comportamento em S?

Os motivos do formato em S

O comportamento da curva em S é gerado por conta de duas forças que atuam em direções opostas. Nas duas primeiras fases (introduction ou market development e growth), o que normalmente está agindo é algum tipo de crescimento exponencial descrito por padrões que o modelo de Bass-Diffusion do artigo anterior consegue prever.

O crescimento exponencial é gerado por conta de boca a boca, atratividade extrema do produto, fit com o mercado, campanhas de marketing ou alguma viralidade inerente. De qualquer forma, o crescimento tende a se comportar como o gráfico abaixo.

Neste momento, o produto claramente ainda está gozando do potencial de crescimento e dos efeitos cumulativos, ou seja, conforme mais pessoas passam a usar o produto ou serviço e “infectam” mais pessoas, essas também estimulam que mais pessoas utilizem.

O gráfico acima foi gerado por uma versão do modelo Bass-Diffusion considerando parâmetros bem simples: população que pode aderir ao produto, taxa de contato com possíveis “adopters” do produto e taxa de adoção do produto ao ter contato com o difusor.

Ok, já conseguimos entender que o comportamento da curva S no seu início acontece por um crescimento exponencial. Mas por que ela atinge o seu platô e eventualmente para de crescer com esse comportamento?

Utilizando o modelo acima e considerando os seguintes parâmetros:

• População total: 500 pessoas
• Taxa de contato entre adopters e potential adopters: 8, ou seja, um adopter entra em contato com 8 potential adopters
• Taxa de adoção do produto/serviço após o contato: 1,5%
• Efetividade de marketing: 0%, ou seja, não estamos fazendo nenhuma campanha

Nós experimentamos uma curva de adoção como a ilustrada abaixo:

Um dos principais motivos para esse comportamento é a diminuição do estoque de “potential adopters”, que simula a relação entre o mercado acessível pelo produto ou serviço e uma saturação dele. Por exemplo, se olharmos para os mesmos parâmetros do gráfico anterior mas focarmos no comportamento dos potential adopters, temos o seguinte:

E se, por outro lado, olharmos a curva de comportamento do fluxo entre potential adopters e adopters, temos o seguinte gráfico:

A junção de todos esses fatores denota, na verdade, as duas forças trabalhando em direções opostas que eu comentei no início do texto. Enquanto existe um ciclo que se reforça em direção ao aumento da adoção do produto ou serviço, depois de um tempo começa um ciclo que se equilibra, denotado principalmente pelo fato de que a base de potential adopters vai diminuindo com o tempo e os efeitos exponenciais, como boca a boca, viralidade inerente ao produto, marketing e etc. chegam ao seu limite superior, fazendo com que a curva tenha outro comportamento e atinja o platô superior da curva S.

Essas duas forças opostas podem ser representadas pelo diagrama abaixo, que descreve a relação entre um loop que se reforça e um loop que se equilibra como um fator limitante do crescimento.

Modelando uma extensão ao ciclo de vida de um produto

O que aconteceria se, após saturado o grupo inicial de potential adopters, decidíssemos por levar o produto ou serviço para outro mercado determinado geograficamente como, por exemplo, para um novo país ou região que inicialmente não era atendida?

Para simular essa situação, adicionamos um fluxo de novos usuários em potencial, que começa a gerar novos usuários em algum ponto no futuro. Ou seja, simulando uma dinâmica na qual após algum tempo levamos o produto ou serviço para ser disponibilizado e ofertado para outro mercado, ficaríamos com o modelo seguinte:

Se simularmos as duas execuções do modelo, uma sem levar o produto/serviço até um novo mercado e outra na qual o levamos, temos as seguintes curvas de adoção:

Reparem que na segunda execução do modelo (linha vermelha), temos aumento na quantidade de pessoas que adotam o produto/serviço ao acessar um mercado com novos usuários em potencial.

E como acontece o declínio?

Para simular o declínio, adicionamos ao estoque de adopters um fluxo de perda/escoamento de usuários (user churn):

Podemos simular esse churn, por exemplo, com uma taxa de 5% da base de usuários (adopters). Neste caso, teríamos o comportamento conforme o gráfico abaixo. Repare que a execução 1, que considera o churn de usuários, tem um comportamento diferente da execução 2, o modelo que não considera o churn de usuários.

É claro que existem diversas ocasiões em que o comportamento de churn de usuários poderia acontecer. Aqui, optamos por uma simulação que decresce rapidamente, mas outros comportamentos de curva poderiam acontecer.

Em outras simulações poderíamos esperar uma retenção maior, diminuindo o fluxo de churn, ou uma extensão do ciclo de vida de um produto/serviço utilizando diversas alavancas, como por exemplo:

• entrada em uma nova segmentação do mercado, respeitando os quesitos de variações do produto/serviço que poderiam ser oferecidos, de novos tipos de compradores que poderiam adotar/comprar o produto/serviço, novos canais que permitiriam acessar uma nova gama de potenciais usuários/compradores do produto/serviço ou ainda novos clientes/usuários a partir de uma segmentação geográfica distinta.
• oferta de novos incentivos para que o usuário/cliente continue utilizando o produto/serviço por meio de incentivos utilitários maiores, como comodidade, barreiras para a mudança ou simplesmente uma performance superior ou mais adaptada às necessidades do clientes/usuários do produto/serviço.

Ficou alguma dúvida ou tem algo a dizer? Aproveite os campos de comentários. E se você quiser trabalhar com um time que está sempre atento à gestão de produtos, clique aqui, candidate-se a alguma de nossas vagas e vamos aprender juntos. Até a próxima!

Ciclo de vida de um produto e modelos de difusão was originally published in Accenture Digital Product Dev on Medium, where people are continuing the conversation by highlighting and responding to this story.

Meu primeiro projeto aqui na Accenture ainda estava em fase de estudos e planejamento. O objetivo era criar um site para administração de projetos, e uma das obrigatoriedades era usar o logon da empresa e a Azure como repositório. O projeto não foi adiante, mas tive que aprender alguns passos para iniciar uma aplicação na Azure e o objetivo deste post é compartilhar com vocês um pouco do que aprendi.

Antes, porém, vamos entender um pouco mais sobre a Azure AD B2C.

O que é Azure Active Directory B2C?

O Azure AD B2C é uma solução de gerenciamento de acesso e identidade do cliente. É um serviço global de alta disponibilidade que se expande para milhares de usuários e bilhões de autenticações por dia. Permite que empresas, governos e outras organizações forneçam a seus clientes e consumidores acesso a aplicativos Mobile e Web voltados ao público. A solução usa identificadores que já possuem registros de clientes externos por meio de conta local (e-mail) ou contas sociais como (Facebook, Twitter, Linkedin, etc).

O B2C também pode centralizar a coleta de informações de perfil e preferência do usuário e capturar informações analíticas detalhadas sobre comportamento e conversão de inscrição, servindo como uma autoridade de autenticação central para todos os seus aplicativos. O B2C fornece ainda uma maneira de construir uma solução de logon único para qualquer API, Web ou Mobile. A Microsoft atuava como a porta de entrada segura para qualquer um desses aplicativos.

Além disso, o serviço cuida da segurança da plataforma de autenticação, do monitoramento e do tratamento automático de ameaças. Assim, não precisamos lidar com negação de serviço, difusão de senha e ataques de força bruta.

O B2C usa protocolos de autenticação espaçadas padrão como OpenID Connect, OAuth2 e Saml. Portanto, pode se integrar com quase qualquer aplicativo moderno ou softwares comerciais off-the-shelf.

Explicado? Então vamos começar a criar nosso próprio locatário:

Para configurar um Azure AD B2C, a primeira etapa é ter uma assinatura válida do Azure e, por sua vez, os direitos correspondentes. Para saber mais sobre isso, é só clicar aqui. Feito isso, é só seguir o passo a passo:

1. Faça login no portal Azure. Quando estiver conectado, você verá essa tela:

2. Certifique-se de estar usando o diretório da sua assinatura:

3. Adicione Microsoft.AzureActiveDirectory como um provedor de recursos para a assinatura do Azure em uso. Para isso:

a) No portal do Azure, pesquise e selecione Assinaturas.

b) Selecione sua assinatura e no menu esquerdo escolha Provedores de recursos. Se você não visualizar o menu à esquerda, selecione o ícone mostrar o menu para nome da assinatura > na parte superior esquerda da página para expandi-lo.

c) Verifique se a linha Microsoft.AzureActiveDirectory mostra um status Registrado. Se não, selecione a linha e escolha registrar.

4. Volte para a página inicial e selecione “criar um recurso”.

5. Então, procure por Azure Active Directory B2:

6. Depois de selecionado, clique em criar:

7. Selecione um nome de organização e o de domínio inicial, que é usado no nome do locatário, selecione o País (não pode ser alterado posteriormente) e clique em criar:

Após clicar em criar, espere até que se confirme a criação, que deve levar de um a dois minutos.

Depois de algum tempo, deve aparecer uma mensagem de locatário criado.
Você criou com êxito um novo locatário do Azure AD B2C!

Se você clicar neste recurso (imagem abaixo), você vai obter a visualização do link nesta assinatura e NÃO o próprio inquilino. Mas aqui já podemos obter informações importantes:

Locatário

Você pode descobrir o nome de domínio e ID do locatário B2C na visão geral, bem como a função de exclusão. Mais detalhes sobre o inquilino você pode acessar em “Propriedades”. A propósito, excluir o registro neste ponto levaria apenas à remoção do link entre a assinatura e o locatário B2C, mas não o locatário em si, ok?

Caso você tenha deixado passar alguma informação, vou tentar resumir e adicionar alguns pontos.

• Azure B2C é um serviço que permite gerenciar contas de usuário em seu aplicativo cliente.
• O modelo de precificação oferece 50.000 usuários ativos mensais (MAU) de forma gratuita.
• Para criar um serviço Azure B2C, você precisa se lembrar de vincular sua assinatura de faturamento padrão.
• Uma vez que seu serviço B2C esteja configurado, você pode criar seus aplicativos que vão cuidar de todas as suas tarefas de gerenciamento de identidade.
• Você precisa criar os fluxos de usuário para seu aplicativo.
• Os fluxos de usuário determinam a rota que um usuário pode seguir ao navegar em seu aplicativo.

Com isso, você permite que seus usuários se inscrevam e façam login em suas contas. Esta primeira parte de configuração foi realizada com sucesso! Criamos um Azure AD B2C e o conectamos a uma assinatura existente, um serviço totalmente funcional. Agora estamos prontos para a próxima etapa.

Ficou alguma dúvida ou tem algo a acrescentar? É só aproveitar os campos de comentários. Até a próxima!

Referência:
https://docs.microsoft.com/pt-br/azure/active-directory-b2c/overview
https://azure.microsoft.com/pt-br/trial/get-started-active-directory-b2c/

Como criar um locátario na Azure AD B2C was originally published in Accenture Digital Product Dev on Medium, where people are continuing the conversation by highlighting and responding to this story.

Você já deve ter tido aquele compromisso que “não deu tempo” de participar, uma reunião que foi “de última hora” ou até mesmo um almoço “correndo, pois estou meio atrasado”, estou certo? Os passos rápidos estão cada vez mais frequentes porque estamos sempre sem tempo.

Falta de tempo é algo que sinto na pele, como algo crônico, com o qual deveria me acostumar, tomar aquela dose analgésica, seguir em frente e aceitar o fardo… #sóquenão. Com o amadurecimento pessoal e profissional, a interpretação sobre essa falta de tempo foi dando voz a um dito popular, tão conhecido por todos, que sempre ouvi dizer:

“é preciso dar tempo ao tempo”

E lendo de forma objetiva essa frase, cheguei à conclusão de que realmente, precisamos dar tempo ao nosso tempo. Essa correria intensa gera uma sensação de que nunca vamos conseguir realizar tudo o que precisamos, ou gostaríamos de fazer. E essa reflexão me fez concluir que esse sentimento também pode ser traduzido como falta de conhecimento sobre a utilização desse valioso recurso, que é o nosso tempo.

Será que não temos tempo mesmo?

O nosso dia é composto por 24 horas, e são exatamente as mesmas 24 horas para todos. O quanto sabemos sobre o uso do nosso tempo? Acredito que o questionamento correto seria: estamos utilizando esse recurso de maneira inteligente?

Interessante que quando falamos sobre gestão temos um conceito bem amplo, desde gestão de produtos, stakeholders, pessoas… mas todos são sempre muito bem embasados. Entretanto, pouco buscamos clareza sobre gestão de tempo e a importância dela para a qualidade de vida, profissional e pessoal.

Quando temos uma fotografia mais ampla sobre os resultados que obtivemos ao longo do tempo, quando deixamos de fazer uma boa gestão de tempo, percebemos que a tendência é ter uma baixa qualidade de vida, e isso se reflete de maneira geral, e não somente em ambiente profissional.

Durante essa jornada, dei de cara com um universo e diferentes formas que podem contribuir para uma melhor gestão de tempo, mas gostaria de destacar 4 técnicas que me ajudaram de forma muito eficiente com resultados surpreendentes.

Lei de Parkinson

A teoria, de autoria do historiador e escritor britânico Cyril Northcote Parkinson, foi publicada pela primeira vez em 1955 em um artigo da revista The Economist.

A lei formulada por Parkinson foi baseada a partir da experiência no serviço civil britânico e basicamente diz que:

“o trabalho se expande de modo a preencher o tempo disponível para sua realização”

Ou seja, se precisamos realizar uma tarefa, e temos 8 horas para realizá-la, provavelmente vamos utilizar as 8 horas. Se for um período de 3 horas para a mesma tarefa, utilizaremos as mesmas 3 horas. Se tudo deu errado, e temos apenas 30 minutos para concluir a tarefa, ele será concluída. Não é fácil, mas com determinação podemos deixar a procrastinação um pouco de lado e focar naquilo que de fato importa e gera valor.

Como podemos aplicar:

• Limite o tempo para concluir as atividades do dia a dia;
• Dê prazos agressivos para conclusão das atividades;
• Respeite os prazos que foram determinados.

Princípio de Pareto ou Regra dos 80/20

O princípio de Pareto ou regra dos 80/20 afirma que, para muitos eventos, aproximadamente 80% dos resultados efetivos vêm de 20% dos esforços.

O consultor de negócios Joseph Moses Juran sugeriu o princípio e o nomeou em homenagem ao economista italiano Vilfredo Pareto, que notou a conexão 80/20 em sua passagem pela Universidade de Lausanne em 1892. Essencialmente, Pareto mostrou que aproximadamente 80% da terra na Itália pertencia a 20% da população.

É comum no mundo dos negócios, por exemplo, ter o entendimento que “80% das suas vendas vêm de 20% dos seus clientes”

Como podemos aplicar:

• Limite os esforços para executar atividades que não exijam perfeição;
• Tenha foco no que é essencial para concluir sua tarefa;
• “80% dos resultados são obtidos com 20% dos esforços”

Técnica Pomodoro

O método é baseado na ideia de que pausas frequentes podem aumentar a agilidade mental. Essa técnica foi desenvolvida por Francesco Cirillo no final dos anos 1980, e basicamente consiste na utilização de um cronômetro para “fatiar” atividades em períodos de concentração, separados por breves intervalos. Esse método é baseado no conceito de que pausas frequentes aumentam a agilidade mental.

Como sabemos, cada pessoa tem seu ritmo, cada um tem seu tempo. Basicamente, essa ténica promove ciclos de foco total na tarefa desempenhada, com intervalos entre elas.

Como podemos aplicar

• Inicie um timer e, durante esse tempo, tenha foco total na atividade, com o mínimo de distrações possíveis. Sugiro ciclos de 50 minutos;
• Quando o timer tocar, pare e relaxe por 10 minutos. Ande por aí, faça um carinho no seu pet, prepare um café, mas relaxe a mente por 10 minutos;

Plano Semanal

Coloque sua agenda em dia! Planejamento é essencial em nossa vida, independente de ser aplicado durante a jornada profissional ou pessoal. Ter uma gestão visual das atividades facilita nosso próprio entendimento, monitora o uso do nosso recurso (tempo) e nos guia sobre os esforços aplicados. Nós nos preparamos melhor quando temos clareza dos nossos compromissos e, sem dúvida, essa clareza contribui para uma melhor gestão de produtos em ambientes complexos.

Estruturando de maneira adequada e aplicando os conceitos apresentados de forma combinada, podemos ter uma melhor qualidade de vida, .

Acredito que, seguindo a Lei de Parkinson, que nos ajuda a limitar o tempo para realizar a tarefa, sem distrações e com prazos agressivos, com atenção ao princípio de Pareto, que nos diz que podemos limitar esforços, dando foco naquilo que é essencial, e utilizando a técnica Pomodoro, que sugere ciclos de 50 minutos focados e intervalos de 10 minutos para descanso mental, e juntando tudo isso ao Plano Semanal, temos um bom leque de informações que podemos utilizar como guia para preservar e melhor utilizar o mais precioso recurso de vida, o tempo.

E você? Tem alguma técnica ou experiência com gestão do tempo para compartilhar? Deixe nos campos de comentários! E se você quiser fazer parte de um time que está sempre em busca de melhoria contínua, é só dar uma olhada aqui e se candidatar a alguma de nossas vagas. Vamos aprender juntos!

Gestão de “calma aí que tô chegando!” was originally published in Accenture Digital Product Dev on Medium, where people are continuing the conversation by highlighting and responding to this story.

Já diziam: jogo é jogo, treino é treino. Vamos aos resultados?

Nesta série de posts, nós já conversamos sobre a migração de “servermess” para serverless e mostramos alguns resultados de um benchmark, provando que os custos compensam e muito essa migração. Agora, vamos por fim mostrar o resultado em produção de uma infraestrutura em serverless. Vamos lá?

Volume de Requests

No gráfico abaixo conseguimos observar o volume das chamadas efetuadas na última semana:

Constatamos que o uso da aplicação segue uma tendência senoidal. Esse cenário é excelente para serverless, pois temos diariamente um período com uma quantidade mínima de acessos que seriam anteriormente atendidos por duas máquinas (para garantir a alta disponibilidade), porém potencialmente com elas 100% sem uso.

Filtrando pelas últimas 48h conseguimos ver essa falta de uso de forma fácil e ela fica em torno de 7h com uso mínimo. Isso são 210h de tempo de máquinas desperdiçadas e pagas sem motivo por mês. Com a hora das máquinas custando 0,20 centavos/hora temos uma economia de 45 dólares sem perder disponibilidade do serviço.

Latência

No gráfico abaixo conseguimos observar que a latência se mantém ao longo da semana entre 250–700ms. Há um grande pico de latência, mas foi causado pela indisponibilidade de um serviço terceiro.

Aplicando um Fourier nos pontos de latência temos o seguinte gráfico.

Nele conseguimos ver que a frequência com que as latências ocorrem gira em torno de 75ms. Infelizmente não conseguimos dados reais para comparação, mas “de cabeça” a latência ficava próxima de 100ms. Esse é um excelente sinal, que indica que nosso wrapper não adicionou nenhum grande aumento de ciclos de máquina.

Como a API é parecida com agregação, ou seja, consome outros serviços, ela se torna fortemente acoplada a esse serviço terceiro. Logo, não é uma métrica que devemos interpretar no vácuo da ausência de contexto. Conseguimos, então, mostrar como aplicações serverless conseguem alcançar performance igual e equivalente (talvez maior) do que a aplicação com servidores.

Memória

Abaixo temos o uso de memória dos últimos 3 dias do aplicativo serverless:

Nele podemos ver um padrão claro de uso e desuso. Esse valor de uso de memória é apenas uma fração do total de memória RAM alocada nos servidores e processos. Isso evidencia a eficiência de execução do código.

Porém, o ponto mais interessante desse gráfico é o limite superior do uso de memória. Pelo gráfico podemos afirmar que ele fica em torno dos 300 MB, e isso é 1/3 da memória que usamos nos cálculos de custo.

Custo

Como observamos nos dois últimos tópicos, os valores que colocamos em nossas estimativas estavam exagerados e portanto o seu resultado também.

Abaixo temos a contagem de chamadas totais e a média do tempo de respostas calculados pela Azure Insight em um período de 7 dias.

Aplicando o mesmo cálculo de previsão de custo com os valores de tempo de respostas e memórias reais temos o seguinte resultado:

Nosso custo será de 90 dólares, ou seja, 11 vezes mais barato. Incrível, não?

Ressalto que isso ainda é uma estimativa baseada na última semana e o valor pode ser tanto maior quanto menor.

Mas acabamos esquecendo de um detalhe: a comparação está correta mas esse volume de chamadas representa o pior pico de uso no Natal, e não um mês usual. Se extrapolarmos o volume do primeiro gráfico da sessão sobre o volume de chamadas, temo que a média semanal é próxima a 1,8 milhões.

Incrível! Uma API com 7,2 milhões de chamadas por mês custando 28 dólares. Bem-vindo ao mundo do serverless!

Otimizações valem Ouro

É importante frisar a vantagem “oculta” do serverless, que é o alto retorno de investimento nas ações que otimizam o uso de memória e do tempo de respostas. Todas essas otimizações têm efeito direto no custo da API, diferente de aplicações nos servidores que são geralmente tratadas com bastante abundância de recursos para evitar que quebrem.

Nos gráficos acima, fornecidos no dashboard do azure app insights, temos as APIs mais lentas e mais chamadas da aplicação. Com esses dados podemos criar um plano de ação que visa otimizar o código desses grandes ofensores e cortar ainda mais nossos custos.

Entre outros benefícios não ditos temos a vasta complexidade reduzida migrando de uma arquitetura com Kubernetes para uma em Azure Functions. Essa redução diminui pontos de falha a serem administrados e reduz a necessidade de um time para monitoria da aplicação, já que nós apenas cuidamos do código e todo restro é provido pela Azure.

Gostaram dos posts? Querem outros cenários serverless? Deixem seus comentários com o feedback. E se quiser trabalhar em um time que preza pela automação, é só clicar aqui e se candidatar a alguma de nossas vagas. Obrigado a todos que acompanharam essa pequena saga. Até mais!

Leia mais:

• Serverless Saga #1 — De Serverness para Serverless
• Serverles Saga #2 — Benchmarks & Custo

Serverless Saga #3 — Produção was originally published in Accenture Digital Product Dev on Medium, where people are continuing the conversation by highlighting and responding to this story.

Será que vale todo o esforço para transformar ou criar uma aplicação de serverness em uma serverless?

No primeiro post desta série, vimos como transformar ou criar uma aplicação serverness em uma serverless de forma muito mais portável para outras nuvens e até mesmo para migrar de volta para uma infraestrutura com servidores. Mas será que vale a pena todo esse esforço? Neste segundo post, vamos explorar alguns dados reais e simulados de benchmarks para validar nossa hipótese antes de levá-la ao cliente.

Benchmarks

Criamos quatro grupos de chamadas de APIs que simulam o fluxo de uso de um usuário médio no projeto em que atuamos. A ferramenta utilizada foi o Artillery.io.

Ajustamos os valores de quantidade de chamadas por segundo para alcançar o limite das infras construídas, mas depois que encontramos os limites usamos para os dois testes.

Serverness (com servidores)

Na infraestrutura antiga conseguimos apenas 271 chamadas com sucesso num período de 70 segundos e tivemos vários 429, o erro que o Azure API Manager lança quando o serviço esta indisponível.

Com isso, temos apenas 3,9 req/sec com sucesso.

Serverless

Já com o serverless, conseguimos 848 chamadas com sucesso! Isso equivale a 12,11 req/sec com sucesso!

Histórico de Uso

Bem, esses números por si só não representam grandes coisas. Precisamos compará-los com a quantidade real de chamadas que iríamos receber. Abaixo temos o pico histórico da aplicação. Dela tiramos que o maior pico de uso foi no dia 22, com 335 req/min. Para normalizar esse valor com os valores acima, dividimos por 60 segundos.

A infra teve um pico de 5,58 por segundo. Logo, a arquitetura serverless conseguiria atender até 2 Natais sem problemas!

Custo da Aplicação

As duas infraestruturas têm formas muito diferentes de cobrança. Na infraestrutura com servidores nós basicamente pagamos pelo tempo das máquinas usadas, usando o recurso ou não.

Já no serverless, o pagamento é feito pelo número de execuções, duração da execução e memória alocada. Para comparar cenários iguais e críticos pegamos o mês que mais houve estress na aplicação, ou seja, o mês com a maior quantidade de chamadas.

Do plot acima tiramos a pior latência histórica: 600ms e o volume total de chamadas: 2.000.000 chamadas

Serverness (com servidores)

Para achar o custo da aplicação, pegamos o conjunto de máquinas iguais às do cenário de testes e multiplicamos pela quantidade de máquinas. Nesse cenário nós tivemos que levantar dois conjuntos de máquinas com essa config:

Utilizamos dois grupos compostos de 6 máquinas com vCores e 8 GB cada capazes de atender a aplicação.

Da calculadora acima chegamos à conclusão de que cada máquina custa 140 dólares por mês. Multiplicando esse valor por 6 teríamos 840 dólares!

Serverless

Para calcular o custo da infraestrutura serverless podemos simplesmente preencher a calculadora de custos da própria Azure com os dados que coletamos de tempo e quantidade de execuções.

O total é de 190 dólares, ou uma economia prevista de quase 80%!

Um ponto importante a destacar é que, diferentemente do custo por máquinas, o custo serverless pode variar já que o tempo de execução influencia no custo.

Custo, Monitoria e Logs

Um “acidente feliz” que tivemos durante a migração da aplicação foi que não conseguimos reutilizar a ferramenta de tracing e monitoramento que usávamos (Dynatrace), pois ela exigia a execução de um binário ao qual o serverless não dá suporte.

Por isso, precisamos migrar para uma ferramenta de monitoria que não precisasse de binários e, com isso, conhecemos o Azure App Insight, na qual a instrumentação é feita direto no código.

Mas as vantagens do App Insight são ainda maiores do que apenas viabilizar o serverless. Por ser uma ferramenta que cobra por chamada e volume de dados, conseguimos uma redução de custo na monitoria, pois a modalidade de cobrança do Dynatrace é por instância utilizada.

Além disso, conseguimos mitigar um grande problema, que era o link entre o tracing e os logs. Na arquitetura antiga os logs ficavam no appinsight e o tracing no dynatrace. Juntando os dois criamos uma super ferramenta de debug.

Otimizações

Em uma arquitetura clássica não temos tantos incentivos para otimizar o código. Se ele funcionar em 600ms ou 800ms no dia a dia, o impacto pode ser pequeno, ou até nenhum. No entanto, numa arquitetura serverless reduzir de 800ms para 400ms pode cortar o custo da infra pela metade.

Com serverless temos motivação direta de diminuir o tempo de execução, o uso de memória e a quantidade de chamadas que nossa aplicação realiza, pois teremos um impacto direto e visível no custo da aplicação.

Outra flexibilidade para reduzir custos é reduzindo a quantidade de logs e de tracing, já que a modalidade de cobrança é baseada no uso e não em um contrato previamente feito.

Acho que chegamos à conclusão de que uma API serverless é uma excelente ideia e deve ser considerada no início (ou até mesmo no meio) de um projeto, certo? No próximo post, vamos mostrar dados reais da aplicação em produção. Se você tem alguma dúvida ou quer comentar algo, aproveite os campos abaixo. Ou se você quer fazer parte de um time que aprende o tempo todo, é só clicar aqui e se candidatar a alguma de nossas vagas. Até a próxima!

Leia mais:

• Serverless Saga #1 — De Serverness para Serverless
• Serverless Saga #3 — Produção

Serverles Saga #2 — Benchmarks & Custo was originally published in Accenture Digital Product Dev on Medium, where people are continuing the conversation by highlighting and responding to this story.