Nos últimos anos, a evolução da tecnologia e a demanda por aplicações web e mobile escaláveis e conectadas entre si têm colocado novos desafios diante das empresas e desenvolvedores. Nesse contexto, a adoção de uma arquitetura de microservices tem se tornado cada vez mais popular, permitindo uma maior flexibilidade, modularidade e facilidade de escalabilidade. No entanto, com o aumento do número de serviços que compõem uma aplicação, surgem novos desafios, como a gestão e o controle desses serviços de maneira eficiente.

Neste cenário entra o API Gateway, um componente fundamental para garantir o sucesso da sua arquitetura. O API Gateway atua como um ponto de entrada único para todos os serviços em uma aplicação distribuída, oferecendo uma série de benefícios e funcionalidades que simplificam e aprimoram a gestão e o controle dos serviços.

O artigo visa introduzir conceitos importantes sobre um API Gateway, de forma simples e falarei sobre o Red Hat 3Scale API Management que é uma ferramenta que tenho atuado em vários clientes.

O que é um API Gateway?

Um API Gateway é como um "porteiro" digital que controla o acesso a informações e funcionalidades de um software. Imagine que você está entrando em um prédio com várias salas, cada uma com um propósito específico. O API Gateway seria o ponto de entrada principal, onde você precisa se identificar e solicitar acesso às salas que deseja visitar.

Os softwares são frequentemente divididos em várias partes, chamadas de "serviços". Cada serviço tem suas próprias funções e informações. O API Gateway serve como um intermediário entre os usuários (ou apps) e esses serviços.

O API Gateway também pode fornecer outras funcionalidades, como autenticação (verificar se você tem permissão para acessar determinado serviço), autorização (decidir quais partes do serviço você pode usar) e segurança (proteger os dados que estão sendo transmitidos).

O que é o Red Hat 3Scale API Management?

O Red Hat 3Scale é uma plataforma de gerenciamento de APIs mantido pela Red Hat.

É um produto que oferece recursos essenciais para o gerenciamento de APIs em uma arquitetura de software, fornecendo um gateway seguro e escalável para exposição e controle de serviços.

Funcionalidades do 3Scale

Seguem as principais funcionalidades do 3scale

1. Gerenciamento de acesso: Permite controlar quem pode acessar suas APIs e como eles podem usá-las, através de autenticação e autorização.

2. Controle de limite de uso: Permite impor limites de uso nas suas APIs, como o número máximo de solicitações por minuto, para evitar abusos e garantir o desempenho adequado do serviço.

3. Monitoramento e análise: Fornece métricas e análises detalhadas sobre o uso das APIs, permitindo que você acompanhe e entenda como suas APIs estão sendo utilizadas, identifique padrões de uso e tome decisões informadas sobre melhorias e otimizações.

4. Portal do desenvolvedor: Oferece um portal dedicado para desenvolvedores acessarem informações sobre suas APIs, incluindo documentação, exemplos de código, guias de integração e outras informações relevantes.

5. Gerenciamento de versões: Permite gerenciar diferentes versões das suas APIs, facilitando a transição entre versões antigas e novas, sem interromper o funcionamento dos aplicativos que já as utilizam.

6. Gateway de API: O 3Scale atua como um gateway de API, facilitando a roteamento de solicitações entre os apps e os serviços correspondentes, garantindo a segurança e o controle adequados.

7. Personalização e extensibilidade: Permite personalizar a aparência e o comportamento do portal do desenvolvedor, adaptando-o à identidade visual da sua empresa. Além disso, é possível estender as funcionalidades do 3Scale através de integrações e plugins.

8. Gerenciamento de cobrança (billing): Caso seja necessário, o 3Scale também oferece recursos para facilitar o gerenciamento e a cobrança de acesso às suas APIs, permitindo a monetização dos serviços.

Diagrama representativo com o 3Scale

Seguem algumas ideias de como você pode representar o 3Scale na sua arquitetura.

