Recomendados
Mais conteúdo relacionado
Semelhante a Utilização de DevOps
Semelhante a Utilização de DevOps (20)
Mais de Caio Candido
Utilização de DevOps
- 1. powered by Cloud Services Sua nuvem utilizando OpenSource Estratégia de uso de Cloud com containers, automação e IaaS+PaaS Caio Candido Senior Technology Strategist, Latin America Ready Solutions & Red Hat
- 2. GENERAL DISTRIBUTION2 ANOS / MESES MESES / SEMANAS SEMANAS / DIAS Transformação Digital IMPACTA A FORMA DE CONSTRUIR, EXECUTAR E GERENCIAR SOFTWARE
- 3. GENERAL DISTRIBUTION Como o OpenSource nasceu e cresceu? RED HAT FOI FUNDADA IPO AQUISIÇÃO DO JBOSS LANÇAMENTO DO ENTERPRISE LINUX LANÇAMENTO DO RED HAT VIRTUALIZATION ADIÇÃO DA RED HAT AO ÍNDICE DO S&P 500 LANÇAMENTO DO CLOUDFORMS & OPENSHIFT US$1 BILHÃO EM RECEITA 1993 1999 2002 2006 2009 2011 LANÇAMENTO DO RED HAT OPENSTACK PLATFORM UNIÃO DO CENTOS À RED HAT AQUISIÇÃO DO ANSIBLE AQUISIÇÃO DAS EMPRESAS INKTANK (CEPH), ENOVANCE (OPENSTACK), & FEEDHENRY (MOBILE) US$2 BILHÕES EM RECEITA AQUISIÇÃO DA 3SCALE LANÇAMENTO DO RED HAT STORAGE LANÇAMENTO DO OPENSHIFT ENTERPRISE AQUISIÇÃO DA CoreOS 2018 2017 2016 2015 2014 2013 2012
- 4. GENERAL DISTRIBUTION Como funciona o modelo de “Subscription”? *Cliente CSM Suporte L2 Expert SBR Engenharia Suporte L1 TAM $ Instrutor Consultor Red Hat Network Kbase Arquiteto de Dominio Arquiteto de Soluções DE GS S GP S GLS Download Documentação Atualizações – Versões Correções – Patchs – Bugs Segurança – Ciclo de vida Inovação – Novas tecnologias Suporte Standard – Comercial Suporte Premium - 24x7 Educação Monitoramento – Relatórios Homologação - Ecosistema TQM Escritor
- 5. GENERAL DISTRIBUTION Portfólio de produtos Red Hat na DellEMC
- 6. GENERAL DISTRIBUTION Ofertas de Mercado para Service Providers APPLICATION HARDWARE OPERATING SYSTEM Application Runtime Application Services Application Workflow Container Scheduling Container Orchestration Container Engine IaaS Operating System Virtual / Physical Infrastructure DEV APP OPS SYS OPS
- 7. GENERAL DISTRIBUTION Softwares para sua estratégia de nuvem
- 8. GENERAL DISTRIBUTION CloudForms + Ansible Nutanix Vxrail Vmware Amazon AWS Service Providers Azzure OpenStack Gestor de nuvem híbrida Automação de todo o ambiente de hardware e software Container Virtual Machine
- 10. GENERAL DISTRIBUTION Como obter mais conhecimento? https://www.redhat.com/en/services/training/rh024-red-hat-linux-technical-ov https://www.redhat.com/en/services/training/rh018-virtualization-and-infrastr https://www.redhat.com/en/services/training/do092-developing-cloud-native- https://www.redhat.com/en/services/training/do080-deploying-containerized- https://www.redhat.com/en/services/training/do007-ansible-essentials-simpl https://www.redhat.com/en/services/training/cl010-red-hat-openstack-techni
- 11. GENERAL DISTRIBUTION Os Problemas na engenharia de software Aplicações possuem um processo de instalação, configuração e integrações complexo que deve ser realizado a cada novo deploy. Além disso, precisamos gerenciar ambientes de maneiras diferentes para prover a infra-estrutura por Ops e Dev consumir.
- 12. GENERAL DISTRIBUTION O Desafio OPERAÇÕES DE TIDESENVOLVEDORES
- 14. GENERAL DISTRIBUTION Quando pensamos em DevOps … Automação em todo lugar Tudo como código Continuous Integration/Delivery A aplicação é sempre “releasable” Monitoramento de Aplicações Rápido Feedback Rebuild vs. Repair Delivery pipeline
- 15. GENERAL DISTRIBUTION Tudo como Código – Pensando em Agilidade LIB UI LIB LIB BIZ LOGIC DATA ACCESS Aplicativo Navegador Dados Modelo atual com aplicações monoliticas
- 16. GENERAL DISTRIBUTION16 Provisionamento atual de ambientes TEST QA PRODDEV ≠ ≠ ≠ PONTO DE FALHA! PONTO DE FALHA! PONTO DE FALHA!
- 17. GENERAL DISTRIBUTION17 Automação em todo lugar – Para onde iremos TEST QA PRODDEV ≠ ≠ ≠ Ferramenta de automação de ambientes - Ops Ferramenta Multicloud, conectar de forma hibrida nossos ambientes - Ops Ferramenta de provisionamento e gestão de ambientes - Ops
- 18. GENERAL DISTRIBUTION A Solução Adotar uma estratégia de containers irá permitir que as aplicações sejam facilmente compartilhadas e implantadas. Além do uso de ferramentas que ajudam a entregar uma esteira DevOps.
- 19. GENERAL DISTRIBUTION O que são containers? Depende, para quem você pergunta ... ● É uma aplicação rodando em um “Sandbox” em um ambiente onde apenas o Kernel do Linux é compartilhado ● São mais simples, leves e densos que máquinas virtuais ● Portável para qualquer ambiente ● É um pacote com minha aplicação e todas as suas dependências ● Implantação (deploy) para qualquer ambiente em segundos e permite o CI/CD ● Acesso fácil e compartilhado de ambientes containerizados INFRAESTRUTURA APLICAÇÕES
- 20. GENERAL DISTRIBUTION Máquinas virtuais e containers As diferenças de uso na entrega de Máquinas e/ou Containers
- 21. GENERAL DISTRIBUTION Pensando em desempenho Entrega de uma máquina virtual e um container
- 22. GENERAL DISTRIBUTION Adoção de um modelo baseado em containers Pensando nos futuros pápeis e responsábilidades do Dev e do Ops
- 23. GENERAL DISTRIBUTION O que o container nos ajuda no dia-a-dia? Aqui não possuimos uma estratégia de infra ágil
- 24. GENERAL DISTRIBUTION Você não precisa “matar” sua infra atual Entenda como o container pode te ajudar
- 25. GENERAL DISTRIBUTION Docker é uma tecnologia de software que fornece contêineres, promovido pela empresa Docker, Inc. O Docker fornece uma camada adicional de abstração e automação de virtualização de nível de sistema operacional no Windows e no Linux.
- 26. GENERAL DISTRIBUTION Físico Virtual Cloud Privada Cloud Pública container
- 27. GENERAL DISTRIBUTION Repositório de fontes CI/CD engine Dev container Físico Virtual Cloud Privada Cloud Pública
- 29. GENERAL DISTRIBUTION $ docker build -t app:v1 . $ docker run app:v1
- 30. GENERAL DISTRIBUTION $ docker build -t app/frontend:v1 . $ docker build -t app/backend:v1 . $ docker build -t app/database:v1 . $ docker build -t app/cache:v1 . $ docker build -t app/messaging:v1 .
- 31. GENERAL DISTRIBUTION $ docker run app/frontend:v1 link-to-backend $ docker run app/frontend:v1 link-to-backend $ docker run app/backend:v1 link-to-db-cache-messaging $ docker run app/backend:v1 link-to-db-cache-messaging $ docker run app/database:v1 $ docker run app/cache:v1 link-to-db $ docker run app/messaging:v1
- 33. GENERAL DISTRIBUTION Não é suficiente! Necessitamos ir além de containers! Lifecycle and health Mantém os containers rodando a despeito de falhas Scheduling Decide onde devemos fazer o deploy dos containers Discovery Localiza outros containers na rede Monitoring Visibilidade de como os containers estão rodando Segurança Controla quem pode fazer o que Scaling Estala os containers Up e Down Persistência Mantém os dados além do ciclo de vida do container Agregação Compor Aplicações com multiplos containers
- 34. GENERAL DISTRIBUTION Kubernetes é um sistema OpenSource para automação de deployment, operações, e scaling de aplicações conteinerizadas através de múltiplos hosts. O Kubernets é um Gerenciador (a nível)de Containers muito poderoso.
- 36. GENERAL DISTRIBUTION DevOps utilizando Kubernets Dev Repositório de fontes CI/CD engine container Kubernets
- 37. GENERAL DISTRIBUTION DevOps utilizando Kubernets NETWORK Não é suficiente! Precisamos de networking!
- 38. GENERAL DISTRIBUTION DevOps utilizando Kubernets IMAGE REGISTRY NETWORK Não é suficiente! Necessitamos de registro das imagens!
- 39. GENERAL DISTRIBUTION DevOps utilizando Kubernets IMAGE REGISTRY METRICS AND LOGGING NETWORK heapster Não é suficiente! Necessitamos de métricas e logging!
- 40. GENERAL DISTRIBUTION DevOps utilizando Kubernets IMAGE REGISTRY Não é suficiente! Necessitamos de gerenciamento de ciclo de vida! APP LIFECYCLE MGMT METRICS AND LOGGING NETWORK
- 41. GENERAL DISTRIBUTION DevOps utilizando Kubernets IMAGE REGISTRY Não é suficiente! Necessitamos de App Services, exemplo: DBs e messageria APP SERVICES APP LIFECYCLE MGMT METRICS AND LOGGING NETWORK
- 42. GENERAL DISTRIBUTION DevOps utilizando Kubernets IMAGE REGISTRY Não é suficiente! Necessitamos de portal de self-service! SELF-SERVICE APP SERVICES APP LIFECYCLE MGMT METRICS AND LOGGING NETWORK
- 43. GENERAL DISTRIBUTION Não é suficiente! Necessitamos ir além de Kubernets! Routing & Load Balancing Multi-tenancy CI/CD Pipelines Role-based Authorization Capacity Management Chargeback Vulnerability Scanning Container Isolation Image Build Automation Quota Management Teams and Collaboration Infrastructure Visibility
- 44. GENERAL DISTRIBUTION44 RED HAT OPENSHIFT CONTAINER PLATFORM PORTAL DE AUTO- SERVIÇO MULTI-LINGUAGEM CONTROLE DE VERSÕES / S2I AUTOMAÇÃO DE IMPLANTAÇÃO - CD MONITORAME NTO E FEEDBACK PADRONIZAÇÃO DOS AMBIENTES - DOCKER (OCI) GESTÃO E - KUBERNETES (CNORQUESTRAÇÃOCF) AUTOMAÇÃO DE CONSTRUÇÃO E TESTES - CI O CICLO COMPLETO PARA DEVOPS
- 45. GENERAL DISTRIBUTION Red Hat OpenShift Container Platform ENTERPRISE-GRADE CONTAINER OS Business Automation CONTAINE R CONTAINE R CONTAINE R CONTAINE R CONTAINE R Integration Data Web & Mobile 3rd party frameworks CONTAINER INFRASTRUCTURE SERVICES (Orchestration & Scheduling, Storage, Registry, Security, Networking) LIFECYCLE AUTOMATION (Self-service, CI/CD, Image Stream) CONTAINER MANAGEMENT (Monitoring, Capacity, Policies) Red Hat Enterprise Linux & Atomic Host Tradicional, Stateful & Microservices como base para Apps PaaSCaaSIaaS
- 46. GENERAL DISTRIBUTION Plataforma para aplicações em Containers baseada em Docker e Kubernetes para construir, distribuir e rodar containers em larga escala.
- 48. GENERAL DISTRIBUTION OpenShift como Gerenciador de Containers Ainda não estamos falando das aplicações e tudo que a plataforma entrega
- 49. GENERAL DISTRIBUTION Implementação baseada em Open Container Initiative do Kubernetes Container Runtime Interface. Arquitetura mínima e segura. Otimizado para trabalhar com o Kubernetes. Executa qualquer imagem compatível com OCI (incluindo Docker).
- 50. GENERAL DISTRIBUTION Um contêiner é a menor unidade de um sistema operacional na computação Container
- 51. GENERAL DISTRIBUTION Image Contêineres são criados a partir de imagens de contêiner
- 52. GENERAL DISTRIBUTION Registry As imagens do contêiner são armazenadas em um registro de imagem
- 53. GENERAL DISTRIBUTION Repository Um repositório de imagens contém todas as versões de uma imagem no registro de imagens
- 54. GENERAL DISTRIBUTION IP Contêineres são agrupados em grupos de unidades de implantação e gerenciamento
- 55. GENERAL DISTRIBUTION Deployment A configuração de pods é definida em uma implementação
- 56. GENERAL DISTRIBUTION Backend Service Serviços fornecem balanceamento de carga interno e descoberta de serviço em pods
- 57. GENERAL DISTRIBUTION Backend API Os aplicativos podem conversar entre si por meio de serviços
- 58. GENERAL DISTRIBUTION Route Rotas adicionam serviços ao balanceador de carga externo e fornecem URLs legíveis para o aplicativo
- 59. GENERAL DISTRIBUTION POD Projetos isolam aplicativos em ambientes, equipes, grupos e departamentos
- 60. GENERAL DISTRIBUTION Podemos ter mais de uma alternativa para Infra
- 61. GENERAL DISTRIBUTION Instâncias de Nodes com RHEL onde o app funciona
- 62. GENERAL DISTRIBUTION Apps funcionando em Containers
- 63. GENERAL DISTRIBUTION Pods são as unidades de orquestração
- 64. GENERAL DISTRIBUTION O Master faz todo o controle
- 65. GENERAL DISTRIBUTION API de identificação
- 66. GENERAL DISTRIBUTION Estado valido e desejado
- 67. GENERAL DISTRIBUTION Integração com o container Registry
- 68. GENERAL DISTRIBUTION Orquestração e Agendamento
- 69. GENERAL DISTRIBUTION Inserção de políticas
- 70. GENERAL DISTRIBUTION Escalação de Pods
- 71. GENERAL DISTRIBUTION Serviços e Descovery
- 72. GENERAL DISTRIBUTION Dados persistentes dos containers
- 73. GENERAL DISTRIBUTION Roteamento e Load Balance Texto
- 74. GENERAL DISTRIBUTION Acesso via Web, CLI, IDE e API
- 75. GENERAL DISTRIBUTION INDÚSTRIA ESTÁ CONVERGINDO PARA KUBERNETES
- 76. GENERAL DISTRIBUTION A Solução Adotar uma estratégia de containers irá permitir que as aplicações sejam facilmente compartilhadas e implantadas.
- 77. GENERAL DISTRIBUTION Get Start! OPERAÇÕES DE TIDESENVOLVEDORES
- 78. GENERAL DISTRIBUTION Como? OPERAÇÕES DE TIDESENVOLVEDORES
- 79. GENERAL DISTRIBUTION A Solução Adotar uma estratégia de containers irá permitir que as aplicações sejam facilmente compartilhadas e implantadas.
- 80. GENERAL DISTRIBUTION A Solução Adotar uma estratégia de containers irá permitir que as aplicações sejam facilmente compartilhadas e implantadas.
- 81. GENERAL DISTRIBUTION A Solução Adotar uma estratégia de containers irá permitir que as aplicações sejam facilmente compartilhadas e implantadas.
- 82. GENERAL DISTRIBUTION A Solução Adotar uma estratégia de containers irá permitir que as aplicações sejam facilmente compartilhadas e implantadas.
- 83. GENERAL DISTRIBUTION A Solução Adotar uma estratégia de containers irá permitir que as aplicações sejam facilmente compartilhadas e implantadas.
- 84. GENERAL DISTRIBUTION A Solução Adotar uma estratégia de containers irá permitir que as aplicações sejam facilmente compartilhadas e implantadas.
- 85. GENERAL DISTRIBUTION A Solução Adotar uma estratégia de containers irá permitir que as aplicações sejam facilmente compartilhadas e implantadas.
- 86. GENERAL DISTRIBUTION A Solução Adotar uma estratégia de containers irá permitir que as aplicações sejam facilmente compartilhadas e implantadas.
- 87. GENERAL DISTRIBUTION A Solução Adotar uma estratégia de containers irá permitir que as aplicações sejam facilmente compartilhadas e implantadas.
- 88. GENERAL DISTRIBUTION88 A PLATAFORMA PARA DESENVOLVIMENTO Mobile AMQ Fuse 3scale API Mgmt Data Virt Data Grid BRMSEAP BPM Apps Integration Data Automation BARE METAL VIRTUAL Build | Deploy | Scheduling | Scaling | Elasticity | Metrics | Logging
- 89. GENERAL DISTRIBUTION89 INTEGRAÇÃO DOS MICROSERVICES Mobile AMQ Fuse 3scale API Mgmt Data Virt Data Grid BRMSEAP BPM Apps Integration Data Automation BARE METAL VIRTUAL Build | Deploy | Scheduling | Scaling | Elasticity | Metrics | Logging
- 90. GENERAL DISTRIBUTION $ docker build -t app:v1 .
- 91. GENERAL DISTRIBUTION $ docker build -t app:v1 .
- 92. GENERAL DISTRIBUTION Como o Ansible pode fazer parte da sua estartégia?
- 93. GENERAL DISTRIBUTION Como começamos esta jornada?
- 94. GENERAL DISTRIBUTION Os diferenciais do Ansible
- 95. GENERAL DISTRIBUTION As diferenças entre Ansible e Ansible Tower
- 96. GENERAL DISTRIBUTION Gerenciamento das Tarefas Serviços de Mensagens Auto Escaling e inventários Agendamento das Tarefas Execução remota Acesso e Segurança garantida Suporte e Desenvolvimento Global Visibilidade de tudo Principais Diferencias do Ansible Tower Trabalhando com DevOps Dashboard Integrado Criação de Playbooks automatizados
- 97. GENERAL DISTRIBUTION Como posso obter mais conhecimento?
- 98. GENERAL DISTRIBUTION Git Server Arquitetura inicial para seu projeto Usuário Camada de Código Ambiente existente na sua Infra Ansible Tower Worker Ansible Tower Base de Dados Camada do Ansible Tower Camada de Servidores Ambiente existente na sua Infra
- 101. GENERAL DISTRIBUTION Como aprender tudo isso?
- 102. powered by TT Obrigado!ANK YOU Caio Candido, caio.candido@dell.com https://www.linkedin.com/in/ccandido/
Notas do Editor
- Esta linha do tempo mostra como a Red Hat se tornou a fornecedora líder em soluções open source para a TI corporativa. Desde o primeiro lançamento do Red Hat Linux (e a fundação da empresa em 1993), a Red Hat vem expandindo seu portfólio de tecnologias. A Red Hat adquiriu várias empresas que contribuíram para a ampliação do nosso portfólio. Nós transformamos as tecnologias adquiridas em soluções corporativas open source o mais breve possível. Enquanto isso, nosso crescimento financeiro tem sido orgânico, o que significa que nosso negócio está crescendo de maneira natural, e não devido as nossas aquisições. Caso um cliente deseja acessar a lista de empresas que foram adquiridas pela Red Hat ao longo dos anos, um bom material de referência pode ser encontrado aqui:http://en.wikipedia.org/wiki/Red_Hat. Entre os anos de 2014-2016, a Red Hatadquiriu diversas empresas e tecnologiasque contribuíram para a ampliação do seu portfólio geral de soluções: Inktank, fornecedora de tecnologia de armazenamento em cloud baseado no projeto Ceph. eNovance, além de uma contribuidora significativa da comunidade de desenvolvimento do OpenStack, é também fornecedora de serviços de consultoria e implantação de cloud OpenStack. CentOS, integrada à Red Hat, fornecemos à organização do CentOS os fundos e os recursos necessários para sobreviver e trabalhar no desenvolvimento de novas soluções baseadas no Red Hat Enterprise Linux. FeedHenry, uma plataforma de aplicativos mobile corporativa da próxima geração, desenhada em torno de componentes open source. Essa plataforma baseada em cloud proporciona o desenvolvimento rápido e facilitado de aplicativos mobile capaz de conectar-se de forma segura aos sistemas corporativos existentes. Essa tecnologia oferece suporte ao desenvolvimento de aplicativos mobile, Mobile Backend-as-a-Service, gerenciamento de serviços mobile, segurança e autenticação, análises e relatórios, além de implantações on-premise e em cloud. Ansible, fornecedora de soluções de automação de TI. Essa solução tem como objetivo ajudar as empresas a avançar em direção a uma TI sem atritos. Com o Ansible, os clientes podem implantar e gerenciar aplicativos em clouds públicas e privadas, acelerar a entrega de serviços por meio de iniciativas de DevOps, simplificar atualizações e instalações OpenStack e acelerar a adoção de containers ao simplificar a configuração e orquestração. 3scale, fornecedora líder em tecnologia de gerenciamento de APIs. Ao adicionar a 3scale ao seu portfólio, a Red Hat fortalece sua capacitação de economia de API com arquiteturas baseadas em microsserviços e integração de cloud simplificada. Caso esteja faltando alguma informação importante, favor nos avisar que tentaremos adicioná-la na próxima versão.
- Este slide apresenta nosso processo em criar produtos a partir de software open source: Participação: apresenta o enorme ecossistema de projetos open source, muitos dos quais a Red Hat tem um papel de liderança no desenvolvimento (exemplos: Kernel Linux, KVM virtualization, OpenStack). Integração: a Red Hat patrocina e integra projetos open source em dois grandes projetos de consolidação: Fedora (a base do Red Hat Enterprise Linux) e a comunidade do JBoss Developer (a base do portfólio de soluções do Red Hat JBoss Middleware). Fornecendo, assim, ambientes gratuitos que são usados como laboratórios para o desenvolvimento de software e oferecendo fundamentos para os recursos que poderão ser incorporados nas soluções corporativas da Red Hat. A Red Hat é também o principal patrocinador de outros projetos de consolidação em cloud, armazenamento e virtualização. Este slide ilustra que o open source não é desenvolvido por um exército de voluntários (algo que poderia preocupar clientes em potencial). Mesmo projetos relativamente novos, como o OpenStack, são desenvolvidos pelos fornecedores de TI líderes globais. O desenvolvimento de soluções é altamente profissional. Voluntários e estudantes certamente têm um papel fundamental, e podem trazer contribuições vitais em áreas de pesquisa e tecnologias emergentes. No entanto, os recursos e capacidades corporativas não são controladas por eles. E isso se repete em cada projeto open source. Observe que o Red Hat Enterprise Linux, por exemplo, abrange um milhão de outros projetos, e a Red Hat é a maior contribuidora no desenvolvimento de vários destes, incluindo projetos como o Kernel Linux, KVM, SELinux, GCC, WildFly, Gluster, Ceph, GFS, etc. Essa combinação de desenvolvimento informal e profissional fornece um ambiente altamente dinâmico. Esse processo é tão eficiente que uma grande proporção de desenvolvimento de software dos dias atuais estão sendo baseados no modelo open source. Estabilidade: criação de soluções corporativas da Red Hat. Esta é muito mais que apenas uma coleção de projetos open source maduros e testados. Eles são integrados em soluções completas e prontas para empresas. Além de serem criados com um amplo suporte do ecossistema que inclui tudo, desde parceiros para dar suporte/manutenção até documentação, treinamento, serviços de consultoria, certificações de hardware e software, e outros. Esse completo ecossistema é o que nos difere da concorrência. É importante ressaltar que o trabalho de engenharia é realizado pela Red Hat por meio de extensivas atividades de garantia de qualidade (QA) e certificações de software e hardware.Manutenção a longo prazo é um recurso simples, porém importante. Caso um bug de segurança é descoberto em uma solução da Red Hat de 5 anos de uso, nossa equipe fornecerá uma correção para ele. Esta correção pode ser criada a partir da base de código da versão upstream ou desenvolvida do zero. E é isso que faz da Red Hat a solução ideal para implantações de longo prazo. Em contrapartida, muitos projetos open source da comunidade avançaram e hoje não há interesse pela comunidade em criar patches para softwares legados. Por exemplo, não há patches para versões antigas (com 5 anos ou mais) do Fedora ou outros projetos open source, como o Ubuntu. Os fornecedores de TI contribuem para o desenvolvimento de software open source em cada fase. Profissionais autônomos também podem contribuir. Enquanto o desenvolvimento compartilhado gera redução de custos, ele é também uma forma poderosa de garantir que novos recursos estejam alinhados com as necessidades atuais dos clientes.
- Due to deployment, configuration and integration inconsistency between applications, delivering an application into production is a non-trivial task with lots of friction and many back-and-forth cycles between Developers and IT Operations. Painful deployments leads to not only poor quality of the delivered service but also to a tendency to avoid the pain by deploying to production as seldom as possible. This in turn, results in larger deployments with more features being delivered at once and higher risk of things going wrong, which results in more pain, fewer deployments, … and story goes on.
- Due to deployment, configuration and integration inconsistency between applications, delivering an application into production is a non-trivial task with lots of friction and many back-and-forth cycles between Developers and IT Operations. Painful deployments leads to not only poor quality of the delivered service but also to a tendency to avoid the pain by deploying to production as seldom as possible. This in turn, results in larger deployments with more features being delivered at once and higher risk of things going wrong, which results in more pain, fewer deployments, … and story goes on.
- DevOps only took off when containers gained popularity and significantly simplified the automation that DevOps advocates. Containers provide consistent environment and tools for both Developers and Operations to package, delivery and manage the applications and therefore simplify the deployment process regardless of how the application looks like and the frameworks Developers have used to build the application. They also provide a common set of building blocks that can be reused in any stage of development to recreate identical environments for development, testing, staging, and production, extending the idea of write once; deploy anywhere
- Developers have different motivations and concerns than the IT Operations. Developer's job is to deliver a change and care about new frameworks, architectures and tools to do so, while IT Operations’ job is to bring stability and care about environment predictability, lifecycle management, security, costs and monitoring. As a result, applications are designed and developed in accordance to Developers mindset and Operations requirements are layered over it at later stages of delivery, leading to frustrating frictions specially in the end of each delivery cycle.
- <number>
- <number>
- <number>
- Community and vendor interest in Kubernetes is huge in the container market and many vendors have adopted Kubernetes within their platforms, sometimes at cost of replacing their own proprietary orchestration, as the standard container orchestration framework. Platforms Google: Container Engine Red Hat: OpenShift Engine Yard: Deis Intel: OpenStack on Kubernetes Apprenda: Apprenda Apcera: Apcera VMware: Photon Platform Walmart: OneOps Canonical: Kubernetes CoreOS: Tectonic Rancher: Rancher Mesosphere: Enterprise DC/OS Huawei: Cloud Container Engine Microsoft: Azure Container Service
- DevOps only took off when containers gained popularity and significantly simplified the automation that DevOps advocates. Containers provide consistent environment and tools for both Developers and Operations to package, delivery and manage the applications and therefore simplify the deployment process regardless of how the application looks like and the frameworks Developers have used to build the application. They also provide a common set of building blocks that can be reused in any stage of development to recreate identical environments for development, testing, staging, and production, extending the idea of write once; deploy anywhere
- Developers have different motivations and concerns than the IT Operations. Developer's job is to deliver a change and care about new frameworks, architectures and tools to do so, while IT Operations’ job is to bring stability and care about environment predictability, lifecycle management, security, costs and monitoring. As a result, applications are designed and developed in accordance to Developers mindset and Operations requirements are layered over it at later stages of delivery, leading to frustrating frictions specially in the end of each delivery cycle.
- Developers have different motivations and concerns than the IT Operations. Developer's job is to deliver a change and care about new frameworks, architectures and tools to do so, while IT Operations’ job is to bring stability and care about environment predictability, lifecycle management, security, costs and monitoring. As a result, applications are designed and developed in accordance to Developers mindset and Operations requirements are layered over it at later stages of delivery, leading to frustrating frictions specially in the end of each delivery cycle.
- DevOps only took off when containers gained popularity and significantly simplified the automation that DevOps advocates. Containers provide consistent environment and tools for both Developers and Operations to package, delivery and manage the applications and therefore simplify the deployment process regardless of how the application looks like and the frameworks Developers have used to build the application. They also provide a common set of building blocks that can be reused in any stage of development to recreate identical environments for development, testing, staging, and production, extending the idea of write once; deploy anywhere
- DevOps only took off when containers gained popularity and significantly simplified the automation that DevOps advocates. Containers provide consistent environment and tools for both Developers and Operations to package, delivery and manage the applications and therefore simplify the deployment process regardless of how the application looks like and the frameworks Developers have used to build the application. They also provide a common set of building blocks that can be reused in any stage of development to recreate identical environments for development, testing, staging, and production, extending the idea of write once; deploy anywhere
- DevOps only took off when containers gained popularity and significantly simplified the automation that DevOps advocates. Containers provide consistent environment and tools for both Developers and Operations to package, delivery and manage the applications and therefore simplify the deployment process regardless of how the application looks like and the frameworks Developers have used to build the application. They also provide a common set of building blocks that can be reused in any stage of development to recreate identical environments for development, testing, staging, and production, extending the idea of write once; deploy anywhere
- DevOps only took off when containers gained popularity and significantly simplified the automation that DevOps advocates. Containers provide consistent environment and tools for both Developers and Operations to package, delivery and manage the applications and therefore simplify the deployment process regardless of how the application looks like and the frameworks Developers have used to build the application. They also provide a common set of building blocks that can be reused in any stage of development to recreate identical environments for development, testing, staging, and production, extending the idea of write once; deploy anywhere
- DevOps only took off when containers gained popularity and significantly simplified the automation that DevOps advocates. Containers provide consistent environment and tools for both Developers and Operations to package, delivery and manage the applications and therefore simplify the deployment process regardless of how the application looks like and the frameworks Developers have used to build the application. They also provide a common set of building blocks that can be reused in any stage of development to recreate identical environments for development, testing, staging, and production, extending the idea of write once; deploy anywhere
- DevOps only took off when containers gained popularity and significantly simplified the automation that DevOps advocates. Containers provide consistent environment and tools for both Developers and Operations to package, delivery and manage the applications and therefore simplify the deployment process regardless of how the application looks like and the frameworks Developers have used to build the application. They also provide a common set of building blocks that can be reused in any stage of development to recreate identical environments for development, testing, staging, and production, extending the idea of write once; deploy anywhere
- DevOps only took off when containers gained popularity and significantly simplified the automation that DevOps advocates. Containers provide consistent environment and tools for both Developers and Operations to package, delivery and manage the applications and therefore simplify the deployment process regardless of how the application looks like and the frameworks Developers have used to build the application. They also provide a common set of building blocks that can be reused in any stage of development to recreate identical environments for development, testing, staging, and production, extending the idea of write once; deploy anywhere
- DevOps only took off when containers gained popularity and significantly simplified the automation that DevOps advocates. Containers provide consistent environment and tools for both Developers and Operations to package, delivery and manage the applications and therefore simplify the deployment process regardless of how the application looks like and the frameworks Developers have used to build the application. They also provide a common set of building blocks that can be reused in any stage of development to recreate identical environments for development, testing, staging, and production, extending the idea of write once; deploy anywhere
- DevOps only took off when containers gained popularity and significantly simplified the automation that DevOps advocates. Containers provide consistent environment and tools for both Developers and Operations to package, delivery and manage the applications and therefore simplify the deployment process regardless of how the application looks like and the frameworks Developers have used to build the application. They also provide a common set of building blocks that can be reused in any stage of development to recreate identical environments for development, testing, staging, and production, extending the idea of write once; deploy anywhere
- Going forward, we have seen that the market has shifted, and there is a new standard platform for Cloud Native Applications, but also can be leveraged for Modernized, Fast Monoliths. This new platform must run in the many public, private or hybrid clouds. It must use container as the fundamental building block to build, test, deploy, run and and scale microservices, and uses higher level Middleware Services to solve complex integration and data consistency problems related to this type of architecture. Red Hat has the complete picture, with our Platform and Infrastructure technologies of RHEL and OpenStack. OpenShift Container Platform that creates an abstraction layer between the many environments and clouds, and provide all fundamental tools for the container life cycle, including CI/CD, elasticity, metrics and security. JBoss Middleware and the OpenShift Application Runtimes provides all tools to build and integrate both legacy but also microservices applications. It brings the best developer experience for organizations that are moving beyond traditional Enterprise Java and embracing cloud-native application development, with full capabilities for: Microservices Agile Integration CI/CD Cloud Scale Fault tolerance Security & Compliance
- Going forward, we have seen that the market has shifted, and there is a new standard platform for Cloud Native Applications, but also can be leveraged for Modernized, Fast Monoliths. This new platform must run in the many public, private or hybrid clouds. It must use container as the fundamental building block to build, test, deploy, run and and scale microservices, and uses higher level Middleware Services to solve complex integration and data consistency problems related to this type of architecture. Red Hat has the complete picture, with our Platform and Infrastructure technologies of RHEL and OpenStack. OpenShift Container Platform that creates an abstraction layer between the many environments and clouds, and provide all fundamental tools for the container life cycle, including CI/CD, elasticity, metrics and security. JBoss Middleware and the OpenShift Application Runtimes provides all tools to build and integrate both legacy but also microservices applications. It brings the best developer experience for organizations that are moving beyond traditional Enterprise Java and embracing cloud-native application development, with full capabilities for: Microservices Agile Integration CI/CD Cloud Scale Fault tolerance Security & Compliance
- Packaging an application as a docker image is fairly simple. All needed is to create a file (Dockerfile) and describe what should the image contain and then run a single command to package the application as a docker image.
- Packaging an application as a docker image is fairly simple. All needed is to create a file (Dockerfile) and describe what should the image contain and then run a single command to package the application as a docker image.
- Running the image is also simple. A single command and the container process gets started on the host.
- Running the image is also simple. A single command and the container process gets started on the host.
- Running the image is also simple. A single command and the container process gets started on the host.
- Running the image is also simple. A single command and the container process gets started on the host.
- Many of the practices and values in DevOps aim at mitigating this problem. However despite the fact that DevOps was first introduced in 2009, it only gained popularity in the last two years. The reason for that was that implementing many of these practises proved to be extremely difficult using virtualization and other technologies which were available at the time.
- Developers have different motivations and concerns than the IT Operations. Developer's job is to deliver a change and care about new frameworks, architectures and tools to do so, while IT Operations’ job is to bring stability and care about environment predictability, lifecycle management, security, costs and monitoring. As a result, applications are designed and developed in accordance to Developers mindset and Operations requirements are layered over it at later stages of delivery, leading to frustrating frictions specially in the end of each delivery cycle.
- Due to deployment, configuration and integration inconsistency between applications, delivering an application into production is a non-trivial task with lots of friction and many back-and-forth cycles between Developers and IT Operations. Painful deployments leads to not only poor quality of the delivered service but also to a tendency to avoid the pain by deploying to production as seldom as possible. This in turn, results in larger deployments with more features being delivered at once and higher risk of things going wrong, which results in more pain, fewer deployments, … and story goes on.
- E falando em posições hierárquicas, a estrutura da organização provavelmente mudará para uma mais achatada com menos silos, que dê suporte a equipes de alta autonomia, em um ambiente favorável para criatividade, em que testar e falhar é visto como um caminho para aprender e melhorar. Isso será necessário para responder rapidamente a um ambiente sempre em mudança. Esta maneira de como se fazer as coisas é sobre o que é Agile. Sobre a arquitetura de aplicações temos o sistema tradicional de desenvolvimento de aplicações o “Monolitico”
- Red Hat Open Innovation Labs is a focused and intimate teaming engagement that helps companies accelerate innovation—by providing the people, processes, and technologies required to meet modern business challenges. It is a platform to help customers bring their innovative ideas to market—more quickly. Customers learn how to build and containerize applications on OpenShift, while working closely with Red Hat subject matter experts to understand and integrate DevOps approaches and methodologies to be able to accelerate innovation now and into the future. At the close of a Red Hat Open Innovation Labs engagement, you leave with the skills, and the community-powered tools and methodologies, to drive and sustain innovation. <number>
- Developers have different motivations and concerns than the IT Operations. Developer's job is to deliver a change and care about new frameworks, architectures and tools to do so, while IT Operations’ job is to bring stability and care about environment predictability, lifecycle management, security, costs and monitoring. As a result, applications are designed and developed in accordance to Developers mindset and Operations requirements are layered over it at later stages of delivery, leading to frustrating frictions specially in the end of each delivery cycle.