Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Operating Microservices

744 views

Published on

Video and slides synchronized, mp3 and slide download available at URLhttp://bit.ly/1ExFWai.

Michael Brunton-Spall shows how DevOps-like patterns can be applied on microservices to give the development teams more responsibility for their choices, and how monitoring, logging, auditing, security and other concerns can be managed in a distributed system. Filmed at qconlondon.com.

Michael Brunton-Spall is a technical architect working for the Government Digital Service, a service in the Cabinet Office of the UK Government. He works as a consulting architect with a variety of government departments, helping them understand and implement Agile, DevOps, service operation and modern web architectures.

Published in: Technology

Operating Microservices

  1. 1. Michael Brunton-Spall Technical Architect Government Digital Service @bruntonspall
  2. 2. InfoQ.com: News & Community Site • 750,000 unique visitors/month • Published in 4 languages (English, Chinese, Japanese and Brazilian Portuguese) • Post content from our QCon conferences • News 15-20 / week • Articles 3-4 / week • Presentations (videos) 12-15 / week • Interviews 2-3 / week • Books 1 / month Watch the video with slide synchronization on InfoQ.com! http://www.infoq.com/presentations /microservices-devops-patterns
  3. 3. Presented at QCon London www.qconlondon.com Purpose of QCon - to empower software development by facilitating the spread of knowledge and innovation Strategy - practitioner-driven conference designed for YOU: influencers of change and innovation in your teams - speakers and topics driving the evolution and innovation - connecting and catalyzing the influencers and innovators Highlights - attended by more than 12,000 delegates since 2007 - held in 9 cities worldwide
  4. 4. I'm a civil servant GDSMichael Brunton-Spall
  5. 5. GDSMichael Brunton-Spall
  6. 6. This isn’t the crown’s opinion on micro-services GDSMichael Brunton-Spall
  7. 7. Because everyone has an opinion GDSMichael Brunton-Spall
  8. 8. What am I not going to cover? GDSMichael Brunton-Spall
  9. 9. What are micro-services GDSMichael Brunton-Spall
  10. 10. How to develop them GDSMichael Brunton-Spall
  11. 11. Micro-service patterns GDSMichael Brunton-Spall
  12. 12. So what are micro-services? GDSMichael Brunton-Spall
  13. 13. Vertically aligned stacks that communicate via simple and standard interfaces GDSMichael Brunton-Spall
  14. 14. Ownership of data GDSMichael Brunton-Spall
  15. 15. Team ownership of code GDSMichael Brunton-Spall
  16. 16. Team ownership of code and runtime GDSMichael Brunton-Spall
  17. 17. Small is beautiful GDSMichael Brunton-Spall
  18. 18. Why are we all raving about them? GDSMichael Brunton-Spall
  19. 19. Because small owned systems can be updated more easily and frequently GDSMichael Brunton-Spall
  20. 20. Because teams can move fast and break stuff GDSMichael Brunton-Spall
  21. 21. Because teams can own the whole stack GDSMichael Brunton-Spall
  22. 22. So why do infrastructure teams hate them? GDSMichael Brunton-Spall
  23. 23. Because small owned systems can be updated more easily and frequently GDSMichael Brunton-Spall
  24. 24. Because teams can move fast and break stuff GDSMichael Brunton-Spall
  25. 25. Because teams can own the whole stack GDSMichael Brunton-Spall
  26. 26. “Microservices represent a new organisational model as much as a new architectural model” @JeffSussna GDSMichael Brunton-Spall
  27. 27. You (Engineering and Operations) exist purely for the benefit of the business GDSMichael Brunton-Spall
  28. 28. Micro-services can help you have a radical focus on delivering business value GDSMichael Brunton-Spall
  29. 29. The role of engineering and operations is changing GDSMichael Brunton-Spall
  30. 30. Operations is the constraint GDSMichael Brunton-Spall
  31. 31. Operations is perceived as the constraint GDSMichael Brunton-Spall
  32. 32. Micro-services in the small GDSMichael Brunton-Spall
  33. 33. How can we get started? GDSMichael Brunton-Spall
  34. 34. Start small GDSMichael Brunton-Spall
  35. 35. Automate infrastructure or containers GDSMichael Brunton-Spall
  36. 36. Base Image GDSMichael Brunton-Spall
  37. 37. Base Image = Ubuntu LTS GDSMichael Brunton-Spall
  38. 38. Base Image + Cloud Init GDSMichael Brunton-Spall
  39. 39. Cloud Init = "apt-get update; apt-get install xxx" GDSMichael Brunton-Spall
  40. 40. Base Image + Cloud Init + Deployed Application GDSMichael Brunton-Spall
  41. 41. Deployed Application = "wget URL_TO_JAR; java - jar application.jar" GDSMichael Brunton-Spall
  42. 42. Time to new server = 1-2 minutes GDSMichael Brunton-Spall
  43. 43. Why is this useful? GDSMichael Brunton-Spall
  44. 44. Developer stupidity should have a business impact GDSMichael Brunton-Spall
  45. 45. Monitoring tools that are easy to hook into GDSMichael Brunton-Spall
  46. 46. Developers can create a new metric and graph it GDSMichael Brunton-Spall
  47. 47. GDSMichael Brunton-Spall
  48. 48. "If it moves, graph it. If it doesn't move, graph it anyway just in case it does” @lozzd GDSMichael Brunton-Spall
  49. 49. Automate log aggregation GDSMichael Brunton-Spall
  50. 50. ElasticSearch, LogStash, Kibana GDSMichael Brunton-Spall
  51. 51. GDSMichael Brunton-Spall
  52. 52. Cloud-friendly databases GDSMichael Brunton-Spall
  53. 53. Automate deployments GDSMichael Brunton-Spall
  54. 54. GDSMichael Brunton-Spall
  55. 55. GDSMichael Brunton-Spall
  56. 56. GDSMichael Brunton-Spall
  57. 57. Hand the keys for deployment to developers GDSMichael Brunton-Spall
  58. 58. Keep logs of deploys GDSMichael Brunton-Spall
  59. 59. GDSMichael Brunton-Spall
  60. 60. (Graph them even!) GDSMichael Brunton-Spall
  61. 61. GDSMichael Brunton-Spall
  62. 62. Alerting GDSMichael Brunton-Spall
  63. 63. (Sensu Screenshot) GDSMichael Brunton-Spall
  64. 64. Give developers pagers too GDSMichael Brunton-Spall
  65. 65. Developers should be exposed to the pain they cause GDSMichael Brunton-Spall
  66. 66. Developers having root on their service? GDSMichael Brunton-Spall
  67. 67. "You break it, you fix it" GDSMichael Brunton-Spall
  68. 68. "You break it and cost £X million, you take the blame" GDSMichael Brunton-Spall
  69. 69. Automate Infrastructure Monitoring tools Log aggregation Databases Automated deployments Alerting GDSMichael Brunton-Spall
  70. 70. These are all solved problems GDSMichael Brunton-Spall
  71. 71. You are not *that* special GDSMichael Brunton-Spall
  72. 72. Most of what you do is wrapping libraries and other peoples code GDSMichael Brunton-Spall
  73. 73. Pareto principle GDSMichael Brunton-Spall
  74. 74. You now have a single, well supported micro service GDSMichael Brunton-Spall
  75. 75. Microservices in the large GDSMichael Brunton-Spall
  76. 76. Microservices are going to fail in more spectacular ways than equivalent monoliths GDSMichael Brunton-Spall
  77. 77. Simple GDSMichael Brunton-Spall
  78. 78. Simple Complicated GDSMichael Brunton-Spall
  79. 79. Simple Complicated Complex GDSMichael Brunton-Spall
  80. 80. Diagnosis tools GDSMichael Brunton-Spall
  81. 81. Someone will have to do diagnosis across all the services GDSMichael Brunton-Spall
  82. 82. How are services monitored? GDSMichael Brunton-Spall
  83. 83. Shallow Check - Is my service working GDSMichael Brunton-Spall
  84. 84. Deep check - Are my dependencies working? GDSMichael Brunton-Spall
  85. 85. Average response time isn't enough GDSMichael Brunton-Spall
  86. 86. 90%, 95%, 99% as well GDSMichael Brunton-Spall
  87. 87. Distributed systems need to embrace failure GDSMichael Brunton-Spall
  88. 88. Partitions are network breaks and latency spikes GDSMichael Brunton-Spall
  89. 89. Timeouts are tricky, use with care GDSMichael Brunton-Spall
  90. 90. Standardise admin interfaces GDSMichael Brunton-Spall
  91. 91. Alerting tools GDSMichael Brunton-Spall
  92. 92. If citizens can’t submit a claim at 1am because the mainframe is down, who’s problem is that? GDSMichael Brunton-Spall
  93. 93. You still need 1st line support and triage GDSMichael Brunton-Spall
  94. 94. What about when the developers get bored? (They do that!) GDSMichael Brunton-Spall
  95. 95. Maturity model for support? GDSMichael Brunton-Spall
  96. 96. System must have < N faults in M weeks and complete run book to be handed off GDSMichael Brunton-Spall
  97. 97. Systems that have more than N faults in M weeks get handed back GDSMichael Brunton-Spall
  98. 98. Who pays for this support? GDSMichael Brunton-Spall
  99. 99. Operations teams should act like consultants GDSMichael Brunton-Spall
  100. 100. "You want an elastic search cluster, sure we'll help you …” GDSMichael Brunton-Spall
  101. 101. "... if we can document and automate it (+20% effort)" GDSMichael Brunton-Spall
  102. 102. Pioneers pay the cost GDSMichael Brunton-Spall
  103. 103. Settlers pave the roads behind GDSMichael Brunton-Spall
  104. 104. Everyone else follows GDSMichael Brunton-Spall
  105. 105. Don't forget to keep the lights on at the monolith GDSMichael Brunton-Spall
  106. 106. Michael Brunton-Spall Technical Architect Government Digital Service @bruntonspall
  107. 107. Watch the video with slide synchronization on InfoQ.com! http://www.infoq.com/presentations/ microservices-devops-patterns

×