6. Improve Deployments
Here are some common things that DevOps
teams do to improve software releases:
• Increase efficiency – less waste
• Decrease time to commit software changes
• Automate tests
• Identify defects/issues quickly
• Automate the build process
• Simplify the deployment process
• Make deployments reproducible
• Automate as much as possible
8. Principles of Continuous Integration
• Maintain a code repository
• Automate the build
• Make the build self-testing
• Everyone commits to the baseline every day
• Every commit (to baseline) should be built
• Keep the build fast
• Test in a clone of the production environment (ElasticBox)
• Make it easy to get the latest deliverables
• Everyone can see the results of the latest build
• Facilitate automated deployments
9. How CI Improves Efficiency
• Simplify Merges
• Rapid Feedback
• Identify problems early
• Makes bugs easier to find
• Reduce bug accumulation
• Visibility (team and stakeholders)
• Builds Automated
• minimizes manual intervention
• plug-ins (i.e. for static code analysis, gathering metrics)
• Precursor to Continuous Delivery & Deployment
11. Keys to Continuous Delivery
• Process should be automated
• Reduces the number of features introduced per release,
minimizing shock to users
• Will reduce the standard release cycle
• Changes approach to releasing software from an event to a
non-event
• Helps to avoid off-hour, high risk, expensive deployments
• Know your rollback plan (do you rollback or roll forward only)
• Build in health checks
14. The Reality Check –
IT does not enable the business, it is the business
Global executives believe
innovation is extremely
important to their growth
strategies
84%
Are unsatisfied
with their
innovation
performance
94%
15. Business Places Strict Demands of IT – Is IT Ready?
CIO
• Risk
• Capex vs.
Opex
Agility Efficiency
• Stability
• QoS
Innovation
Development
•Speed
Operations
Innovation
Efficiency
Agility
16. Is PaaS the holy grail?
• Agility
• Simplicity
• Enable
innovation
Platform-as-a-Service
Today, less than 5% of business Applications run on PaaS
• Vendor Lock-In
• Immature
• Not enterprise-ready
PaaS is a journey…
…you need an actionable path TODAY to enable
innovation in the face of constant change.
17. Application evolution
Yesterday
•Waterfall development
•Weeks to provision
•Static resources
•Limited change windows
•$100k+ of compute
•Limited number of users, in
business hours
Tomorrow
•Agile development
•Continuous deployment
•Dynamic resourcing
•Spans across data centers
and clouds
•Friction of compute costs
•Millions of users with 24x7
access
Web Server
App Server
Database
End Users Internet/Firewall Lan/network Web front-end Services Middleware
Private
Public
Public
Web
Server
Message Q
Database
In Memory
Cache
App
Server
App
Server
18. How to get there – Cloud is driving innovation
“Respondents are satisfied that
virtualization is reducing data
center floor space, energy cost
and thermal output. However,
expectations for an overall
reduction in hardware capital
expenditure and increased
application deployment speed
and efficiency have not been
fully met”
Cloud is accelerating innovation—The number of Applications moving to IaaS is more
than doubling each year.
19. The “Cloud operating model” enabling efficiency and agility
App release, Performance,
Availability, Usage, Cost,
Cloud Ops
(Infra Ops)
Infrastructure Performance,
Capacity, Config, Security
Storage
NW
Storage
NW
Private Public
App Ops
Compute Compute
Infrastructure
Service Health and
Cost
Utilization and
App Visibility
20. Dev Ops
DevOps is a response to the interdependence of
software development and IT operations.
Result of organizations that could not tolerate the
ramifications of two camps with different MBOs
Development Operations
-Production
-Handoff
-Package
-Test
-Deploy
-Stage
-Package
-Build
-Code
-Design
-Requirements
DevOps
21. Aligned IT
Development
Delivering Innovation
Enabling Innovation
Operations
CIO
Managing Innovation
• Innovation
• Change
•Risk
•Capex vs. Opex
• Stability
• QoA
Agility
Innovation
Efficiency
22. Traditional Deployment & Configuration Tools Break in the Cloud
Complex and time consuming
• Bottom up thinking
• Vertical and static approach
• On going management is procedural and
reactive
Proliferation of IT assets
• Lack of standardization increases
permutations of software components
Not cloud aware
• Each deployment plan is tied to a specific
infrastructure service
Configure
MW
Deploy MW
Configure OS
Deploy OS
OS
OS
OS OS
OS
23. Immutable Application Management – New approach
IT Developers
“Write code, not tickets”
Boost application
• Friction-free deployment
• Latest high productivity frameworks
• Choice of application services
• Platform Agnostic (You don’t see)
velocity
IT Operations
“IT as a service provider”
•More responsive to developers
•Elastic and dynamically scalable
•Change aware
•Digest future cloud advances
24. My take a NEW Engineering Team’s perspective on the Cloud
25. A fresh look at today’s Application Landscape
Written in diverse frameworks and languages
Traditional (Java, .Net) and Modern Frameworks
Developed with ‘agile’ or ‘iterative’ methodologies
Apps released early and often
Deployed on virtual and cloud infrastructure
Span across Private, Public and Hybrid Clouds
Private Clouds
Public/Private/H
ybrid Cloud
Public Clouds
26. Enabling the lifecycle for any app, anywhere
ANY type of app
Provision
Secure
Monitor
Update
Public
Private
Custom IaaS
PaaS
Custom PaaS
27. Impact of Cloud and DevOps, on the Provisioning Process
Traditional app provisioning
4 days to
8 weeks
Setup Infrastructure
• Configure N/w and
Storage
• Deploy and Configure OS
Setup Application
Middleware
• Deploy and configure
application middleware
• Connect it to Database
Deploy
Application
• Development
• Test
• Production
What app provisioning should be …
Minutes
An application architect uses a self-serve application provisioning portal to
fully provision & update applications across Amazon Web Services by calling
the necessary APIs – Such As Cloud Formation
28. Impact of Cloud and DevOps, on Monitoring and Maintenance
Process
Traditional app monitoring/updates
Deploy Monitor
Trouble
shoot
War
room
Guess?
Fix
False
start
Update
Time Accuracy
What app monitoring/updates should be…
Optimize
Build Deploy Monitor
Continuous, factual data about application performance
Time Accuracy
29. A Model Driven Approach to Application Provisioning
Catalog of
Application
Services (Cloud Formation
And Boxes)
Web
Server
Applicatio
n Server
Messagin
g
In-memory
database
OS
OS
OS
DB
OS
Application Blueprint
Deployment
Profiles
Test
Prod
Deployments
Dev
30. Collaborative Platform for various roles
Application Blueprint
Architect
Cloud Admin
Deployment
Profile
(dev)
Application Binaries
Application Stack - (Middleware, OS)
Deployment
Profile
(test)
App Dev, QA,
Release
Public
AWS
Private
AWS Cloud
EC2
Logical Application Topology with
Application Policies, Configurations
Pre-instrumented with App Monitoring
Standardized configurations of OS,
Middleware and Databases
Box Catalog
Deployment
Profile
(prod)
Standardized Configuration = ElasticBox Delivers Continues Deployment and Standards
across App Environments
31. Ongoing Updates : Model driven App Management
Application Blueprint
Application Binaries
Application Stack - (Middleware, OS)
Update
Profile
Make a change – code,
config, scale-out
Deployment
Change
ChanCgheange
Change
Change
Deployment
Analyze impact & auto-generate flow with
dependencies
32. Performance Monitoring
OS
OS
OS
OS
OS
Application Health
Application Infrastructure
Monitors
infrastructure/middleware
Collects thousands of metrics
across all tiers – web, app,
messaging, DB.
Code
Instruments the application
code to easily detect “bad code”
that impacts application
performance
Avg Hits/Minute,
Avg Latency, Errors
Avg Network
Latency
Queue Size,
Enqueue Count
Thread Pool, JDBC
Pool, Number of JVM
Servlets, beans
Code latency
Network Transactions
Automatically traces transactions
Measures transaction times –
Latency, Usage, and Throughput
What is DevOps?
In traditional organizations, there are separate and distinct groups for development and operations.
The development team is responsible for writing code and delivering software.
The Ops team is responsible for deploying releases, managing systems, security and environment stability.
DevOps is a philosophy to bring Dev and Ops (and QA too) together to improve the overall development, deployment and management process.
** Why would you want to embrace DevOps?
So, why DevOps?
DevOps breaks down communication barriers between Ops and Dev.
It promotes collaboration to solve problems experienced by both teams. The primary focus is on efficiency and reducing risk when building and deploying software.
Avoid scenarios like, “Sorry the deployment failed. We didn’t test on that platform.”
** Let’s take a look at some metrics showing potential benefits of DevOps.
This comparison highlights a few interesting things:
DevOps teams spend less time fighting fires, handling support issues and tied up in meetings than traditional IT groups.
They also spend more time doing positive things: infrastructure improvements and self-improvement.
Another metric not on the chart showed that on average DevOps teams worked late only 1.5 days/week compared to 2.3 in traditional organizations.
** Let’s drill down into the potential benefits when releasing software.
One of the ultimate goals of DevOps teams is to streamline the software release process using automation.
This slide highlights the amount of time that traditional and DevOps teams take to deploy a new release.
As you can see, on average, the DevOps oriented teams are able to release approximately 43% faster – 36 minutes per release vs. 85 for traditional IT teams.
* What are some common things that DevOps teams do to improve deployments?
Here are some common things that DevOps teams do to improve software releases:
Increase efficiency – less waste
Decrease time to commit software changes
Automate tests
Identify defects/issues quickly
Automate the build process
Simplify the deployment process
Make deployments reproducible
Automate as much as possible
Continuous integration is the frequent merging of work with a main branch to simplify the merging process and test updates when integrated.
The concept usually involves a unit testing framework and a process to trigger builds and/or tests.
Here are some principles of continuous integration:
Maintain a code repository
Automate the build
Make the build self-testing
Everyone commits to the baseline every day
Every commit (to baseline) should be built
Keep the build fast
Test in a clone of the production environment
Make it easy to get the latest deliverables
Everyone can see the results of the latest build
Facilitate automated deployments
** Can these principles help us improve?
How Continuous Integration Improves Efficiency:
Simplify Merges
Rapid Feedback
Identify problems early
Makes bugs easier to find
Reduce bug accumulation
Visibility (team and stakeholders)
Builds Automated
minimizes manual intervention
plug-ins (i.e. for static code analysis, gathering metrics)
Precursor to Continuous Delivery & Deployment
And building on Continuous Integration, are the concepts of Continuous Delivery and Deployment.
Continuous Delivery is a software development discipline where you build software in such a way that the software can be released to production at any time.
Continuous Deployment is where every change goes through a pipeline and automatically gets put into production, possibly resulting in many production deployments every day.
Continuous Delivery means that you are able to do frequent deployments but may choose not to.
In order to do Continuous Deployment you must be doing Continuous Delivery.
** Let’s take a look at some of the key concepts for CD.
Keys to Continous Delivery:
Should be automated
Reduces the number of features introduced per release, minimizing shock to users
Will reduce the standard release cycle
Changes approach to releasing software from an event to a non-event
Helps to avoid off-hour, high risk, expensive deployments
Know your rollback plan (do you rollback or roll forward only)
Build in health checks
** What if the software has a data dependency?
One of the hurdles to implementing continuous delivery is data management.
A plan must be in place to identify the appropriate, low-risk approach to deploying changes around systems reliant on a data store (i.e. databases).
For instance, possibly add an automated step to create a backup of the data as part of the release/upgrade process.
Changes should be managed as software as much as possible. Tools are available to help implement and manage a solution – Flyway & Liquibase.
** Speaking of tools here are a few tools to help with CI and CD.
Here are some CI/CD tools:
Version control systems such as: git and Subversion
Automated build tools such as: Jenkins, Bamboo and CruiseControl
Infrastructure as code tools such as: Chef and Puppet
Log management/monitoring tools such as: Splunk and Logstash
System monitoring tools such as: Nagios and Ganglia
** Let’s transition to logistics and problem-solving.
This presentation will attempt to pull together and relate sessions on the following topics:
DevOps, continuous delivery/deployment and methods for improving your work space, problem-solving skills and overall health.
