Transferir como KEY, PPTX
Carregado porThiago Ganzarolli
DevOps, NoOps...afinal que raios é isso?
DevOps, NoOps e NoOps são abordagens que promovem a integração entre desenvolvedores e operações, reduzindo conflitos e custos. DevOps envolve melhor comunicação entre times e profissionais multifuncionais. NoOps reduz a necessidade de administração de sistemas à medida que serviços são externalizados em nuvem.
![[DevOps Summit Brasil] Procura-se: DevOps!](https://cdn.slidesharecdn.com/ss_thumbnails/devopssummitbrasilprocura-sedevopsv1-160516050715-thumbnail.jpg?width=640&height=640&fit=bounds)
DevOps, NoOps...afinal que raios é isso?
- 1. DevOps, NoOps afinal que raios é isso?
- 5. Thiago Ganzarolli @tganzarolli http://github.com/tganzarolli
- 6.
- 7.
- 8.
- 9.
- 10.
- 11. Campinas São Paulo
- 30.
- 31.
- 34. Conflito: sysadmins vs developers
- 35.
- 36. “Funciona na minha máquina”
- 37. “Não é oservidor, é o código”
- 38. Parar de jogara culpa e focar no negócio
- 39. DevOps como conceito • É a filosofia ou abordagem cultural que promove a melhor comunicação entre os times de desenvolvimento e administração de sistemas.
- 40. DevOps como cargo • É o cargo do profissional que desempenha tanto o papel de desenvolvedor quanto o de administrador de sistema.
- 41. Para startups • Equipe reduzida • Time de elite e multifuncional • Recursos escassos • Necessidade de entregar valor muito rápido, de forma muito dinâmica (e barata)
- 42. Para grandes empresas • Mais agilidade • Menos burocracia • Redução de custos • Resolução de conflitos
- 43. Para Metodologias ágeis • XP • Scrum • Lean
- 44. Para Metodologias ágeis • XP • Scrum • Lean • DevOps
- 45. Para Metodologias ágeis • XP • Scrum • Lean • DevOps
- 46. Amadurecimento + mudança comportamental + tecnologia
- 47. “From an operationsstandpoint, the big story of the web isn’t the evolution toward full-fledged applications that run in the browser; it’s the growth from single servers to tens of servers to hundreds, to thousands, to (in the case of Google or Facebook) millions.When you’re running at that scale, fixing problems on the command line just isn’t an option” Mike Loukides, O’Reilly radar, What is DevOps
- 48. Distanciamento do hardware
- 49. Distanciamento do hardware
- 51.
- 52.
- 54. A tendência éver cada vez menos isso
- 55.
- 56. Infraestrutra torna-se código
- 57.
- 58.
- 59.
- 60.
- 61. Máquinas idênticas rodandoos mesmos serviços
- 62. Gerenciamento de configuração • Homogeinidade • Previsibilidade • Facilita escalabilidade • Confiança no ambiente
- 63. • Serve para máquinas dos desenvolvedores também (máquinas virtuais) • Sem ‘configurando o ambiente por uma semana’
- 64.
- 65. Existem mais ferramentas • Gerenciamento de configuração
- 66. Existem mais ferramentas • Gerenciamento de configuração • Automação de build / Integração contínua
- 67. Existem mais ferramentas • Gerenciamento de configuração • Automação de build / Integração contínua • One-click deploy
- 68. Existem mais ferramentas • Gerenciamento de configuração • Automação de build / Integração contínua • One-click deploy • Auto-scale e self-healing
- 69. Existem mais ferramentas • Gerenciamento de configuração • Automação de build / Integração contínua • One-click deploy • Auto-scale e self-healing • Métricas
- 70. Métricas • Monitorar • Tratar logs • Instrumentação • Detectar gargalos, bugs, falhas • Saber quando escalar • Post-mortem da equipe após crise
- 71. Ferramenta sem cultura não funciona!
- 72. DevOps com PaaSou NoOps
- 73. • Reduz a gerência de configuração • Tendência é cada vez menos tempo gasto com SysAdmin • Ainda preciso monitorar, ter integração contínua, etc... • DevOps on steroids
- 74. Preocupações externalizadas • Tolerância a falhas • Escalabilidade • Load balancing • Pode agregar váris outros addons • Precificação mais simples/visível
- 76. SaaS também alavanca NoOps
- 77. Analista de suporte? Github
- 78. O mercado eDevOps
- 83. A indústria eNoOps
- 89. • DNA técnico (cultura development from top down) • Referência em NoOps • Chaos monkey
- 90. O que críticosdizem • Operações ainda existem • As preocupações e atribuições são outras • SysAdmin ou DevOps irão operar em outro nível de abstração
- 91.
- 92. Bottom line • Operações ficando mais baratas e simples • Desenvolvedores e empresas tendo mais foco na aplicação
- 93. Cada empresa temseu nível de adoção • Cloud pode não ser pra todos • Assim como PaaS • ClickJogos gastaria na casa de milhões com tráfego na Amazon se não estivesse no UOL • Bancos jamais abrirão mão do controle
- 95. Compartilhe! Trocar experiências fazparte da cultura
- 96. Comunidade em formação • Open source • Github (social coding!) • StackOverflow e ServerFault • DevInSantos!
- 98.
Notas do Editor
- #2 6 começa\n
- #3 \n
- #4 \n
- #5 \n
- #6 \n
- #7 \n
- #8 \n
- #9 \n
- #10 \n
- #11 \n
- #12 \n
- #13 Atos, metodologias ágeis (mesmo que undercover), projetos paralelos. Rails, a nunvem, EncontreSeuPacote\n
- #14 Atos, metodologias ágeis (mesmo que undercover), projetos paralelos. Rails, a nunvem, EncontreSeuPacote\n
- #15 Atos, metodologias ágeis (mesmo que undercover), projetos paralelos. Rails, a nunvem, EncontreSeuPacote\n
- #16 Atos, metodologias ágeis (mesmo que undercover), projetos paralelos. Rails, a nunvem, EncontreSeuPacote\n
- #17 Atos, metodologias ágeis (mesmo que undercover), projetos paralelos. Rails, a nunvem, EncontreSeuPacote\n
- #18 Atos, metodologias ágeis (mesmo que undercover), projetos paralelos. Rails, a nunvem, EncontreSeuPacote\n
- #19 Apontador, programador poliglota, AWS, Business Model Canvas, concursos startup\n
- #20 Apontador, programador poliglota, AWS, Business Model Canvas, concursos startup\n
- #21 Apontador, programador poliglota, AWS, Business Model Canvas, concursos startup\n
- #22 Apontador, programador poliglota, AWS, Business Model Canvas, concursos startup\n
- #23 Apontador, programador poliglota, AWS, Business Model Canvas, concursos startup\n
- #24 \n
- #25 \n
- #26 \n
- #27 \n
- #28 \n
- #29 Sinergia, CEO entende de business, Leandro excelente design e usabilidade. Let’s go.\nNovos desafios.\nNão esqueça de falar um poquinho do modelo de negócios\n
- #30 6 até aqui\n
- #31 3 começa\n
- #32 Developer, desenvolvimento do produtoOperações, estabilidade, uptime, manutenção, performancefry\n
- #33 \n
- #34 \n
- #35 9\n
- #36 5 começa\n
- #37 Ou, numa grande empresa, quem coordena o processo entre as duas áreas\n
- #38 \n
- #39 \n
- #40 15 até aqui\n
- #41 15 até aqui\n
- #42 15 até aqui\n
- #43 15 até aqui\n
- #44 15 até aqui\n
- #45 7 começa\n
- #46 Óbvio que maiora das empresas não estará nessa escala, mas daí surgiram ferramentas e know how para a nuvem, e o que acontece..\n
- #47 \n
- #48 \n
- #49 \n
- #50 \n
- #51 Esse cara vai estar na Amazon, no Heroku, no Facebook ou será uma parte reduzida da equipe.\n
- #52 Esse cara vai estar na Amazon, no Heroku, no Facebook ou será uma parte reduzida da equipe.\n
- #53 \n
- #54 Mesmo que o SysAdmin não trabalhe na aplicação, ele tem que saber codar (programar!)\n
- #55 22 aqui\nPor a infraestrutura ser código, torna-se mais fácil o perfil híbrido, e a troca de área. Também força um dev a aprender sobre infra, e um sysadmin a dominar programação.\n
- #56 9 começa\n
- #57 \n
- #58 Mas: ferramentas não são nada sem cultura e comportamento. Além disso há outras formas de fazer, capistrano AWS AMI. \nAmazon pricing: complexo. Tem o calculator.\n\n
- #59 \n
- #60 Vagrant, Foreman\n
- #61 Releases frequentes, desde que se tenha confiança, diminuim muito o custo da mudança. Casar estabildade com mudança.\n
- #62 Releases frequentes, desde que se tenha confiança, diminuim muito o custo da mudança. Casar estabildade com mudança.\n
- #63 Releases frequentes, desde que se tenha confiança, diminuim muito o custo da mudança. Casar estabildade com mudança.\n
- #64 Releases frequentes, desde que se tenha confiança, diminuim muito o custo da mudança. Casar estabildade com mudança.\n
- #65 Releases frequentes, desde que se tenha confiança, diminuim muito o custo da mudança. Casar estabildade com mudança.\n
- #66 Releases frequentes, desde que se tenha confiança, diminuim muito o custo da mudança. Casar estabildade com mudança.\n
- #67 \n
- #68 \n
- #69 \n
- #70 Google App Engine, Heroku, AppFog\n
- #71 31 até aqui. Amazon AWS precificação complexa\n
- #72 3 começa aqui\n
- #73 Engraçado que SaaS e IaaS se desenvolveram antes, deixando PaaS no meio. E é um fato pouco reconhecido.\n
- #74 34 até aqui. O trabalho deste cara é configurar estes serviços na nuvem, e não instalar exchange, etc. Sem time de manutenção, sem hardware para instalação, sem ter que pedir que sua cota aumente de 50 mega pra 100 (2009), sem ter que comprar uma máquina IBM num antiquário (2006)\n
- #75 Teste\n
- #76 3 começa aqui\n
- #77 \n
- #78 Segurança! Requisitos não funcionais\n
- #79 \n
- #80 37 até aqui\n
- #81 2 pra indústria\n
- #82 AppFog\n
- #83 \n
- #84 \n
- #85 \n
- #86 39 até aqui\n
- #87 6 começa aqui\n
- #88 \n
- #89 \n
- #90 \n
- #91 45 até aqui\n
- #92 2 começa\n
- #93 \n
- #94 \n
- #95 \n
- #96 \n
- #97 52 fim\n