fbpx
Habilidades do futuro?

Habilidades do futuro?

De um lado as guerras dos frameworks e tecnologias, de outro as guerras de skills e culturas. Cultura DevOps, Agile. Então serverless ou containers? Fullstack é um pato que não corre bem, não nada bem, e não voa bem?

Aproveitei essa noite para reler as pesquisas que eu faço anualmente, onde coleto opiniões, críticas e sugestões e resolvi pegar um tópico recorrente para falar: Carreira. Vocês pediram e eu vou trabalhar em cima desse assunto hoje.

Sobre carreira há muito a dizer, há inúmeras considerações a serem feitas, mas vou usar minha história como fio condutor desse texto, mostrando o que eu fiz, o que eu faço. Assim eu vou narrando o que eu fiz e o conceito ao redor do que eu fiz, com os exemplos que uso.

Indecisão técnica

Pra começar, deixa eu te contar uma coisa: Eu era extremamente indeciso.

Qual tecnologia? Qual framework? Qual blablabla?

Mas, diferente da maioria dos meus colegas de trabalho, eu não aceitava opiniões. Na verdade bem no início eu aceitava e ficava cada vez mais perdido.

Então desde cedo eu senti a necessidade de chegar às minhas próprias conclusões. E há bons argumentos sobre isso que queria compartilhar com você.

Arrogância? Não. Eu simplesmente sempre fui crítico. Não aceito um “Porque não”, preciso entender o motivo para entender como posso chegar à mesma conclusão.

E isso se dá pela cu-ri-o-si-da-de!

Eu sempre quis entender como as pessoas tomavam decisões, como chegavam às conclusões. Eu não queria cair no ridículo de ter uma opinião “ruim”, “frágil”, “descabida”. Eu precisava filtrar meus pensamentos e pra isso precisava julgar minha própria opinião como válida e/ou pelo menos pertinente.

Dessa forma, verdades enlatadas nunca me satisfizeram. Eu precisava sujar a mão para ter a minha opinião. Eu passei toda a minha vida profissional comprometido com isso!

E quando eu falo em comprometimento… ahhhh você não imagina quanto código eu já produzi, quanto cliente, projetinho, poc e mais o que eu fiz para chegar às minhas conclusões.

Fato que decision makers me chamam a atenção desde sempre.

Como aquela pessoa conseguia entender com tanta profundidade algo, ao ponto de descartar ou não.

Como era o processo de tomada de decisão?

Como aquelas pessoas que decidiam, decidiam?

Um ponto curioso do início da carreira é que eu sempre chegava a conclusões diferentes das dos meus colegas. Eu sempre fui curioso, simultaneamente esforçado (odeio esse termo), mas a soma desses 2 elementos me faz uma máquina de testar coisas.

Me peguei essa semana percorrendo exatamente o mesmo processo ao analisar uma reunião de marketing, material que tenho estudado.

Como elas julgavam?

Onde encontrar esse nível de consciência ao ponto de definir se uma simples ideia maluca é maluquice ou algo fantástico?

No final, toda decisão é um julgamento. Há um juízo de valor.

Sempre esteve claro para mim que o contexto é fundamental para se tomar decisões, e assim, decisões nunca são absolutas. Isso quer dizer que, na minha opinião, se você tomou uma decisão com serenidade e sabedoria, você levou em conta o contexto e foi influenciado por ele para chegar a uma conclusão.

Eu percebia que quando eu tentava percorrer os mesmos caminhos, eu chegava a conclusões diferentes, por mais que estivesse sob o mesmo contexto.

Não era difícil chegar à conclusões antagônicas.

Assim percebi que é necessário conhecer melhor as pessoas e o que as motivam na hora de decidir entre uma tecnologia ou outra.

E minha perspectiva sobre isso também não é das melhores:

A maioria de nós decide em função do esforço e não da qualidade. Essas decisões são sobre quem está estudando a tecnologia e não sobre a tecnologia em si. Assim é fácil concluir que sempre haverá flame exatamente porque as pessoas querem olhar pela sua própria perspectiva. Ninguém está disposto a olhar pela perspectiva do projeto, da empresa, do cliente. Decisões pessoais influenciando decisões técnicas.

O processo de decisão

Eu criei meu framework mental para tomada de decisão técnica. Serve desde decisões grandes até decisões pequenas.

Consiste em listar os pontos de interesse de uma decisão e realizar uma sabatina.

