3740
🔥Desde 2016! 💥O maior e mais ativo grupo de .NET do Telegram há 9 anos. 🎯Grupo sobre .NET, ASP.NET, Mono, .NET Core, Xamarin, C# etc. Use /info para as regras e informações adicionais. 👉Regras: go.gaGO.io/dotnetbr-rules
Aí que tá, eles podem ficar isolados, se forem reaproveitados,
mas aí há uma questão.
Se você quer reaproveitar, você vai tirar toda o acoplamento com a camada web e vai transformar em um modelo puro.
Por que não? Esses objetos são apenas contratos da API, e como tal deveriam ficar nela, não? Qual é o sentido dos contratos de APIs ficarem em “Application” (ou qualquer outra coisa). Eu vejo grandes problemas com isso porque algum desavisado pode alterar um objeto que está em “Application” e com isso acabar quebrando a API.
O que eu vejo como ideal, na verdade, é ter um projeto apenas para esse objetos, um “Contracts” — e se necessário isso virar um NuGet pra outras APIs.
@tenshizer0 agora voltei para o escritório, mas acima a imagem mais famosa descreve o objetivo desse isolamento do core.
Читать полностью…
Oh bom mesmo é saber que de 2018 pra cá apareceram varias alternativas ao Docker algumas ate interessante, é sempre bom ter alternativas.
Читать полностью…
É muito fácil demandar uma segunda forma de entrada/saída.
Mensageria é o mais comum.
Mas pode ser um console, um job scheduler...
Tu tens algum artigo onde explicas isso melhor? Estou procurando aqui nas APIs que mantenho se existe alguma coisa que quebre essa regra de request/response estarem na Application
Читать полностью…
Os 6 níveis de maturidade no uso de Containers
Do usuário eventual ao heavy user, Docker consegue entregar diversas experiências de acordo com seu nível de maturidade e conhecimento.
Se comparado com outras tecnologias, Docker e Containers em geral são assuntos pequenos, para poucas semanas de estudo. Mas embora a extensão do conhecimento não seja tão grande, a abrangência do seu uso beira o infinito. E cada vez que você aprofunda no uso vai mudando a perspectiva sobre o que é aceitável, certo esperado.
Entender os níveis de maturidade ajuda na compreensão de onde você está e onde você pode chegar.
https://gago.io/blog/docker-6-niveis-de-maturidade/
(post de 2022)
Aqui comigo hoje:
- Angular > Docker
- Wordpress > Docker
- Bancos Relacionais e não relacionais > Docker
- Mensageria > Docker
- Cache > Docker
- Ci/CD > Docker
- Api gateway > Docker
- .NET Web MVC -> Docker
- .NET Web API -> Docker
- .NET Worker -> Docker
- .NET Queue Consumer -> Docker
- .NET Bot -> Docker
nada aqui roda fora de container há pelo menos alguns muitos anos.
É um modelo que suporte desde pequenos projetos para servers do tamanho de um raspberry até grandes clouds e projetos multicloud com milhares de instância.
Читать полностью…
Já quanto ao desenvolvimento, temos um ambiente de build, por mais complexo que seja, 100% documentado. Em uma documentação que não tem como ficar defasada.
Simplesmente porque é parte do projeto.
Sem o dockerfile, seu projeto não builda, então além de descrever todas as necessidades, deixa de exigir configurações bizarras e setups lentos de novos desenvolvedores.
O primeiro ponto de absoluta diferença é sair do windows server e do IIS. Aqui estamos falando de ganhos monumentais.
Um mesmo parque (hardware) é infinitamente mais estável, e entrega muito mais processamento por core/gb.
Meu papel é dar pitaco no projeto dos outros. Era um sonho antes de ser implementado pela microsoft.
Hoje é realidade na maior parte dos projetos novos que tomo conhecimento.
E desde 2019 tenho curso ensinando essa jornada.
Não coloco 1 vírgula sem docker em produção nunca mais!!!!!
Claro a não ser que seja um caso em que temos apenas uma resposta que só atende à web, aí não vejo sentido em não estar no projeto web.
Читать полностью…
são?
se são só da API, devem ficar nela.
se não são
não devem ficar nela.
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 nisso?
- Isso é para vender cloud? Para vender curso?
É sobre isso que vamos debater hoje.
https://gago.io/blog/overengineering-bduf-complexidade-acidental-por-que-estamos-usando-tantas-ferramentas-tecnologias-etc/
Trocar de http json ou rest pra gRPC, nunca foi demanda (é igual cabeça de bacalhau), todo mundo sabe que existe mas ninguém nunca viu.
Mas separar responsabilidades, desfazer processos inchados, quebrar processos, sempre foi demanda para solucionar uma infinidade de problemas.
Ps: estou falando de monolitos que permanecem monoliticos.
Não confundir com migração de monolito para microsserviço.
Não é a simples quebra de um processo em vários que faz de uma arquitetura microsserviços.
Eu passei de 12 anos só fazendo recuperação e reestruturação de projetos dotnet fracassados, e o maior problema em absoluto era focar no que não importa e esquecer o que importa.
Em todas as reestruturações mensageria foi adotada para os mais variados objetivos.
Desde reduzir infra, para atender mais demanda, a entregar resiliência para poder fazer deploy com uma periodicidade maior.
É parte do que a maioria dos projetos dotnet capota, em não olhar para o que o mercado open source faz para fazer o que fazem.
Sob hipótese alguma eu penso em um core com apenas 1 porta.
E a api é uma porta.
Eu nunca vou cogitar que uma aplicação seja ela qualquer, tenha apenas a api para sempre.
O breakeven dos projetos Docker
– Sem docker é mais caro
Docker já faz parte de muitos projetos que tenho assistido e participado, e está cada vez mais no dia-a-dia de mais gente. Uma vez superada a curva de aprendizado, você rapidamente se vê com super poderes, compondo suas aplicações com os mais variados serviços, e eliminando assim a necessidade de construção e setup extenso de diversos desses serviços. Esse empoderamento lhe permite fazer muito mais, de forma muito mais profissional com menor custo1.Então vemos um fenômeno curioso, o breakeven dos projetos Docker, onde meus orçamentos saem mais caros quando não uso docker, do que usando docker. É sobre isso que vou abordar hoje.
https://gago.io/blog/o-breakeven-dos-projetos-docker/
(post de 2018)
e o que muda de um cliente muito pequeno para um cliente muito grande é o nível de maturidade que você escolhe para esse ambiente.
Por exemplo, o cliente tem uma pegada mais de serviços gerenciados, então o banco tem de ser gerenciado, o rabbitmq tb, já redis sempre vai ser melhor no container.
Mas clientes grandes em que o time tem maturidade para lidar com clusters em ambientes kubernetes, até banco e rabbitmq vão para o kubernetes.
mas em linhas gerais um conhecimento só, planificado, útil para qualquer contexto.
Sabendo que bala de prata não existe, é o mais próximo que existe de bala de prata / one size fits all.
Читать полностью…
no windows, em horario de pico, ficava caindo, no .net 3.1 tinha horarios de pico que dava problema no docker, no .net 6 ja foi resolvido e migramos, agora estamos no .net com telemetria (opentelemetry).
Читать полностью…
Não depender do IIS, nos dá a oportunidade de não depender de apertares de botão. Zero interface gráfica.
Tudo configurável, versionado junto com o projeto. Isso dá uma paz.
Acho que o modelo devOps e outros conceitos né de escalonamento acabam forçando a galera a migrar
Читать полностью…
Queria saber se tem se tornado um padrão de mercado
Читать полностью…