Guia do Iniciante para certificados SSL
Comentário Se você está disposto a começar do zero, desistir de alta disponibilidade, a capacidade de executar vários sistemas operacionais em um único servidor e todas as outras compensações, em seguida, Docker realmente não pode ser derrotado. Você está indo para empinar mais cargas de trabalho em uma determinada peça de hardware com Docker do que com um hypervisor, e ponto final.
Do ponto de vista de um provedor de nuvem - ou uma empresa grande o suficiente para funcionar como um - que é perfeitamente normal. Muitas das cargas de trabalho que correm não precisa ter um monte de guloseimas à base de hypervisor apreciador de qualquer maneira. Eles usam o agrupamento em aplicação ou aplicações que foram recodificados para a computação em nuvem pública.
Você não está vMotioning torno AWS, e dado que tomou VMware até cerca de meados de 2015, para obter uma versão de produção de tolerância a falhas lock-passo com mais de um vCPU para fora da porta, não se espera que em um não -VMware provedor de nuvem pública qualquer momento em breve. (Você também pode apostar VMware vai cobrar um centavo bonita para ele.)
É na tecnologia
Hypervisors são maravilhas da infra-estrutura avançada com ferramentas, técnicas e capacidades que recipientes como Docker pode nunca ser capaz de igualar. Como, exatamente, você mover uma carga de trabalho em contentor entre servidores com dramaticamente diferentes versões do kernel ou hardware diferente, sem a adição de uma camada hypervisor tipo de abstrações?
Como recipientes será ampliado ao longo do tempo como a geração existente de servidores de viver lado a lado com o próximo e cargas de trabalho se a transição? Há um monte de perguntas sem resposta, e será anos antes de nós tem certeza de como recipientes vai caber no quebra-cabeça global de tecnologia.
O outro lado é que Docker está em uma série de maneiras mais responsivos às necessidades dos clientes do que a maioria dos hypervisors lá fora. Não são apenas os desenvolvedores do núcleo ainda apaixonados por "seu bebê", mas a comunidade que surgiu ao redor faz fronteira com evangelicamente religiosa. Não há fim de energia para todas as coisas Docker, e aqueles com a energia estão entre as mentes mais brilhantes que já produzidos.
Docker é fácil de usar, embora não por causa de ferramentas de gestão, APIs, documentação ou marketing liso. Docker é fácil de usar, pois os tipos de cargas de trabalho que você deseja executar no Docker vir como uma implantação de-push-button simples a partir de um "app-store" como interface.
Alguns desses "pacotes de aplicativos" são suportados oficialmente. A maioria é dirigida a comunidade. Mas eles são fáceis de encontrar, mais fácil de usar e fácil de reembalar em um modelo e ir de sua testbed única para uma nuvem de milhares de casos.
Fornecedores de hypervisor pode ser razoavelmente visto como sendo obcecado com o fornecimento de infra-estrutura mais flexível e resiliente possível. Para contraste, Docker é a evolução de uma obsessão com não querer gerir ou manter infra-estrutura, mas em vez de continuar com o negócio de realmente usar essa infra-estrutura para fazer algo útil.
Containers acabará por ser usado em conjunto com hypervisors tradicionais e serviços em nuvem mesmo públicas, formando um novo (ish) oferta de serviços básicos para as massas e que nos permite fazer algo que temos feito há algum tempo que pouco melhor.
E contra ou
Não se engane, no entanto, como a nuvem pública, antes deles, os recipientes são um, e não um "ou" tecnologia "e". Hypervisors fosse um "ou" tecnologia. Sempre fui hypervisors, eles maciçamente deslocados computadores bare-metal e rendido então ameaçado, se não extinto. Os contentores não são - Eu não repetir enfaticamente - que perturbadora.
Docker pode ser pego por uma titan tecnologia. Dado o interesse da VMware na empresa, ele pode muito bem encontrar uma casa dentro VMware. Da mesma forma, os recipientes pode vir a ser (ou, na minha experiência, com bastante frequência são) implantado dentro hypervisors.
Isso permite que os administradores usam o hypervisor embaixo para alcançar os tipos de infra-estrutura subjacente magia em que hypervisors se destacaram, ao mesmo tempo colocando algumas ou todas as cargas de trabalho que exigem um ambiente semelhante em uma única VM como um meio de aumentar a eficiência. Um compromisso, se você quiser.
Containers pode acabar implantado em alguns servidores de metal para certas classes de cargas de trabalho, enquanto outros vivem em hypervisors para as próximas décadas. Neste momento, não há nenhuma maneira de saber exatamente como ele vai jogar fora. *
Pessoalmente, eu espero que isso será diferente para cada organização. Containers nos oferecem a possibilidade de fazer escolhas sobre o risco versus eficiência. Hypervisors nos ajudar a lidar com o risco: o risco de cursinhos tantas cargas de trabalho em um único sistema, o risco de uma falha de sistema, ou de precisar de culpar totalmente as capacidades tolerantes.
Hypervisors nos ajudar a lidar com as realidades de ambientes heterogêneos e o fato de que nem tudo é uma carga de trabalho baseado na web, ou pronto para ser recodificados para "escala".
30-year old software ainda corre em muitas das organizações do mundo de hoje, e não há absolutamente nenhuma razão para esperar que o mesmo não será verdade daqui a 30 anos. Hypervisors nos dará a capacidade de lidar com isso de uma maneira que os recipientes nunca será. ®
* Se a história serve de guia VMware, provavelmente, tem uma operação skunkworks trabalhando na construção de um concorrente Docker diretamente no hypervisor agora. VMware não fazer "parceria" nestas áreas para particularmente muito antes de qualquer compra de uma empresa relevante ou rola a sua própria versão. Essas brigas podem obter particularmente desagradável .
Da Microsoft rápida aceitação de Docker tenha deturpado a bola de cristal um pouco, e fez a pressão sobre VMware ainda mais intensa.
Nenhum comentário:
Postar um comentário