O que é importante, quais pontos são relevantes a serem avaliados. Abaixo segue um esboço.

Nem adianta se basear nesses itens pois o que temos aqui é uma lista feita no freestyle.

Em geral perco mais tempo definindo precedência e prioridade dessa lista do que das tecnologias em si.

  • UI
    • Flexibilidade
    • Capacidade de representar design complexo
    • Semântica
  • Backend
    • Mensageria
      • Resiliência
      • Facilidade
      • Curva de aprendizado
      • Confiabilidade
    • Web Framework
      • Flexibilidade
      • Extensibilidade
      • Praticidade
      • Portabilidade
      • Monitoramento
      • Segurança

Essa lista deve contemplar o que eu desejo como resultado de uma decisão técnica.

Tudo que eu coloco na minha arquitetura, ou me aproxima ou me distancia de algum desses elementos.

Dica para a vida: Não existe nada que seja adicionado que seja indiferente. Ou é positivo, ou negativo, neutro: Não existe!

Isso faz com que você tome partido de todas as possíveis escolhas.

E tomando decisões e mais decisões, eu adotei o ataque, desqualificação e descarte.

Sim, eu transformo minhas decisões técnicas em rinhas mentais. 

É quase um processo esquizofrênico onde eu encaro 2 realidades: Defensores e Detratores.

1° Round

A primeira fase, é uma peneira. Ela é pouco propositiva e visa reduzir o esforço da segunda fase.

Ataque: Ataque a tecnologia com seus problemas que você tem a resolver.

Defesa: Defenda a tecnologia, validando se o argumento de fato é um argumento pertinente ou se está fora de contexto.

Desqualificação: Desqualifique a tecnologia com base nas suas premissas, Ache aquilo que é incompatível com teu contexto.

Descarte:..

O que estamos fazendo aqui é peneirando diversas tecnologias. Um ponto importante é que desse pipe, não sai apenas 1 vencedor, saem 2, ou 3 vencedores.

2° Round

Agora tudo que vimos no primeiro pipe não funciona com a tecnologia, funciona com detalhes de cada tecnologia.

Em vez de comparar o contexto, comparamos as tecnologias, concorrentes sob o prisma dos requisitos.

É uma comparação do que cada uma das tecnologias traz com maior fit para endereçar um problema que você tem a resolver.

Ataque: Ataque uma feature com sua similar

Defesa: Defenda o ponto de vista do problema, quem resolve melhor o problema?

Desqualificação: Ache argumentos que inviabilizam o uso. Seja o mais contundente possível.

Descarte

Isso gera…

Essa forma de lidar com decisões é traumática.

Ela exige que você estude mais do que provavelmente está habituado a estudar. 

Não te faz expert, mas te faz no mínimo conhecedor, muito, mas muito além do overview. Mas para teu conforto, você não precisa percorrer esse caminho sempre. Esse tipo de profundidade faz com que você reaproveite muito seus estudos.

Então, sempre que me deparo com algo novo, eu faço isso.

E para entender com essa profundidade, eu muitas vezes preciso recorrer ao fundamento.

Como foi com Docker. Precisei parar para entender, mesmo que superficialmente, o kernel e como os pontos se conectam. Precisava saber o papel de cada coisa para que pudesse, no momento seguinte fazer sentido. E mais tarde servir de alicerce para entender a tecnologia em si. Que por sua vez serviu de alicerce para ensinar a tecnologia.

Quando eu comecei a ensinar docker, eu estava fascinado, e produção com Docker era meu servidor pessoal.

Mas note: Eu falava sobre o assunto, testava, implantava, via rodando e usava aquilo que eu estava falando.

É graças a esse tipo de abordagem que consigo falar com propriedade sobre diversos assuntos e tecnologias.

Essa forma de pensar, que leva em conta “sujar a mão de lama” abdicando do mi-mi-mi me permite discutir decisões com profissionais de outras áreas, me permite fazer coisas típicas de profissionais de outras áreas. Me faz entender o ponto de vista da outra pessoa, me faz entender o que ela quer dizer com o que está dizendo.

Essa “boa vontade” tem uma pitada de busca por autonomia. Busca por ser autossuficiente, se assim precisar. Só SE PRECISAR!!!!!!!!!!!!!!!

Outro ponto relevante que lembrei agora enquanto estava revisando esse post, é que por sorte, em situações normais de temperatura e pressão (SNTP), você tem poucos problemas por vez. Ou pelo menos pode revisá-los para ter poucos por vez.

