Conheça o pipeline DevOps da AWS

Em qualquer time de desenvolvimento de software, um pipeline representa um conjunto de processos automatizados que possibilitam compilar, empacotar e implantar código de forma confiável e eficiente em produção. Na AWS, contamos com uma variedade de soluções robustas para construir um pipeline DevOps: o AWS CodePipeline, o AWS CodeBuild, o AWS CodeDeploy, o AWS CodeStar e o AWS CodeCommit. Neste post, vamos abordar como cada um desses serviços complementa o processo de CI/CD. AWS CodePipeline Com o AWS CodePipeline os desenvolvedores podem modelar todo o processo de entrega contínua, fazer o deploy de software ou infraestrutura de forma padronizada e automatizada, testar suas aplicações e liberá-las para seus clientes. É uma ferramenta que oferece todos os recursos para criação de um workflow completo de continuous delivery e ainda permite a integração com diversos outros recursos, possibilitando a integração com seu provedor de Git favorito e muito mais. AWS CodeBuild O AWS CodeBuild é um serviço de build totalmente gerenciado que compila o código fonte, executa testes de unidade e produz artefatos prontos para o deploy. O CodeBuild também elimina a necessidade de configuração, patch, atualização e gerenciamento de servidores de build. O desenvolvedor tem a vantagem de contar com ambientes de build pré-empacotados para linguagens de programação populares e escalonamento automático para atender ao seu volume de build. Com isso, terá também a vantagem de nunca pagar pela capacidade ociosa do servidor de build. AWS CodeDeploy O AWS CodeDeploy é um serviço criado para automatizar implementações de código em instâncias do Amazon EC2, instâncias locais (on-premises), AWS Fargate, funções Lambda Serverless ou serviços Amazon ECS. O CodeDeploy facilita o lançamento rápido de novos recursos, ajuda a evitar o tempo de inatividade durante o deploy e lida com a complexidade da atualização das aplicações existentes. Com o CodeDeploy também é possível fazer o deploy de executáveis, pacotes, scripts, arquivos web e de configuração, e de arquivos multimídia. AWS CodeStar Com o CodeStar é possível desenvolver, criar e implementar aplicações rapidamente na AWS. Assim, um projeto do CodeStar cria e integra serviços da AWS para uma cadeia de ferramentas (toolchain) de desenvolvimento de projetos. Você pode estar se perguntando: “mas qual a diferença para o AWS CodePipeline, eles são iguais”? Não exatamente: com o CodePipeline, o desenvolvedor cria, testa e implementa seu código sempre que há uma alteração no mesmo, com base nos modelos de processo de lançamento que ele define, ao passo que no AWS CodeStar é possível desenvolver, compilar e implementar aplicações ágeis na AWS. AWS CodeCommit O AWS CodeCommit é um serviço de controle de origem totalmente gerenciado que pode ser usado para armazenar e gerenciar ativos de forma privada (como documentos, código fonte e arquivos binários) na nuvem da Amazon. Também facilita a hospedagem de repositórios Git privados de forma segura e altamente escalável. A diferença entre o popular GitHub é que, embora este seja ótimo para publicar bibliotecas gratuitas de código aberto e forneça integração perfeita com muitas ferramentas de terceiros, o GitHub não oferece a mesma camada de segurança integrada do AWS CodeCommit, que, por outro lado, é totalmente integrado ao AWS Identity and Access Management (IAM), tornando-o altamente seguro. Conclusão Uma parte fundamental da abordagem DevOps é adotar a cultura de integração, implementação e entrega contínua (CI/CD), onde um commit ou alteração no código passa por vários estágios automatizados, desde a criação e teste até o deploy de aplicações, do desenvolvimento ao ambiente de produção. E esse é o objetivo das soluções pipeline DevOps da Amazon. Na O2B trabalhamos com todos esses serviços integrados para fornecer aos nossos clientes uma esteira de entrega contínua (continuous delivery) completa. Além disso, suportamos estrutura, ajustes e o desenvolvimento de novos pipelines DevOps usando soluções AWS. Assim, aceleramos o desenvolvimento de novas features para nossos clientes, diminuindo o tempo de implementação e entrega dos projetos de software. Quer saber mais? Entre em contato conosco! Facebook Twitter LinkedIn
14 benefícios de uma arquitetura cloud native

