10 Years of DevOps: What Has Changed
•Download as PPTX, PDF•
0 likes•28 views
DevOps practices have evolved over the past 10 years to help reduce the time between committing code changes and deploying to production while maintaining high quality. Key changes include treating infrastructure as code, enabling continuous delivery of changes, adopting cloud-native approaches, and ensuring DevOps culture and tooling work together to empower development and operations teams.
Recommended
Recommended
More Related Content
What's hot
Recently uploaded
Recently uploaded (20)
10 Years of DevOps: What Has Changed
- 1. Ten years of DevOps What changed? Oleksii Dzhulai, Director, Technology Solutions
- 2. About the speaker • Systems Architect • Open Source Enthusiast • Director, Technology Solutions, EPAM Ukraine @odzhu
- 3. “DevOps is a set of practices intended to reduce the time between committing a change to a system and the change being placed into normal production, while ensuring high quality” Len Bass DevOps: A Software Architect's Perspective @odzhu
- 4. Infrastructure as CodeInfrastructure is Code @odzhu
- 9. Culture or Tooling ?Culture and Tooling ! @odzhu
Editor's Notes
- Many books and articles .. I like the most the short one DevOps first mentioned and came from world of web giants like Google, Amazon 10 years ago.
- Что такой управление инфраструктурой Относят Конфигурация хардваре Настройка сети и систем хранения данных Конфигурация и настройка платформ, гипервизоров и уровня операционной системы, управление обновлениями и т д Настройки безопасности {Характеристики инфраструктуры для содействия DevOps целям? (Озвучить их быстро) Конфигурация должна быть повторяемой Конфигурация должна быть известной Configuration management на стороне инфра должен быть согласован протестированы на уровне приложений, для каждого изменения. Безопасной, прозрачной. Infrastructure as Code - Набор инструментов Old good Cfengine , Puppet 2006, Chef 2009 - Инструменте использовались в изоляции инфраструктурными командами и никак не согласовывались с апликейшн пайплайнами. - Не редко можно было увидеть одновременно автоматизированный и ручной метод configuration management, snowflake server No AWS Cloud formation 2011 No TF 2014 No chef supermarket or terraform registry If you wanted to automate you at best got preprovisioned VMs and had to write scripts, cookbooks mostly from scratch. Сильная изоляция инфраструктурных команд от разработчиков. Что у нас есть сегодня ? Is Code Infrastrucure via pipelines Terraform, Chef, rspec, testkitchen SDN, SDS Dynamic/disposable environments Change to infra trigger app quality gates Clouds Scrum команда также отвечает частично за инфраструктуру.
- CD – очень комплексный задача В добавок к опытной и слаженной команде CD подразумевает автоматизацию всех фаз включая, код ревью, билд , квалити гейтов , деплоймента. Оглядываясь назад можно сказать что пайпланы были намного проще и времени на их построение уходило намного больше, ) В те годы “continuous” delivery выглядел так: Ночные сборки по расписанию и следовательно сложный процесс исправление проблем интеграции. Не одинаковая конфигурация инваронментов в следствие ручных правок либо не согласованного configuration management Manual testing steps Отсутствие систем диплоймента и оркестрации, следовательно ненадежный и долгий диплоймент по инструкции либо в лучшем случае с помощью configuration management систем. Continuous deployment вообще rocket science: автосатизация лоад балансеров, версионирование баз данных и дисковых данных Сегодня у нас есть : Managed CI/CD platforms: Azure DevOps, Code Build, Codedeploy, Pipeline as code, plugins and integrations PaaS: app engine, beanstalk, service mesh Containers and orchestrators. FlyWayDB, Liquybase Knative, Spinnaker дают нам возможность практически получить CD OOB
- Cloud Его появление совпадает с развитием двопс и он один из основных двигателей В 2008 клауд был новинкой, дорогим и уделом смелых стартапов которые не были готовы капитально инвестировать в инфраструктуру. Сегодня страх крупных предприятий сменяется Multi-Cloud, Hybrid и Claud First стратегиями. Помимо традиционных ценностей таких как scaling, эластичность и high availability клауд дает: 100% автоматизации Disposable environments прозрачность Managed services Built-in experience and best practices Сегодня деливери команда может полностью автоматизировать и контролировать свой енваронмент включая слои инфраструктуры!
- Можем ли мы сказать что Enterprise готов для DevOps? В каждом случае ответ будет разным и зависит от уровня зрелости среды и культуры. Но абсолютно точно можно сказать что сегодня DevOps является проверенной методологии по оптимизации деливери в IT. Мы видим, что понимание методологий DevOps и опыт роботы c автоматизацией – стал критическим навыком для любого проекта и всюду востребован. Мы видим как эволюция продолжается и передовые компании активно развивают Claud Native технологии, в результате CNCF за 3 года вырос до 600 проектов и сейчас это самая быстро растущая область опенсорса. Появляются новые фреймворки, инструменты которые позволяют сделать деливери более эффективным.
- В последнее время есть мнение что с развитием serverless технологий потребность в operations пропадает Или что полна автоматизация в клауде в последствии не требует оперейшена. Это не так ) Но никто никто не отменял непредвиденного увеличения или характера трафика, секьюрити инцидентов, вопросов мониторинга и оптимизации. В ходе улучшения автоматизации фокус DevOps комманды смещается в сторону проактивного улучшения вместо тушения пожаров. Также поскольку сегодня у производителей софта есть возможность автоматизировать всю платформы начиная инфраструктурой и заканчивая кенери деплойментом апликейшена. Диплоймент пекедж может быть расширен operational знаниеми и автоматизацией, таким образом системма сама может мониторить корректировать свою работу и востонавливатся в случае сбоя. Ярким примером данной концепции является CoreOS Operator framework для Kubernetes
- Использование PaaS или пол авт pipeline не означает что мы практикуем девопс Автоматизация больших монолитов конечно дает выгоды хотя мы все равно вынужденны выполнять сложную координацию релизов с низкой скоростью и качеством. Культурные измененния необходимы для переосмысление старых способов работы и улучшений. В тот же самый момент непрвильно недооценивать инструментарий по отношению к культуре ипроцессу Делать что то постоянно, быстро и надежно требует исключения человека из цепочки. Девопс это об автоматизации и переиспользовании опыта в том числе и через инструментарий. Культура или инструменты, нельзя что то выбросить нам нужно и то и другое!