1. Diagrama de Componentes: A arquitetura do 3scale pode ser ilustrada através de um diagrama de componentes. No núcleo, estaria o 3scale API Management, que se comunica com vários apps através de um Gateway de API (Red Hat Fuse (Camel) ou Apicast). Os apps poderiam variar desde aplicativos web, mobile até outros serviços internos. Além disso, o 3scale se integraria com outras plataformas de gerenciamento, como sistemas de autenticação e sistemas de banco de dados.

2. Diagrama de Fluxo de Tráfego: Outro tipo de diagrama que poderia ser útil seria um que descrevesse o fluxo de tráfego. Este diagrama começaria com o pedido de um cliente, passaria pelo Gateway de API, que por sua vez se comunicaria com o 3scale para a autenticação do pedido. Uma vez autenticado, o pedido seria passado para o backend relevante. As respostas seguiriam o caminho inverso, retornando ao cliente através do gateway.

Conceitos importantes do 3Scale

Backends

Backends são as APIs ou serviços existentes que estão sendo expostos e gerenciados pelo 3Scale. Os backends representam as fontes de dados e funcionalidades que você deseja expor e fornecer acesso controlado por meio da API gerenciada pelo 3Scale.

Ao configurar um Backend no 3Scale, você está integrando e conectando a API ou serviço subjacente à plataforma. Isso permite que você defina políticas, controles de acesso e outras configurações para gerenciar a exposição dessa API aos aplicativos e usuários.

Alguns pontos importantes sobre Backends no 3Scale são:

• Configuração e integração: Ao adicionar um Backend no 3Scale, você precisa fornecer informações sobre a localização da API, como URL, endpoint, cabeçalhos de autenticação e outros detalhes relevantes. Isso permite que o 3Scale se conecte ao Backend e gerencie o acesso a ele.

• Definição de métodos: No 3Scale, você pode definir os métodos disponíveis na API Backend. Isso significa identificar as operações ou funcionalidades específicas que podem ser acessadas por meio da API exposta pelo 3Scale.

• Mapeamento de endpoints: É necessário mapear os endpoints da API Backend para os endpoints correspondentes na API exposta pelo 3Scale. Isso permite que as solicitações dos aplicativos sejam corretamente direcionadas para a API Backend adequada.

• Segurança e políticas: O 3Scale permite que você defina políticas de segurança, autenticação e autorização para o Backend. Isso garante que apenas aplicativos e usuários autorizados tenham acesso à API Backend e possam usar seus recursos de acordo com as regras definidas.

• Monitoramento e análise: O 3Scale fornece recursos de monitoramento e análise para o Backend, permitindo que você rastreie o desempenho, o uso e outras métricas relevantes relacionadas à API subjacente.

Em resumo, os Backends no 3Scale representam as APIs ou serviços existentes que são gerenciados e expostos pela plataforma. Ao adicionar um Backend, você pode configurar políticas, controles de acesso e outras configurações para gerenciar a exposição e o acesso controlado a esses serviços por meio da API gerenciada pelo 3Scale.

Accounts

Para configuração dos produtos, é necessário a criação de um Account, segue abaixo uma explicação sobre o que é uma Account.

Account no 3Scale é uma entidade que representa uma conta de usuário ou uma organização dentro da plataforma. O Account é usado para agrupar e organizar recursos relacionados a APIs, produtos e configurações no 3Scale.

Ao criar uma conta no 3Scale, você tem acesso a um conjunto de recursos e funcionalidades para gerenciar suas APIs. Alguns aspectos importantes de um Account no 3Scale incluem:

• Informações do usuário: Um Account contém informações sobre o usuário que possui a conta, como nome, endereço de e-mail e credenciais de login.

• Gerenciamento de APIs: Dentro do Account, você pode criar, configurar e gerenciar as APIs que deseja expor. Isso envolve a definição de endpoints, métodos disponíveis, autenticação e outras configurações relacionadas à API.