A habilidade do futuro

E assim eu concluo dizendo que a habilidade do futuro não é sua linguagem, framework, navegador ou console favorito.

A habilidade do futuro é a capacidade de se reinventar. De aprender coisas novas, é a capacidade de não parar, de não ser um dinossauro.

Hard skill a gente aprende, compra.

Cognição para aprender, desaprender e reaprender não! Essa a gente desenvolve!

Desenvolva sua habilidade de aprender.

Eu ainda tenho outros posts sobre aprendizado, que estão engavetados aqui no rascunho.

Me diga o que achou desse aqui.

Deixo aqui um vídeo do TEDxFAAP com Michelle Schneider.

 

Essa palestra merecia um prêmio.

DevShow #12 – RETROSPECTIVA 2019

DevShow #12 – RETROSPECTIVA 2019

Neste último episódio da nossa 1ª temporada, fizemos um resumo de algumas novidades e anúncios que tivemos durante o ano, principalmente as voltadas a área de desenvolvimento de software com tecnologias Microsoft. Perdeu algo durante o ano? Então vem com a gente no último episódio de 2019!

(mais…)
Rebranding

Rebranding

Hora de acertar a casa, rever os nomes, marcas, páginas, perfis, grupos, tudo! Fim de ano chega e está na hora de rever o que está certo, o que está errado, hora de planejar o próximo ano.

No meu caso também errei e também fiz uma lambança com marcas, projetos. Impulsionei alguns, negligenciei outros. Está na hora de acertar isso e a melhor hora de fazer isso era há 1 ano atrás, mas antes tarde do que nunca!

A confusão

Eu sempre me posicionei como Luiz Carlos Faria, e mais tarde, como gaGO.io. Nomes/Marcas que fazem sentido, tem um contexto uniforme sobre a minha imagem. Durante essa transição já tinha um projeto chamado Docker de A a Z, onde publicava uma série de conteúdos sobre Docker. Mais tarde nasceu o projeto Docker Definitivo, com o Renato e aí começou a zona!

Docker Definitivo é o treinamento, que acabei criando página, canal no youtube, e uma parafernalha que, fazia sentido por um momento, mas deixava de fazer sentido na medida que Renato saiu do projeto. Agora é hora de acertar a casa.

Novidades

Em linhas gerais Docker Definitivo deixa de ser uma “Entidade Autônoma”, com página, canal, grupo e vira apenas um produto.

  • A página Docker Definitivo do Facebook morre.
  • O canal Docker Definitivo do Youtube morre.
  • O grupo Docker Definitivo do Facebook será renomeado para Docker de A a Z (no final do mês).

Todo o material será migrado entre as contas. Nada será perdido.

Todo o material gratuito que antes era publicado na página do Docker Definitivo, será migrado para a minha página do Facebook.

Esse processo também acontecerá no Youtube do canal Docker Definitivo para Luiz Carlos Faria.

Essas mudanças tem uma função clara: Entregar não só uma melhor experiência, simplificando as marcas, mas também evitando confusão.

Motivador

Docker Definitivo foi uma marca que brotou do nada.

A marca até então tinha uma fusão entre conteúdo gratuito e treinamento pago, gerando uma zona na cabeça de quem participava.

Docker Definitivo é um acidente de percurso, um acidente que está dando muito certo para todos os envolvidos: Eu, alunos, Facebook, Google, Hotmart, Governo… são muitos “sócios” nesse projeto!

O problema é que a rotina de publicações estava confusa. Gerando mais confusão do que clareza. E esse assunto precisava ser revisitado.

Conclusão

O projeto Docker Definitivo continua forte, em breve teremos uma segunda turma. Isso será em Janeiro/2020.

Pelo ponto de vista de conteúdo, nada muda, apenas o local onde estou postando cada coisa.

Se você quer ficar por dentro do Docker Definitivo, inscreva-se no formulário abaixo:

Comprometa-se a tomar a melhor decisão

Comprometa-se a tomar a melhor decisão

Todos os dias, ou quase todos, no suporte à comunidade vemos um estereótipo: Muita informação para absorver, muitos assuntos para estudar, pouco conhecimento e a busca pela “a solução ideal” em busca de um atalho para o sucesso. Essa ideia se pauta na esperança de que se fizer a escolha certa, a respeito de tecnologia, o stack perfeito, a arquitetura perfeita, o design perfeito conseguirá ter sucesso ou conseguirá ter mais sucesso que os demais. Essa é a narrativa que vamos desconstruir hoje.