Para o arquiteto de sistemas Tom Grey, especialista Google Cloud, “um sistema cloud native bem arquitetado deve ser amplamente auto recuperável, econômico e facilmente atualizado e mantido via processos automatizados de Continuous Integration/Continuous Delivery (CI/CD)”. Se esse paradigma parece complexo a organizações ainda não familiarizadas com a ideia, a boa notícia é que todas as melhores práticas aplicadas à infraestrutura tradicional de sistemas “pré-cloud” valem também para aplicações cloud native. E com inúmeros benefícios inerentes à nuvem: computação distribuída, elasticidade, escalabilidade, flexibilidade e resiliência, entre várias outras vantagens que iremos abordar neste post. Antes, uma breve introdução É importante ressaltar que o termo “cloud native” faz referência a um paradigma de design difundido pela Cloud Native Computing Foundation (CNCF). A CNCF é uma entidade internacional criada para fomentar a comunidade em torno de projetos e ecossistemas sustentáveis de alta complexidade que orquestram containers como parte de uma arquitetura de microsserviços. Assim, a partir da definição da CNCF, as aplicações cloud native podem ser tecnicamente definidas como sendo aplicações executadas em um ambiente conteinerizado e dimensionado horizontalmente com base em diferentes tipos de workloads. Abstraída a infraestrutura subjacente – o que não ocorre na infraestrutura tradicional de sistemas – a implementação de microsserviços segue um pipeline DevOps (e muitas vezes usando Kubernetes para operação de containers, como é o que fazemos aqui na O2B para nossos clientes). Por fim, é importante notar ainda que aplicações executadas na nuvem não são necessariamente cloud native. Um simples “lift and shift” de uma arquitetura on-premises para a nuvem por si só não irá garantir o máximo proveito dos benefícios que a nuvem oferece. Isto posto, vamos aos 14 benefícios proporcionados por uma arquitetura cloud native, ou seja, aquela que é construída diretamente na nuvem para entregar as vantagens que só a computação distribuída oferecida pelo modelo cloud é capaz de proporcionar para o seu negócio. #1. Lançamentos mais ágeis O “time to market” é o diferencial chave entre as empresas mais inovadoras no mercado. Assim, quanto mais rapidamente uma organização puder prototipar, construir e entregar valor para seus clientes, maior o sucesso em seu segmento de atuação. A abordagem DevOps pressupõe automação em todo o processo de entrega de software, desde a construção, à fase de testes, implementação e manutenção. Uma aplicação cloud native suporta todos os processos envolvidos nessa abordagem, que por definição é mais ágil e colaborativa do que a “antiga” de desenvolvimento local com servidor limitado. #2. Customer experience aprimorada Construir uma ótima experiência do cliente requer não apenas a entrega rápida de novas features do produto de software como também iterações contínuas para que ele se mantenha sempre bem atualizado. Também significa adotar uma abordagem mobile-first para o desenvolvimento de aplicativos e boas práticas de UX, incluindo Design Thinking. A integração baseada em API é a forma moderna de conectar o armazenamento de um volume gigantesco de dados corporativos a aplicativos frontend mais ágeis – e melhor conectados à experiência do usuário. Uma integração que é bastante facilitada quando os apps são nativos na nuvem, dando nova vida a esses sistemas. #3. Facilidade de gerenciamento O modelo cloud native também oferece opções serverless para simplificar o gerenciamento de infraestrutura, como é o caso da AWS Lambda e Azure Functions, usadas pelos times de desenvolvimento da O2B. As plataformas de computação serverless permitem carregar código em forma de funções, que são executadas de forma que os times não precisem se preocupar em provisionar instâncias na nuvem, configurar redes ou alocar armazenamento suficiente. #4. Custo reduzido por conteinerização e padrões de nuvem Os containers facilitam o gerenciamento e a segurança das aplicações independentemente da infraestrutura que os suporta. O Kubernetes também tem se consolidado como a plataforma de escolha para o gerenciamento desses containers em grande escala. Além do Kubernetes, que é open source, há uma série de ferramentas cloud native padronizadas e poderosas disponíveis no mercado atualmente. E padronização de infraestrutura com ferramentas open source significa redução de custos. Combinadas com recursos serverless, workloads dinâmicos podem ser executados em milissegundos em um modelo pay-per-use. #5. Sistemas mais confiáveis O tempo de inatividade era algo normal muitos anos atrás, e atingir a tolerância a falhas era algo muito difícil e caro. Mas com uma arquitetura baseada em Kubernetes e microsserviços, é possível criar aplicações tolerantes a falhas com resiliência e auto recuperação integrada. Dessa forma, quando ocorrem falhas, é fácil isolar o incidente para que ele não afete toda a aplicação. Em vez de servidores e aplicações monolíticas, os microsserviços cloud native ajudam a obter sistemas mais confiáveis e com maior tempo de atividade para seus usuários. #6. Evita o chamado “vendor lock-in” Até pouco tempo atrás, os fornecedores de sistemas legados emitiam licenças de 3 anos para hardware proprietário. Mas isso já é coisa do passado: com o aumento da oferta de tecnologias de cloud open source, a nuvem híbrida e a multi-cloud têm se tornado norma no mercado. As empresas normalmente usam uma combinação de datacenter on-premises (local) com uma plataforma de nuvem pública. E mesmo entre diferentes plataformas de nuvem já existe a possibilidade de fazer a portabilidade entre nuvens, para que o cliente não tenha que se manter preso a um único fornecedor, o chamado “vendor lock-in”. #7. Melhor custo-benefício Com aplicações cloud native, todas as soluções são projetadas para funcionar diretamente na nuvem. Essa compatibilidade com a infraestrutura nativa da nuvem tem a vantagem de reduzir custos com backup, manutenção, desenvolvimento e uso de recursos. Com um sistema open source e recursos serverless – que adotam um modelo de pagamento por uso – os custos para as empresas são reduzidos consideravelmente. #8. Facilita uma abordagem mobile-first A migração de apps para a nuvem é uma maneira eficiente de não ter que abandonar décadas de trabalho e investimento em desenvolvimento de software. De quebra, ainda aloca recursos em plataformas mais modernas, escaláveis e flexíveis. Mas não é só isso: a migração para aplicações cloud native ajuda a adotar uma abordagem mobile-first no design de aplicativos, onde se encontra a maior fatia do público atualmente. Com ferramentas que focam em um ciclo de feedback x deploy,
Quais as vantagens do Rancher e sua relação com o Kubernetes?

