How do you change business processes and bring about a change within your organisation to take advantage of the pay as you go model? Organisations, People, Procurement Processes are all impacted by this model. This session will cover user cases on how some organisations have successfully transition their business to take advantage of the benefits of the Cloud.
Presenter: Glen Gore, Senior Manager, Solution Architects - APAC, Amazon Web Services
2. Building a cloud ready team
Glen Gore, Senior Manager, Solution Architects - APAC,
Amazon Web Services
3. The journey
IDC discovered that the five-year
total cost of ownership (TCO) of
developing, deploying, and
managing critical applications in
AWS delivered a 72% savings
when compared with deploying the
same resources on-premises or in
hosted environments. The findings
also showed a 626% ROI over five
years.
http://media.amazonwebservices.com/IDC_Business_Value_of_AWS_Accelerates_Over_time.pdf
4. What does this “IT Team” do today?
Activities
• Procure
• Architect / Design
• Implement
– Equipment rack and stack
– Software installation
– Configure hardware and software
– Test
• Operate
– Monitor
– Troubleshoot
– Optimize
– Upgrade
Characteristics
• Static
• Centralised control
• Enterprise wide rules
• Fixed capacity
• Non-disposable elements (pets)
• Hardware defined
• Multi-year deployment
• Minimum spend
• Technology silos
• Manual provisioning
5. “Cloud Ready”?
• Is it really different?
• Is it right for every application
or platform?
Provider of
Service
Broker of
Service
Enabler of
Service
6. Building a “Cloud Ready” IT Team
• Cultural changes
• Skills requirements
• Structures
7. Cultural Changes
• Focused vision & pace of urgency
• Curious and passionate people
• Ongoing iteration
• Software defined with leveraging of components
• New goals and KPIs.
8. Skills Requirements
Does the team have?
• Primary Skills
– Amazon Web Services
– Security
– Automation
– Integration
• Secondary Skills
– Performance
– TCO and Cost Optimization
9. Skills Requirements
Areas to engage with
• Security / Risk
• Change Management
• Operations
• IT and Finance Mgmt
10. Skills Requirements
Obtainment
• Hands on
• AWS Training
• Partners
• AWS Professional Services
• Secondment from previous teams
• Recruitment
12. Structures - attribute
Networks
Servers
Storage
Windows
Linux
Security
Develop
Deploy
Procure Operate
13. Structures - attribute
Networks
Storage
Servers
Windows
Linux
Security
Develop
Deploy
Operate
Procure
Virtualisation
collapsed a
core group into
a tighter team
with greater
interaction.
14. Structures - attribute
Networks
Storage
Servers
Deploy
Operate
Security
Develop
Procure
OS
Cloud Ready
collapses a
project group into
a single team
Application
Owner
15. Structures - attribute
• When a task cannot be partitioned because of
sequential constraints, the application of more effort
has no effect on the schedule.
• In tasks that can be partitioned but which required
communication among the subtasks, the effort of
communication must be added to the amount of
work to be done.
Brooks in The Mythical Man-Month
16. Structures - attribute
“If you can’t feed a team with
two pizzas, it’s too large.”
Jeff Bezos
20. Structures - Patterns
Tiger Teams
“a team of […] technical specialists, selected
for their experience, energy, and imagination,
and assigned to track down relentlessly every
possible source of failure in a spacecraft
subsystem.”
• Limited life
• Get it done
• Single
project
focused
21. Structures - Patterns
Continuous
Integration &
Continuous
Deployment
(CI/CD)
Networks
Storage
Servers
Develop
Security
Operate
Deploy
OS
Services
• Additional
focus on
delivering
ongoing
efficiency
& reduced
cycle times
22. Structures - Patterns
Dev/Ops
Networks
Storage
Servers
Develop
Security
Deploy Operate
OS
Services
• Additional
focus on long
term
operational
performance
23. Change in Characteristics
Existing
• Static
• Centralised control
• Enterprise wide rules
• Fixed capacity
• Non-disposable elements (pets)
• Hardware defined
• Multi-year deployment
• Minimum spend
• Technology silos
• Manual provisioning
Cloud Ready
• Elastic
• Business in control
• Application flexability
• No capacity constraints
• Disposable elements (cattle)
• Software defined
• Pay-per-use
• Pay-as-you-go
• DevOps
• CI/CD and API provisioning
24. Four take away items
• Impactful outcomes can be achieved
• Enabler by integrating IT further into the
business
• Team changes in skills and structure
• Measurement outcomes (goals and KPIs)
Editor's Notes
* Lastly, this can be hard stuff to achieve, but the benefits are great.
http://media.amazonwebservices.com/IDC_Business_Value_of_AWS_Accelerates_Over_time.pdf
Taking from good to GREAT.
* Implies there is something different
* This is true and false
* May not be about every application or platform in your business.
Its great where you have change, the more change the more you want this style of team.
Rate of change = rate of innovation.
So systems of record, maybe not, eg core banking or your backend system for an airline
But the systems that front those like your internet banking, checkin etc YOU WANT THIS.
* Provider of Service -> Broker of Service -> Enablers of Service.
* Business with a credit card is going direct.
* Speed and a pace of urgency. Successful teams move fast, make decisions and have a short time of realisation of outcome. They fail fast and succeed frequently. Disposable infrastructure leads to …
* People with an curiosity and passion. Staff that learn fast and that can accept then embrace change. The great people are those that lead the change, the change agents.
* An platforms "environment" is a fluid system and change. Rather than locked around 3 year procurement cycles the Cloud application and take on improvements frequently. New instance types, new services, new features, new techniques, new tools. "Continual course correction, over perfection". You don’t need Enterprise wide agreement and each application might take a different approach.
* It's all software defined, I can test everything, all the time.
* Leverage AWS features and services. Lockin is over-rated or may be
* Changing the goals, KPIs, different ways (contrast old and new)
Availability metrics focused, 99.999.
Look at the internet, it was designed because things fails. Werner, everything fails. Take that concept up the stack!
How fast can you recover, recoding lower level failures.
New metrics.
Days effort to make a change, if you can take it down from 3 to .5 that’s a massive change, especially if you are doing more! Frequency of change and hidden costs,
Fail and recover, how fast can you do this
AB testing for UX
User experience
Performance and resilience
* Utalisation of the environment (not something you would traditionally do)
* 99% uptime vs 99% of deployments successful
* Rollbacks
* …
Who are the actors that make up the IT teams today?
Virtualisation collapsed a number of these, but it was still potential isolated from many areas of the business and required communications in and out of that team.
Way beyond what we had with virtualisation
Next is the size of that collapse team.
Or if you want to say it in a more modern way, our founder said …
These are the patters we have seen.
It Service Catalog model is the least effective. Build it and why would they come?
Look back at those original characteristics.
Contrast how they look inside a Cloud Ready IT team.