Presentaion done at Devops Day Bologna 2018.
We talk about DevOps as Dev + Ops, and the evolution of this movement, mainly on the ops point of view.
We’ll arrive to today new paradigm “NoOps”, to try to answer a question: “Is this the end of the operations team ?”
2. DevOps Movement Evolution
Today we talk about
DevOps as Dev + Ops,
and the evolution of this
movement, mainly on the
ops point of view.
We’ll arrive to today new
paradigm “NoOps”, to try
to answer a question: “Is
this the end of the
operations team ?”
3. Disclaimer
We’ll show some of the tools, best practice and procedures we have used, or
heard of, in these years.
All the contents of this talk are the overcome of our experiences, the views and
opinions expressed in this presentation are those of the authors and do not
necessarily represent official policy of their company.
Any similarity to actual people or events is purely coincidental and unintentional.
4. Who are we
Riccardo Capecchi
● 1999 Aix System Administrator
● 2001 Linux System administrator
● 2006 Vmware administrator
● 2013 Puppet and git for configuration management
● 2014 Docker and Kubernetes
● 2016 Moving on Cloud with AWS as part of a Devops Team
● 2018 Using Faas on AWS Cloud
https://about.me/riccardocapecchi
5. Who are we
Piermarco Zerbini
● 2009 System Administrator
● 2013 System Administrator + devops methodology
● 2016 Moving on Cloud with AWS as part of a Devops Team
Worked with puppet, ansible, terraform, jenkins, docker
https://it.linkedin.com/in/piermarcozerbini
9. Developers life
From requirements to business
● Gather requirements from non
technical people
● time to market
○ the delivery day is always...
“yesterday”
10. Developers life
Software delivery
● IT department is a services’ provider
● The latest version of code and libraries are
required
○ system packages are “too old”
● Manual tests
● SCM as “backup server”
● Restricted access
○ “I can’t do it by myself and you should do it for me”
11. Sysadmin life: IT Infrastructure
Datacenter management
● Hardware setup
● Networks
● Bare metal and hypervisors
● Hands on partition tables and lvm
● Storage Server
● Backup/Disaster Recovery
● Law Compliance
13. Sysadmin life: Operations
Operations :)
● Bash
● cssh/parallel ssh
● network utilities
● Versioning configurations
○ cp apache.conf apache.conf_date
○ rsync data between environments
● Direct access to all servers and devices
○ cssh/parallel ssh
○ rdesktop
○ serial port
● Repetitive activities
● Sarcasm
14. Sysadmin life: do you remember ?
Operations - Deploy the code
● Tarball
● SCP/SFTP
● Backup
● Cross the fingers
● Deploy
15. Sysadmin life: do you remember ?
Operations - Deploy the code.. or not?
You don’t have to deploy if you are
developing like a PRO...duction :)
16. Sysadmin life: do you remember ?
Operations - To Analyze the logs
● all files only in local disks
○ disk is full
● raw logs, human parser
● compliant with laws?
● accessible only by sysadmins
● grep is the more advanced
tool
● Metrics ? Which metrics ?
17. Sysadmin life: do you remember ?
Operations - To Analyze Alerts
● Mail from:
○ Monitoring server
○ Crontab
○ Applications
○ Your boss
● Static thresholds
● Remember to put checks in
downtime before starting the
maintenance
● Any reactions to alerts?
● Pager by night
20. DevOps
Devops is
● Culture
● Lean
● Automation
● Measurement
● Sharing
Devops is not
● Tools
● A job position
● A new team
● A new name for an
old team
22. Cloud and Sysadmin Evolution
The Cloud
It could really change the work of a sysadmin:
● Cloud provider configuration
○ Security
○ IaC
● Capacity and Costing Review
● To avoid vendor lock-in ?
All the “not cool” stuff are still present:
● Alert
● Backup
● Logging
24. Serverless
Bare Metal
Deploy in days
Lives far too long
Virtualization
Deploy in hours
Lives for years
Docker
Deploy in seconds
Lives for days
Serverless
Deploy Instantly
Lives for seconds
25. From monolith to Functions
Are you really
“serverless ready”?
● sessions
● costs
● performances
26. Serverless means NoOps ?
“NoOps (no operations) is the concept that an IT environment can become so
automated and abstracted from the underlying infrastructure that there is no
need for a dedicated team to manage software in-house.”
http://searchcloudapplications.techtarget.com/definition/noops
28. Basic Serverless Service
A simple serverless
architecture
● Api gateway: Provides an
HTTP/S API endpoint that is
fully configurable.
● Lambda : Run whatever logic
is needed to answer the
request.
● You can choose your data
tier on aws with RDS, or
Dynamo
29. Serveless without DevOps approach
NO-OPS is great
● Developers will only focus on code
development
● The cloud provider will take care of all the
operations
30. Serveless without DevOps approach
NO-OPS is great… BUT...
● Someone has to ensure that issues are not introduced when the configurations are
changed.
● Someone needs to set all cloud provider configurations.
● Someone should handle the alerts
● Someone should manually deploy the code
● Who is that guy?
32. DevOps is useful - Real world Service
The real world
In the real world you’ll
probably have one or more
functions, but you’ll have
also to rely on other cloud
services, database and
external services.
33. DevOps is useful - to handle the code
Complexity
As Twin Tech Innovations pointed out: “For each
non-trivial route (piece of functionality) added to a
software system, the number of lines of
configuration code needed to maintain the project
grows at a steep linear rate when using a serverless
architecture.”
34. DevOps is useful - to handle the code
Serverless coding = more lines of code.
35. DevOps is useful - to handle the code
Serveless + DevOps:
● to automate
packaging
● to write your
code
dependencies
● to automate your
deployment
procedures
36. Serverless for Sysadmin
Serverless can also be a new tool for sysadmins, instead of use the old way
(Virtual Machine with cron) we can use functions to:
● Dynamically manage our Auto Scaling Group
● Dynamically manage our Security Group
● Improve checks
37. Serverless for Sysadmin - an example
An example of a FaaS useful for an “ops” team is the project auto-spotting
When installed and enabled on an existing on-demand AutoScaling group,
AutoSpotting clones one of your on-demand instances from the group with
a spot instance that is cheaper, at least as large (automatically considering
memory, CPU cores and disk volumes) and configured identically to it. Once
the new spot instance is ready, it is attached to the group and an
on-demand instance is detached and terminated to keep the group at
constant capacity.
38. Serverless for Sysadmin - an example
It continuously applies this process across all enabled groups from all regions gradually replacing
your on-demand instances with much cheaper spot instances. For your peace of mind, you can
also configure it to keep running a configurable number of on-demand instances given as
percentage or absolute number.
39. Conclusions
● DevOps is part of the company culture: it’s made by people of different
teams working together and, of course, with the agreement of the
managers. So it doesn’t matter if you choose serverless or another
technology.
● The DevOps best practices are useful to improve the value of your
code and the time-to-market
● The DevOps approach will help you to integrate your serverless
environment with legacy or external services
● The DevOps approach will provide to you a better no-ops