Como uma plataforma open source de orquestração de múltiplos clusters, o Rancher lida com os desafios operacionais no gerenciamento de vários clusters Kubernetes ao mesmo tempo. Desde a sua aquisição pela SUSE, em 2020, a plataforma tem otimizado sua oferta de ferramentas integradas para executar workloads em containers. Dessa forma, o Rancher ajuda os times de desenvolvimento engajados na cultura DevOps a adotarem o Kubernetes da maneira mais simples e escalável possível. Ele é capaz de fazer isso oferecendo uma pilha de software completa que simplifica e aprimora o processo de gerenciamento de clusters Kubernetes em vários ambientes de nuvem, sejam eles públicos, privados, bare metal ou mesmo em cenários híbridos. O Rancher adiciona uma camada completa de gerenciamento de workload e User Interface (UI) ao Kubernetes, o que simplifica sua adoção e integração a um pipeline CI/CD, e também a outras tecnologias de dados e monitoração que usamos na O2B, como Prometheus, Grafana e Fluentd. Ou seja, enquanto o Kubernetes oferece recursos avançados de dimensionamento para garantir o desempenho e a alta disponibilidade da aplicação, sua funcionalidade se concentra no gerenciamento de recursos em um único cluster. O Rancher, por outro lado, é uma plataforma projetada para gerenciar vários clusters Kubernetes, também para dar visibilidade a tudo que está sendo executado em um cluster. Vantagens do Rancher Alta Disponibilidade: O Rancher pode ser implementado em alta disponibilidade (HA) e assim garantir um ambiente de gerenciamento resiliente. Interface de gerenciamento: Conta com uma interface web intuitiva (UI) com muitos recursos visuais para facilitar a gestão do ambiente. Multi ambientes: Suporta o gerenciamento de cluster Kubernetes nas principais clouds públicas e ainda conta com um ecossistema completo para deploy de cluster em datacenters ou onde quiser. Multi orquestradores: Suporta trabalhar com Docker, mas também com Containerd e Cri-o que são os motores mais conhecidos para execução de containers. Integração com as principais clouds: Suporta integração com os principais provedores de cloud pública, tais como AWS e Azure; conta com um projeto próprio chamado RKE e permite o deploy de clusters gerenciados em qualquer lugar ou servidor. Serviços: Facilita a gestão de serviços e de endpoints internos da aplicação, além de adicionar suporte nativo a service mesh com Istio, literalmente com poucos cliques. Catálogo de serviços: Dispõe de um catálogo completo de aplicações que podem ser adicionadas ao seu ambiente, tais como: MongoDB, Redis, RabbitMQ, Kafka e muitos outros. Load balancer: Gerencia load balancers na camada de aplicação e redes. Repositórios de imagens: Permite a adição de repositórios de containers para acesso seguro por parte das aplicações. Storage: Gerenciamento de volumes de diversos tipos suportados nativamente pelo Kubernetes e ainda conta com um projeto chamado Longhorn para gestão avançada de volumes com replicação de dados, backups e muito mais. Controle de acesso integrado: Com ele conseguimos gerenciar usuário e suas permissões para os clusters, projetos e namespaces. Também contempla integração com diretórios externos de usuários como AD e LDAP. Logs de auditoria: Facilita a visualização de informações essenciais para a gestão dos clusters. API de gerenciamento e webhooks: Permite a operação via API Restful para os clusters e conta com integração com qualquer outra solução que suporte webhooks. Acesso à containers: Fornece acesso direto a containers via interface. Logs e acesso ao bash do container: Permite a visualização dos logs das aplicações em tempo real para cada container, assim como o login no shell do container para realizar testes e validações em tempo real. Documentação: Possui documentação oficial Conclusão Ter uma plataforma para centralizar o gerenciamento dos ambientes Kubernetes e prover uma solução completa dentro do ecossistema de containers é uma vantagem bastante interessante que o Rancher oferece. A aquisição pela SUSE também agrega maior segurança e confiança no atendimento ao suporte oficial do software. Como parceira de negócios da Rancher, a O2B utiliza sua plataforma como interface administrativa padrão para acelerar e escalar a entrega de novos Produtos Digitais com enorme aceitação de mercado. Quer saber mais? Entre em contato conosco! Facebook Twitter LinkedIn
Conheça as 8 ferramentas CI/CD mais usadas na abordagem DevOps

