"Precisamos gastar cada vez mais com servidores"

Tecnologia
ThiagoDV  
em 21/02/20 20:08

Comentários

Último comentário 1º comentário do autor Só moderadores Só quem eu sigo Ordenar por gostei
oxe  
em 21/02/2020 20:37
De maneira relacionada :)

; 4; ; 0;
0 '; 0';
"Precisamos gastar cada vez mais com servidores" - #1 de 25
andre_santos  
em 21/02/2020 20:51
Muito bom o tópico, parabéns. Quando não se tem dinheiro "infinito" (cenário de uns 95% dos serviços) servidor é um baita desafio, quem dera desse pra jogar tudo num auto scaling da amazon e esquecer disso haha.

Há uns tempos li uma matéria sobre os custos do Lyft (app de transporte semelhante ao Uber), e eles diziam gastar cerca de US$100 milhões por ano com infra (que dava tipo uns 14 cents por corrida).
; 2; ; 0;
0 '; 0';
"Precisamos gastar cada vez mais com servidores" - #2 de 25
ChihuehueBR  
em 21/02/2020 21:04
Talvez seja hora de rever algumas features do site?
; 4; ; 0;
0 '; 0';
"Precisamos gastar cada vez mais com servidores" - #3 de 25
rangafera  
em 21/02/2020 21:56
Administro um portal de notícias conhecido no meu Estado e sei bem como é isso.

Já usei a Digital Ocean e saí recentemente com a alta do dólar. O servidor ficou ainda mais caro.
; 2; ; 0;
0 '; 0';
"Precisamos gastar cada vez mais com servidores" - #4 de 25
gustavo  
em 21/02/2020 22:22
bem explicado ThiagoDV

tem q colocar nessa "conta" além da capacidade de processamento:

- capacidade de backup / recovery disaster: em pouco tempo iniciar uma instancia nova com os dados mais recentes. ex. snapshot diário de todos os discos, custa $$$

- capacidade de escalabidade: o quão rápido seria disponibilizar mais memoria, CPU ou disco caso tenha um pico de acesso ou mesmo crescimento rápido. Dependendo do cloud usado, leva apenas alguns minutos mas custa $$$

- egress: um dos custos mais altos na nuvem, tudo q é "baixado" / sai do servidor (musica, imagem, video, dados em geral), dependendo do custo vale a pena contratar uma CDN para fazer cache ? $$$

- recursos de segurança: firewall de borda, anti DDos, WFA, limitações de acesso ao console do servidor etc $$$

- stackdriver: capacidade de monitorar remotamente o servidor além de poder ser notificado de N formas quando algo está fora do comum, ou fora do ar $$$

- licença com AV $$$

e por ai vai...

oq @alyr3 citou
refatoração e database tuning  são uma constante, e até mesmo encerrar algumas funcionalidades não mais usadas, não só ajudam bastante a reduzir o custo com servidor como fazem parte da rotina de manutenção do sistema
; 8; ; 0;
0 '; 0';
"Precisamos gastar cada vez mais com servidores" - #5 de 25
Bastter  
em 21/02/2020 23:27
eu entendi servidores FP hahahaha
; 15; ; 0;
0 '; 0';
"Precisamos gastar cada vez mais com servidores" - #6 de 25
JPM  
em 22/02/2020 00:46
O ministro Caco Antibes quase morreu com o título do tópico.
; 6; ; 0;
0 '; 0';
"Precisamos gastar cada vez mais com servidores" - #7 de 25
Romulo07  
em 22/02/2020 06:17
Custos, esse foi o motivo principal de mudar para Golang. Goroutines tem a capacidade de usar todos os cores do cpu. Além disso o sistema de concurrency usa um type chamado channel que torna as requisições simplesmente insignificantes,  lightweight thread. Na China é usado ao extremo pois os servidores recebem milhões de requisições, a população do país é gigantesca. Acho que o ORUTUF é esse, acredito que todas as tecnologias irão se adaptar, mas Google com sua tecnologia saiu na frente.
; 1; ; 0;
0 '; 0';
"Precisamos gastar cada vez mais com servidores" - #8 de 25
TCEC  
em 22/02/2020 07:43
Também achei que fosse tratar dos funcionários públicos, já que vc TB é "servidor". Estava até me perguntando sobre a área tira dúvidas kkk
; 4; ; 0;
0 '; 0';
"Precisamos gastar cada vez mais com servidores" - #9 de 25
carryon  
em 22/02/2020 08:06
Muito bom o texto, parabéns! Só complementando:

