[GTER] Cloud que aceite vmware
Flavio Rescia Dias
flavioresciadias at gmail.com
Mon Jan 23 08:56:30 -02 2017
Israel,
Tudo o que você disse, e agradeço por compartilhar suas experiências
conosco, resumem o que eu disse: "depende".
Apenas uma coisa sobre suas considerações (o Lima também falou disso),
quando falamos de "desligar o que não precisamos" em EC2, não nos
referimos, apenas, a dar shutdown em determinados horário, o que queremos
dizer é "crie as instâncias (ou outros serviços) quando precisar", com isso
o custo efetivo do que está desligado/não existe é sim zero. Esse é um
paradigma de quem começa a mexer com AWS, pois é diferente do antigo modelo
que os sysadmin estão acostumados a trabalhar. É claro que isso não é
possível com qualquer aplicação e que a persistência dos dados precisa ser
pensada.
On Jan 21, 2017 6:49 PM, "Israel Ramos" <israel.melo.ramos at gmail.com> wrote:
Vamos aos números dos que fica mais fácil de entender meu ponto de vista:
O projeto que citei acima:
1. Tinha cargas variáveis? SIM. Existiam processos que rodavam em
horários específicos e consumiam muito CPU, Memória e IO. O tempo de
duração desses processos era determinado pela performance da máquina de
cada processo, número de cores e memória.
2. Existia consumo de tráfego de dados externo por esses processos? SIM.
Haviam processos de crawling e chamadas para APIs externas para coleta de
dados de redes sociais.
3. Havia necessidade por grande volume de armazenamento? SIM. Na época
havia cerca de 3 TB armazenados no total e subindo, fora backup.
4. Havia necessidade por performance de I/O. SIM. Tínhamos usávamos SSD
para alguns processos e HDD pra outros.
5. Quantas VMs no total? 4 Windows Server 2012 e 8 Ubuntu Server todas
com diferentes configurações de recursos.
6. Havia reserva de recursos não utilizados? SIM. Havia folga para
provisionar mais máquinas caso necessário tanto para uso em produção como
para testes e outros motivos.
7. A performance de hardware era satisfatória para a execução plena do
negócio e todos os processos. SIM. Com folga.
8. Custo mensal disso tudo rodando no dedicado com ESXi na OVH? Cerca de
€250.
9. Custo mensal de uma estrutura com menos máquinas na Amazon AWS?
Variava entre €450 e €600.
10. A performance na AWS era satisfatória? NÃO. Se
quiséssemos melhora-la teríamos que contratar instancias maiores para
algumas máquinas e subir novas instancias. O que aumentaria drasticamente
custo total.
Ficou mais claro agora?
On Sat, 21 Jan 2017 at 00:12 Israel Ramos <israel.melo.ramos at gmail.com>
wrote:
> Flávio,
>
> A maioria dos projetos que trabalho são projetos de redução de custos.
> Utilizando para isso técnicas que vão desde a troca de tecnologias
> proprietárias por Open Source, passando por reformulação de arquiteturas
> tanto de software quanto de hardware/rede, passando também por automação
de
> processos ou coisas, até chegar a contratação, troca ou eliminação de
> fornecedores/intermediários de tecnologia. Basicamente os clientes com
quem
> trabalho chegam em mim e dizem: "Preciso reduzir os custos do meu negócio.
> Qual é a solução?".
>
> Sempre que o cliente faz essa pergunta (Qual é a solução?), a primeira
> resposta que vem à mente é aquela palavra mágica, velha conhecida de
> muitos, "DEPENDE". E pelo visto concordamos nesse ponto.
>
> Eu poderia responder sua mensagem com um simples "depende". Apesar de ser
> a resposta mais sincera e correta na maioria das situações, acho chato ter
> que ouvi-la ou dize-la, principalmente quando temos um problema para ser
> resolvido, assim como o autor da thread demonstrou ter. Então eu vou
tentar
> comentar sua mensagem da maneira mais construtiva possível.
>
> Primeiramente, só pra reforçar, eu acredito sim que existam casos que AWS
> e afins são melhor solução. Gosto dessas soluções e as considero serviços
> fantásticos. Existe muita engenharia brilhante por trás dessas
plataformas.
> É muito prazeroso trabalhar com essas soluções. Mas para que a utilização
> desse tipo de plataforma realmente traga efetividade e custo benefício é
> necessário fazer a lição de casa e refletir sobre algumas coisas.
>
> Quando falamos em AWS estamos falando em um conjunto enorme serviços
> diferentes montados sob uma estrutura virtualizada composta por N camadas.
> Cada serviço isolado é construído para um determinado propósito. O ponto
em
> comum entre todos esses serviços é que foram abstraídos em uma interface
de
> operação que permite o provisionamento e gerenciamento facilitado por
parte
> do cliente. Trata-se de IaaS - Infrastructure as a Service. Em outras
> palavras é como um Self Service de infraestrutura.
>
> Quanto você contrata 1 serviço na AWS, na verdade está contratando pelo
> menos 2 coisas diferentes. O primeiro é a capacidade computacional e
> armazenamento. O segundo é justamente a plataforma de abstração do
> provisionamento que tenta tornar um pouco mais simples e rápido a
operação.
> E apesar de parecer uma coisa só, acredite você está pagando por esses
dois
> serviços. E adivinha? É assim que AWS ganha dinheiro. Simplesmente
> tornando, na maioria das vezes, mais fácil/simples a vida de quem precisa
> de provisionamento rápido e, em alguns casos mais complexos,
"elasticidade".
>
> Parece um mar de rosas não é mesmo? Concordo. Mas existem fatores
> importantíssimos a serem considerados, são eles:
>
> 1. Todos os recursos na AWS são cobrados separadamente (instancia,
> armazenamento, recursos e funcionalidades de rede, backup, IP, load
> balance, etc, etc).
> 2. Os recursos são oferecidos com perfis de performance diferentes.
> Geralmente os mais baratos são compartilhados e com limites bem
estreitos.
> 3. Se engana quem acha que instancia parada não custe dinheiro.
> 4. Elasticidade é algo que todo entusiasta de AWS utiliza como
> principal argumento. Porém, quantos de nós realmente utilizam de forma
> correta e eficiente os recursos de elasticidade da plataforma? Aumentar
> numero de CPU e memória de uma instancia é possível fazer em qualquer
> plataforma de virtualização e os recursos de Elasticidade na AWS vão
muito
> além disso. Grande parte nem tem conhecimento ou tempo suficientes para
> montar arquiteturas de fato elásticas. É necessário ter tempo, braço,
> dinheiro e expertise para planejar e implementar sistemas voltados e
que
> funcionem para esse propósito (sistemas distribuídos). E para esses
poucos
> que tem esses recursos e decidem construir isso em cima da plataforma
AWS
> acabam ficando reféns dos próprios serviços existentes lá. De modo que
se
> precisar migrar haverá muita dor de cabeça. Ou seja, clientes
vitalícios,
> rsrs.
> 5. Usar AWS pra hospedar um monte de instancias pequenas e isoladas
> (sem interoperabilidade) ou, o contrário, uma única instancia enorme
com
> tudo dentro é burrice na maioria dos casos. Pois os serviços que trazem
> maior beneficio na AWS não são o aluguel instancias. Para aluguel de
> instancia isolada existem outros fornecedores bem mais baratos como por
> exemplo DigitalOcean ou Linode que, apesar de não oferecerem a grande
> quantidade de recursos que AWS oferece, também possuem provisionamento
> rápido de coisas simples.
>
> Eu poderia listar aqui mais uns 20 fatores a serem considerados, mas não
> vou me apegar a detalhes. A conclusão que quero expor é que, quando você
> opta por usar AWS precisa ter clareza sobre suas as reais necessidades e
> quais recursos da AWS serão indispensáveis para para seu projeto.
>
> Na maioria dos casos que abordo acabam sendo necessidades de arquiteturas
> simples. Geralmente um conjunto de algumas VMs rodando sistemas
> específicos, funcionalidades de rede básicas, mas que demandam bom poder
de
> processamento dedicado e armazenamento. Na ponta do lápis se botar lado a
> lado você vê que consegue montar estruturas muito mais poderosas pagando
> muito menos e ainda possuir reserva de recursos de sobra pra suportar o
> crescimento da empresa por um bom período ou até mesmo para suportar
alguma
> demanda sazonal. Tudo isso usando a infraestrutura segura e resiliente do
> datacenter.
>
> Um ponto negativo de trabalhar com dedicado está ligado ao fato de que se
> alguma falha de hardware ocorrer na sua instancia haverá um tempo de
> downtime até que o pessoal do dc substitua. Coisa que se evita contratando
> outro hardware e colocando como redundância ou trabalhando em HA (feature
> que a plataforma de virtualização já te fornece).
> Outro ponto negativo a ser considerado é que você terá muito mais trabalho
> e complexidade para montar seu ambiente. Mas uma vez montado e configurado
> a manutenção se assemelha muito ao da AWS. A maior parte das tarefas de
> operação são no escopo de aplicações, serviços, dados e monitoramento,
> coisa que você precisa fazer pra tocar os negócios independente de rodar
em
> dedicado ou AWS.
>
> Grande abraço.
>
> On Fri, 20 Jan 2017 at 16:14 Flavio Rescia Dias <
> flavioresciadias at gmail.com> wrote:
>
> Israel,
>
> Discordando um pouco do que você disse, acredito que em alguns casos o
> serviço da Bare Metal, como o contratado com os servidores Dedicados da
> OVH, são mais adequado. Porém não acho que o uso de AWS só se aplique a
> "coisinhas pequenas" com com orçamento infinito, há diversos casos de
> aplicações onde o uso de AWS sai mais baixo mesmo se compararmos "hardware
> por hardware" e sem falar dos custos implícitos, seguem alguns deles:
>
> - *Uso de muito variável:* Com OVH por exemplo, você mesmo disse que
> multiplica por 5 sua capacidade computacional, porém se você tem um
> ambiente que é 6x maior em alguns períodos do dia, mês, ou ano, sua
> conta
> fecharia melhor com AWS/Azure/Google Cloud pois com bare metal você
> precisaria ter 100% do necessário e ainda subtrair contingência, e
> margem
> para o que não for previsto, e não estamos falando de ambientes
> pequenos;
> - *Alto Processamento:* Você precisaria compra servidores físicos muito
> grande, enquanto com EC2 o custo "a grosso modo" é o mesmo se você
> tiver 1
> instância com 1vCPU por 2 horas ou 2 com 1vCPU por 2 horas. Além disse
é
> possível o uso de instâncias Spot o diminui muito o custo ;
> - *Curto Tempo de Deploy:* Quando você trabalha em ambientes que
> precisam subir estruturas novas em questão de minutos, não conheço um
> fornecedor que faça mais rápido que a OVH, mas isso depende do estoque
> deles e pode levar dias.
>
> Eu entendi o que você quis dizer e não acho AWS barato, só acho que
existem
> outros cenário que AWS/Azure/Google Cloud cai bem.
>
> Flávio Rescia Dias
>
> Em 20 de janeiro de 2017 10:38, Israel Ramos <israel.melo.ramos at gmail.com>
> escreveu:
>
> > Christiano,
> >
> > Montei um projeto pra uma empresa Irlandesa.
> > Contratei um dedicado na OVH (www.ovh.co.uk).
> > Usei VMware ESXi.
> > Usei um datacenter deles localizado no Norte da França.
> > O atendimento dos caras é um pouco ruim, mas o produto é bom.
> >
> > Eu migrei a infra inteira deles que estava em instancias EC2 da AWS e
> > reformulei em cima do ESXi. A capacidade computacional multiplicou por 5
> e
> > o custo reduziu pela metade.
> > AWS na minha opinião sempre custou muito caro. Só vale a pena para
> > coisinhas pequenas ou quando o dinheiro não é problema.
> >
> > No caso foi para uma empresa que estava na Irlanda então a latência não
> foi
> > problema para hospedar na França. Agora se a empresa/usuários/trafego
for
> > proveniente do Brasil talvez não valha a pena (depende muito do tipo de
> > serviço que você vai querer hospedar). Nesse caso tentaria algo em DCs
> aqui
> > do Brasil mesmo.
> >
> > Se precisar de ajuda, estamos ai.
> >
> > Grande abraço.
> >
> >
> > On Fri, 20 Jan 2017 at 10:05 Luzemário Dantas <luzemario at luzehost.com.br
> >
> > wrote:
> >
> > > Sim, a SoftLayer aceita.
> > >
> > > Fornecem licenças VMWARE Server atá nos pacotes Cloud (como opcional,
> > > pago à parte), assim você tem "virtualização dentro da virtualização".
> > >
> > > Luzemário
> > >
> > > Em 19-01-2017 15:41, Douglas Fischer escreveu:
> > > > Talvez tua pergunta seria:
> > > > Clouds que aceitem Nested Virtualization...
> > > >
> > >
> > > --
> > > gter list https://eng.registro.br/mailman/listinfo/gter
> > --
> > gter list https://eng.registro.br/mailman/listinfo/gter
> >
> --
> gter list https://eng.registro.br/mailman/listinfo/gter
>
>
--
gter list https://eng.registro.br/mailman/listinfo/gter
More information about the gter
mailing list