(mais…)
DevWeek 2019 | Canal .NET

DevWeek 2019 | Canal .NET

O Canal .NET apresenta pelo 5° ano consecutivo o DevWeek. O evento começa hoje, segunda-feira e termina nessa quarta.

Convidados

São 4 convidados que falarão sobre Desenvolvimento Móvel, ASP.NET Core, Blazor e Prometheus!

Canal .NET #completo

Dessa vez, nosso time do Canal .NET está completo, sem desfalques! Uhuuuuu!!!

Aqui fica meu convite, se inscreva pelo meetup para saber mais sobre o evento.

Fica aqui meu convite! Compartilhe esse post com alguém, principalmente se essas tecnologias fizerem sentido para o projeto dela.

A propósito, vou falar de RabbitMQ. Tem uma série super legal aqui no site.

Os 8 primeiros posts da série sobre RabbitMQ já estão no ar.
📍#1 Prefácio
https://gago.io/blog/rabbitmq-amqp-1-prefacio/

📍#2 Pra que mensageria?
https://gago.io/blog/rabbitmq-amqp-2-pra-que-mensageria/

📍#3 Conceitos
https://gago.io/blog/rabbitmq-amqp-3-conceitos/

📍#4 Perguntas e Respostas
https://gago.io/blog/rabbitmq-amqp-4-qna/

📍#5 Management UI, Filas e Exchanges
https://gago.io/blog/rabbitmq-amqp-5-management-ui-filas-e-exchanges/

📍#6 – Show me the code
https://gago.io/blog/rabbitmq-amqp-6-show-me-the-code/

📍#7 – Pipelines & Youtube Downloader
https://gago.io/blog/rabbitmq-amqp-7-pipelines-youtube-downloader/

📍 #8 – RabbitMQ & AMQP – Redis, um Message Broker?
https://gago.io/blog/rabbitmq-amqp-8-redis/

Até mais tarde!

Docker Definitivo – Janela de Inscrição Aberta!

Docker Definitivo – Janela de Inscrição Aberta!

Na tarde desse domingo, dia 27/out alcançamos o limite de alunos.
As inscrições para a primeira turma estão encerradas!

Cadastre-se para receber notícias, link das lives e para participar do grupo do facebook.

Em 2015 eu conduzi um projeto de refactoring daqueles complicados.

Ao todo foram quase 10 meses com um time dedicado ao refactoring desse projeto. Mas uma coisa que chamou a atenção nesse projeto. Foram 4 meses em que eu me dediquei a entender a baseline de código, sem entregar absolutamente NENHUMA LINHA DE CÓDIGO.

Eu precisava entender o projeto para propor uma solução.

Não era apenas o que fazer, era sobre como e onde fazer.

Nessa jornada, levei esses 4 meses compreendendo como faria uma aplicação que caia com 5 usuários, suportar 1000 usuários simultâneos.

A questão é que naquela época eu havia escutado a respeito de Docker. Era algo que estava no meu radar, mas naquela época era uma buzzword, um termo da modinha. Não tinha compreensão plena de como usar, nem tinha maturidade para implantar algum projeto baseado nele. Aliás, naquela época ainda não havia muita informação sobre .NET Core. .NET core era algo em desenvolvimento.

Meses depois, dediquei a estudar docker e Voilà!

Descobri que “havia perdido semanas” produzindo uma documentação de implantação, com os mínimos detalhes sobre como subir uma infra completa com RabbitMQ, Elasticsearch, LogStash e Kibana. Do download à produção!

Mais tarde, na medida que aprendia docker e me apaixonava pelas oportunidades que ele me traria, recriei esse mesmo stack que mantenho, cariosamente, até hoje. O EnterpriseApplicationLog.

Eu troquei mais de 10 documentos Word, complexos, cheios de detalhes, por alguns poucos arquivos de configuração e composição de stack.

Você não precisa mais do que:

git clone https://github.com/docker-gallery/EnterpriseApplicationLog.git
cd ./EnterpriseApplicationLog
docker-compose up

Para ter esse stack na sua infra.

Se eu tivesse docker ao meu lado naquela época…

  • Eu poderia demonstrar e acelerar todo o processo de convencimento a respeito do uso desse stack.
  • Eu não perderia tanto tempo criando documentos texto, perecíveis.
  • Eu produziria um repositório que por si só colocaria o stack no ar, sem intermediários, sem procedimentos lentos.
  • Eu trocaria uma implantação de 8-16 horas por 8-16 minutos.