Cada requisição vai consumir um pouco de recurso da máquina. Cada servidor tem uma capacidade para cpu, memória e disco (no caso de disco, operações por segundo e espaço disponível). Estes recursos são finitos, então dependendo da aplicação, ao ir aumentando o número de requisições um deles vai se esgotar primeiro. Quando um recurso se esgota, o sistema sofre com lentidões e erros.

Daí para aumentar essa quantidade de recursos existem duas formas: escalabilidade vertical e escalabilidade horizontal.

Escalabilidade vertical é adicionar no servidor existente mais cpu, ram ou capacidade de disco. Tende a ser mais fácil, pois na aplicação não precisa fazer nada, mas é mais limitado em capacidade que pode atingir. Por exemplo, na imagem da digital ocean tem servidores com até 128 Gb de RAM. Se precisar de mais de 128 Gb de RAM não vai ter uma opção.

Escalabilidade horizontal é adicionar mais servidores respondendo requisições. Um pouco mais complicado, porque vai entrar complexidade de como balancear e coordenar as requisições em mais de uma máquina diferente. Só que aí já não tem aquele limite do 128 Gb de RAM do exemplo. Vamos dizer que o sistema como um todo precisa de 1 Tb de RAM para operar. Podemos colocar 10 servidores com 128 Gb de RAM.

Em sistemas tipo desses ecommerces grandes, vão ter diversos componentes e servidores separados. Servidores para a aplicação, banco de dados, servidores de cache, firewall, load balancers. Cada um deles pode esgotar a sua capacidade.
; 1; ; 0;
0 '; 0';
"Precisamos gastar cada vez mais com servidores" - #10 de 25
DanielFP  
em 22/02/2020 08:37
Ótimo texto! Seria interessante explicar para o pessoal a diferença entre servidores físicos e virtuais. Nos exemplos de vendas de servidores para web que deu, na verdade são máquinas virtuais,o que torna a escalabilidade muito mais prática.
; 1; ; 0;
0 '; 0';
"Precisamos gastar cada vez mais com servidores" - #11 de 25
Dan__  
em 22/02/2020 10:13
Prabéns pela explicação descomplicada @TiagoDV.
Pra apimentar um pouco o tópico: este modelo está umas duas gerações para trás na atual forma de desenvolver aplicações.

Ainda que seja possível escalar verticalmente como mencionado acima, há gargalos como rede e o próprio barramento interno do servidor.
Junte insto com load-imbalance (um servidor hospedando máquinas virtuais com serviços com padrões de carga conflitantes) é suficiente para derrubar SLAs e provocar lentidão do mesmo jeito. Mesmo quando o servidor não está a 100% de carga. Isto é um problema importante tanto que tem um largo campo de pesquisa em schedulers para co-alocar serviços complementares, o que choca com a disponibilidade (tolerancia à falhas). Não existe almoço grátis

Do outro lado a solução de distribuir a carga, resolve o problema mas torna o desenvolvimento mais complexo. No mundo perfeito à medida que você adiciona servidores você adiciona capacidade. Assim, se a carga aumentar bastante basta ligar mais máquinas que elas ficariam responsáveis por atender aos novos pedidos. Há vários problemas aqui.
Primeiro de provisionamento. Para dar conta de um pico de carga eventual havia a necessidade de ter disponivel a capacidade de processamento. Significando que na média boa  parte dos recursos não seriam utilizados até que numa black-friday a capacidade seria suficiente para lidar com a carga. 90% do tempo seria subutilizado mas nos 5 dias onde 40% dos négocios são feitos a capacidade seria suficiente para atender à demanda. Ninguém gosta de disperdício. A evolução natural seria escalar *elasticamente*. Assim a capacidade do sistema (por exemplo número de máquinas) aumentaria quando há mais carga e reduz quanto menor for a necessidade (com menos carga).  O Kubernetes, por exemplo, faz isto de forma automática.

