Diese Präsentation wurde erfolgreich gemeldet.
Wir verwenden Ihre LinkedIn Profilangaben und Informationen zu Ihren Aktivitäten, um Anzeigen zu personalisieren und Ihnen relevantere Inhalte anzuzeigen. Sie können Ihre Anzeigeneinstellungen jederzeit ändern.

Monoliths, Balls of Mud and Silver Bullets

A talk from the European Perl Conference 2019 (but not about Perl)

  • Loggen Sie sich ein, um Kommentare anzuzeigen.

  • Gehören Sie zu den Ersten, denen das gefällt!

Monoliths, Balls of Mud and Silver Bullets

  1. 1. Monoliths, Balls of Mud & Silver Bullets
  2. 2. Monoliths are bad
  3. 3. Monolithic Balls of Mud are worse
  4. 4. Microservices will save us
  5. 5. Well...
  6. 6. I am old
  7. 7. Old people have long memories
  8. 8. “Those who refuse to learn from commit history are doomed to reimplement it”
  9. 9. “Adding manpower to a late software project makes it later.”
  10. 10. “Observe that for the programmer, as for the chef, the urgency of the patron may govern the scheduled completion of the task, but it cannot govern the actual completion.”
  11. 11. “There is no silver bullet”
  12. 12. “No Silver Bullet”
  13. 13. Microservices are not a Silver Bullet
  14. 14. Disclaimer Please note that nothing I say over the rest of this presentation should be taken as me saying or implying that microservices are not an improvement over most software architectures that preceded them. I am merely pointing out that they are not the cure-all that some of their fans seem to think they are and that some care needs to be taken in order to get the most benefit from them. I’m also, of course, going for a few cheap laughs here. All advice is worth exactly what you paid for it. Satisfaction guaranteed or your money back.
  15. 15. Advantages of microservices
  16. 16. Simplicity
  17. 17. Simplicity
  18. 18. Less complexity
  19. 19. Ownership
  20. 20. Autonomy
  21. 21. Faster releases
  22. 22. Inside your monolithic ball of mud
  23. 23. Microservices version
  24. 24. Microservices on a monolithic database
  25. 25. Who owns the database schema?
  26. 26. How do you change the database schema?
  27. 27. How do you ensure you that your changes to the database schema don’t affect other users of the monolithic database?
  28. 28. Microservices need microdatabases
  29. 29. Simplicity?
  30. 30. Ownership?
  31. 31. How many stacks do you need?
  32. 32. AWS == £$€
  33. 33. Some tips
  34. 34. Microservices are REST over HTTPS
  35. 35. <SOAP/> Dodger
  36. 36. JSON is standard
  37. 37. HTTP is more than GET and POST
  38. 38. Use HTTP Verbs for CRUD CRUD REST over HTTP Create POST Read GET Update PUT Delete DELETE
  39. 39. Assume your private API will be public
  40. 40. Issue API keys
  41. 41. Version your API
  42. 42. Use HAL (Hypertext Application Language)
  43. 43. Generate docs from specs (Swagger)
  44. 44. Generate docs from specs (Swagger)
  45. 45. Generate docs from specs (OpenAPI)
  46. 46. Emulate Johnny Cash Destroy the monolith “One Piece at a Time”
  47. 47. Emulate Johnny Cash Destroy the monolith “One Piece at a Time”
  48. 48. Dave Cross https://perlhacks.com @perlhacks