Enfim, esse projeto foi um sucesso, faltava muito pouco para colocar o projeto em produção, mas já conseguíamos alcançar nosso objetivo com ferramentas de teste de carga especializadas. Aliás, subir essas ferramentas com Docker seria algo absolutamente incrível.

Docker e o Novo mundo

O ponto é que Docker mudou a forma como vemos automação, isolamento, tornando Linux Container algo popular, fácil de usar, algo produtivo.

Vemos claramente uma disruptura da forma com lidamos com infraestrutura e como compomos stacks.

Um dia será difícil explicar como fazíamos quando não tínhamos Docker.

Minha jornada

Essa jornada de aprender docker se confunde com minha jornada de ensinar docker.

Eu vi tanto potencial e fiz uma aposta tão grande em empenho de tempo e dedicação ao assunto, que acabei por me sentir no DEVER de trazer isso para a comunidade .NET.

Eu queria mostrar como é mais fácil, como podemos criar aplicações mais robustas, eficientes e resilientes usando o que há de melhor no mundo open source.

Encontrei no Docker uma oportunidade para oxigenar os projetos com tecnologias especialistas, evitando a criação de gambiarras. Agora uma solução especialista em cache como Redis, ou em mensageria como RabbitMQ, estão ao seu dispor com muito pouco esforço.

Essa caminhada ensinando docker me fez produzir muito, mas muito conteúdo mesmo!

Ao todo, caminhando para as 8 mil horas de conteúdo assistido em mais de 30 horas de conteúdo.

Seu pedido…

Mas vocês pediram um modelo de treinamento.

Vocês que me chamam no privado! Pediram muito! E agora está aqui!

Mas eu não queria fazer um treinamento qualquer. Tinha de ser algo agressivo, que pudesse de fato transformar quem não conhece absolutamente nada de Linux.

E com as partes chatas mesmo, com os fundamentos explicados pela perspectiva de quem sempre usou Windows.

Aliás, até 2015 minhas experiências com Linux haviam sido pífias. Hoje conseguimos nos entender bem, é uma relação que parece muito mais estável e duradoura! 🙂

Eu vivi essa frustração, angustia, em não saber qual o próximo passo na hora de lidar com um linux server headless. Foi frustrante até me jogar de cabeça!

Eu quero trazer essa experiência para o treinamento. Uma experiência que mostre exatamente o que fazer para não se sentir desconfortável

Ah, mas você só quer ganhar dinheiro!!!

A forma menos eficiente que eu conheço para quem quer vender algo, é você mesmo produzir um concorrente gratuito!

Docker de A a Z é uma série gratuita. Que “concorre” diretamente com o Docker Definitivo.

A diferença é que o Docker de A a Z é limitado em atenção, em acompanhamento. Não tem o viés de uma jornada, com uma turma. Não tem lives quase que semanais.

Se o objetivo fosse ganhar dinheiro, não faria sentido ter produzido tanto conteúdo gratuito!

Não teria produzido tantos stacks.

Não teria disponibilizado tantos projetos, no github, ou no docker hub.

Dezenas de milhares de potenciais “clientes” aprenderam docker com o Docker de A a Z.

Sinceramente! Para muitos só faltava um detalhe. E eu fiz questão de atender a essa expectativa. E o conteúdo gratuito continua arqui: gago.io/docker/.

Use o conteúdo gratuito para me testar

Se quer ver como eu ensino, como eu apresento conteúdos técnicos, você tem zilhões de horas no youtube.

Esse material serve para você me avaliar!

Aproveite! Você tem até domingo, 27/out 23:59 para tomar sua decisão!

Garantia

Meu compromisso é com o resultado. Com o teu engajamento nessa jornada. Inclusive é por isso que eu não deixei a janela de inscrição aberta por muito tempo. É injusto com a galera que está comprando. Com a galera que comprou nessa madrugada e hoje durante o dia.

E para mostrar meu compromisso, de forma contundente! Te dou uma garantia de 30 dias.

Uma garantia incondicional!

Então se você acha que não tem tempo, não tem aptidão, não tem skill ou sei lá o que. Basta apertar um botão e desistir. Ter seu dinheiro de volta!

São 30 motherfucker dias de garantia!

Sim, todo o risco é MEU, e somente MEU.