• Applications: O Account permite que você crie e gerencie as Applications, que representam os aplicativos ou clientes que desejam acessar suas APIs. Você pode configurar diferentes Application Plans, chaves de API e políticas de segurança para cada Application associada à sua conta.

• Analytics e relatórios: O Account fornece acesso a métricas, análises e relatórios sobre o uso das suas APIs pelos aplicativos associados. Isso ajuda a monitorar o desempenho, o consumo de recursos e outras estatísticas relevantes.

• Gerenciamento de acesso: Com uma conta no 3Scale, você pode controlar o acesso e as permissões de outros usuários dentro da sua organização. Isso permite que você compartilhe o gerenciamento das APIs e recursos com membros da equipe específicos.

Em resumo, um Account no 3Scale é uma entidade que representa uma conta de usuário ou uma organização, fornecendo recursos para gerenciar APIs, Applications e configurações relacionadas. Ele serve como o ponto central para controlar e monitorar o uso das suas APIs e gerenciar as configurações necessárias para facilitar a integração e o acesso seguro aos seus serviços.

Application plans

Para a configuração do produto é necessário a criação de um Application Plan.

Um Application Plan no 3Scale define as regras e as limitações associadas a um determinado conjunto de APIs para os aplicativos ou desenvolvedores que desejam acessá-las. Ele especifica detalhes como taxas de limite de solicitações, limites de uso, recursos disponíveis e outros parâmetros relevantes.

Ao criar um Application Plan, você pode configurar políticas de acesso e limitações específicas para diferentes níveis de usuários ou aplicativos. Isso permite que você gerencie diferentes tipos de planos de assinatura ou níveis de serviço para suas APIs, oferecendo opções como um plano gratuito, plano básico, plano premium, entre outros. Cada plano pode ter diferentes restrições e benefícios, como limites de utilização, cotas de uso diárias ou mensais, acesso a recursos específicos e outras políticas que podem ser aplicadas.

Ao associar um Application Plan a um produto ou usuário, você controla o acesso e o uso das APIs com base nas regras definidas no plano. Isso ajuda a garantir que sua API seja usada de acordo com suas políticas e requisitos, permitindo a monetização, a aplicação de limites de uso e a proteção de recursos críticos.

Em resumo, um Application Plan no 3Scale é um mecanismo flexível para gerenciar o acesso e controlar o uso das suas APIs, permitindo que você defina diferentes níveis de serviço e restrições para diferentes aplicativos ou desenvolvedores.

Application

As Applications se referem às entidades que representam os aplicativos ou clientes que desejam acessar suas APIs (Interfaces de Programação de Aplicativos) expostas no 3Scale.

Quando você configura uma API no 3Scale, as Applications são usadas para gerenciar e controlar o acesso a essa API. Cada aplicativo é identificado por um conjunto de chaves de API (API keys) exclusivas que são usadas para autenticação e autorização ao fazer solicitações à API.

Ao criar um aplicativo no 3Scale, você pode definir diferentes configurações e restrições para esse aplicativo, como:

• Application Plan: Um aplicativo pode ser associado a um Application Plan específico que define as regras de acesso, limitação de requisição e recursos disponíveis para a API. Cada aplicativo pode estar vinculado a um plano diferente com diferentes níveis de serviço.

• Chaves de API (API Keys): Cada aplicativo recebe um conjunto exclusivo de chaves de API que são usadas para autenticar as solicitações feitas à API. Essas chaves de API identificam o aplicativo e podem ser usadas para controlar o acesso e monitorar o uso da API.

• Políticas de segurança: Você pode definir políticas de segurança específicas para cada aplicativo, como autenticação por token, autenticação OAuth ou outros mecanismos de autenticação personalizados.

• Métricas e análises: O 3Scale fornece recursos para rastrear e analisar o uso da API por aplicativos individuais. Você pode monitorar métricas como taxas de solicitação, uso de recursos e outras estatísticas relevantes para cada aplicativo.