O outro problema é conceitual mas tem impacto em como pensamos sobre o comportamento do sistema: consistência. Num exemplo simples se mais de uma máquina guarda um RODATNOC com o estoque da loja, para vender o item é preciso considerar um estoque único. Não se deve poder vender o mesmo item duas vezes. Isto requer coordenação isto é, as máquinas envolvidas no processo precisam se comunicar pra realizar as operações de forma que o resultado se apresente da mesma forma que se fosse uma única máquina superpoderosa  fazendo a mesma coisa. A solução passa por separar as operações que requer coordenação i.e. consistencia forte.
Felizmente a maior parte das operações são de leitura e não necessitam consistência forte. Outras operações podem usar formas mais relaxadas, por exemplo, separando o estoque em máquinas como quotas. Daí desenhar aplicações escaláveis é "oto patamá". kkkk

Logo este tipo de funcionalidade foi engarafada em sistemas que se encarregam de lidar com a complexidade de escalar elasticamente e já não faz sentido aos provedores cobrar por servidores. Entra em cena a arquitetura de micro-serviços. Assim os sistema agora são um mesh de diversos outros sistemas para realizar em conjunto um serviço. Um classico exemplo é o gráfico da interconexão dos microservicos do Netflix conhecido como death star:




Quando você abre a página do facebook, cerca de centenas de serviços são ativados para produzir a página para você. Tudo isto em paralelo com restrições rigidas de tempo de resposta.


Apesar de dar como exemplo grandes empresas, todas as ferramentas usadas nisto são opensource e ativamente usada por startups. Afinal numa primeira fase crescimento é mais importante que lucro. E para elas a infraestrutura não pode ser uma barreira ao crescimento.

A discussão é interassante, mas pra não ficar muito grande paro por aqui. Se interessar falo mais sobre estas ferramentas e modelo de desenvolvimento. ;-)
; 7; ; 0;
0 '; 0';
"Precisamos gastar cada vez mais com servidores" - #12 de 25
danesseAsVoadoras  
em 22/02/2020 15:29
Booooooa, Thiago!
Já favoritei pra ler com calma hj a noite.

Espero que também o pessoal que trabalha com isso possa postar suas contribuições. 
; 1; ; 0;
0 '; 0';
"Precisamos gastar cada vez mais com servidores" - #13 de 25
ThiagoDV  
em 22/02/2020 16:40
@andre_santos e pelo menos para referências, estudo, é um assunto difícil de achar material. Algo comparando as opções de mercado, como escalar um serviço (sem depender do auto scaling da AWS), esse tipo de situação. 

@gustavo aí já entra num nível que eu se tentasse explicar provavelmente falaria mesbla por falta de experiência prática mesmo. Aprendi muito com teu comentário rs espero um dia ter essa experiência toda. 

@Bastter o título do tópico ia ser só "Servidores", aí mudei pra este por achar que ia gerar ambiguidade com SP mas pelo visto talvez tenha piorado a ambiguidade

@Romulo07 Go parece ser uma linguagem bem promissora. O tempo vai dizer se Go e Flutter não são mais projetos que o Google decidiu matar repentinamente como alguns casos recentes. 

@carryon ótima contribuição. Obrigado. 

@Danuco eu ia explicar mas achei que já tinha falado demais e a mensagem já tinha sido passada da forma que eu imaginava. Vai que fica pra uma parte 2 rs

@Dan__ cara, pode complementar o quanto quiser rs aprendi muito. 
Só um adendo na questão dos micro-serviços, muita gente vende como bala de prata, que todo mundo devia usar micro-serviços, que é mais escalável, mais confiável, mas o Stack Overflow por exemplo, site que todo mundo que desenvolve algo tem noção do que é, recebe infinitas requests diárias e é um monolito feito em .NET. Então tem casos que micro-serviços são melhores, tem casos que não deve ser a melhor opção. 

@mvbs depois dá um feedback aí se ficou claro, se ainda resta dúvida. Já tivemos ótimas contribuições aqui e espero que tenhamos mais rs 
; 1; ; 0;
0 '; 0';
"Precisamos gastar cada vez mais com servidores" - #14 de 25
gustavo  
em 22/02/2020 17:08
@ThiagoDV
meu conhecimento é o básico necessário do desenvolvedor e tá bem longe do "suficiente", tanto que na última migração de servidor contratamos um especialista.

Boa parte foi aprendendo no sufoco, que é mais ou menos o q eu coloquei acima.

Mas esse tipo de conhecimento desenvolvedor nenhum pode fugir, tanto q eu pretendo fazer logo alguns cursos de cloud (google, azure, etc) e recomendo a todos pois já virou requisito saber o básico de algum cloud.