Ou você gosta do Docker Definitivo! E esse projeto traz para você a transformação que você quer, ou ok, você cancela e pronto, está tudo bem!

Janela de Inscrição

Para ser justo com quem já comprou, a janela é curta, fecha domingo, dia 27/out às 23:59, ou quando a turma lotar. O evento que ocorrer primeiro, causa o fechamento da janela.

Dapr – Distributed Application Runtime – Primeiras Impressões

Dapr – Distributed Application Runtime – Primeiras Impressões

Nessa quarta-feira a Microsoft anunciou no Open Source Blog um projeto curioso chamado Dapr. Entre os principais pontos, o que me chama a atenção é que tem muita cara de servidor de aplicação/componente. E isso de certa forma me chama a atenção pelas possibilidades.

Na versão alpha, versão atual, vemos alguns building blocks muito interessantes, como:

  • Service-to-service Invocation
  • State Management
  • Pub/Sub
  • Resource Binding & Triggers
  • Actors
  • Distributed Tracing
  • Extensibility

Valle lembrar que o projeto está na versão 0.1.0, e nada do que temos agora é compromisso firmado com a versão final, eles deixam isso bem claro. Ainda está em alpha.

O post original está aqui Announcing Distributed Application Runtime (Dapr), an open source project to make it easier for every developer to build microservice applications e apenas vou traduzir algumas partes para dar prosseguimento aos comentários.

Diagnóstico e motivação

It is remarkable to see the transformation over the last few years as more and more developers build scalable, cloud native applications, taking advantage of managed services to deploy and run them. With this transformation, microservice architectures have become the standard for building cloud native applications, and it is predicted that by 2022, 90% of new apps will feature microservice architectures. A microservice architecture offers compelling benefits, including scalability, loose service coupling and independent deployments. However, this approach can come at a high cost of understanding and skilling on distributed systems.

Developers want to focus on business logic, frequently and incrementally migrating legacy code, while leaning on the platforms to provide their applications with the required scale, resiliency, maintainability, elasticity and the other attributes of cloud-native architectures. What developers find though, is limited portability between cloud and edge and they continually end up solving the same distributed system problems such as state management, resilient method calling and handling events. In addition, many programming runtimes often have narrow language support and tightly controlled feature sets, making it challenging to build microservice architectures.
É notável ver a transformação nos últimos anos, à medida que mais e mais desenvolvedores criam aplicações escaláveis ​​cloud native, aproveitando os serviços gerenciados para implantá-los e executá-los. Com essa transformação, as arquiteturas de microsserviço tornaram-se o padrão para a criação de aplicações nativos da nuvem, e prevê-se que até 2022, 90% dos novas aplicações apresentem arquiteturas de microsserviço. Uma arquitetura de microsserviço oferece benefícios atraentes, incluindo escalabilidade, acoplamento de serviço flexível e implantações independentes. No entanto, essa abordagem pode ter um alto custo de entendimento e habilidade em sistemas distribuídos.

Os desenvolvedores desejam se concentrar na lógica de negócios, migrando com frequência e incrementalmente o código legado, enquanto se apoiam nas plataformas para fornecer às aplicações a escala, resiliência, capacidade de manutenção, elasticidade e outros atributos necessários das arquiteturas nativas da nuvem. O que os desenvolvedores descobrem é a portabilidade limitada entre a nuvem e a borda e eles acabam resolvendo os mesmos problemas de sistema distribuído, como gerenciamento de estado, chamada de método resiliente e manipulação de eventos. Além disso, muitos tempos de execução de programação geralmente têm suporte a idiomas estreitos e conjuntos de recursos rigidamente controlados, tornando difícil a construção de arquiteturas de microsserviços.

Dapr: Microservice building blocks for cloud and edge

Dapr is an open source, portable, event-driven runtime that makes it easy for developers to build resilient, microservice stateless and stateful applications that run on the cloud and edge. Dapr embraces the diversity of all programming languages and developer frameworks and simplifies building applications such as the e-commerce example.