Ao gerenciar suas APIs no 3Scale, as Applications desempenham um papel importante no controle e monitoramento do acesso à API por parte dos aplicativos ou clientes. Elas fornecem uma camada de gerenciamento e segurança, permitindo que você defina políticas específicas e controle o uso da API de forma granular.

Methods and Metrics

"Methods and Metrics" (Métodos e Métricas) são elementos usados para definir e monitorar o desempenho e o consumo de recursos de uma API.

Methods (Métodos) referem-se às operações específicas que podem ser realizadas em uma API. Por exemplo, uma API de serviços bancários pode ter métodos como "consultar saldo", "transferir fundos" e "criar conta". Cada método representa uma funcionalidade específica que os aplicativos podem acessar através da API.

Metrics (Métricas) são medidas quantitativas relacionadas ao uso e ao desempenho da API. Elas são usadas para monitorar e registrar informações sobre as chamadas feitas aos métodos da API. Algumas métricas comuns incluem:

• Contagem de solicitações (Request Count): Essa métrica registra o número de solicitações feitas a um método específico em um determinado período de tempo. Ela permite rastrear o volume de uso de um método e avaliar sua popularidade.

• Tempo de resposta (Response Time): Essa métrica mede o tempo necessário para que a API responda a uma solicitação feita a um método. Ela ajuda a monitorar o desempenho da API e identificar possíveis gargalos ou problemas de latência.

• Taxa de erros (Error Rate): Essa métrica indica a porcentagem de solicitações que resultaram em erros ao chamar um método da API. Ela permite identificar problemas de integridade ou estabilidade do sistema.

Ao configurar uma API no 3Scale, você pode definir métodos e associar métricas a esses métodos. Isso permite que você monitore e registre informações detalhadas sobre o uso da API, ajudando a tomar decisões informadas sobre capacidade, otimização e gerenciamento de recursos.

Além disso, as métricas também desempenham um papel importante na definição de limites e políticas de acesso. Por exemplo, você pode estabelecer limites de taxa de solicitação para cada método com base em métricas, garantindo um uso equilibrado e controlado da API.

Mapping Rule

Mapping Rule (Regra de Mapeamento) é uma configuração utilizada para direcionar e transformar solicitações e respostas entre a API exposta e a API backend subjacente.

Quando uma solicitação é feita a uma API exposta no 3Scale, as Mapping Rules definem como essa solicitação é tratada e enviada para a API backend correspondente. Elas permitem que você mapeie os parâmetros, cabeçalhos e outros elementos da solicitação original para os formatos necessários pela API backend.

As Mapping Rules podem ser usadas para realizar as seguintes ações:

• Roteamento de solicitações: As regras de mapeamento podem direcionar a solicitação para um determinado endpoint da API backend com base em critérios específicos. Isso permite que você defina diferentes rotas e lógica de encaminhamento com base em parâmetros da solicitação.

• Transformação de dados: As regras de mapeamento podem modificar ou transformar os dados da solicitação antes de encaminhá-los para a API backend. Por exemplo, você pode ajustar os formatos de dados, renomear campos ou adicionar informações adicionais à solicitação.

• Manipulação de cabeçalhos e autenticação: As regras de mapeamento podem adicionar, remover ou modificar cabeçalhos da solicitação para garantir a compatibilidade com a API backend. Além disso, elas podem ser usadas para adicionar informações de autenticação ou autorização necessárias para acessar a API backend.

• Transformação de respostas: Além de manipular as solicitações, as regras de mapeamento também podem ser usadas para transformar as respostas recebidas da API backend antes de serem retornadas ao aplicativo ou cliente que fez a solicitação.

Ao definir as Mapping Rules no 3Scale, você pode personalizar o fluxo de dados e a interação entre a API exposta e a API backend, garantindo que os dados sejam corretamente direcionados e adaptados às necessidades específicas do seu sistema.

