As ofertas virtualizadas têm um desempenho significativamente pior (veja meus experimentos de 2019: httpsjan.rychter.com/enblog/cloud-server-cpu-performance e custam mais. A diferença é que você pode "escalar sob demanda", o que descobri não ser necessário, pelo menos no meu caso. E se eu precisar escalar, ainda posso fazer isso, só que conseguir novos servidores leva horas em vez de segundos. Bem, eu não preciso escalar em segundos
No meu caso, toda a minha fatura mensal para o ambiente de produção completo e um ambiente de preparação/espera duplicado é constante, simples, previsível, muito baixa em comparação com o que eu precisaria para pagar à AWS, e ainda tenho muito espaço para desempenho
Uma coisa que vale ressaltar é que trato os servidores físicos como virtuais: tudo é gerenciado pelo ansible e posso recriar tudo do zero. Na verdade, eu uso outro ambiente "devcloud"no Digital Ocean, e esse é girado usando terraform, antes de ser passado para o ansible que faz o resto da configuração
Eu suspeito que VendorOps e ferramentas complexas como kubernetes são favorecidos por comerciantes de complexidade que surgiram na última década. Parece ótimo no currículo e dá aos líderes de tecnologia uma falsa sensação de conquista
Enquanto isso, o Stackoverflow, que é indiscutivelmente mais importante do que a maioria das startups, está funcionando em máquinas dedicadas
1: httpsstackoverflow.blog/2016/02/17/stack-overflow-the-arc..
Parece que a tendência neste espaço é pular direto para a camada mais alta de abstração. Pular os fundamentos e apontar para ferramentas, bibliotecas e produtos $ buzzword
Você vê vislumbres disso em diferentes formas. Um deles são os tópicos de mídia social que perguntam coisas como Quanto de X eu preciso saber para aprender Y Onde X é uma tecnologia ou campo fundamental, possivelmente muito estável e Y é alguma ferramenta do dia ou um produto ou serviço direto
CORBA pertence lá. E talvez até o material da web semântica. Definitivamente XML!
XML é ótimo - se você não acredita, pode estar interessado nas dores de análise de JSON: httpseriot.ch/projects/parsing_json.html
E não me fale sobre YAML..
O custo incremental de estar em uma nuvem vale totalmente a pena para mim ter bancos de dados gerenciados, instantâneos automáticos, balanceadores de carga hospedados, armazenamento em bloco plug and play, etc.
Quero me preocupar se nosso produto é bom, não com falhas de hardware no meio da noite, girando um novo servidor e fazendo com que não funcione direito porque não havia incentivo para usar o gerenciamento de configuração com uma única caixa, tendo uma única tarefa descontrolada causar OOM ou disco cheio e quebrar tudo em vez de apenas tarefas VM, medo de reiniciar uma máquina que está inativa há 1000 dias, etc.
Para mim, o fascínio da nuvem não é uma moda passageira de escalabilidade FAANG quando não é necessária, mas correção automática do sistema operacional, balanceamento automático de carga, serviços NAT, logs centralizados e analisáveis, serviços de banco de dados que não preciso gerenciar, fora do atualizações contínuas de caixa para serviços, gerenciamento de chaves criptográficas e segredos e, é claro, armazenamento de objetos. (Estas são todas as coisas que usamos em nossa inicialização)
Eu diria que servidores dedicados podem ser muito viáveis/econômicos quando atingimos uma certa escala, e não o contrário. No momento, as despesas com nuvem valem a pena para minha startup
Se você estiver fazendo a configuração do seu ambiente como código, não importa se o seu destino é um servidor dedicado, uma VM ou alguma configuração específica da nuvem configurada por meio de uma API
Realmente não importa qual, o ponto é que você tem um que pode construir uma nova caixa ou trazer uma caixa com mau comportamento de volta a um bom estado simplesmente executando um comando
Claro, a pilha real de Go(o) que o impulsiona pode ser melhorada (e está realmente melhorando)
Dito isso, a dura verdade é que sua abordagem é a correta, quase todos os negócios (startups!) superestimam em vez de focar em fornecer valor, identificar o nicho real etc. (Sim, também há o lado da demanda, pois o As startups superestimadas pelo dinheiro do VC querem depender de terceiros que possam assumir a carga, escalar com eles, SLAs e outros enfeites devem ser anunciados.)
Kubernetes é fantástico! Sempre que vejo um negócio potencialmente concorrente começar a usar o Kubernetes, fico imediatamente aliviado, pois sei que não preciso mais me preocupar com eles. Eles estão prestes a desaparecer em uma pilha de problemas técnicos insolúveis, tentando corrigir problemas que não podem ser rastreados em uma pilha de tecnologia de complexidade inacreditável e contornando as limitações impostas por um sistema projetado para empresas com tráfego dois ou três de magnitude maior. Além disso, o CPV deles será muito maior do que o meu, o que significa que eles precisarão precificar seus produtos mais alto, a menos que estejam apenas queimando dinheiro de VC (nesse caso, eles são um flash na panela)
Coisas boas ao redor
Ansible é imperativo, pode trabalhar em direção a um estado estático, e é isso. Se ele tiver um problema, ele abre sua conexão SSH e chora toneladas de erros de python e desiste para sempre. Mesmo com seu inventário está longe de ser declarativo
k8s é um conjunto de loops de controle que tentam progredir em direção ao seu estado declarado. A falha não é um problema, ele tentará novamente. Ele verificará constantemente seu próprio estado, possui uma boa API para relatar isso e, graças a muitos conceitos reificados, é mais difícil ter conflitos estranhos entre os componentes implantados. (Considerando que a integração de vários playbooks com o Ansible não é trivial.)
httpsgithub.com/spantaleev/matrix-docker-ansible-deploy
E mesmo que o k8s apresente muitos legados, há manifestações mais enxutas das ideias centrais. (Ex. httpsgithub.com/aurae-runtime/aurae )
E agora você está sugerindo que as pessoas usem uma implementação não padrão mais simples?
Então é claro que você pode implementar uma solução de complexidade mínima ou pode usar algo "pronto para uso"k8s é complexo e parte dele é definitivamente desnecessário para sua situação, mas também é bastante geral, flexível, bem suportado, etc.
>você está sugerindo que as pessoas usem uma implementação não padrão mais simples?
O que sugeri é que, se k8s o projeto/software ficar grande demais para falhar, as pessoas podem mudar para uma alternativa. Felizmente, os conceitos e a API do k8s são de código aberto, portanto, podem ser implementados em outros projetos, e dei um exemplo para ilustrar que escolher o k8s não é um bloqueio de fornecedor semelhante ao Oracle
Eu sempre ouço sobre todas as coisas incríveis que você obtém praticamente de graça dos provedores de nuvem. Isso é realmente tão fácil de configurar e usar? Sempre que tentei configurar minha pilha LAMP em um serviço de nuvem, era um processo tão confuso e assustador que acabei desistindo. Eu estou querendo saber se eu só preciso empurrar um pouco mais e vou chegar ao Cloud Heaven
Ser capaz de dizer "Eu quero um MySQL em cluster aqui com esse tipo de especificação"é muito melhor (em termos de tempo) do que fazê-lo sozinho. As atualizações também estão bem agrupadas no sistema, então estou apenas dizendo "aplique a atualização mais recente"em vez de garantir manualmente que os failovers/reinicializações ocorram na ordem correta
Então você paga para simplificar as coisas, mas o ganho dessa simplificação só entra em ação com projetos maiores. Se você tiver algo em um único servidor que possa reiniciar enquanto seus usuários recebem uma página de erro, pode não valer a pena
A nuvem não é fácil, mas tentar obter refrigeração e eficiência de energia de uma pequena sala de servidores em qualquer lugar perto dos níveis de eficiência da maioria das grandes publicações de datacenter é quase impossível, assim como a conectividade de Internet de vários fornecedores
Com a nuvem, tudo isso desaparece, pois é gerenciado por qualquer operador de data center em que a nuvem esteja sendo executada, mas o que as pessoas esquecem é que isso também é verdade para serviços de colocation antiquados, que geralmente oferecem um melhor custo/valor do que a nuvem.
E embora seja definitivamente mais difícil gerenciar coisas como AWS ou Azure porque sangra um monte de abstrações que os provedores vpc de pequena escala escondem de você ou que você realmente não obtém com um único servidor doméstico, não é difícil na escala de ter que executar alguns de racks de servidores vmware com armazenamento baseado em SAN Com as coisas da nuvem, você tem mais configurações a fazer porque se trata de configurar servidores virtuais, etc. Em vez de levar o PC em uma caixa para o seu quarto, você deve "configurar"para disponibilizá-lo Os bancos de dados DO têm backups que você pode configurar ao seu gosto, armazene-os em DO Spaces (como S3). O gerenciamento de usuários do banco de dados é fácil. Há também servidores de cache para Redis Você pode adicionar um balanceador de carga e conectá-lo aos seus vários servidores web Acho que demorei cerca de 30 minutos para configurar 2 servidores da web, um servidor de banco de dados, servidor de cache, balanceador de carga, um servidor de armazenamento e conectá-los conforme necessário usando alguns formulários simples. realmente não pode bater isso Se você tiver mais informações ou opiniões, por favor, compartilhe Muitos artigos na internet sobre como proteger um servidor Linux, os que eu tentei levam um pouco mais de 30 minutos para seguir as etapas, muito mais se eu estiver tentando realmente aprender e entender o que cada coisa está fazendo, por que é importante, qual é a vulnerabilidade subjacente e como posso precisar personalizar algumas configurações para meu caso de uso específico Tenho certeza de que você pode encontrar exemplos de scripts de configuração online (configurar atualizações automáticas, firewall, aplicativos etc. deve ser uma questão de executar 'curl $ URL'e depois 'chmod +x $ ARQUIVO'e 'bash $ ARQUIVO'. Não precisei de gerenciamento de configuração (eu uso o serviço de backup do meu provedor, o que é importante, eu acho) Algo assim: httpsraw.githubusercontent.com/potts99/Linux-Post-Install.. (visto em httpswww.reddit.com/r/selfhosted/comments/f18xi2/ubuntu_d ) Obviamente, o mesmo pode ser dito para VMs de longa duração, e isso pode ser resolvido com uma equipe disciplinada, mas acho que geralmente é mais provável em um ambiente com uma única máquina dedicada de longa duração A Hetzner tem tudo isso, exceto bancos de dados gerenciados httpswww.hetzner.com/servidor gerenciado Os pacotes de webhosting também incluem 1..DBs ilimitados (MySQL e PostgreSQL) httpswww.hetzner.com/webhosting/ ele tem backup automático e failover? >Com o backup diário agendado ou o backup incluído no tipo de servidor, todos os dados são copiados diariamente e mantidos por no máximo 14 dias. A recuperação de backups (Restore) é possível através da interface de administração do konsoleH Mas tenho a impressão de que os bancos de dados em servidores gerenciados são destinados ao uso por aplicativos em execução nesse servidor, portanto, não há realmente um conceito de failover httpswww.hetzner.com/legal/ managed-server/ Uma única unidade em um único servidor com falha nunca deve causar uma interrupção na produção Muitos problemas de configuração podem ser rastreados para implantações independentes. Esse arquivo de fonte ou JRE realmente precisa ser instalado em todo o servidor ou você pode agrupá-lo em sua implantação Nossas implantações usam destinos locais e EC2. O script de implantação não é diferente, apenas o IP do host é Agora, direi se posso usar o S3 para algo que farei 100%. Não há uma alternativa local para ele com o mesmo conjunto de recursos O objetivo do DevOps é "Gado, não animais de estimação". Coloque um marcador em seu servidor uma vez por semana para encontrar seus pontos de falha Eu adoraria se você entrasse em nosso Discord/Slack e trouxesse alguns dos problemas que você está vendo, para que possamos pelo menos tornar a experiência melhor para outras pessoas que usam o Dokku. Sinta-se livre para me bater lá (meu nick é `savant`) Deixe-me começar e dizer que sou um desenvolvedor de aplicativos com apenas um conhecimento prático do Docker.Não sou muito habilidoso em infra e o aplicativo com o qual lutei tem parâmetros de implantação peculiares: é um aplicativo Python que, em tempo de compilação, analisa vários shows de rastreamentos de HTML estático para preencher um banco de dados Postgres que é estático após ser construído. Um aplicativo da Web Flask serve nesse banco de dados. A análise de HTML evolui rapidamente e, portanto, os dados de banco de dados preenchidos devem ser agrupados como parte da(s) imagem(ões) do aplicativo IIRC, lutei para estruturar Dockerfiles quando o banco de dados não era persistente, mas apenas outra parte transitória do aplicativo, mas parecia superável. O maior problema parecia ser como evitar a extração de dados raramente alterados do S3 para cada compilação quando, idealmente, seria armazenado em cache, especialmente de uma maneira que se comportasse de maneira saudável na DigitalOcean e em meu ambiente local. Presumo que o cache correto da camada de imagem do Docker resolveria o problema, mas rapidamente cheguei ao fim do meu conhecimento e paciência O DX de Dokku parece ótimo para pessoas que fazem coisas normais. :) 0. httpscoolify.io/ Além disso, quem não quer brincar com o brinquedo mais novo e legal com o dinheiro de outra pessoa? Definitivamente, há um argumento para mover (algumas) coisas para fora da nuvem mais tarde na jornada, quando a flexibilidade (ou lidar com fluxo/pivotagem) se torna menos um fator principal e a escala/custo começa a dominar Claro, você pode fazer algo funcionar na Hetzner, mas esteja preparado para responder a muito mais perguntas Concordou em seu último ponto da empresa pedindo isso, o que, novamente, é triste que esses "requisitos"de negócios ditem como arquitetar e hospedar seu software quando outra maneira pode ser muito melhor A recuperação de desastres é um problema muito real. É por isso que eu testo regularmente. Em um cenário de terra arrasada, posso colocar em funcionamento um sistema secundário (preparação) ou um sistema de nuvem terraformada em menos de uma hora. Para o meu negócio, isso é o suficiente
Passamos por um boom de crescimento e, como todos antes, isso significava que muitas pessoas inexperientes recebiam muito dinheiro e expectativas urgentes. É uma receita para o cultivo de carga e marketing explorador
Mas o crescimento está diminuindo e o dinheiro está ficando mais caro, então vamos desacelerar e começar a reaprender as velhas lições com novas e empolgantes variações. (Como aqui: gerenciamento de dimensionamento bare metal e com contêineres e orquestração)
E todo o ciclo se repetirá no próximo boom. Essa é a nossa indústria por enquanto
Um servidor dedicado sólido é 99% do tempo muito mais útil do que um VPS aleijado em hardware compartilhado, mas obviamente tem um custo maior se você não precisar de todos os recursos que eles fornecem.
Sim - mas os anseios de "fazer o que todos os garotos legais estão fazendo agora"são pelo menos tão fortes naqueles que normalmente seriam referidos como "gerentes"versus "funcionários"resultado A) gastos enormes com microsserviços/nuvem dão errado, bem, pelo menos você estava seguindo as práticas recomendadas, essas coisas acontecem, o que você pode fazer
resultado B) você optou por um servidor Hetzner e algo deu errado, bem, você é um e deveria ter optado por microsserviços, aproveite a procura de um novo emprego
Incentivando assim os gestores a optar por microsserviços/nuvem. Pode não ser a decisão certa para a empresa, mas é a decisão certa para o gerente, e é o gerente que toma a decisão
(Assim como ser um consultor que deseja uma extensão e escrever um software que funcione, como descobri da maneira mais difícil.)
Há uma desconexão entre os fundadores e todos os outros
Os fundadores acreditam que vão >10x a cada ano
A realidade é que eles têm 90% de probabilidade de falhar
90% do tempo - você está bem falhando em qualquer coisa
Alguns % dos 10% do tempo que você consegue, você ainda está bem sem a nuvem - pelo menos por vários anos de sucesso, muito tempo para mudar, se necessário
Eu só tenho uma configuração ansible, e ela pode funcionar tanto para servidores virtualizados quanto para físicos. Nenhuma diferença. A única diferença é que os servidores virtualizados precisam ser configurados primeiro com o terraform, e os físicos precisam ser solicitados primeiro e seus IPs inseridos em um arquivo de configuração (inventário)
Claro, também tenho o cuidado de evitar ficar dependente de muitos outros serviços em nuvem. Por exemplo, eu uso o VpnCloud (httpsgithub.com/dswd/vpncloud) para comunicação entre os servidores. Como benefício colateral, isso também me dá a flexibilidade de mudar para qualquer provedor de infraestrutura a qualquer momento
Meu ponto principal foi que, embora as ofertas virtualizadas tenham seus usos, há uma (enorme) lacuna entre um VPS de hobby de $ 10 / mês e uma empresa com negócios B2C em crescimento explosivo. A maioria dos novos negócios realmente se enquadra nessa lacuna: você não espera um crescimento exponencial de taco de hóquei em um SaaS B2B lucrativo. É aí que você deve questionar a escolha padrão usual de "usar AWS". Eu me preocupo com meu CPV e minhas margens, então vejo essa escolha com muito cuidado
Você não é uma empresa de software, basicamente você fabrica e vende rodas dentadas
As opiniões aqui seriam contratar uma grande equipe de engenheiros / TI para "comprar e manter servidores"(PaaS é ruim) e provavelmente "escrever um código você mesmo"(SaaS é ruim) ou o que quer que seja popular aqui (o último tópico aqui foi "Empurrando PHP sobre SFTP sem Git, e você saberá se precisar de mais"lol)
Mas acredito que as empresas devem fazer One Thing Well e evitar tentar competir (fazendo isso manualmente) por coisas fora de sua competência principal. Nesse caso, eu definitivamente acho que a Sprocket Masters não deve tentar gerenciar seu próprio hardware e deve confiar em um provedor para lidar com dimensionamento, segurança, tempo de atividade, conformidade e todos os pequenos detalhes. Também acho que o software deles deve ser padrão, com o mínimo possível de uso interno. Eles não são uma loja de software e devem escrever o mínimo de código possível
Realisticamente, os Widget Masters poderiam administrar esses sites com uma equipe bastante pequena, a menos que decidissem fazer tudo manualmente; nesse caso, provavelmente precisariam de uma equipe muito maior
No entanto, o que também vejo e o que acho que o postador anterior estava falando são negócios em que a tecnologia está no centro do negócio, e aí muitas vezes faz menos sentido e, em vez de economizar tempo, parece custar tempo. Há uma razão para existirem especialistas da AWS: não é trivial. Servidores "reais"também não são triviais, mas também não são necessariamente mais difíceis do que os serviços em nuvem
Mas essas agências também não querem ter funcionários para manter o hardware físico.
Mas a Sprocket Masters ainda precisa ter um consultor de nuvem caro simplesmente para responder a emergências
Se você vai ter alguém na equipe para lidar com os problemas de nuvem, você também pode alugar um servidor
Eu pessoalmente executei Servidores Dedicados para nossos negócios nos primeiros dias, mas à medida que expandimos e escalamos, ficou muito mais fácil ir com os provedores de nuvem para fornecer vários serviços rapidamente, mesmo que os custos subissem. Sem mencionar que é muito mais fácil dizer a um cliente em potencial que você usa "nuvem como AWS"do que "Ah, alugamos essas máquinas em um data center administrado por alguma empresa"(o que pode ser melhor, mas os clientes geralmente não entenderão isso) . Auditoria, Compliance e outros
Para muitos até muito menos do que isso. Eu executo um pequeno projeto paralelo [1] que se tornou viral algumas vezes (30.000 visualizações em 24 horas ou mais) e está sendo executado em um único servidor da Web de CPU de núcleo e um Postgres gerenciado da mesma forma em um único núcleo de CPU. Não chegou nem perto da utilização total
1: httpsaihelperbot.com/ Eu poderia mudar alguns deles para funções lambda? Ou mudar para ECS? Ou mudar para algum outro serviço de nuvem do dia? Talvez. Mas o tempo que gastei escrevendo este comentário já representa cerca de seis meses de economia para essa mudança. Se for mais difícil do que "aperte o botão, receba um serviço traduzido 100% confiável", é difícil justificar Parte disso também ocorre porque a nuvem fornece alguns outros serviços agora que permitem esse tipo de coisa. Não preciso executar um cluster Kafka para mensagens básicas, todos eles vêm com um barramento de mensagens. Eu uso isso. Eu uso as opções de banco de dados hospedado. Eu uso S3 ou equivalente, etc. Acho que o que sobrou quase não vale a pena tentar me prender a algum outro paradigma quando estou pagando um dígito de dólares por mês apenas para executar em uma instância do EC2 É absolutamente verdade que nem todos ou todos os projetos podem fazer isso. Não estou preso a isso como um objetivo final. Quando não funciona, eu imediatamente tomo a ação de dimensionamento apropriada. Não estou sugerindo que você vá reprojetar nada com base nisso. Só estou dizendo, não é uma opção a ser desprezada. Ele tem muita flexibilidade e o faturamento é bastante consistente (ou, em outras palavras, o fato de que, se de repente eu tiver 50x o tráfego, meu sistema começa a engasgar e engasgar visivelmente, em vez de simplesmente cobrar centenas de dólares mais é um recurso para mim em vez de um bug), e geralmente você não está se esforçando para se contorcer em algum paradigma que seja conveniente para algum serviço em nuvem, mas pode não ser conveniente para você Você já teve que gerenciar um desses ambientes? O problema é que, se você deseja obter escalabilidade básica de mais de uma pessoa e devops adequados, é necessário provisionar em excesso por um fator significativo (possivelmente anulando suas economias) Você inevitavelmente acabará com uma solução sob medida, o que significa que os novos funcionários terão mais dificuldade em dominar o sistema e as pessoas importantes que deixarem a empresa trarão consigo seu conhecimento íntimo de sua infraestrutura. Você está de volta aos animais de estimação em vez de gado. Alguns servidores são especiais, depois de um tempo a automação significa "muitos scripts shell de cola aqui e ali"e uma atualização do sistema operacional significa que metade da infra é KO por um tempo ou você não faz nenhuma atualização do sistema operacional E, felizmente, você precisa aumentar Você pode encontrar surpresas desagradáveis E nunca me fale sobre o lado da rede. A menos que você esteja alugando todo o seu rack e colocando seu próprio hardware de rede, você obtém o que recebe. O que poderáser muito pobre tanto em funcionalidades como em desempenhos Assumindo que não estejas a fazer nada extravagante Se você deseja 100,0000% de tempo de atividade, com certeza. Mas você não costuma. As empresas que desejam esse tipo de uptime normalmente têm equipes dedicadas a isso de qualquer maneira E o dimensionamento também funciona bem em bare-metal se você dimensionar verticalmente - você tem alguma ideia da quantidade de energia e taxa de transferência que pode obter de um único servidor? É preocupante continuar ouvindo sobre "escala"quando o locutor quer dizer "escala horizontal" Se seus requisitos estão "dimensionando", então o dimensionamento vertical o levará longe Se seus requisitos são "escalonamento horizontal sob demanda", então, com certeza, os provedores de nuvem ajudarão nisso. Mas, poucos lugares precisam desse tipo de dimensionamento Não estou dizendo que 100% de tempo de atividade em bare metal é barato, estou dizendo que 100% de tempo de atividade frequentemente não é necessário Porque a indústria está cheia de pessoas que estão atrás de tendências e palavras-chave e para as quais o mais importante é adicionar essas palavras-chave aos currículos O objetivo do IME para escalabilidade é extremamente errado para a maioria dos serviços/aplicativos/qualquer coisa. E geralmente você paga tanto overhead pelas soluções "escaláveis"que precisa escalar para compensar isso Eu realmente duvido disso.O único tema que você vê em quase todos os proponentes da AWS é uma grande quantidade de ilusão sobre o que garante que a AWS realmente oferece a vocêSim, claro.Ninguém é demitido por comprar da IBMBem, se as grandes empresas tivessem alguma competência na tomada de decisão, elas seriam imbatíveis e seria inútil trabalhar em qualquer outra coisa todos.Então, sim, isso é um bem públicoFonte: quase trinta anos de operaçõesAté agora não percebi que se eu gastar mais para a empresa que também recebo maisobter a confiabilidade equivalente com ferros é muito mais caro do que alugar "dois servidores dedicados"- agora você pode ficar bem com um servidor e uma solução de backup , e isso é justo. mas um sysad para criar tudo isso, mesmo com um contrato curto para a configuração inicial e sem manutenção, vai muito além da diferença de preço da nuvem, especialmente se houver um banco de dados no mix e você se importar com esses dadosHoje, a nuvem é semelhante - o tempo de lançamento no mercado é mais rápido, pois há menos partes móveis.Quando a economia afunda e o crescimento diminui, os contadores de feijão entram e fazem o que queremAcontece toda vezIsso só torna a AWS mais rica no nível de empresas e equipes de nuvemÉ trivial provisionar e cancelar o provisionamento de uma instância do EC2 automaticamente, em segundos, se sua implantação precisar aumentar ou diminuir.Isso é o que o torna fundamentalmente diferente de um servidor bare metal
Agora, não estou negando que ainda pode ser mais econômico quando comparado à AWS para provisionar alguns servidores dedicados a mais do que você precisa, mas quando você tem cargas de trabalho realmente imprevisíveis, não é fácil acompanhar
se você está ligando e desligando as VMs para atender à curva de demanda - algo está seriamente errado com sua arquitetura
Já lhe ocorreu, como é que o stackoverflow usa cerca de 8 servidores dedicados para atender o mundo inteiro e não precisa ativar e desligar as VMs para atender à demanda global dos clientes?
--
Ao planejar a infraestrutura de computação, é importante voltar ao básico e não cair na propaganda do fornecedor de nuvem
Você mesmo disse. Nem todos os aplicativos precisam atender o mundo inteiro, portanto a demanda será menor quando as pessoas forem dormir
Mesmo com aplicativos globais, existem regulamentos que exigem que você hospede aplicativos e dados em regiões específicas. Imagine um aplicativo usado por clientes na Europa, Austrália e Estados Unidos. Eles precisam ser atendidos a partir de centros de dados regionais, e um cluster ficará quase inativo quando o outro estiver em execução (devido aos fusos horários). Com servidores dedicados, você desperdiçaria 60-70% de seus recursos, enquanto usando algo como EC2/Fargate, você pode reduzir para quase 0 quando sua região está inativa
Existe um método para a loucura, aqui é chamado de "desenvolvimento orientado para a segurança no trabalho"Porque é uma ameaça aos seus empregos
Há todo um grupo de pessoas que têm as habilidades técnicas para se auto-hospedar, ou hospedar pequenas instâncias para sua família/amigos/associação/clube de caminhada. Essa pequena margem em que você pode gastar um pouco mais porque deseja torná-la adequada, mas não pode justificar pagar tanto e gastar tempo fazendo manutenção pesada. Um pequeno VPS, com um Nextcloud compartilhado ou um pequeno site, é tudo o que é necessário em muitos casos
Para isso até uso um pouco de Raspberry Pi 400 no meu quarto
httpsjoeldare.com/private-analtyics-and-my-raspberry-pi-4..
Eu mesmo hospedei minhas próprias coisas por quase uma década. Ninguém tentou fazer DDoS em minha configuração, porque eles tentariam? Que benefício eles possivelmente tirariam disso? Eu seria praticamente a única pessoa afetada e, uma vez que parassem, não demoraria muito para se recuperar.
Há pouco ou nenhum incentivo para DDoS em uma caixa pessoal, muito menos por um rando na Internet
Você está superestimando drasticamente as habilidades de um adolescente
Apenas pingar o IP repetidamente não vai fazer muito. Talvez um ataque DoS dependendo do que a rede de destino tem em termos de IPS, mas mesmo assim é mais provável que eles infectem seus computadores com vírus antes de terem a chance de realmente atacar você
Eu pessoalmente fui alvo de um deles por, de alguma forma, enganar um trapaceiro no GTA 5. Isso definitivamente acontece e não é divertido
Editar: parece que isso pode ser automático. Isso é algo interessante que eu deveria investigar um pouco. Provavelmente é apenas uma complexidade extra para o meu pequeno servidor, mas tenho alguns usos em mente.
Tecnicamente, meu homelab também está em um IP público estático - isso foi mais um exercício de "eu poderia fazer isso"do que "realmente necessário", mas ainda é legal e estou muito feliz
O único problema era que eu tinha que configurar o Wireguard para manter o túnel ativo, caso contrário, às vezes o VPS receberia o tráfego de entrada e se meu laboratório não entrasse em contato por um tempo (o que, por que?) o túnel estaria inativo, e a conexão proxy faria. Felizmente, essa é uma funcionalidade integrada
Portanto, parece que adicionar feeds RSS / Atom em um site de páginas jekyll ou GitHub é bastante simples
1. httpsgithub.com/jekyll/jekyll-feed
2. httpsdocs.github.com/en/pages/setting-up-a-github-pages-s..
3. httpspages.github.com/versions/
Atom 2c/4t, 4gb de ram, 1tb de drive, 100mbit
Alguns anos de tempo de atividade neste ponto
Se ininterrupto: alguma atualização pode ser necessária.
As atualizações de segurança do kernel são uma coisa
Achei o Atoms insuportavelmente lento, mesmo com o Linux. É claro que é o suficiente para servir sites e outros enfeites, mas é desconcertante quanta energia eles usam para não funcionar
Exatamente. Essas instâncias VPS abaixo de $ 10 são ótimas para pequenos projetos onde você não deseja entrar em contratos longos ou lidar com o gerenciamento de seus próprios servidores
Se você estiver administrando um negócio real em que as margens são mínimas e você tem todo o tempo livre do mundo para lidar com problemas de servidor se (quando) eles surgirem, esses servidores dedicados de ~ $ 50 podem ser interessantes para explorar
Mas se você estiver administrando um negócio real, mesmo uma fatura de US$ 10.000/mês da AWS é mais barata do que contratar outro desenvolvedor qualificado para ajudar a gerenciar seus servidores dedicados
Isso é o que geralmente se perde nas discussões sobre custos de nuvem em lugares como HN: Sim, a nuvem é cara, mas contratar até mesmo um único administrador de sistema/desenvolvedor para ajudá-lo a gerenciar a infraestrutura personalizada é incrivelmente caro e muito menos flexível. É por isso que gastar hipotéticos US$ 5.000/mês em uma solução hospedada na nuvem que poderia, em teoria, ser personalizada em um servidor de US$ 50/mês com investimento de tempo suficiente ainda pode ser um ótimo negócio. Engenheiros são caros e o tempo é limitado
Uhhh, com licença, mas quanto você está pagando para esse cara do DevOps? Esta parece ser uma perspectiva muito americana, mesmo na área do vale. Na Europa, contratar um cara seria mais barato
Os custos de emprego totalmente carregados são significativamente mais altos do que você leva para casa em seu contracheque. Na verdade, é pior na Europa. Dê uma olhada nestes gráficos: httpsaccace.com/the-true-cost-of-an-employee-in-europe/
Se você pagar a alguém 1.000 EUR no Reino Unido, isso custará à empresa um total de 1.245 EUR
Se você pagar a alguém 1.000 EUR na Romênia, isso custará à empresa 1.747 EUR no total
Portanto, um custo total de US $ 120.000 pode comprar apenas um salário de US $ 68.000 para um devops da UE.
Mas você não pode ter apenas uma pessoa devops. Você precisa de pelo menos 2 se quiser permitir que um deles faça uma pausa, saia ou saia de férias
Posso ligar para você em cerca de 3 horas
A AWS é muito econômica para outros serviços (S3,SES,SQS, etc), mas as máquinas virtuais não são um bom negócio. Você obtém menos memória RAM& CPU, com a sobrecarga de virtualização, e paga muito mais dinheiro
Especialmente para o Postgres, se você executar alguns testes com o pgbench, poderá realmente ver a penalidade que paga pela virtualização
Talvez a habilidade do administrador de sistemas de poder construir sua própria infraestrutura esteja se tornando uma arte perdida, caso contrário, não consigo explicar por que as pessoas adoram pagar 5x por menos desempenho
Hetzner é barato e confiável na Europa, se você estiver na América do Norte dê uma olhada na OVH. Especialmente sua alternativa econômica chamada SoYouStart. Você pode obter 4/8 4,5 GHz, 64 RAM e uma unidade NVME por US $ 65
(Não tenho nenhuma afiliação com a OVH, sou apenas um cliente com quase 100 servidores, e funcionou muito bem para mim)
Também observarei que sou velho hehe, e em um dos meus primeiros empregos tínhamos um data center de tamanho decente no local. Lidar com SANs, unidades de fita (os rotadores automáticos de fita na época eram servidores, etc. era um PITA enorme. Embalar fitas e enviá-las para outro escritório para redundância de local sempre foi divertido
O aplicativo específico que gerencio realmente sofre com baixo GHz e não possui todos os dados na memória. Eu executei os benchmarks no EC2, alguns relatórios que terminam em ~ 5 segundos podem levar mais de um minuto em uma instância EC2 comparável que custa cerca de 10 vezes mais. Este aplicativo realmente precisa da CPU bruta. e sim, temos uma equipe de engenharia bastante grande que otimizou todas as consultas, índices, etc.
No que diz respeito à replicação, backups, etc. Eu configurei tudo isso e, honestamente, não foi grande coisa. São alguns capítulos curtos no livro Postgres que explicam tudo de forma muito simples, como configurar, testar continuamente (e automaticamente), etc.
Eu concordo que SANs são um pesadelo. É por isso que envio todos os meus WALs (arquivos de backup PG) para o S3 (e eventualmente para o Glacier). Dessa forma, não preciso pensar em perder esses arquivos e é muito barato
Acho que há um equívoco de que esses tipos de configurações são muito complicados para um único engenheiro configurar, com a necessidade de manutenção interminável. Na realidade, você pode configurar tudo em menos de uma semana e só precisa de manutenção quando quiser atualizar o Postgres (algumas configurações podem ter mudado). Eu estimaria que leva cerca de 5 horas por ano de manutenção
A infraestrutura de autoatendimento parece tornar-se cada vez mais viável à medida que continuamos melhorando a entrega de última milha e expandindo o acesso à fibra. A nuvem se tornará autocanibalizante? Com certeza talvez
O que a nuvem oferece a você é a capacidade de colocar seus dados/carga de trabalho no centro sem ter que fazer acordos especiais com seu provedor local e com muito mais resiliência do que você provavelmente pagaria, a menos que estivesse pelo menos no contêiner múltiplo de 20 pés cheio da escala de servidores da necessidade de computação
httpswww.cloudflare.com/products/tunnel/
httpsgithub.com/cloudflare/cloudflared
httpsdevelopers.cloudflare.com/cloudflare-one/connections..
Edit: Se alguém estiver interessado em auto-hospedagem, é simples com cloudflared. Eu tenho um Google Pixelbook 2017 executando o Ubuntu em um firmware personalizado que atende a um site baseado em Flask. Estou na minha mesa carregando enquanto conectado a uma rede Wi-Fi para convidados. Ele recebe uma pontuação de 100/100 no Mobile PageSpeed e leva 0,8 segundos para carregar totalmente
Da DO eu obtenho todos os benefícios de uma empresa confiável, escalabilidade, backups automatizados etc etc. De jeito nenhum eu mudaria
A nuvem da Hetzner agora tem dois locais nos EUA. Ainda não há servidores dedicados nos EUA - esses seriam reais. Mesmo que suas próprias ofertas de nuvem atuais já sejam aproximadamente 30% do preço dos principais equivalentes em nuvem.
Como você, também executo meus serviços em um servidor físico alugado. Eu costumava usar o Versaweb, mas as máquinas deles são muito antigas. Anteriormente, não gostava da Hetzner porque tinha ouvido coisas ruins sobre eles interferirem no que você está executando
No entanto, mudei para eles em dezembro, quando minha instância Versaweb acabou de morrer, provavelmente SSD de velhice. Agora estou pagando 50% do que paguei ao Versaweb e posso executar 6 dessas instâncias do Postgres
Então, é de se perguntar se vale a pena pagar $ 700 ou $ 800 por um serviço gerenciado com uma interface de usuário de nuvem sofisticada, atualizações e backups automáticos, etc.
Para um show de 1 pessoa ou uma pequena startup, acho que não. Mais barato usar um serviço disponível e despejar backups para S3 ou algo mais barato
A empresa que eu costumava trabalhar para a empresa A pagava quatro vezes mais do que a empresa B cobrava exatamente pelo mesmo serviço, apenas porque a empresa A estava disposta a enviar faturas trimestrais de uma forma que combinava bem com nosso sistema de faturamento. Para as empresas, economizar algumas centenas de dólares aqui e ali muitas vezes não vale a pena o aborrecimento de introduzir qualquer atrito extra
Há um custo implícito aí. Se for apenas uma ou duas dessas coisas, basta pegar os serviços gerenciados
Se você começar a escalar, obtenha um funcionário do tipo administrador para economizar nisso
Caso contrário, eu teria que contratar/contratar alguém muito experiente, ou dedicar um mês inteiro ou mais do meu tempo (que não estava disponível), apenas para tenha 100% de certeza de que sempre poderemos restaurar backups PITR registrados rapidamente
Posso economizar muito nos custos da nuvem em outros lugares, mas o PostgreSQL gerenciado com credibilidade foi uma decisão bastante fácil (mesmo que o preço básico fosse maior do que o esperado)
Uma startup inicial que não pode perder uma hora de dados de produção provavelmente é muito frágil para sobreviver de qualquer maneira
É uma inicialização precoce - haverá interrupções maiores do que isso no serviço e qualquer cliente que fugir após uma perda de dados de produção de uma hora simplesmente não valorizou o produto o suficiente de qualquer maneira
(Na inicialização específica em que eu estava pensando, eu já tinha alguns despejos de banco de dados frequentes e automatizados para S3 com retenção imposta, mas não achei que fosse bom o suficiente para esse cenário específico. Mas não tendo certeza de que poderíamos recuperar com PITR/journaling adicionaria um novo ponto único de falha apostando no sucesso de um negócio que, de outra forma, poderia ter uma saída de mais de 9 dígitos em alguns/vários anos, apenas para economizar algumas centenas.)
Além disso, suponho que algumas das primeiras startups que têm necessidades menos exigentes, mas são negligentes sobre suas obrigações em relação aos dados dos clientes/usuários, ainda estão sendo negligentes com as práticas básicas mínimas
Talvez uma maneira intuitiva de apreciar: imagine uma notícia de negócios na HN, em algumas operações de inicialização, com os nomes dos fundadores anexados, e a história diz e acontece que eles não tinham bons backups Então um dos cofundadores, que talvez não tenham dormido muito porque sua empresa está quebrando ao seu redor, respondem "Os dados do cliente não são tão importantes em uma startup inicial; se fossem, estaríamos muito frágeis"(digitado antes que o cofundador pudesse jogar o laptop dessa pessoa do outro lado da sala para impedi-los de digitar). Não seria uma boa aparência
Vou abordar isso no final
>Imagine uma notícia de negócios na HN, em algumas operações de inicialização caindo na bola, com os nomes dos fundadores da startup anexados, e a história diz e acontece que eles não tinham bons backups
ITYM e acontece que eles não tiveram a última hora de backup
Posso imaginar tudo em seu cenário, até mesmo os bits não cortados, e tudo parece normal, a menos que você leia "Nossos clientes iniciantes, que nos usam há um mês, saíram imediatamente quando perdemos a última hora de seus dados"Eu realmente não consigo imaginar esse cenário
Agora, certo, existem algumas empresas onde o benefício de usá-lo é que não há nem uma hora de dados perdidos
IOW, os clientes o usam porque não perdem nenhum dado: colaboração de documentos online[1], por exemplo[2]. Se você tiver um colapso que perca uma hora dos últimos dados inseridos, com certeza, espere que todos os usuários atuais afetados fujam imediatamente
[1] Embora, pessoalmente, eu diminua o risco duplicando o documento atual no localstorage enquanto ele está sendo editado
[2] Talvez a bolsa de valores também precise do sistema para manter a última hora de dados? O que mais?
Acho que mesmo para equipes maiores pode fazer sentido gerenciar bancos de dados você mesmo, desde que você tenha competência para fazê-lo bem. Há tantas coisas que podem dar errado com os serviços gerenciados e eles não escondem a implementação subjacente da mesma forma que coisas como armazenamento em bloco ou armazenamento em objeto.
O desempenho máximo é certamente pior - mas não estou muito incomodado se algo demorar mais para ser executado de qualquer maneira. Você certamente está correto em ter tanta automação no provisionamento de um servidor, algo que não fiz com um servidor físico
Eu costumava ter um servidor raiz para meus projetos de estimação, mas, honestamente, isso não faz sentido. Não estou executando um tráfego intenso, computo SaaS intenso em minhas máquinas. É apenas um site estático e alguns projetos. Estou reduzido a custos mensais de 24, incluindo uma caixa de armazenamento de 1 TB para armazenar todos os meus dados
O principal problema em qualquer cenário envolvendo hardware real é que você precisa de uma equipe competente tanto em hardware quanto em sistemas Linux/UNIX. Muitos afirmam estar em seus currículos e depois não podem atuar uma vez no trabalho (pelo menos na minha experiência). Na minha opinião, um dos grandes motivos para a explosão do mundo cloud foi justamente a dificuldade e o custo financeiro de construir tais equipes. Além disso, há um atrito um tanto natural (e necessário) entre os desenvolvedores de aplicativos e o pessoal de sistemas. O pessoal dos sistemas deve sempre recuar e defender mais segurança, mais processos e menos implantações. A equipe de desenvolvimento deve estar sempre defendendo mais flexibilidade, mais lançamentos e menos processos. A boa gestão deve, então, encontrar o caminho do meio entre os dois. Infelizmente, gerentes incompetentes geralmente decidem se livrar do pessoal de sistemas e mover as coisas para a terra da AWS
Por fim, gostaria apenas de observar que a arquitetura de nuvem é ruim para o planeta, pois requer superprovisionamento por provedores de nuvem e requer mais poder de computador em geral devido às muitas camadas de abstração. Embora qualquer projeto seja responsável por pouco desse desperdício, toda a nuvem global como um agregado é muito desperdiçada. Isso me incomoda e, obviamente, é um fator provável como um viés emocional em minhas opiniões (grandes quantidades de sal para todos os itens acima)
Pode-se argumentar que você pode desenvolver um meio de alugar servidores físicos antes da receita, então, quando fizer sentido, você pode usar a depreciação padrão -ou- Seção 179 em compras definitivas e/ou Locações da Seção 179
Por exemplo, você pode implantar um grupo incrivelmente capaz de, digamos, quatro máquinas físicas 1U de $ 100.000 absolutamente superprovisionadas em diferentes instalações de colo para redundância. Existem todos os tipos de truques aqui para balanceamento de carga e failover com o serviço de nuvem XYZ, DNS, anycast, o que você quiser. Você pode ir com várias instalações colo que operam datacenters em todo o mundo, enviar o hardware do fornecedor para eles e, em seguida, provisioná-los com Ansible ou qualquer outra coisa sem nunca ver a instalação ou tocar no hardware
Portanto, agora você tem hardware físico redundante que rodará em círculos em torno da maioria dos provedores de nuvem (especialmente para I/O), custos fixos como tudo o que você pode largura de banda (que não tem a marcação de 800% dos serviços de nuvem, etc) - sem mais espera para a inevitável conta de nuvem de $ 50.000 ou tentando rastrear (em pânico) o que fez com que você excedesse seu orçamento de nuvem configurado em um dia em vez de um mês. Ah, btw, você não está se prendendo a APIs proprietárias idiotas para provisionar e até mesmo utilizar serviços que não sejam máquinas virtuais oferecidas por $BIGCLOUD
Se você estiver fazendo qualquer ML, poderá treinar em seu próprio hardware ou (ou na nuvem ocasional) e executar inferência 24 horas por dia, 7 dias por semana, com coisas como a NVIDIA A10. O aluguel contínuo da nuvem para instâncias de GPU é inacreditavelmente caro e o ROI na compra do hardware geralmente fica na faixa de alguns meses (ou muito à frente quase imediatamente com a Seção 179). Como exemplo, recentemente fiz um benchmark com a Nvidia A10 para um modelo que estamos atendendo e ela pode fazer mais de 700 solicitações/s de inferência em FP32 com menos de 10 ms de latência. Com um único A10 por chassi em quatro instâncias saudáveis, isso é 2800 req/s (e provavelmente poderia ser ajustado ainda mais)
Então, se você ficar MUITO grande, pode começar a comprar armários e muito mais. Em termos de falhas de hardware, conforme mencionado, tudo o que posso dizer é PS dual RAID-ed out, etc hardware é (na minha experiência) extremamente confiável. os fornecedores incluirão SLAs incríveis para substituição. Você avisa sobre a falha, eles mandam um técnico< oito horas diretamente para as instalações do colo e substitua o disco, PS, etc pela luz intermitente
Minha experiência é que um (bom) recurso de FTE pode facilmente gerenciar isso até a escala de vários gabinetes. Para o seu ponto, o problema atual é que muitas dessas pessoas foram arrebatadas pelos grandes provedores de nuvem e substituídas (no mercado) por recursos que podem navegar no ridículo limítrofe que está usando dezenas (se não mais) produtos/serviços de $ GRANDE NUVEM
Também descobri que essa configuração é MUITO mais confiável do que a maioria dos $BIGCLOUD. Chega de se perguntar o que está acontecendo com uma interrupção de $ BIGCLOUD que eles nem reconhecem (e sobre a qual você não tem absolutamente nenhum controle). Vindo de um histórico em telecomunicações e saúde, é completamente louco para mim como o tempo de atividade piorou muito com os provedores de nuvem. Normalmente, você pode apenas dizer aos clientes "oh, a Internet está tendo problemas hoje", porque eles provavelmente verão manchetes sobre isso, mas para muitos aplicativos isso é totalmente inaceitável - e devemos esperar melhor
[0] - httpswww.section179.org/section_179_deduction/
[1] = httpswww.section179.org/section_179_leases/
Se eu quiser criar um novo projeto ou experimentar hospedar algo novo, leva alguns minutos e eu tenho os scripts. As implantações são rápidas, a manutenção é baixa e eu tenho muito mais pelo meu dinheiro
Para quem estiver interessado, este é o esboço do que estou usando:
* Ansible para gerenciar tudo
* Um pouco de terraform para algumas entradas de DNS que posso substituir um dia
* restic para backups, novamente controlado por ansible
* tailscale for vpn (eu tenho alguns pi's rodando em casa, nada demais, mas o tailscale torna isso fácil e seguro)
* docker-compose para praticamente todo o resto
O aplicativo principal é o Clojure, então eu executo uma JVM nativa. O banco de dados está totalmente distribuído, RethinkDB, agora trabalhando na mudança para o FoundationDB
O importante é não gerenciar nada manualmente, por exemplo. trate os servidores físicos como qualquer outro servidor em nuvem. Não importa se é físico ou virtualizado
Já vi muitas pessoas menos experientes pagarem demais por hetzner e similares quando um $ 5-10 vps teria funcionado
Sim, você está suportando seu próprio hardware nesse ponto. Não, não é uma grande dor de cabeça
O maior custo adicional para isso é alugar mais endereços IPv4, que a Hetzner cobra generosamente agora que há tão poucos disponíveis
O que quer que você crie, começará com 0 usuários e uma máquina real inteira é um exagero para essa carga 0 que você obterá. Você atualiza seu VPS em um par de máquinas reais, depois em um pequeno cluster alugado e depois em um datacenter (se alguém não reduzir esse). Todos eles têm contas previsíveis e desempenho superior por seu preço
Qualquer coisa que você possua em um colo também será mais por mês. Quando eu tinha conexões onde podia pagar por um IP estático, isso geralmente custava US$ 5/mês
Agora estou alugando um servidor bastante simples, mas custa US$ 30/mês. Muito mais tudo que eu preciso, mas é bom. E eles não abandonaram o suporte para meu sistema operacional enquanto aumentavam os preços para melhorar o suporte ou algo assim. (Embora eu tivesse algum hardware inicialmente instável que precisava ser trocado)
como você apontou, o bare metal é o caminho a percorrer. é o oposto da nuvem - um pouco mais de trabalho no início, mas muito menos de despesas no final
Mais informações httpseuropa.eu/youreurope/business/taxation/vat/cross-bor..
Configurar e gerenciar o Postgres é uma dor de cabeça. Seria bom ter uma maneira mais simples de fazer tudo certo
1. Força a configuração a ser reproduzível, pois as VMs ficarão inativas
2. Você pode obter grandes descontos na AWS que reduzem a dor
3. As outras coisas às quais você tem acesso nas VMs são mais baratas/rápidas, uma vez que suas coisas já estão na nuvem
4. É mais fácil ter uma configuração de sistema documentada (por exemplo, documentos da AWS) do que treinar pessoas/documentar as coisas especiais que você tem internamente. Especialmente útil na contratação de novas pessoas
5. Você não precisa de espaço ou energia redundante/internet/etc no local. Apenas o suficiente para permitir que as pessoas executem seus laptops
Eu usei um VPS antes disso, mas parei e mudei para um físico porque era um negócio melhor e não esbarrávamos nos limites de CPU
O monitoramento de disco não é muito difícil. Para discos rígidos, execute smartctl uma vez por hora, alerta quando os setores realocados ou pendentes crescem rapidamente ou atingem 100. Para SSDs, cruze os dedos; na minha experiência com alguns milhares, eles tendem a funcionar muito bem até desaparecerem do ônibus, para nunca mais serem vistos. Tenha um plano de recuperação de dados que não envolva o armazenamento dos dados nos mesmos dispositivos de modelo com erros de firmware correlacionados de energia em horas muito semelhantes são reais
Afinal, a Hetzner tem uma API para solicitar servidores dedicados e uma API para instalar um sistema operacional (ou para reiniciar para resgatar e exibir qualquer imagem que você desejar)
Acho que se eu estivesse investigando opções comerciais, teria o "tronco"resolvido no escritório com uma solução de provedor comercial, IP estático, bom hardware de TI talvez, mas pelo que sei neste exato momento, se um cliente precisasse de hospedagem, eu d sempre ir direto para alugar um vps
Eu era mais um desenvolvedor júnior na época, então talvez eu fosse um an, mas não sinto falta disso. Em teoria, concordo com o que você está dizendo, mas implantar um Dockerfile em algo como o Google Cloud Run é muito mais fácil. Sim, estou pagando mais do que estaria gerenciando meu próprio VPS, mas acho que isso é mais do que compensado pelas horas de desenvolvimento economizadas
- o hardware físico apresenta problemas, por ex. falha do ventilador ->minha VM é migrada ao vivo para um host diferente, não percebo ou me importo
- hardware físico explode ->minha VM reinicia em um host diferente, posso notar, mas não me importo
O planejamento de desastres é muito mais fácil com VMs (mesmo com animais de estimação, não gado)
Para um iniciante, os mais baratos fazem o trabalho
Tenho certeza de que, à medida que a computação em nuvem evolui, essas ofertas se tornam mais comuns
Há outro aspecto da computação em nuvem. As empresas de médio a grande porte contam a computação em nuvem como porcentagens de um dígito em seus cálculos de custo. Isso significa que as decisões tomadas pelos gerentes e equipes, muitas vezes, buscam confiabilidade e escalabilidade (para serem colocadas em suas apresentações) ao invés de "minha configuração é cara ou barata"Meu empregador adotou a nuvem como uma jogada comercial/financeira, não religiosa. Muitas vezes, colocamos novas compilações na nuvem e migramos para um data center, se apropriado, posteriormente
Os aplicativos no local custam cerca de 40% menos. Aplicativos que são mais econômicos na nuvem permanecem lá
Acho que AWS/GCP/Azure não são ofertas com custo muito competitivo na Europa. O que não estou vendo é evidência disso para os EUA
para a mesma especificação, com certeza. Acho que os virtuais fazem sentido em ambas as extremidades - ou a escalabilidade dinâmica para N grande é importante ou você só precisa de uma pequena fração de uma caixa física. Pagar 45/mês por algo que funciona em 5/mês também não é sensato e oferece mais flexibilidade para não agrupar coisas apenas para usar seu servidor
Mantenha backups em qualquer caso. De preferência em outro provedor ou pelo menos em um local físico diferente. E, claro, teste-os
E se você estiver gerenciando um bom regime de backup e monitorando seus dados/aplicativos de qualquer maneira, o monitoramento de drives é uma dificuldade extra significativa?
--
[1] na verdade, se você automatizar o processo de restauração para outro local, o que eu faço para alguns dos meus bits, basta clicar nesse botão e atualizar o DNS quando concluído e talvez alocar um pouco mais de RAM + núcleos (meu teste os espelhos são menores que as VMs ao vivo, pois não precisam atender a padrões de uso reais)
Exatamente o que faço por mim e pelos meus clientes. Economiza toneladas de dinheiro
Mesmo que eu queira atualizar, basta puxar a versão mais recente para o modelo docker-compose e executar novamente o playbook ansible. Obviamente, se a atualização exigir mais, que assim seja, mas não é diferente de qualquer outro trabalho de configuração.
Provavelmente, a única coisa que _preciso_ fazer manualmente é testar meus backups. Mas eu tenho um script para cada projeto que faz isso, então eu apenas SSH, executo o one-liner, verifico o resultado e pronto. Eu faço isso mais ou menos uma vez por mês, mas também recebo e-mails se um backup falhar
Portanto, não pode ser hora nenhuma. Normalmente, leva de 1 a 2 horas por mês se eu estiver recebendo atualizações semi-regularmente. Mas isso aumentará com mais coisas que você hospedar e gerenciar
Em outras palavras, a única diferença é de onde vem o arquivo de inventário ansible. Ou é uma lista estática de IPs ou vem de terraform
Se você deseja RAM ECC, parece ser 60/mês e também avança para uma CPU de 8 núcleos mais poderosa
Independentemente disso, se estamos falando de um "ambiente de produção completo e um ambiente de teste/espera duplicado"(para citar a pessoa a quem você respondeu), então 60/mês * (2 ou 3) ainda é muito barato em comparação com qualquer AWS de inicialização conta que eu vi
Os casos de uso variam, mas tendo a concordar que AWS/GCP/Azure não é a resposta para todos os problemas
Para alguém que pode encaixar seu aplicativo em um VPS de $ 4, isso obviamente será mais barato do que qualquer coisa de metal puro, mas a nuvem aumenta muito caro em muitos casos. Bare metal também não é a resposta para todos os problemas, mas muitas pessoas na indústria parecem não apreciar quando pode ser a resposta certa.
SERVIDORES PRIVADOS VIRTUAL#120
