Building a "Cloud Ready" IT Team
•
2 likes•1,213 views
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
Recommended
Recommended
More Related Content
What's hot
What's hot (20)
Viewers also liked
Viewers also liked (20)
Similar to Building a "Cloud Ready" IT Team
Similar to Building a "Cloud Ready" IT Team (20)
More from Amazon Web Services
More from Amazon Web Services (20)
Recently uploaded
Recently uploaded (20)
Building a "Cloud Ready" IT Team
- 1. Bangalore
- 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
- 18. Structures - Patterns Shadow IT ?
- 19. Structures - Patterns IT Service Catalog ITaaS
- 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.
- Here are the four things you want to remember.