É importante destacar que a configuração das Mapping Rules pode variar dependendo da plataforma ou tecnologia utilizada para a implementação do 3Scale.

Policies

Policies (Políticas) são conjuntos de regras e configurações aplicadas às APIs para controlar o acesso, a segurança e o comportamento das solicitações feitas pelos aplicativos aos endpoints da API. As políticas permitem que você personalize o comportamento da API e defina restrições específicas de acordo com suas necessidades.

As políticas no 3Scale podem abranger uma variedade de funcionalidades e recursos, incluindo:

• Autenticação e autorização: Você pode configurar políticas para autenticar e autorizar as solicitações dos aplicativos à API. Isso pode envolver autenticação por chave de API (API key), OAuth, tokens de acesso ou outros métodos de autenticação personalizados.

• Limites de taxa: As políticas de limites de taxa permitem controlar o número de solicitações permitidas em um determinado período de tempo. Você pode definir limites de taxa para cada aplicativo, método ou endpoint da API, evitando abusos e garantindo uma utilização equilibrada dos recursos.

• Controle de acesso a recursos: As políticas de controle de acesso permitem definir quais recursos específicos da API estão disponíveis para cada aplicativo ou usuário. Isso permite que você restrinja o acesso a determinados endpoints, métodos ou funcionalidades da API com base em regras predefinidas.

• Transformação de dados: As políticas de transformação de dados permitem manipular e modificar as solicitações e respostas da API. Isso pode incluir a transformação de formatos de dados, a filtragem de informações sensíveis ou a adição de campos adicionais às respostas.

• Logging e auditoria: As políticas podem ser usadas para registrar e rastrear informações sobre as solicitações feitas à API para fins de auditoria, análise ou conformidade. Isso inclui a capacidade de registrar dados de solicitação, dados de resposta e outras informações relevantes.

Ao configurar políticas no 3Scale, você pode personalizar a segurança, o comportamento e as restrições associadas às suas APIs. Isso ajuda a proteger seus recursos, controlar o acesso e garantir o uso adequado da API pelos aplicativos e usuários autorizados.

APICast Self-Managed

APICast Self-managed é uma opção de implantação e gerenciamento do APICast, que é um componente fundamental do 3Scale. O APICast atua como um gateway de API, permitindo o controle e a proteção das APIs expostas pelo 3Scale.

A opção APICast Self-managed refere-se à capacidade de implantar e gerenciar o APICast em seu próprio ambiente de infraestrutura, em vez de usar a opção de hospedagem gerenciada fornecida pela 3Scale. Isso permite que você tenha maior controle sobre o ambiente de implantação, personalização e escalabilidade do APICast.

Ao optar por utilizar o APICast Self-managed, você é responsável pela implantação do APICast em seus próprios servidores ou nuvem. Isso envolve a configuração e a manutenção dos recursos necessários, como servidores, balanceadores de carga e outros componentes de infraestrutura, para garantir o funcionamento adequado do APICast.

Algumas vantagens da opção APICast Self-managed incluem:

Controle total: Com a implantação do APICast em seu próprio ambiente, você tem controle total sobre a configuração, personalização e escalabilidade do gateway de API.

Segurança e conformidade: Ao gerenciar o APICast em sua própria infraestrutura, você pode aplicar as políticas e as medidas de segurança específicas do seu ambiente para garantir a conformidade com requisitos regulatórios ou de segurança.

Integração com infraestrutura existente: A opção APICast Self-managed permite integrar o gateway de API à sua infraestrutura existente, facilitando a comunicação e a troca de dados com outros sistemas e serviços internos.

Flexibilidade de implantação: Você pode ajustar a escala e os recursos de acordo com as necessidades do seu aplicativo e da sua base de usuários, garantindo o desempenho e a disponibilidade adequados.

Conclusão

