fbpx

.NET

Cloud Native e Cloud Agnostic

para rodar .NET em qualquer Cloud
ou sem Cloud sempre de forma profissional!

Últimas publicações

Aqui estão os últimos 12 posts de mais de 400…
Além das 3 camadas | Ferramenta: Redis

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...

ler mais
Além das 3 camadas | Iniciando os trabalhos

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...

ler mais
O que aprendi acompanhando projetos sem arquitetos

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...

ler mais

Fique por dentro e não perca nada

Menos de 10% da audiência recebe o conteúdo publicado

A newsletter é o meio mais eficiente de furar o bloqueio dos algoritmos das redes sociais e fazer o conteúdo chegar até você.

Assim evitamos poluir as comunidades com chamadas para eventos e lives.

Essa é forma mais eficiente de receber meu conteúdo.

Somos mais de 6k inscritos

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 tutorial

Para 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 Podcast

Em 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.

Saiba mais...

.NET

Docker – de A a Z – 19 – Youtube Downloader – o projeto

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)

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.

ler mais…

Escassez de documentação, entenda como as coisas funcionam

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.

ler mais…

JWT no ASP.NET Core – Standalone

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.

ler mais…

.NET Core – Configurações específicas por SO

.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.

ler mais…

Arquitetura

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!

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.

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.

ler 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.

ler mais…

Containers

Docker – de A a Z – 18 – NodeJS API com MongoDB

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.

Docker – de A a Z – 17 – Build and running WSO2 Identity Server

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…

Docker – Images vs Layers

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

2018-2020

2020-2021

2021-2022

2022-2023

2023-2024

2024-2025

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.