Para desenvolvedores, os contêineres podem parecer um truque de mágica: eles são portáteis, eficientes e facilitam a criação de novos aplicativos. Embora os contêineres sejam ótimos para aplicativos simples, é necessário ter suporte adicional para desenvolvê-los em aplicativos e serviços maiores. Quando os contêineres começaram a ser usados há alguns anos, as organizações de TI tiveram muita dificuldade para gerenciá-los. Implantar contêineres na infraestrutura alocada era uma tarefa relativamente manual, com pouco suporte para o escalonamento automático dessa infraestrutura de modo rápido e eficiente.
Em 2014, completamos 10 anos executando o Borg, o gerenciador de contêineres interno, e achamos que disponibilizar uma versão dele para a comunidade de código-aberto poderia ser muito útil. Quatro anos depois, o Kubernetes se tornou a plataforma dominante de orquestração de contêineres. De acordo com o IDC1, 43% das empresas já usam os serviços de contêineres públicos. Prova disso é o nosso próprio produto, o Google Kubernetes Engine (GKE). Mais de 80% dos nossos maiores clientes já usam o GKE para executar cargas de trabalho em produção, e mais de 40% dos clusters do GKE são executados em cargas de trabalho com estado.
Adotar o Kubernetes oferece alguns benefícios: os recursos são usados de modo mais eficiente e a disponibilidade aumenta. Os desenvolvedores podem implantar novos aplicativos com mais frequência e aumentar a velocidade da criação de novos softwares. O Kubernetes também introduziu uma biblioteca de config declarativa extensível que oferece um modelo de operação consistente para todos os serviços, inclusive de terceiros. De modo mais imediato, a combinação do Kubernetes com contêineres permitiu que desenvolvedores adotassem uma arquitetura de microsserviços, que são unidades discretas de software dentro de serviços de uso único que podem ser incorporadas a aplicativos grandes e distribuídos que são executados em ambientes de nuvem híbrida e no local.
A camada de gerenciamento que faltava
Por experiência própria na execução de uma infraestrutura global, sabemos que embora a orquestração de contêineres seja uma função de TI essencial, ela não é o suficiente. Principalmente se você estiver executando um aplicativo distribuído de qualquer tamanho, que talvez decomponha um único aplicativo monolítico em centenas ou até mesmo milhares de componentes individuais. Você eventualmente precisará gerenciar a coleção de microsserviços e garantir políticas consistentes em todos eles. Mais importante ainda, essas políticas precisam ser dissociadas dos serviços individuais para que possam ser mais uniformes e atualizadas independentemente dos serviços.
Anos atrás, percebemos que para executar os serviços do Google com confiança, precisávamos de um sistema comum de monitoramento, geração de registros, autorização e cobrança. Dessa forma, as equipes individuais não precisariam resolver esses problemas por conta própria e com métodos diferentes a cada vez. Nossa solução foi usar o Stubby, um mecanismo de chamada de procedimento remoto, junto com uma funcionalidade de plano/controle por meio de um proxy secundário. Com essa combinação, temos os benefícios de uma rede de serviços: telemetria automatizada, autenticação e criptografia de serviço mútuo, balanceamento de carga do cliente, rede avançada e integração independente de linguagem dos sistemas de back-end. O plano de sidecar + plano/controle foi projetado especificamente para permitir o atendimento às necessidades de serviços internos e externos, bem como APIs públicas (que previamente precisavam de mecanismos diferentes) com uma única plataforma.
Nossa plataforma de serviços internos oferece uniformidade em todos os serviços. Já nossos engenheiros de segurança de sites (SREs) possuem painéis padrão de cada serviço sem precisar integrar manualmente as ferramentas de monitoramento. De modo semelhante, os serviços são automaticamente integrados aos nossos mecanismos de autenticação e política (por exemplo, para limitação de taxa e cota). Agora, os desenvolvedores não precisam começar do zero a cada novo serviço criado, e os SREs possuem um método padrão para operá-los.
Atender à chamada com o Istio
À medida que as equipes do Kubernetes implantarem mais microsserviços, acreditamos que elas precisarão de recursos similares. Para atender a essa necessidade, ano passado criamos uma parceria com a Lyft e a IBM no Istio, uma rede de serviços de código-aberto para aplicativos distribuídos híbridos e modernos. O Istio oferece visibilidade na forma de telemetria para monitorar e registrar serviços, além de segurança, ao atribuir uma identidade forte para cada serviço com base no papel e permitir a criptografia por padrão. Com essa funcionalidade essencial, o Istio também pode ser a base para serviços de nível mais alto. Por exemplo, ele pode ajudar a aplicar políticas de segurança de rede ou controlar lançamentos de software por meio de implantações canário.
O Istio também garante a dissociação adequada entre desenvolvimento e operações, permitindo que equipes de operações mudem o comportamento do sistema sem alterar de fato o código-fonte. Um exemplo é a política de nova tentativa. Imagine um sistema em que um microsserviço-chave começa a exibir uma latência estranhamente alta. Se os serviços dependentes desse microsserviço tiverem uma política de nova tentativa agressiva, eles podem sobrelotar o sistema de demora e, assim, piorar o problema. O Istio permite que a equipe de operações mude essa política de nova tentativa, recuando os sistemas dependentes, sem alterar o código-fonte e sem implantá-lo outra vez. Nossas equipes também podem mudar as políticas de “circuit-breaking”, redirecionamento de tráfego, execução de implantações canário e mais.
Essa dissociação da lógica de desenvolvimento e operações do Istio oferece duas coisas: ela permite que desenvolvedores foquem a escrita da lógica comercial, e não da infraestrutura (tornando-os mais produtivos) e que equipes de operações tenham as ferramentas necessárias para executar aplicativos e serviços de modo mais confiável.
A promessa do Istio já está repercutindo com os usuários do Kubernetes, incluindo Descartes Labs, eBay e AutoTrader RU. O Descartes Labs, por exemplo, usa o aprendizado de máquina no serviço de inteligência preditiva com APIs em execução nos clusters do GKE. O Kubernetes ofereceu a eles a possibilidade de escalonamento sob demanda, mas como seu aplicativo tem muitos microsserviços e dependências, a detecção de problemas de desempenho foi difícil. Quando um serviço ficava sobrecarregado, a verificação de registros para encontrar o problema poderia levar horas de trabalho. Implantar o Istio ofereceu clareza. Com o Istio há mais de um ano, eles podem ver a origem do tráfego de qualquer serviço e, assim, podem resolver problemas de modo muito mais rápido.
“O Istio era a peça que faltava no ecossistema do Kubernetes. O Kubernetes nos permitiu distribuir um aplicativo, mas o Istio nos permitiu entendê-lo”, diz Tim Kelton, cofundador do Descartes Labs. Agora que conseguem observar melhor o app, eles também começaram a adotar alguns dos recursos avançados de rede do Istio.
O futuro é agora
Usar o Istio ficará ainda mais fácil para usuários do Google Cloud com o Istio no GKE. Disponibilizado em Beta no próximo mês e com dezenas de clientes com acesso antecipado já o executando na produção, o Istio no GKE oferece uma camada de rede de serviço nos clusters existentes do GKE e reúne telemetria sobre os contêineres executados neles. Essa telemetria é enviada para o Stackdriver ou Prometheus para que seja monitorada a integridade dos serviços executados nos contêineres do mesmo modo que os SREs do Google fazem, ou seja, pelo monitoramento dos chamados Sinais de ouro (tráfego, taxas de erro e latências). Além disso, é possível auditar as dependências entre serviços ou analisar o desempenho com o rastreamento. Talvez o melhor de tudo seja poder também aumentar a segurança pela ativação do mTLS, que criptografa todos os dados em trânsito entre os serviços. É possível configurar tudo isso em movimento, basta selecionar a caixa “Ativar Istio” no console de gerenciamento do GKE.
Em geral, o Istio no GKE é só uma das formas que integramos o Istio ao portfólio de computação. Nos próximos meses, fique de olho para ver como integraremos o Istio a uma variedade de produtos, como parte do Cloud Services Platform. Por exemplo, neste verão, anunciaremos nossos planos para o GKE On-Prem, uma versão compatível com binário do GKE que pode ser executada no seu data center privado. Para ter visibilidade dos seus aplicativos sem servidor, use o Istio para isso também. Assim como o Kubernetes, queremos que você consiga executar o Istio do jeito que quiser, seja por conta própria ou como um serviço gerenciado autônomo.
Foi exatamente por essas razões que o Keybank, uma grande instituição financeira dos EUA, escolheu colaborar conosco. “O Google criou o Kubernetes e o Istio, então não havia dúvida que eles eram nossa escolha em nuvem para levar os aplicativos em contêineres para nossos data centers. Em poucas palavras, o Cloud Services Platform nos ofereceu a segurança, a portabilidade e a produtividade que nossos desenvolvedores queriam”, diz Keith Silvestri, diretor de tecnologia da Keybank.
Não somos os únicos a acreditar no Istio. Alguns dos grandes nomes da indústria estão contribuindo com o Istio. Empresas como IBM, Red Hat e VMware estão trazendo seu conhecimento e sua experiência. Como o Istio é um programa de código aberto, você tem a liberdade de adicionar a funcionalidade que quiser e integrá-la ao seu ambiente de modo muito mais rápido.
Aqui no Google, os SREs falam muito sobre evitar os “desastres do sucesso”, ou seja, um serviço que supera suas expectativas e, assim, sua capacidade de usá-lo. Independentemente de você usar nuvem nativa ou querer modernizar seu ambiente de TI, desenvolver seus aplicativos no Kubernetes e em contêineres o levará longe. No entanto, também é preciso refletir sobre como você gerenciará um ambiente que extrapola suas expectativas. O Istio pode guiá-lo pelo resto do caminho. Assim, você pode planejar o bom e velho “sucesso”.
1. PaaSView para desenvolvedores: A experiência de desenvolvimento moderna (IDC nº US44223218, agosto de 2018)
2 comentários :
PINGIN CEPAT KAYA ? Bingung mulai dari mana ? Baru..!! Game judi online 2019 wargapoker terpercaya. Dapatkan bonus-bonus untuk pemain baru, Ada begitu banyak jenis taruhan judi online dengan uang asli yang bisa anda mainkan di afapoker kapan saja dan dimana saja, cukup menggunakan satu user id saja. Anda dipastikan memainkan permainan judi online yang murni dominobet dimana Anda bermain 100% player vs player tanpa ada campur tangan bot link alternatif domino88 2019. Tidak perlu lagi bersusah payah mencari uang, Anda bebas menikmati waktu Anda. Situs link alternatif pokerace 2019 deposit murah yang menyediakan banyak permainan dengan pelayanan berkualitas. Jadi silahkan daftar dan segera mainkan permainan. Dijamin mudah dan cepat. Anda akan diberi pelayanan yang ramah dan cepat saat proses pendaftaran. Didukung dengan sistem terbaru dan tim profesional serta kemudahan bertransaksi. Kami menjamin kerahasiaan data member.
Bagi Anda pecinta permainan poker, Telah hadir permainan lapak303 terpercaya sangat mengutamakan Fairplay dan Kenyamanan Pemainnya link alternatif miyabipoker 2019 , dimana terdapat berbagai macam jenis permainan yang seru dan tentunya sangat menguntungkan. Tunggu apa lagi segera daftar dan dapatkan keuntunganya Di pokerlounge99. Dijamin Anda akan diberi pelayanan yang ramah dan cepat saat proses pendaftaran. Didukung dengan sistem terbaru dan tim yang profesional serta kemudahan bertransaksi Di pokerrepublik Anda tidak akan kecewa. Kami menjamin kerahasiaan data member. Jangan hanya di baca saja segera kunjungi kudapoker. Ajak juga teman Anda untuk bisa merasakan sensasi luar biasa saat bermain. Hanya dengan modal minim Anda sudah punya user id dan Anda bisa menjadi Milioner dadakan. Segera daftar dan mainkan jangan sia-siakan kesempatan ini, Sayang bila Anda lewatkan.
Postar um comentário