Dapr consists of a set of building blocks accessed by standard HTTP or gRPC APIs that can be called from any programming language. These building blocks empower all developers with proven, industry best practices and each building block is independent; you can use one, some, or all of them in your applications. In addition, through the open source project, we welcome the community to add new building blocks and contribute new components into existing ones. Dapr is completely platform agnostic, meaning you can run your applications locally, on any Kubernetes cluster, and other hosting environments that Dapr integrates with. This enables developers to build microservice applications that can run on both the cloud and edge with no code changes.
O Dapr é um runtime de código aberto, portátil e orientado a eventos, que facilita para os desenvolvedores a criação de aplicações resilientes, sem estado e sem estado de microsserviço, executados na nuvem e na borda. O Dapr abraça a diversidade de todas as linguagens de programação e estruturas de desenvolvedores e simplifica a criação de aplicações como o exemplo do comércio eletrônico.

O Dapr consiste em um conjunto de blocos de construção acessados ​​pelas APIs HTTP ou gRPC padrão que podem ser chamadas a partir de qualquer linguagem de programação. Esses blocos de construção capacitam todos os desenvolvedores com as melhores práticas comprovadas do setor e cada bloco de construção é independente; você pode usar um, alguns ou todos eles em suas aplicações. Além disso, por meio do projeto de código aberto, damos as boas-vindas à comunidade para adicionar novos componentes e contribuir com novos componentes nos já existentes. O Dapr é totalmente independente da plataforma, o que significa que você pode executar suas aplicações localmente, em qualquer cluster Kubernetes e em outros ambientes de hospedagem aos quais o Dapr se integra. Isso permite que os desenvolvedores criem aplicações baseadas em microsserviço que podem ser executados na nuvem e na borda sem alterações de código.

Get Started e Primeiras Impressões

A home do projeto está disponível em dapr.io. De lá o get started nos leva para o github do projeto onde encontramos alguns poucos links, mas o principal é o configure Dapr locally. Não depender do Kubernetes é um ponto alto para o projeto. Poder rodar com Docker puro, faz diferença, e dá a dimensão de que sim, é capaz de rodar em qualquer lugar, sem nos empurrar para o uso do Kubernetes.

Vale lembrar que Kubernetes embora seja standard, diversos grandes nomes da comunidade nacional e internacional não recomendam k8s para a maioria dos workloads pequenos. Nesses cenários docker swarm atende perfeitamente, e tem melhor fit. Consideramos workloads pequenos, até 7 nós masters em um cluster (detalhes). Entre os nomes que respaldam essa afirmação está Bret Fisher, um Docker Captain (detalhes sobre essa treta)

A configuração inicial é super simples, consiste em instalar uma CLI. Eu optei pelo setup com powershell pois, como eu já imaginava, uma vez instalado, poderia ser executado a partir do bash com windows terminal. Então essa foi minha opção.

Uma vez com a CLI instalada foi hora de instalar o runtime. Super simples também.

Agora era hora de rodar os samples, e ver como funciona.

Segui o passo-a-passo do primeiro hello world e tudo funcionou de primeira.

Para uma versão alpha eu achei o projeto incrível. Vale lembrar que o Hello workd é em NodeJS. A propósito, se for rodar a demo, não deixe de rodar npm install na pasta da demo.

É assim que começa “o jogo”. Uma vez sem container nenhum rodando, basta rodar dapr init para que os containers sejam inicializados. O próximo passo é rodar sua aplicação.

dapr run --app-id mynode --app-port 3000 --port 3500 node app.js

Note que ao rodar, você já enxerga um log no console estruturado como todo bom application server.

Entendendo sua arquitetura

Um das coisas que me chamou a atenção era a falta de um dockerfile no projeto node, e a necessidade de rodar um npm install no windows.

Enquanto eu esperava que mesmo que a CLI rodasse no windows, TODO o workload seria executado completamente no Linux, em containers docker. Mas a abordagem escolhida pelo projeto ainda nessa versão alpha é diferente. Nessa versão (e não há nada que eu tenha lido que aponta para uma mudança) o seu projeto é executado junto com a CLI. Assim, se a CLI está no Windows, o daprd também está no windows, e consequentemente sua aplicação roda no Windows. Por outro lado, recursos adicionais são executados diretamente no linux. Como o redis e uma instância do dapr.

E rodando estão os seguintes processos

Isso me chamou muito a atenção, pois a aplicação está rodando no Windows e apenas consumindo serviços hospedados com docker.

Nessa imagem fica claro que a CLI dapr está chamando o daprd (daemon) que hospeda algum serviço de comunicação, como um sidecar para minha aplicação node.

Essa topologia é descrita aqui:

Do outro lado, alguns serviços são hospedados como containers mas fazem parte da infraestrutura do daprd.

E assim nasce um modelo super interessante e funcional.

