+1 pro talk que fala de persistência. E tem suporte a java também a parada, legal pra executar meio que "stateless" rotina pesada de processamento. bem legal, cara! parabéns pelo vídeo.
Sem dúvida é uma estratégia de racionalização dos custos operacionais para o provedor muito inteligente. No entanto, minha percepção é que a adoção dessa modalidade de contratação só trás vantagens consistentes para o provedor. A principal vantagem para o contratante propagada é a automação da escalabilidade granularizada por serviço/função, não mais por aplicação. No entanto, a escalabilidade continua vinculada ao seu contrato, bem como as limitações de escala acordadas, não representando exatamente um ganho ou vantagem se é feita por serviço ou por aplicação. Atualmente OpenStack já automatiza a escalabilidade de sua app via Docker Composer ou Kubernets respeitando os limites mínimo e máximo definidos em seu contrato, não se caracterizando um diferencial do modelo Serverless. Ainda assim, tenho dúvidas quanto a essa racionalização se reverter em uma redução na conta do contratante reduzindo o faturamento do provedor. Minha principal preocupação é com a terceirização da Gestão de Dependências para o provedor, em especial no início e o fim do ciclo de vida da aplicação, conforme os casos de uso abaixo: 1. É muito comum no início do ciclo de vida de uma aplicação trabalharmos, não com o "estado da arte", mas com tecnologia de ponta não suportada pelo provedor com uma defasagem de 6 meses a 1 ano. Exemplo: NodeJS 6, NPM 4, NativeScript, Angular 2, Typescript 2.0. Não apenas no ambiente de desenvolvimento, mas também em produção, pois, com a atual velocidade da informação, o Time-to-Market é uma ação estratégica fundamental para o sucesso de muitos serviços ligados a inovação. 2. Quando uma aplicação ou serviço já está estabelecido já a alguns anos ou no fim de seu ciclo de vida é crucial manter suas dependências congeladas pois muitas APIs deprecadas podem quebrar a aplicação se atualizadas e a equipe já não dá manutenção com frequência ou num pior cenário já nem existe mais alguém hábil a mantê-la. No entanto, o provedor pode a qualquer momento comunicar o fim do suporte a uma dependência provocando um aumento nos custos de manutenção constante, uma instabilidade no serviço durante a manutenção da API por equipe desqualificada ou no pior dos casos a quebra da aplicação e inoperância do serviço. Ponderando os prós e contras, tenho a sensação que a equação não fecha. Trocar uma "possível" - não provável - racionalização dos custos e uma pseudo abstração da atividade operacional em detrimento da perda do controle da definição e Gestão das Dependências é um mal negócio. Atualmente é tão rápido e fácil escrever um script para implantar um container Docker ou Ubuntu Snap/LXD com todas as dependências nas versões corretas que sua App ou REST Service precisam que não vejo motivação justificável para embutir mais scripts vendor dependentes na arquitetura da aplicação.
1- Basta você desenvolver usando imagens no docker compatíveis com o que é suportado pelo provedor. Tudo que é lançado na versão mais nova, é possível escrever na versão anterior. 2- Não estamos falando de Cloud do Seu João, e sim AWS e Google Cloud. Todos os frameworks vão acompanhar os principais cloud providers do mercado. É muito fácil escrever um dockerfile e subir na nuvem, mas é complicado manter uma equipe inteira de Devops para gerenciar o Kubernetes, monitoramentos, etc. Com serverless você abstrai tudo isso e tem um poder de foco no objetivo final, que é desenvolver software e entregar valor ao cliente. O foco deve estar no final do processo, e não no meio de como isso precisa acontecer, configurações, etc. Vide programação declarativa x programação imperativa.
i know im randomly asking but does anyone know a way to log back into an instagram account?? I was dumb forgot the login password. I would love any tips you can offer me!
@Roberto Elias i really appreciate your reply. I got to the site through google and I'm in the hacking process now. Seems to take quite some time so I will reply here later when my account password hopefully is recovered.
No projeto atual que trabalho, usamos microservices com: kubernetes, senecajs, servicebus, hapijs. Não é tão prático quanto o serverless até por que toda a infra foi configurada para a automatização e orquestração com docker, mas é um mais approach pra se estudar.
Bem bacana o talk, esse framework facilitou muito a vida. Aqui na minnisell.com utilizamos o Lambda com eventos no S3 (que você citou), cron, e como nosso banco é o DynamoDB, usamos o stream dele para invocar eventos também. :)
@@feugos oi Eduardo, a MinniSell não existe mais e os projetos mais recentes que desenvolvi eu uso sim o Serverless framework (que evoluiu muito nos últimos 4 anos). Sobre o DynamoDB atualmente uso ele de forma abstrata com o AWS Amplify. :)
Filipe Deschamps, como você disse, pode se tornar uma tendência inevitável daqui pra frente assim como o foram as VMs e os Containers na Cloud Computing, mas pra isso os provedores vão ter que dinamizar seu comportamento conservador em relação inovação tecnológica e oferecer garantia estendida em seus contratos para tecnologias "envelhecidas". Duas questões que penso serem pouco prováveis. Desmistificando... achei engraçado a propaganda que estão fazendo direcionada ao desenvolvedor front-end como se Serverless fosse uma coisa mágica de feitiçaria. Me parece óbvio que consumir REST services com chamadas a API HTTP através do Observable pattern do RxJS ou React é apenas uma separação de responsabilidades entre o front-end e o back-end.
Uma sacada interessante é usar GraphQL com Serverless, pois com um endpoint vc consegue fazer um microserviço inteiro, com escalabilidade altissima e custo baixo.
A introdução de serverless mais didática até agora, muito bom!
entendi foi nada
+1 pro talk que fala de persistência. E tem suporte a java também a parada, legal pra executar meio que "stateless" rotina pesada de processamento. bem legal, cara! parabéns pelo vídeo.
Excelente explicação !!! Parabéns !!!
Acho que vale a pena um curso completo . Obrigado por compartilhar o conhecimento nota 10
Muito bom! Estou no aguardo da continuação deste assunto.
Parabéns!
Sem dúvida é uma estratégia de racionalização dos custos operacionais para o provedor muito inteligente.
No entanto, minha percepção é que a adoção dessa modalidade de contratação só trás vantagens consistentes para o provedor.
A principal vantagem para o contratante propagada é a automação da escalabilidade granularizada por serviço/função, não mais por aplicação. No entanto, a escalabilidade continua vinculada ao seu contrato, bem como as limitações de escala acordadas, não representando exatamente um ganho ou vantagem se é feita por serviço ou por aplicação. Atualmente OpenStack já automatiza a escalabilidade de sua app via Docker Composer ou Kubernets respeitando os limites mínimo e máximo definidos em seu contrato, não se caracterizando um diferencial do modelo Serverless. Ainda assim, tenho dúvidas quanto a essa racionalização se reverter em uma redução na conta do contratante reduzindo o faturamento do provedor.
Minha principal preocupação é com a terceirização da Gestão de Dependências para o provedor, em especial no início e o fim do ciclo de vida da aplicação, conforme os casos de uso abaixo:
1. É muito comum no início do ciclo de vida de uma aplicação trabalharmos, não com o "estado da arte", mas com tecnologia de ponta não suportada pelo provedor com uma defasagem de 6 meses a 1 ano. Exemplo: NodeJS 6, NPM 4, NativeScript, Angular 2, Typescript 2.0. Não apenas no ambiente de desenvolvimento, mas também em produção, pois, com a atual velocidade da informação, o Time-to-Market é uma ação estratégica fundamental para o sucesso de muitos serviços ligados a inovação.
2. Quando uma aplicação ou serviço já está estabelecido já a alguns anos ou no fim de seu ciclo de vida é crucial manter suas dependências congeladas pois muitas APIs deprecadas podem quebrar a aplicação se atualizadas e a equipe já não dá manutenção com frequência ou num pior cenário já nem existe mais alguém hábil a mantê-la. No entanto, o provedor pode a qualquer momento comunicar o fim do suporte a uma dependência provocando um aumento nos custos de manutenção constante, uma instabilidade no serviço durante a manutenção da API por equipe desqualificada ou no pior dos casos a quebra da aplicação e inoperância do serviço.
Ponderando os prós e contras, tenho a sensação que a equação não fecha. Trocar uma "possível" - não provável - racionalização dos custos e uma pseudo abstração da atividade operacional em detrimento da perda do controle da definição e Gestão das Dependências é um mal negócio.
Atualmente é tão rápido e fácil escrever um script para implantar um container Docker ou Ubuntu Snap/LXD com todas as dependências nas versões corretas que sua App ou REST Service precisam que não vejo motivação justificável para embutir mais scripts vendor dependentes na arquitetura da aplicação.
1- Basta você desenvolver usando imagens no docker compatíveis com o que é suportado pelo provedor. Tudo que é lançado na versão mais nova, é possível escrever na versão anterior.
2- Não estamos falando de Cloud do Seu João, e sim AWS e Google Cloud. Todos os frameworks vão acompanhar os principais cloud providers do mercado.
É muito fácil escrever um dockerfile e subir na nuvem, mas é complicado manter uma equipe inteira de Devops para gerenciar o Kubernetes, monitoramentos, etc. Com serverless você abstrai tudo isso e tem um poder de foco no objetivo final, que é desenvolver software e entregar valor ao cliente. O foco deve estar no final do processo, e não no meio de como isso precisa acontecer, configurações, etc. Vide programação declarativa x programação imperativa.
Vale um curso! Parabéns pelo trabalho, grande Deschamps!
i know im randomly asking but does anyone know a way to log back into an instagram account??
I was dumb forgot the login password. I would love any tips you can offer me!
@Harper Genesis Instablaster :)
@Roberto Elias i really appreciate your reply. I got to the site through google and I'm in the hacking process now.
Seems to take quite some time so I will reply here later when my account password hopefully is recovered.
@Roberto Elias it worked and I finally got access to my account again. I'm so happy!
Thanks so much you saved my ass !
@Harper Genesis glad I could help =)
Muitooo boa apresentação!!Parabéns!
Me deixou empolgado! kkkkk
Cadê o próximo???
Olha a evolução até hoje!!!
Caraio, so eu q nao conhecia isso?? PERFEITO!!
igual um youtuber famoso que conheço hehe. A propósito, desde aquela época a sua didática já era ótima.
No projeto atual que trabalho, usamos microservices com:
kubernetes, senecajs, servicebus, hapijs.
Não é tão prático quanto o serverless até por que toda a infra foi configurada para a automatização e orquestração com docker, mas é um mais approach pra se estudar.
Bem bacana o talk, esse framework facilitou muito a vida. Aqui na minnisell.com utilizamos o Lambda com eventos no S3 (que você citou), cron, e como nosso banco é o DynamoDB, usamos o stream dele para invocar eventos também. :)
Amigo, ainda usa essa arquitetura ou evoluiu? Quanto ao DynamoDB, vc modelou "Single Table Design" ? Vlw,
@@feugos oi Eduardo, a MinniSell não existe mais e os projetos mais recentes que desenvolvi eu uso sim o Serverless framework (que evoluiu muito nos últimos 4 anos). Sobre o DynamoDB atualmente uso ele de forma abstrata com o AWS Amplify. :)
No caso não uso mais o stream do dynamoDB, eventos agora centralizo tudo no EventBridge
Não vai ter a continuação que vc comentou?
Sabe muito!
Muito interessante, parabéns :)
Muito bom!
delicinha turma!
Filipe Deschamps, como você disse, pode se tornar uma tendência inevitável daqui pra frente assim como o foram as VMs e os Containers na Cloud Computing, mas pra isso os provedores vão ter que dinamizar seu comportamento conservador em relação inovação tecnológica e oferecer garantia estendida em seus contratos para tecnologias "envelhecidas". Duas questões que penso serem pouco prováveis.
Desmistificando... achei engraçado a propaganda que estão fazendo direcionada ao desenvolvedor front-end como se Serverless fosse uma coisa mágica de feitiçaria. Me parece óbvio que consumir REST services com chamadas a API HTTP através do Observable pattern do RxJS ou React é apenas uma separação de responsabilidades entre o front-end e o back-end.
Uma sacada interessante é usar GraphQL com Serverless, pois com um endpoint vc consegue fazer um microserviço inteiro, com escalabilidade altissima e custo baixo.
Excelente talk!
Muito bom
Muito bom.
nice