Neste artigo busquei demonstrar sobre a importância de um API Gateway e apresentei os principais conceitos do Red Hat 3scale API Management.

Existem alguns outros no mercado e que você pode escolher conforme o investimento e necessidade do projeto.

Referências

https://access.redhat.com/documentation/en-us/red_hat_3scale_api_management/2.13

https://access.redhat.com/documentation/pt-br/red_hat_3scale_api_management/2.6/html/using_the_developer_portal/api_documentation

https://www.3scale.net/

https://access.redhat.com/documentation/en-us/red_hat_3scale_api_management/2.6

O Google lançou a V1.0 do Kubernetes em Julho de 2015 e fez uma parceria com a Linux Foundations para formar a Cloud Native Computing Foundation (CNCF) e ofereceu o Kubernetes como tecnologia base.

Ofertas

Neste artigo, focarei as comparações no EKS que é executado na nuvem da AWS, O AKS (Azure Container Services) que é executado no ambiente da Azure e o GKE que é executado no GCP (Google Cloud Platform), se conhecerem outros mandem nos comentários que faço um próximo com as opiniões de vocês.

A primeira grande diferença é que cada um desses serviços gerenciados em nuvem pública foram construídos para serem executados em um ambiente especifico e OpenShift Container Platform foi criado para permitir que os clientes implantem em uma infinidade de ambientes homologadas pela Red Hat e forneçam a mesma experiência para desenvolvedores e equipes de operações em cada um delas.

Decidi comparar o OpenShift Dedicated com as ofertas de nuvem pública por ser o que está diretamente relacionado ao objetivo do artigo. O OpenShift Dedicated é uma oferta de serviços gerenciados da Red Hat onde os clientes pagam pelo uso no ambiente dedicado do OpenShift e a infraestrutura é gerenciada por eles. Os clientes do OpenShift Dedicated sobem aplicações. gerenciam recursos, escalam aplicações, gerenciam pontos de acesso, gerenciam quotas e limites mas as operações do dia a dia são gerenciadas pela equipe de Operações da Red Hat. A AWS, Google Cloud Platform e Azure possuem execuções dedicadas do OpenShift.

O OpenShift (OpenShift Dedicated e OpenShift Container Platform) possui um número considerável de recursos além dos recursos do Kubernetes. Os clientes que assinam um recurso gerenciado do Kubernetes estão na mesma posição dos clientes que instalam o Kubernetes, eles terão de resolver os problemas que a Red Hat resolveu com soluções adicionais.

Os clientes que assinam um serviço do Kubernetes gerenciado pela nuvem pública pagam por serviços adicionais no provedor e não há nada de errado com essa abordagem mas é importante que entendam a diferença entre a implantação do Kubernetes e a implantação do OpenShift.

Segue abaixo os recursos que o OpenShift fornece e o que você precisaria para ter recursos semelhantes caso assine um serviço gerenciado do Kubernetes:

• O OpenShift Container Platform pode ser instalado em ambientes físicos, máquinas virtuais, infraestrutura de nuvem privada, ambientes de nuvem pública. Cada oferta de serviço gerenciada do Kubernetes em nuvem pública está vinculada a seus respectivos ambientes de nuvem.

• O OpenShift fornece consistência nas operações e na experiência do Desenvolvedor e isso significa que uma implantação que abrange vários ambientes de nuvem pública e privada pode ser usada por desenvolvedores e suportada por equipes de operações exatamente da mesma forma. Comparando ao Kubernetes em nuvem, cada serviço de nuvem pública precisaria ser consumido e gerenciado de maneira vinculada à plataforma assinada.

• O Red Hat Enterprise Linux (RHEL) está incluso na licença. Quando um cliente compra suporte para o OpenShift Dedicated ou OpenShift Container Platform, ele também recebe suporte total para o RHEL. Em outras plataformas que você necessite implementar o Kubernetes, o suporte ao sistema operacional precisaria ser adquirido e gerenciado separadamente.