Pelas empresas que passei mesmo as com muita hierarquia e papéis definidos, em algumas situações os desenvolvedores tinham que "meter a mão" no servidor pra resolver ou até mesmo pra saber como otimizar as aplicações pra determinado ambiente.

E geralmente quem te contrata para um projeto (freela), contrata para vc entregar o sistema rodando, não faz ideia de q precisa de servidor, backup, segurança, etc.
Contrata um cara e não uma equipe
; 2; ; 0;
0 '; 0';
"Precisamos gastar cada vez mais com servidores" - #15 de 25
ThiagoDV  
em 22/02/2020 17:25
@gustavo pois é, me ligo dessas questões. 

E por isso cada vez mais eu acho Docker algo fantástico (ainda não sei nada de Kubernetes mas tenho vontade de aprender), pois facilita muitas coisas de infra inclusive o deploy, e gostei muito do Heroku (que inclusive entra nas ferramentas de Cloud), que com um git push a gente já faz o deploy de uma aplicação sem ficar se preocupando com muita coisa de infra.

Agora o quanto soluções como o Heroku são escaláveis eu não faço ideia. Só fiz deploy de API REST pra testes de vagas de empresa. Agora que tou metendo a mão na massa no meu primeiro projeto mais sério e já prevejo muitos percalços por aí  vou tentar ir de Heroku e ver no que dá.

Mas Cloud é importante demais ultimamente. Participei de um Hackathon da AWS semana passada e tentei usar os serviços deles e passei mal na hora  só consegui desenrolar o S3 que é pra upload de arquivos. 
; 1; ; 0;
0 '; 0';
"Precisamos gastar cada vez mais com servidores" - #16 de 25
gustavo  
em 22/02/2020 17:57
@ThiagoDV é isso ai mesmo, meter as caras nessa sopa de letrinhas e sair do outro lado
; 2; ; 0;
0 '; 0';
"Precisamos gastar cada vez mais com servidores" - #17 de 25
Dan__  
em 22/02/2020 20:25
Estranho, tentando madar uma mensagem mas dá sempre erro...
; 1; ; 0;
0 '; 0';
"Precisamos gastar cada vez mais com servidores" - #18 de 25
Dan__  
em 22/02/2020 20:28
@TiagoDV micro-serviços de fato não é bala de prata.  Eu também falei duas gerações mas só comentei da primeira ;-)

O stack-overflow tem tráfego majoritariamente de leitura e um modelo muito simples que demanda apenas causalidade para consistência. Isto garante por exemplo que a resposta a um post seja ordenada após a pergunta (ou mais tecnicamente que as atualizações de estado obedecem a uma ordem parcial causal).

O estado também pode ser facilmente particionado. Replicas do mesmo monolito podem armazenar um subconjunto dos posts. A única coisa em comum entre elas é a autenticação que eu aposto que é feito por outro subsistema.

Outro parâmetro é que as interações não tem restrição de tempo. Alguém posta hoje e a resposta pode vir só amanhã, ou semana seguinte. O sistema não perde valor com isto.
Isto é razoavelmente simples de escalar.

Nada que as Caches e CDNs convencionais não consigam bombar com facilidade. Para cada problema uma solução.  :-)

Um sistema de pagamentos é outra historia.

O Hype com microserviços vai além da escalabilidade, confiabiliade etc....
Tem a ver com eficiencia do desenvolvimento, controle de dependências, gestão de versões, reproducibilidade etc.
Se você já usou o docker sabe o que to falando (se não usou, e quiser, posso falar um pouco) É uma ferramenta essencial que uso todo dia. É impossivel pensar em desenvolver qq coisa sem isso agora.

Disto surgiu toda a área de devops que mudou drásticamente o profissional de gestão de infraestrutura e de redes dado luz a uma enormidade de ferramentas (Vagrant, docker, ansible, terraform, etcd, kubernetes, etc...). E possibilita coisas fantásticas como CI/CD.

Honesamente é uma forma elegante de desenvolver. Mantém tudo organizado especialmente com vários desenvolvedores na equipe e é fácil de detectar problemas e evoluir o sistema :-)
; 2; ; 0;
0 '; 0';
"Precisamos gastar cada vez mais com servidores" - #19 de 25
Dan__  
em 22/02/2020 20:40
Mais alguns comentários:

Golang dificilmente vai morrer. Virou linguagem padrão pra desenvolvimento de sistemas distribuidos. Algumas caracteristicas da linguagem favorecem enormemente isto.
Além disto tem uma codebase gigantesca e essencial já desenvolvida em golang. O docker e o kubernetes por exemplo.

Dart o tempo dirá. Mas o google tem apostado tudo no flutter. Parece muito promissor mas outros já tentaram matar o javascript e falharam...

Além destas, vale a pena conhecer o Elixir (cujo autor é um brasileiro) que é extremamente popular pois deriva do Erlang e permite desenvolver sistemas robustos.

Rust, da Mozilla tem atraido muita gente tb.
Estas linguagens novas tem ferramentas poderosas que permitem desenvolver sistemas com menos bugs e mais rápidos aproveitando ao máximo os novos recursos de hardware.
; 3; ; 0;
0 '; 0';
"Precisamos gastar cada vez mais com servidores" - #20 de 25
Removida  
em 23/02/2020 00:26
Nossa, agradeço mt pela aula. Aquelas explicações genéricas de "precisamos custear o site / servidores" que ficam mais caros etc fez muito mais sentido agora
; 1; ; 0;
0 '; 0';
"Precisamos gastar cada vez mais com servidores" - #21 de 25
ThiagoDV  
em 23/02/2020 11:32
@Dan__ eu acho Docker lindo demais. Tenho curiosidade de dar uma olhada em Kubernetes depois mas é tanta coisa pra ver que se eu só estudar não programo nada

Você é DevOps? Acho muito interessante a área de infra. Tenho vontade de aprender mais. 

@Pmtp e isso é só a ponta do iceberg como você pode ver nos comentários excelentes aqui do tópico 
; 1; ; 0;
0 '; 0';
"Precisamos gastar cada vez mais com servidores" - #22 de 25
Dan__  
em 23/02/2020 19:51
@ThiagoDV, não sou devops (esta não é minha função).
Mas já dei cursos de devops (além de segurança e sistemas).  Tive necessidade de aprender porque trabalho desenvolvendo sistemas de alta dispobiilidade, escaláveis e geo-replicados (que precisam correr em vários data-centers espalhados no mundo).
 
Controlar grupos de muitas máquinas é dia a dia. Centenas de máquinas de vez em quando.
Comecei com redes/segurança, depois redes em fio (roteamento), depois passei pra sistemas distribuidos/transacionais/tolerantes à falhas.
; 2; ; 0;
0 '; 0';
"Precisamos gastar cada vez mais com servidores" - #23 de 25
danesseAsVoadoras  
em 26/02/2020 13:14
@ThiagoDV, ontem a noite consegui ler com calma o tópico. Tinha viajado para o interior e me isolei no meio do mato, até conseguia acessar o site mas quando tentava acessar a área de tecnologia pra buscar esse tópico travava tudo... internet muito ruim.

Eu achei muito bacana! Gostei da forma didática que você abordou o tema.

Também vi que o pessoal que é fera na área compartilhou muita coisa também.

Agradeço muito pelo retorno rápido sobre a dúvida que postei.

Isso sim é geração de valor!

 

Vamos pra cima.
; 2; ; 0;
0 '; 0';
"Precisamos gastar cada vez mais com servidores" - #24 de 25
ThiagoDV  
em 26/02/2020 19:40
@mvbs fico feliz que tenha ficado claro e que a dúvida tenha sido esclarecida. Mas nem foi tão rápida assim a resposta rs é que a dúvida era de um assunto que eu não dominava muito e não queria fazer algo meia boca. Gosto de responder mais rápido do que o tempo que levei pra te responder. 

Mas ainda bem que deu pra entender. Qualquer nova dúvida só perguntar. 
; 2; ; 0;
0 '; 0';
"Precisamos gastar cada vez mais com servidores" - #25 de 25

15 usuários comentaram este tópico.
Clique para ir para o primeiro comentário do usuário.

Ações Pesquisa Videos Livros Análise de Carteira Desconto FAQs Orientação Esportiva Ofertas e Serviços Bastter System Boletim IR Podcasts Revista Tecnologia - Ajuda Eu Assinar Ações Pesquisa Videos Livros Análise de Carteira Desconto FAQs Ofertas e Serviços Orientação Esportiva Boletim BS Podcasts IR Tecnologia Ajuda eu Revista Assinar Assinar

BastterZap