.NET
Cloud Native e Cloud Agnostic
para rodar .NET em qualquer Cloud
ou sem Cloud sempre de forma profissional!
Últimas publicações
Concorrência e Race Condition com Cache Distribuído: O Workflow correto
Se você está vendo cache distribuído pela primeira vez, talvez tenha deduzido qual é a forma adequada de trabalhar com ele. A pergunta que fica é: Você levou em conta a concorrência?. A questão é que quando o cache expira, devemos usar o recurso "lento" para produzir o dado que será cacheado. Mas...
Além das 3 camadas | Prática: Reduzindo pressão sob a aplicação e banco
Nessa série de posts estamos furando a bolha, saindo do desenho básico de 3 camadas, indo além. Hora vamos abordar práticas, hora vamos abordar ferramentas. Hoje vamos falar de uma prática: Reduzir a pressão sobre aplicação e banco de dados. Essa é uma prática super comum, mas negligenciada...
Além das 3 camadas | Ferramenta: Redis
Nessa série de posts estamos furando a bolha, saindo do desenho básico de 3 camadas, indo além. Hora vamos abordar práticas, hora vamos abordar ferramentas. Hoje vamos falar de uma ferramenta, o Redis. Ele pode ser seu aliado na hora de hospedar dados pré-processados. Disclaimer sobre a...
Além das 3 camadas | Iniciando os trabalhos
Se um dia você se questionou sobre o que deveria estudar sobre projetos que vão além de uma Web App, uma API e um Banco de dados aqui vão minhas dicas. Eu separei 3 tecnologias que são matadoras porque ajudam projetos de todos os tamanhos. Dê uma olhada e me diga o que você achou! Por que sair do...
Processamento Síncrono vs Assíncrono e Black Friday – Case Pan, Kabum e Pichau 2021
Essa noite aconteceu uma coisa muito chata. Em plena Black Friday, eu saí frustrado por 2 problemas de arquitetura encadeados. De um lado um banco digital que fica offline todo dia durante a madrugada e pior, inclusive na Black Friday. Do outro, um e-commerce com o fluxo de pagamento síncrono, que...
Overengineering, BDUF, Complexidade Acidental? Por que estamos usando tantas ferramentas, tecnologias etc?
Se você está nesse planeta ativo em alguma comunidade deve ter percebido que todo dia surge uma nova solução que dizem que devemos usar. Docker, Kubernetes, Redis, Jaeger, Helm, RabbitMQ, Kafka, ELK, Kong, NGINX, Traefik, Keycloak, Jenkins, SonarQube... onde isso vai parar? Como deixamos chegar...
Enterprise Application Log – A origem das decisões
Inúmeras vezes eu apresento o Enterprise Application Log e instantaneamente aparece alguém tentando "defender" o Application Insights, como se de alguma forma eu estivesse cometendo uma heresia ao propor qualquer outra coisa. O mais curioso é que essa comparação é superficial e infundada. Hoje...
Docker Definitivo – Inscrições dias 11 e 12 de Novembro
Após um longo inverno, teremos mais uma janela de inscrição para o Docker Definitivo! Esse é o momento em que você poderá se inscrever para fazer parte da nossa tribo! Um dia eu disse que eu acreditava que Docker mudaria a forma como enxergamos a hospedagem de aplicações. Um dia sonhei que talvez...
NHibernate em 2022 – Será que faz sentido?
Se você já me viu falar de persistência, você talvez já saiba do que eu estou falando, mas talvez não entenda os argumentos. A história do NHibernate NHibernate é um full featured ORM que nasceu em 2005 como um port do Hibernate do Java aqui na plataforma .NET. O Hibernate do Java nasceu em 2001,...
RPC sob AMQP seduz enquanto mata… sua implantação de mensageria
Se você viu meu último post e se animou por acreditar que usar RPC sob AMQP seja uma ideia incrível, calma que lá vem um balde de água fria! Com toda certeza eu não vou falar bem da abordagem! E se você resolveu que não vai ler, e ainda vai adotar RPC sob AMQP assim mesmo. Esse post é o que os...
Messaging Patterns: RPC – Remote Procedure Call
RPC pode parecer sofisticado demais, mas que tal Request/Response? Agora "SOA" familiar? Nem só de total assincronismo vive o mundo da mensageria, há momentos em que precisamos de uma resposta. RPC é a forma mais prática de adotar mensageria, mas é preciso entender as consequências dessa...
O que aprendi acompanhando projetos sem arquitetos
Esse é um relato dos meus 20 anos no mercado. Por sorte e até ironia do destino, eu vi o papel do arquiteto desde o dia 1 de minha jornada de trabalho. Isso me possibilitou entender que arquitetos e desenvolvedor possuem interesses diferentes. Aqui vou mostrar o que esses anos vendo e ajudando...
Projetos Open Source
projetos ativos e projetos antigos disponíveis para estudo
Nenhum resultado encontrado
A página que você solicitou não foi encontrada. Tente refinar sua pesquisa, ou use a navegação acima para localizar a postagem.
Entender | Analisar | Projetar | Desenvolver | Implantar | Manter
A segurança que você busca não está em um tutorialPara entender uma tecnologia é importante entender o que influenciou sua criação, o que ela faz de fato, como ela faz. Para que então se sinta seguro e confiante a respeito das decisões que está prestes a tomar.
De um lado precisamos compreender o que está sendo feito por baixo dos panos para descobrir como extrair o máximo de uma tecnologia ou, ao menos, não atrapalhar o bom funcionamento dela.
O Cloud Native .NET é uma jornada de descoberta sobre tecnologias e patterns que fazem parte da maioria dos softwares que usamos, que somos usuários e que suportam e toleram altas cargas de trabalho, de forma eficaz, eficiente e sustentável.
É primeiro entendendo o que eles fazem, que podemos descobrir oportunidades e evoluir no que fazemos…
Conheça nosso Podcast
DevShow PodcastEm 2019 resolvemos criar um podcast, o DevShow Podcast, desde lá são mais de 40 episódios com muito assunto legal, sempre com essa pegada pessoal, falando coisas sérias, mas sem o menor compromisso com a formalidade.
.NET
Docker – de A a Z – 19 – Youtube Downloader – o projeto
Olá, esse é o vídeo de número 19 da série e vamos abordar um tema incomum: Pizza! Oops brincadeira! Youtube Downloader! A escolha desse projeto se dá pela necessidade de utilizar paralelismo para processar as requisições de download, tratar-se de um projeto não convencional, e precisar de cuidados ortogonais quanto ao design da solução em si. São elementos que fazem desse projeto um projeto divertido e cheio de peculiaridades. A principal característica é sair do mais do mesmo, dos cruds com MongoDB e Redis e mostrar um exemplo mais rico. ler mais…
Docker – de A a Z – 14 – ASP.NET Core from Scratch to Production with docker & jenkins (pt-BR)
Apresento aqui um projeto ASP.NET Core, desde sua criação até sua chegada a produção, com jenkins.
Começamos apresentando as opções de criação do projeto, depois habilitamos a integração com o Docker for Windows. Em seguida adicionamos mongodb ao projeto e começamos a desenhar o build de produção, ainda na máquina de desenvolvimento. Ao concluir o processo de configuração, subo o código para o github e faço o build no jenkins, usando pipeline para realizar build e deploy da nossa aplicação ASP.NET Core.
Escassez de documentação, entenda como as coisas funcionam
Se você não é capaz de entender uma implementação lendo código, é bom começar. Mesmo que por hobby, ler código lhe fará entender melhor como as coisas funcionam, ou pelo menos lhe dar mais opções na hora de avaliar alguma implementação. Há inúmeros projetos Open Source bem documentados, no entanto quando se depara com algo recente, a escassez de documentação é uma realidade dolorosa.
Ao encontrar um projeto relevante, provavelmente buscará um tutorial, ou algo que te aproxime do entendimento, mas nem sempre esse tipo de material está disponível. Há momentos que você quer algo específico e também não encontra conteúdo indexado no google. Há momentos em que você só quer entender como um pedaço do projeto foi feito, para entender como alguns problemas são resolvidos, quais padrões foram usados, enfim, como foi feito. Ler código é importantíssimo.
JWT no ASP.NET Core – Standalone
Após o hangout que rolou nessa sexta estávamos discutindo JWT no ASP.NET Core (JSon Web Tokens) e ao apresentar um dos meus projetos cheguei a ficar envergonhado, pois eu havia dado uma certa volta para evitar a utilização de criptografia simétrica e acabei fazendo uma implementação de ISecurityTokenValidator o que é uma imensa volta para uma implementação padrão de geração tokens JWT. Bom, madrugada livre, resolvi acertar isso de uma vez e acabei transformando esse aprendizado em post.
.NET Core – Configurações específicas por SO
Que o .NET Core roda no Windows e no Linux isso é mais que sabido. Mas você pode precisar de configurações específicas por tipo de SO. Paths necessários para executar alguma tarefa podem divergir, e esse é o caso do docker. O endereço da API do Docker Daemon é diferente no Windows e no Linux. No Linux você usa unix sockets, enquanto no Windows named pipes.
Arquitetura
.NET no Linux, vale a pena?
A gente está a tanto tempo nessa batida, que nem nos questionamos mais, mas há muita gente que ainda tem dúvidas ou precisa de argumentos. Enquanto de um lado sequer cogitamos fazer deploy de aplicações .NET Core no Windows, por outro há quem ainda tenha medo de sair do windows.
ler mais…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!
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.
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.
ler mais…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.
ler mais…Containers
Docker – de A a Z – 18 – NodeJS API com MongoDB
Nesse vídeo damos continuidade à série Docker de A a Z e vou abordar o desenvolvimento com NodeJS, TypeScript, Restify, TSLint, MongoDB e VSCode usando Docker para release e debug, além permitir rodar serviços adicionais como MongoDB entre outros.
O projeto do gerador de código é melhor detalhado no post (((((NodeJS + TypeScript + TSLint + Restify) + MongoDB) + Docker) + VSCode ) + Yeoman) = Uma experiência de desenvolvimento incrível!, mas você pode baixar o projeto direto do repositório npm ou github.
(((((NodeJS + TypeScript + TSLint + Restify) + MongoDB) + Docker) + VSCode ) + Yeoman) = Uma experiência de desenvolvimento incrível!
Esse post foi movido para /blog/projetos/yeoman-generator-node-api-docker-1st-class-experience/
Docker – de A a Z – 17 – Build and running WSO2 Identity Server
Um dos recursos mais comuns em aplicações corporativas é a gestão de identidade. Ou você implementa na aplicação, ou você utiliza um serviço externo como Auth0, Azure Active Directory ou outros. Quem está próximo das tecnologias Microsoft já ouviu falar do Identity Server (outro projeto), no entanto é importante conhecer outras soluções e a WSO2 possui uma: O WSO2 Identity Server, e é sobre esse projeto que falarei hoje. ler mais…
Windows Subsystem for Linux & Docker
Ao longo de 2016 fiz uma série de vídeos sobre docker, da qual devo retomar nas próximas semanas. Nesse post vou abordar exclusivamente Docker e Windows Subsystem for Linux. Acho que vai ajudar a esclarecer!
Docker – Images vs Layers
Sempre que fazemos um build de uma imagem docker, estamos criando novas layers a cada comando do dockerfile. A última layer de cada build é a layer que identifica aquela imagem, é sob ela que o Docker aplica a tag quando usamos o parâmetro -t {imagename:tagname}, para dar nomes semanticamente eficientes.
Abaixo trago um vídeo bem curtinho, gerado direto do powerpoint para ilustrar esse aspecto.
É só isso, a intenção é apenas ilustrar esse aspecto, facilitando o entendimento. Em breve esse vídeo estará incorporado a um vídeo maior que detalhará o processo de build.
Mensageria
Nenhum resultado encontrado
A página que você solicitou não foi encontrada. Tente refinar sua pesquisa, ou use a navegação acima para localizar a postagem.
Conteúdo e Posicionamento
.NET + Cloud Native + Cloud Agnostic
.NET | DevOps | Microservices | Containers | Continuous Delivery
.NET muito além do .NET
O mínimo de infra que todo dev e/ou arquiteto deveria saber
Aplicações distribuídas e comunicação entre serviços (RabbitMQ / gRPC)
Containers, Docker e Kubernetes
RabbitMQ e Mensageria e comunicação assíncrona entre aplicações e serviços
Arquitetura de Software e Arquitetura de Solução com foco no melhor aproveitamento em projetos .NET
Nossos números
Desde 2002 trabalhando com desenvolvimento de software
Desde 2002 ajudando outros devs
Desde 2010 trabalhando exclusivamente como arquiteto
Contas atingidas no telegram/facebook
Alunos
Microsoft MVP
Conteúdo Gratuito
Tudo que está aqui no gaGO.io é conteúdo gratuito, feito para ajudar desenvolvedores dos mais variados níveis.
Cursos
Tenho também alguns programas de acompanhamento. Esses programas tem a função de ajudar desenvolvedores em áreas específicas ou de forma mais abrangente na jornada do arquiteto.