• A Red Hat suporta o host do sistema operacional até os serviços que fazem parte do OpenShift Container Platform. Isso significa que todos os elementos do sistema operacional para a camada de serviço são suportados e recebem atualização de segurança caso disponível pela Red Hat. No modelo gerenciado do Kubernetes, o suporte se estende apenas à infraestrutura do Kubernetes.

• O OpenShift inclui um SDN (Software Defined Networking) integrado. O OpenShift SDN é uma solução com suporte a VXLAN que está disponível nativamente. Não está completamente claro como a rede será gerenciada nas ofertas do Kubernetes em nuvem pública. Minha suposição é que cada provedor terá que implementar um plug-in de interface de rede de contêiner (CNI) para trabalhar com suas ofertas de rede interna, mas não está claro, neste momento, o que será fornecido, se alguém tiver um material que esclareça esse ponto eu acrescento nesse artigo mas nas documentações oficiais não está claro.

• Os recursos de roteamento são fornecidos pelo OpenShift nativamente. Nos serviços gerenciados do Kubernetes, os clientes precisarão decidir como lidarão com o roteamento — aproveitando as construções de rede nativas para cada nuvem pública ou instalando, configurando e gerenciando seu próprio software para essa finalidade.

• O OpenShift tem um Image Registry já implementado em sua arquitetura. Embora muitos clientes aproveitem inicialmente o Docker Hub ou outras opções disponíveis, por experiência a maioria dos clientes demonstram interesse em ter seu próprio Image Registry com imagens homologadas e é por isso que o OpenShift fornece o recurso de se ter um Image Registry. Em ofertas de nuvem pública, os clientes precisarão escolher uma solução de registro e configurar seu ambiente para usá-la.

• O log agregado é instalado com o OpenShift. De forma opcional, os clientes podem optar por instalar o Elasticsearch, Fluentd e Kibana (EFK) para a agregação de logs, e o processo de instalação cuidará da construção e configuração do EFK automaticamente. Em um ambiente gerenciado do Kubernetes, os clientes precisam decidir como lidarão com o registro em log do Kubernetes e dos aplicativos implantados no Kubernetes.

• A agregação e apresentação de métricas operacionais estão disponíveis para serem instaladas e configuradas no OpenShift. Semelhante aos recursos de Agregação de Log, o processo de instalação do OpenShift fornece uma maneira simples de implantar métricas para monitorar as aplicações e o próprio OpenShift. A partir do OpenShift 3.7, os clientes podem escolher entre implantar métricas Hawkular ou Prometheus. Os clientes que utilizam um serviço de Kubernetes na nuvem pública precisarão decidir como irão gerenciar as métricas em seu ambiente.

• O OpenShift fornece ferramentas integradas para desenvolvedores (web, CLI e IDE), compilações de contêiner (Source to Image), CI (Jenkins) e CD (Jenkins Pipelines). Os clientes do OpenShift podem optar por integrar suas ferramentas de CI / CD existentes aos fluxos de trabalho do OpenShift ou definir Pipelines do Jenkins e fazer com que o OpenShift suba automaticamente contêineres do Jenkins para executar as pipelines e depois deletar os contêineres assim que os pipelines forem concluídos. Esse tipo de integração de CI / CD está ausente dos serviços do Kubernetes gerenciados em nuvem pública.

• O portfólio de middleware da Red Hat é testado para rodar, escalar e trabalhar de forma confiável no OpenShift. Os serviços gerenciados do Kubernetes são novos e o portfólio de middleware da Red Hat ainda não está certificado para ser executado nessas plataformas.

