This presentation talks about how the Cloud and DevOps are complementary innovations that can work together to rapidly change the productivity inside organisations.
Learn how DevOps can maximise the value of your investment in the Cloud.
This is part 1 of a 3 part series from a joint DevOpsGuys / Microsoft event held at The Shard, London, 24th January 2017
2. 2
Welcome!
Schedule
9:00-9:30 Registration and Coffee
9:30-9:40 Introduction and Housekeeping
9:40-10:15 Steve Thair, How DevOps drives Cloud Productivity
Break
10:30-11:15 Ian Margetts, ASOS Business Acceleration
11:15-12:00 Jeff Johnson, Digital Transformation
12:00-12:30 Open Panel and Questions
3. www.devopsguys.com | Phone: 0800 368 7378 | e-mail: team@devopsguys.com | 2017
Maximising the value of Cloud
through DevOps
How DevOps drives Cloud Productivity
8. 8
0
100
200
300
400
500
600
1879 1889 1899 1909 1919 1929 1937 1948 1953
Productivity of Labour and Capital
Labour Capital
30 Year lag in Productivity
Growth
http://www.j-bradford-delong.net/Teaching_Folder/Econ_210c_spring_2002/Readings/Devine.pdf
9. Complementary Innovation
“Electricity is an example of a general purpose technology,
like the steam engine before it. General purpose
technologies drive most economic growth, because they
unleash cascades of complementary innovations, like
lightbulbs and, yes, factory redesign.” - Erik Brynjolfsson
https://www.brainyquote.com/quotes/quotes/e/erikbrynjo554741.html
10. 10
Devine, From Shafts to Wires
http://www.j-bradford-
delong.net/Teaching_Folder/Econ_210c_spring_2002/Readings/Devine.pdf
11. 11
Indirect benefits of ElectrificationIndirect benefits of Electrification Cloud + DevOps
• Redesigning factory layouts to be more efficient (e.g. aligned for flow).
• Better working environment (e.g. improved lighting)
• More Uptime (e.g. remove the line drive as single point of failure)
• Removal of power generating machinery resulted in:
• Risk reduction (Reduction of fire hazard)
• Free up space for other uses
• Greater control (e.g. Electric motors have fine grained control over speed)
• Lower operating costs (e.g. machinery not in use can be powered down)
• Move the factory to save costs or closer to consumers (i.e. no longer need
water and coal nearby)
http://www.scmfocus.com/scmhistory/2013/08/the-electrification-of-production-plants/#_ftn6
12. 12
0
100
200
300
400
500
600
1879 1889 1899 1909 1919 1929 1937 1948 1953
Productivity of Labour and Capital
Labour Capital
http://www.j-bradford-delong.net/Teaching_Folder/Econ_210c_spring_2002/Readings/Devine.pdf
0
100
200
300
400
500
600
1879 1889 1899 1909 1919 1929 1937 1948 1953
Productivity of Labour and Capital
Labour Capital
30 Year lag in Productivity
Growth
13. Consulting as value-add
In fact, the Detroit Edison Company, in 1905 lent motors
to manufacturers, and then performed the installation in
order to properly apply the motors. In essence, the power
company was providing consulting along with their
motors.” – Warren D. Devine, Jr. “From Shafts to Wires”
http://www.j-bradford-delong.net/Teaching_Folder/Econ_210c_spring_2002/Readings/Devine.pdf
14. 14
Maximise the value of Cloud via DevOps
Cloud is the new “general purpose technology”
Cloud DevOps Value
DevOps is the collection of “complementary innovations”
15. 15
People + Process + Technology
“Taken together, these results provide evidence that the
combination of computers and organizational structures
creates more value than the simple sum of their separate
contributions. The evidence is consistent with the
widespread perception among managers that IT is a
catalyst for a broad set of organizational changes.”
– Intangible Assets: Computers and Organizational Capital” (2002)
https://pdfs.semanticscholar.org/2dc8/8cefc5cbe795be8a326e2c5d1f98cc803f
5f.pdf
16. DevOps in 7 slides in 7 minutes
Just so we’re all on the same page about this DevOps
thing…
Start the clock!
17. 17
People, process and the right tools
working together to make your
product delivery lifecycle faster and
more predictable.
DevOps - Defined
29. 29
“A DevOps culture encourages experimentation within
multi-disciplinary product teams by promoting data-
driven decision making (The “Measurement” in CALMS) as
well as providing the tools to make experimentation fast
and cheap.”
– DevOpsGuys Whitepaper
DevOps Experimentation
31. 31
40
400
2500
0
500
1000
1500
2000
2500
3000
Traditional IT DevOps IaaS (legacy
app)
DevOps Cloud Native
Admin/Server Ratio
Admin/Server Ratio
Azure A0 Linux 1 core
0.75Gb Ram
20GB HDD
£0.0134/hr
Azure G5 Linux 32 Core
448.00 GB RAM
6,144 GB HDD
£7.4456/hr
Staff Cost ~ £40/hr
(£50K annual
salary)
DevOps Smashes the Server/Admin
Ratio Bottleneck
32. 32
About DevOpsGuys
• Founded 2013
• 50 Staff
• 30+ Clients
• £3m turnover FY16
• Headquartered in Cardiff, Wales
• Established as thought leaders in
DevOps
• Quoted by Gartner and Forrester in
research
• Microsoft customer advisory board for
DevOps
“DevOpsGuys are luminaries in the UK DevOps space.”
Gene Kim, Author – “The Phoenix Project”
This is what a steam-powered factory looked circa 1860.
This was called a line drive system - A huge, complicated apparatus of spindles, pulleys, belts and cams that drove the machinery on the shop floor, driven by a huge steam engine mounted on the floor above, driving a massive wheel that in turn drove all the other spindles.
This is what the steam engine upstairs looked like, driving that wheel.
Steam engines need water and coal – so that impacted where you could build your factory and how it was laid out.
You were generating your power locally – and you needed all that related infrastructure locally.
Because of the nature of the system you lost power the further you moved away from the main line drive –
It is estimated that the power loss across the shaft was normally more than 25%, and roughly 1/3 to 2/3s of the power created in the factory’s steam engine was consumed in the friction of turning the various shafts. [http://www.scmfocus.com/scmhistory/2013/08/the-electrification-of-production-plants/#_ftn5]
so as you can see everything was clustered together with very little space, it’s cramped, gloomy, dark etc
The line drive system was basically either on or off – you either powered the whole factor, or none of it, and control over the speed of the machines was limited to either on/off (by moving the drive belt to an idler cam) or by gearing with a fixed set of ratios (based on the diameter of the cam you switched on to).
And then in around 1880 or so these guys came along – Edison and Tesla, and then the Westinghouse Corporation started building electric powerplants, steam turbine electric power,
Electrification – the wonder of the modern age!
So what did the owners and managers of those factories do to take advantage of this modern wonder?
Yes – they replaced the big steam engine in the ceiling… with a big electric motor in the ceiling. And unsurprisingly… nothing much changed in the factory…
These owners and managers were trapped in a particularly mind-set and way of seeing the world – this was the “way things had always been done around here” and they didn’t see the need to change, or indeed see HOW they could change. Line drive systems were their comfort zone.
Perhaps some of you might know people like that today who are in their comfort zone? Any suggestions on who that might be?
Whilst there were some costs savings from electrification they were relatively minor (power generation was less than 3% of the total factory budget overall so even a large change in power costs could never really move the bar).
So whilst we say some productivity gains over the next 30 years we had to wait, partly for that generation of managers to retire and partly because we were waiting for the other shoe to drop – complementary innovations!
IN order to get the true benefit from general purpose technology you need complementary innovations to unlock the value…
During this period people realised that instead of having 1 big motor they would have lots of little motors… in fact, they could have a motor per machine. This was referred to as “unit drive” technology.
In fact, they could completely re-design the machines themselves to take advantage of the motors – they could evolve in tandem.
And, even more importantly, they could REDESIGN THE FACTORY ITSELF to take advantage of the fact they were no longer tied to shafts, pulleys and belts.
The could re-invent the factory, in the way today we are trying to re-invent the software factory.
We could seek to increase FLOW across the production line (in fact, this is what enabled Ford to invent the production line concept!)
Factory layout – aligning our software factory for the flow (along the DevOps pipeline)
Working environment – mastery, autonomy, purpose and belonging by changing the culture and product aligned multi-disciplinary teams
More uptime – remove SPOFs, distributed power and redundancy (in the cloud)
Removing the data centre – reduces risk (their datacentre is better than yours. Fact.) and you can use that DC for office space if it’s on premise!
Greater control – scale up, scale down, use the right instance type in a dynamic way
Lower operating costs – by matching capacity to demand, and turning off Dev/Test overnight.
Move the factory – use cloud regions to match your customer needs for speed, sovereignty etc.
So what do you think happens from 1919 onwards when all these complementary innovations in factory layout, product line flow, better machinery control etc etc all start to come together?
Yup – productivity explodes!
And that ‘s what we are starting to see with DevOps enabled organisations that are harnessing the power of the cloud – more releases, faster time to market, greater productivity.
As one last aside that I noticed in my research about electrification at the turn of the 20th century… consulting as value-add.
Other research backs up this need for complementary innovations – for organisational change to get the most out of the technology.
ONE of the major drivers for migrating the Cloud is the flexibility to scale up (and down) in order to meet customer demand or the growth of your company.
Whilst the capability for dynamic, “right-sizing” of cloud services is inherent in cloud hosting actually delivering on that promise needs both automation and a change of mindset.
That’s where DevOps comes in – DevOps automation techniques enable you to automatically scale your application “on-demand”, and a DevOps culture of collaboration between teams (silos) helps you manage this new, dynamic, environment effectively.
DevOps-powered cloud flexibility also has one other massive benefit – the cost-reduction that comes from “right-sizing” your hosting footprint compared to the over-provisioned approach traditionally found in old-school, static, private data-centres.
It’s the promise of this cost advantage that drives cloud adoption for many organisations but it won’t be realised without DevOps practices giving them the flexibility they need.
MANY organisations are afraid of migrating to the Cloud. They aren’t sure if their existing applications will work “in the cloud” and they don’t know where to get started on their Cloud journey.
A great way to reduce this risk is by using DevOps “Infrastructure as Code” techniques to create software-defined templates (models) of how you want your cloud services to be provisioned and configured.
This enables organisations to rapidly iterate through different server architectures to find the best fit for their needs.
For example, you might use:
Azure Resource Manager (ARM) templates to provision your environment (or an open-source tool like Hashicorp Terraform)
Powershell DSC to configure your server nodes (or other tools like Puppet, Chef or Ansible)
Visual Studio Team Services to build, test and deploy your code (or alternatively perhaps Teamcity and Octopus Deploy for a .Net app)
This ability to create re-usable templates for environments that can be tweaked, iterated and improved reduces the risk of cloud migration and reduces the barriers to adoption.
MANY organisations are constrained in their application development due to the having insufficient development and test environments to meet their team’s needs. Contention for Dev & Test environments, and poor configuration management of these environments, slows down the software development lifecycle and wastes thousands of person-hours a year.
DevOps practices enables the rapid deployment of short-lived Dev & Test environments in the Cloud, at a cost-effective price, which means each developer or team can have as many environments as they need, each with a known, stable configuration controlled by the “Infrastructure as Code” practices we discussed earlier.
This proliferation of Dev & Test environments drives Cloud adoption
KEY POINT – lowering the cost of experimentation and failure = FAIL CHEAP.
“I wonder if… xyz” – what’s it worth to be able to answer those questions quickly and easily?
“I wonder how our app scales to 1,000 nodes” – 1,000 A2 nodes (2 Core, 3.5Gb RAM, 60Gb) for 1 hour = £58.10
“FAIL Fast, Fail Early, Fail Often” is a mantra touted by organisations that are trying to bring innovative new ideas to the market.
Just as important is to “fail cheap” i.e. by reducing the cost of failure – the cost of experimentation – we can promote innovation and hopefully create that killer product for our customers.
A DevOps culture encourages experimentation within multi-disciplinary product teams by promoting data-driven decision making (The “Measurement” in CALMS) as well as providing the tools to make experimentation fast and cheap.
Cloud computing is a key part of changing that cost equation – organisations don’t have to provision expensive, capital-intensive, physical infrastructure – they can rent “on-demand” compute resources that are managed in a cost effective way via DevOps techniques. Decision-making can be improved by using Cloud PaaS data platforms like Azure SQL Databases with tools like PowerBI to make collecting, analysing and displaying business data faster and easier. Similarly, SaaS tools for operations like Application Insights and Operations Management Suite (OMS) provide the DevOps engineers the information they need to optimise the application.
As organisations embrace a culture of experimentation this drives more and more cloud adoption.
KEY Point – Allowing different teams to move at different rates – control their own destiny – Autonomy – You Build it, You run it.
KEY Point – Subscription management and cost control – devolving cost management and having a direct linkage to results/benefits per “product”
OFTEN a significant barrier to cloud adoption is the centralised IT Department itself. This might be for many reasons – lack of understanding of the technology, fear of a loss of control, lack of relevant skills etc. As an end-result of this slow adoption, “Shadow IT” is exploding in many organisations.
DevOps-enabled organisations shift responsibility and ownership of environments away from “traditional” (siloed) IT Departments towards the cross-functional Product teams, who are then empowered to leverage cloud services to optimise the delivery of their product portfolio.
As DevOps product teams bring new services to market many of them are focussing on creating “cloud native” applications that make use of new technology like containers (e.g. Azure ACS), “serverless computing” (e.g. Azure Functions) or machine learning (e.g. Cortana Intelligence Suite) to create exciting new solutions.
One additional benefit of “cloud-native” solutions that leverage PaaS and SaaS technologies is that those workloads are “sticky” to the cloud environment, and highly unlikely to ever be migrated back to an on-premises solution.
DEVOPS encourages Operations to take a different attitude towards server infrastructure – moving away from uniquely-configured “snowflake” servers towards automated, mass-produced, nameless servers. This is often referred to as treating your servers as “Cattle, not pets” – if a server is sick, just get rid of it and provision another, don’t waste time nursing it back to health.
This approach, powered by new DevOps automation tools, means that a given server administrator can now manage far more servers than before – from a rule of thumb of 40:1 ratio for physical servers to up to 400:1 to 2500:1 for large-scale cloud environments. Similarly, adopting a “microservices” software architecture pattern can increase the number of services (and servers) an administrator is expected to manage.
All of this drives cloud adoption , particularly when the relative economics (£0.012/hr for the smallest Azure A0 instance compared to ~£40/hr for a mid-level engineer on £50K/yr, a 3300x ratio) emphasise the human cost, not the server costs. Smashing the server/admin ratio is a key step is driving the cloud adoption return-on-investment.
G5 32 Core 448.00 GB RAM 6,144 GB Storage £7.4456/hr
We were co-founded by 2 experienced technologists, with a track record of delivering results at enterprise scale.