Continuous Integration (CI) é um processo bastante conhecido em desenvolvimento de software. Consiste basicamente em alterações (commits) no código-fonte, feitos por desenvolvedores a partir de um repositório compartilhado, ocorrendo de forma contínua e automática. E, a depender do projeto e da necessidade, podem também ocorrer várias vezes em um único dia. Cada commit é monitorado continuamente por um servidor CI, o que aumenta a eficiência das compilações e verificações de código. A prática permite uma integração mais rápida do código criado pelos times de desenvolvimento, além de diminuir a carga (workload) em cima dos testadores. O Continuous Delivery (CD) é uma abordagem na qual os times de desenvolvimento produzem software em ciclos curtos (ágeis), assegurando dessa forma que possa ser lançado de forma confiável e em pequenas iterações. Essa abordagem ajuda na redução de custos e de riscos, ao possibilitar atualizações incrementais para aplicações em produção. Assim, um processo de implementação simples e de repetição constante é de fundamental importância no Continuous Delivery. Agora você pode estar se perguntando: okay, mas afinal qual a relação entre CI/CD? De uma forma simples, o Continuous Integration trata da automação para construir e testar aplicações sempre que novos commits são enviados para o branch. Já o Continuous Delivery é o Continuous Integration mas com o deploy para produção “ao clique de um botão”. (Talvez você também já tenha ouvido falar em CD como “Continuous Deployment”, que é quando os lançamentos acontecem automaticamente, sem nenhuma intervenção humana, mas esse é assunto para outro post). Neste post, você vai conhecer as 8 ferramentas CI/CD mais usadas na abordagem DevOps: Jenkins O Jenkins é uma ferramenta open source escrita em Java, usada para implementar pipelines de integração e entrega contínua (CI/CD). Não encabeça essa lista por acaso: talvez o Jenkins seja a ferramenta CI mais popular do mercado. Sua arquitetura funciona da seguinte forma: Os desenvolvedores fazem as alterações (commits) no código-fonte, a partir do repositório do projeto O servidor Jenkins CI verifica o repositório em intervalos regulares e extrai todo código que estiver disponível O Build Server cria o código em um arquivo executável. Caso a compilação falhe, um feedback é enviado aos desenvolvedores O Jenkins implementa a aplicação no servidor de teste. Se o teste falhar, os desenvolvedores são alertados Se o código estiver livre de erros, a aplicação testada será implementada no servidor de produção A preferência pelo Jenkins na abordagem DevOps vem do fato de ser modular e possibilitar a integração com praticamente todas as outras ferramentas DevOps existentes, além de oferecer mais de mil plugins para estender seus recursos e torná-lo mais específico para as necessidades de cada usuário. O Jenkins também pode ser instalado em qualquer sistema operacional que execute Java. GitLab O GitLab é uma das ferramentas de CI/CD mais usadas no cenário DevOps. É altamente escalável e pode ser instalada não apenas na nuvem, como on-premises também. Com o GitLab, armazenar o código, desenvolvedor, testar, criar e publicar seu software sem a necessidade de aplicativos ou integração de terceiros. Além disso, oferece documentação forte, controle fácil e boa UX. Mas o principal benefício de usar o GitLab talvez seja o fato de permitir que todos os membros da equipe colaborem em todas as fases do projeto. Ele oferece rastreamento desde o planejamento até a criação para ajudar os desenvolvedores a automatizar todo o ciclo de vida DevOps e com isso alcançar os melhores resultados possíveis. ArgoCD Leve e fácil de configurar, o ArgoCD é uma ferramenta declarativa GitOps criada para fazer o deploy de aplicações no Kubernetes. Possibilita ler e sincronizar automaticamente a configuração do ambiente no repositório git (seja como um helm chart, ou como arquivos kustomize, jsonnet e yaml simples) e aplicá-lo aos namespaces do Kubernetes. Um benefício da sincronização automática é que os pipelines CI/CD não precisam mais de acesso direto ao servidor de API do ArgoCD para performar o deploy. Quanto à segurança, credenciais para os servidores de API dos outros clusters são armazenadas como segredos no namespace da ferramenta. A empresa Intuit, avaliada em mais de US$ 9 bilhões, iniciou o projeto ArgoCD alguns anos atrás para atender à necessidade dos engenheiros de software por um serviço de continuous delivery rápido e confiável o suficiente para implementar centenas de microsserviços em diversos clusters Kubernetes ao mesmo tempo usando o Git. FluxCD FluxCD é tido como uma coleção de ferramentas para Kubernetes que faz o GitOps acontecer em um cluster em execução. Também é usado para automatizar as atualizações de configuração quando há um novo código a ser implementado. Com o FluxCD, um workflow GitOps pode ser configurado em apenas algumas etapas. Em outras palavras, o FluxCD se concentra em tornar possível manter clusters Kubernetes e aplicações cloud-native em sync com recursos externos e definições hospedadas em ambientes como, por exemplo, o GitHub. A diferença básica entre o FluxCD e o ArgoCD é que, enquanto o último permite conectar vários repositórios ao adicionar novas aplicações a um projeto, o FluxCD possibilita fazer o mesmo ao adicionar novos repositórios via bootstrap. GoCD Desenvolvido pela Thoughtworks, o GoCD é open source e está disponível sob a licença Apache 2.0 gratuitamente para todos os times DevOps. O nome vem de uma abreviação do auto-explicativo “Open Source Continuous Delivery and Release Automation Server”. Com o GoCD, você pode armazenar definições de pipeline em um repositório de código-fonte – seja no da própria aplicação ou ainda em um repositório separado. Dessa forma, as definições de pipeline ficam fora do GoCD e sob controle de versão, e podendo ser gerenciadas externamente. A vantagem de usar o GoCD é o suporte imediato aos cenários de continuous delivery mais comuns, sem a necessidade de instalar qualquer plugin para fazer isso. Spinnaker Suportado por uma grande comunidade formada pela AWS, Google, Azure, Oracle, SAP, Cisco e Netflix, entre outras, o Spinnaker é usado por desenvolvedores, testadores e SREs para fazer o deploy de centenas de alterações por dia em produção. Essa plataforma de continuous delivery é também open source e multi-cloud. Combina um sistema de gerenciamento de pipeline flexível, e possui integração com os
Qual a diferença entre Docker e Kubernetes e quando usar um ou outro?