• Os recursos RBAC (Role Based Access Control, controle de acesso baseado em função) são totalmente integrados a todos os recursos do OpenShift. Este é um dos recursos mais solicitados para o Kubernetes, e uma das primeiras coisas que a Red Hat construiu para o OpenShift. Os clientes precisam ser capazes de controlar o acesso a recursos dentro da plataforma. O RBAC é construído na estrutura do OpenShift. Neste estágio, não está claro como os serviços gerenciados do Kubernetes implementarão o RBAC. Como o upstream do Kubernetes implementa as capacidades do RBAC, talvez cada provedor de nuvem pública desenvolva a integração com suas próprias ofertas de serviço do Identity Management.

• O OpenShift fornece uma maneira simples de integrar o Kubernetes com o armazenamento definido por software através da integração do armazenamento nativo de contêiner da Red Hat. A necessidade de armazenamento definido por software torna-se evidente para os clientes quando eles começam a implantar aplicações que esperam uma plataforma de orquestração de contêineres. O OpenShift fornece uma maneira de implantar o Gluster e integrar a implantação ao Kubernetes. Não está claro neste estágio como as ofertas de Kubernetes na nuvem pública irão lidar com o armazenamento.

• O OpenShift fornece uma UI que dá aos desenvolvedores e administradores acesso para implantar e gerenciar aplicações. A UI do OpenShift agora inclui um catálogo de serviços baseado no projeto do Open Service Broker & Kubernetes Service Catalog. Os clientes que escolherem o Kubernetes gerenciado pelo provedor de nuvem pública precisarão decidir como implementar e gerenciar um catálogo de UI e de serviços.

• As ferramentas de segurança da Red Hat integram-se ao OpenShift. Isso significa que o SELinux é incorporado à base das implantações do OpenShift e que o conjunto de ferramentas OpenSCAP pode ser usado para gerenciar os ambientes OpenShift. Em um serviço Kubernetes gerenciado em nuvem pública, os clientes precisarão escolher soluções de segurança para implementar e instalar, configurar e gerenciar por conta própria.

O suporte é fundamental quando você está considerando uma oferta de serviço gerenciado, e durante minha pesquisa a AWS, Google e Azure fornecem um suporte considerável mas não está claro qual o nível de suporte para o Kubernetes será fornecido. Todos esses serviços hospedados do Kubernetes são novos e os serviços estão evoluindo e amadurecendo rapidamente.

https://aws.amazon.com/pt/eks/

https://azure.microsoft.com/pt-br/support/legal/sla/kubernetes-service/v1_0/

Vou dar um exemplo para ficar mais claro, o Kubernetes é mantido pela comunidade e pelo Google e caso você se depare com um BUG na versão que está implementado na nuvem pode acontecer de o suporte das plataformas de nuvem pública não ter um prazo para resolução.

A Amazon não descreveu o Acordo de Nível de Serviço (SLA) para seu serviço Kubernetes. O Kubernetes da Microsoft no AKS é um serviço gratuito e você paga pelos recurso. Não há SLA fora do suporte para VMs subjacentes. Solução de problemas e os problemas do Kubernetes estarão com as equipes de operações. O Google não define o tipo de suporte fornecido para o Kubernetes Engine.

Nenhum desses serviços fornece suporte para o contêiner em si ou para o sistema operacional que hospeda os contêineres. Os serviços dedicados do OpenShift incluem suporte de infraestrutura e tempo de execução para aplicações. Não há dúvidas sobre o nível de suporte que você receberá para o OpenShift — é explicado nos Termos de Serviço. Além do Kubernetes, a equipe do OpenShift Dedicated também suporta todos os outros recursos do OpenShift.

Além do serviço básico do Kubernetes, os clientes precisam considerar os serviços adicionais necessários para tornar o Kubernetes uma plataforma corporativa. Para combinar os recursos do OpenShift nos ambientes de nuvem pública, você também precisará considerar adicionar:

• Load Balancer

• Application Gateway

• Container Registry

• Service Fabric

• Log Analytics

• Policy Service

• Ferramentas de desenvolvimento

• Software Defined Storage

O seu ambiente pode ou não exigir esses recursos mas como o artigo tem por objetivo comparar então estão listados.