O máximo que pude ver foi essa conectividade, a parte de armazenamento de estado (ainda não dá para chamar de gerenciamento pois estado é controlado de forma ativa), mas enfim, já temos grandes avanços, muito interessantes. E dá para vislumbrar muito potencial para o projeto.

Outra característica muito relevante é a afinidade e proximidade com gRPC como protocolo de comunicação entre os nossos serviços e o dapr. Essa iteração vem dando poder e respaldo ao gRPC e apresenta, inclusive, um novo modelo de uso, muito interessante.

Ainda faltam dashboards, faltam algumas coisas para consolidar essa estratégia mas o que vemos já é fantástico.

Em linhas gerais esses são os serviços providos nessa versão alpha. Acredito e imagino que esses mesmos serviços vão ganhando capacidades, e suas implementações passam a ser mais amigáveis e automáticas.

A estratégia de deploy que utilizei é bem parecida com a imagem acima.

No entanto o projeto também está disponível para ser executado em clusters Kubernetes, como mostra a imagem abaixo:

O que eu tinha para apresentar do projeto hoje era só isso.

Vale a pena o teste, mas como o próprio site diz: ainda é cedo para pensar em produção. Mas já há uma boa oportunidade para contribuir com o projeto.

OSBAPI –  Open Service Broker API

OSBAPI – Open Service Broker API

Em um mundo conectado, com cada vez mais soluções SaaS e PaaS. Há uma boa tendência e convergência em iniciativas que visam criar marketplaces de soluções. Compondo serviços dos mais variados estendendo as capacidades de nuvens públicas e privadas.

Ao mesmo tempo, nunca estivemos tão conectados e nunca conectamos tantos serviços a tantos provedores de serviços. Assim novas estratégias para a interoperabilidade nascem, não somente como meios de comunicação, mas protocolos que estabelecem formas de se contratar, alocar e desalocar recursos dinamicamente. Esse tipo de abordagem é facilmente visto em grandes provedores de cloud como Azure, Google, Amazon, que possuem seus próprios padrões. Iniciativas como a OSBAPI nascem para oferecer estratégias para o mercado comum, abrindo possibilidade para não somente players menores, mas inclusive provedores menores oferecerem aplicações das mais diversas. Em um mundo cada vez mais conectado, você talvez consiga disponibilizar seu módulo de CRM/ERM diretamente em um CPANEL like em algum pequeno player ao redor do globo.

(mais…)
Open Application Model

Open Application Model

2019 tem sido um ano intenso, cheio de novidades e muitos novos padrões e standards. Kubernetes já se consolidou como plataforma de orquestração default há alguns anos e agora o movimento que vemos é na linha de criação de standards sobre o Kubernetes. Por outro lado, essa nova leva de padrões e especificações oferece um modelo de aplicações e serviços dinamicamente alocáveis, conectáveis e desalocáveis que parece vir de um futuro muito, mas muito distante. São iniciativas interessantes que muito provavelmente ainda sofrerão mutações e algumas fusões no percurso, mas que oferecem imenso potencial para viajarmos nas possibilidades de um futuro nem tão distante assim.

Assim começamos com o Open Application Model.

(mais…)
Post Resposta: POR QUE ADOTAR KAFKA PARA MENSAGERIA?

Post Resposta: POR QUE ADOTAR KAFKA PARA MENSAGERIA?

Esse é um post resposta ao post POR QUE ADOTAR KAFKA PARA MENSAGERIA? do Elemar JR no site da Eximia, sua empresa.

A resposta estava ficando longa demais, e resolvi transformar em post. Principalmente por se tratar de um conteúdo (RabbitMQ) que está no meu toolset, assim como Kafka está para entrar. Vou aproveitar para usar essas resposta para compor a seqüência de posts da série RabbitMQ de A a Z, pois essa questão RabbitMQ vs Kafka foi um tema solicitado pela audiência e não foi respondida na época.

(mais…)
The Microservices Journey – S1E2

The Microservices Journey – S1E2

No post passado eu citei alguns elementos que precisam ser levados em conta, e não detalhei muita coisa. Só narrei causa e efeito. Hoje eu vou listar o material que já produzi que tem alguma ligação com o tema. Direta ou indiretamente, são elementos que vão ajudar a esclarecer como essa jornada, e mostrar como tudo começou para mim. Eu me proponho a elucidar alguns pontos que vão ajudar a esclarecer e te ajudar a construir soluções melhores.

(mais…)