É comum a confusão em torno do uso das ferramentas Docker e Kubernetes. À primeira vista, isso se deve ao fato de ambos lidarem com containers em uma aplicação. Mas, em uma explicação simplista, podemos afirmar que, enquanto o Docker trata da criação de containers, o Kubernetes cuidará do gerenciamento (ou orquestração) deles em um dado sistema. Ambos possuem, portanto, finalidades distintas. E, como veremos neste artigo, podem também funcionar de forma independente. O que é o Docker no processo de desenvolvimento? O Docker é uma ferramenta open source para construção e implementação de aplicações nativas da nuvem (cloud native). Mas, em virtude de sua utilidade, também é conhecido como “plataforma de conteinerização”. Ele nasce do conceito de que é possível empacotar o código de uma aplicação, com todas as suas dependências, em containers – que nada mais são do que componentes executáveis padronizados que combinam o código-fonte da aplicação com as bibliotecas do sistema operacional e as dependências necessárias para executar esse código em qualquer ambiente. O Docker, dentro desse contexto, serve para empacotar e enviar a aplicação ao próximo nível no processo de desenvolvimento. Qual a importância do Docker? A importância do Docker reside no fato de permitir uma implementação fácil em um ambiente de nuvem, servindo de base para a entrega de aplicações ultramodernas. Além disso, representa uma abordagem focada na eficiência do uso de microsserviços, com tecnologia controlável e granular. Em outras palavras, o Docker possibilita a conteinerização dos microsserviços ao simplificar a entrega e o gerenciamento desses microsserviços. A conteinerização, por sua vez, fornece microsserviços individuais com ambientes de workload isolados, prontos para serem implementados e escalados de forma independente. E onde entra o Kubernetes nessa abordagem? Você pode pensar em container como sendo um pacote padronizado para microsserviços contendo todo o código da aplicação e suas dependências necessárias. O Kubernetes vai entrar em cena nessa abordagem como um sistema para operar aplicações em containers em larga escala. Em sua definição, o Kubernetes representa uma plataforma open source para orquestração de containers que serve para automatizar muitos dos processos manuais envolvidos no deploy, gerenciamento e dimensionamento de aplicações. Ou seja, é bastante útil (e veloz) se você estiver lidando com muitos containers e precisar de automação das etapas ao iniciá-los. Combinar práticas DevOps com containers e Kubernetes possibilitará a construção de uma arquitetura baseada em microsserviços para promover entrega rápida e orquestração escalável de aplicações cloud native. Em resumo, combinar Kubernetes com Docker irá tornar sua infraestrutura mais robusta e sua aplicação mais disponível, em altíssimo nível. No entanto, como afirmamos no início deste artigo, Docker e Kubernetes podem funcionar de forma independente. Sendo o Kubernetes um orquestrador de containers, ele precisa de um container runtime para orquestrar. Por conta disso, ele é mais comumente usado com o Docker, mas também pode ser usado com qualquer outro container runtime. Por exemplo, RunC, cri-o e containerd são outros ambientes de execução de container alternativos ao Docker para se usar com Kubernetes. A Cloud Native Computing Foundation (CNCF) mantém uma lista de ambientes de execução de containers, e a própria documentação do Kubernetes fornece instruções específicas para configurar o uso do containerd e do cri-o. Conclusão Neste artigo, vimos como Docker e Kubernetes podem ser usados de forma complementar. Embora existam outras soluções disponíveis, essa é uma combinação bastante popular no mercado. Mas a joia da coroa é sem dúvida o Kubernetes, pelo simples fato de simplificar enormemente o processo de implementação e lançamento de aplicações. Além disso, também garante a escalabilidade em múltiplos ambientes de desenvolvimento. E talvez o mais importante de tudo: com o Kubernetes é possível simplificar e acelerar a migração de aplicações de um ambiente on-premises para nuvens oferecidas por qualquer provedor. Com isso, o risco de vendor lock-in também é reduzido, uma vez que as aplicações podem funcionar em qualquer ambiente, público ou privado, sem perdas funcionais ou de desempenho pelo caminho. Hoje a O2B gerencia ambientes modernos para os mais diversos tipos de negócios usando Kubernetes e uma série de outras soluções aderentes à plataforma. Desta forma, disponibilizamos serviços padronizados e tecnologicamente enxutos em respeito às melhores práticas de mercado. Quer saber mais? Entre em contato conosco! Facebook Twitter LinkedIn
O que são Plataformas Cloud Native e por que há tanto entusiasmo em torno do conceito

O2B esclarece o que é Cloud Native e por que há tanto entusiasmo em torno do conceito
DevOps: três passos para uma implementação de sucesso

A cultura DevOps traz uma série práticas e ferramentas para ajudar os times de produtos. Veja os três passos para uma implementação de sucesso.
Como proteger seu negócio da indisponibilidade dos provedores de cloud?

Um problema ocorrido em um dos servidores da AWS fez acender o alerta dos executivos sobre como agir em casos de indisponibilidade dos provedores de cloud.
Webmotors atinge 100% das aplicações críticas monitoradas com soluções da O2B

Entre os principais resultados com CloudOps, a Webmotors atingirá 100% das aplicações críticas monitoradas em suas plataformas até o fim deste ano.
Catraca Livre faz modernização tecnológica e reduz em 32% custos mensais de TI

Com o projeto com a O2B, a Catraca Livre ainda melhorou o desempenho e tempo de resposta do portal.