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.
Nächste SlideShare
Das kannste schon so machen
Das kannste schon so machen
Wird geladen in …3
×
1 von 68

Von JavaEE auf Microservice in 6 Monaten - The Good, the Bad, and the wtfs...

0

Teilen

Herunterladen, um offline zu lesen

Mein Foliensatz zum JUG Cologne Vortrag vom 16.11.2015

Ähnliche Bücher

Kostenlos mit einer 30-tägigen Testversion von Scribd

Alle anzeigen

Ähnliche Hörbücher

Kostenlos mit einer 30-tägigen Testversion von Scribd

Alle anzeigen

Von JavaEE auf Microservice in 6 Monaten - The Good, the Bad, and the wtfs...

  1. 1. Von JavaEE auf Microservice in 6 Monaten The Good, the Bad, and the wtfs... André Goliath
  2. 2. ENTERPRISE IT
  3. 3. MY VISION (AND MY KEY HOLDER, TOO)
  4. 4. SO, HOW TO GET THERE?
  5. 5. WHEN WHY WITH WHOM TO WHAT EXTENT SO, HOW TO GET THERE?
  6. 6. WHEN WHY WITH WHOM TO WHAT EXTENT SO, HOW TO GET THERE?
  7. 7. Now!
  8. 8. „Digitization“ Cloud Computing Internet of Things Virtual Reality Microservices $anything as a Service fastIndustry 4.0 Web 2.0 Social Media Big Data Privacy & Security
  9. 9. „Digitization“ Cloud Computing Internet of Things Virtual Reality Microservices $anything as a Service Industry 4.0 Web 2.0 Social Media Big Data Privacy & Security yeah, let´s do this! fast
  10. 10. WHEN WHY WITH WHOM TO WHAT EXTENT SO, HOW TO GET THERE?
  11. 11. Because we can!
  12. 12. Because we need to! How long does it take from idea to production? How long does it need to take from idea to production? What is the cost of implementing an one-liner feature? What should the cost be?
  13. 13. Because we need to! How long does it take from idea to production? How long does it need to take from idea to production? What is the cost of implementing an one-liner feature? What should the cost be? 6 months Cost to develop x 5 and then some…
  14. 14. 6 Monoliths. 600 Services. 15 Clients. 25 Backends. Featuring code from 1995 till today. (Anyone remember J2EE1.2 ?)
  15. 15. Don´t get me wrong. Monoliths are not bad. (at least not all of them)
  16. 16. WHEN WHY WITH WHOM TO WHAT EXTENT SO, HOW TO GET THERE?
  17. 17. How to code? How to deploy? How to use? SO, HOW TO GET THERE?
  18. 18. How to code? How to deploy? How to use? SO, HOW TO GET THERE?
  19. 19. Spring Boot
  20. 20. But be careful!
  21. 21. How to catch a 404 error and wrap it in your own JSON response?
  22. 22. How to catch a 404 error and wrap it in your own JSON response? It took us about 30 work hours to figure this one out. And it involves manipulating the embedded Tomcat. Without a specific Spring Boot API for that feature.
  23. 23. Coding 1 Microservice? Easy. Coding 100 Microservices? Not so easy. How do we organize our configuration? Do we want to share code? Do we want to force all microservices to use the same Spring Boot version? Do we allow communication between services? What aspects do we NEED to be the same for all services? HATOEAS? Service Boundaries?
  24. 24. Share framework code, nothing else.
  25. 25. Share framework code, nothing else. If you have no regrets about sharing your code on github, it is probably framework code
  26. 26. Share framework code, nothing else. Filter (Security, Authentication, Logging, Monitoring) Error Handling Profile / Envíronment Configuration Logging Configuration Common Documentation If you have no regrets about sharing your code on github, it is probably framework code
  27. 27. How about communication?
  28. 28. Customer Search Card Management Account Management „Backend“ Microservices Mobile App Online Banking Branch „Gateway“ Microservices Mobile App Online Banking Branch Actual Frontends
  29. 29. Customer Search Card Management Account Management „Backend“ Microservices Data Tailoring Mobile App Online Banking Branch „Gateway“ Microservices Mobile App Online Banking Branch Actual Frontends HATEOAS Links Service Orchestration Clientspecific Security
  30. 30. Spring Cloud „Production-Ready“ Features… … but only in an ideal world.
  31. 31. Spring Cloud Actuator endpoints Good for quick debugging, but how to integrate them in an enterprise monitoring world? Configserver You better play by the rules. Don´t use a – in your service name! Routing Stuff (Eureka, Zuul, Ribbon) Works. But only if you commit to doing routing the Netflix-way.
  32. 32. How to code? How to deploy? How to use? SO, HOW TO GET THERE?
  33. 33. Automation! Tests Builds Provisioning Deployments
  34. 34. Automation! But… Strict Hardware and OS Restrictions No direct communication between development and production environments No SSH connections to production „I don´t trust those tools“ (senior dev.) You want to put something into production? Fine, here complete these forms, and have them signed by 10 people, who have never heard of you, and have no clue what you are doing.
  35. 35. The most important rule Use the same deployment toolchain for development, UATs, and production!
  36. 36. So here is what we did.
  37. 37. Step 1: Prepare everything for coding
  38. 38. Code Repo Developer Jenkins Deploy Scripts Ansible ansible-playbook create.yml
  39. 39. Step 2: Code and Test
  40. 40. Code Repo Developer Jenkins Deploy Scripts git push origin f-newStuff git post-push hook ssh scp Development / Test Environment Service Host A Service Host B Config Server Apache mod_proxy
  41. 41. Step 3: Deploy to Production
  42. 42. Code Repo Developer Deploy Scripts POTS: „Please deploy v1, I‘ll mail you the paperwork“ ftp ssh Development / Test Environment Service Host A Service Host B Config Server Apache mod_proxy Ops Guy Production Environment Gateway Service Host B Config Server Apache mod_proxy some proprietary protocols… Service Host A
  43. 43. Why no Docker?
  44. 44. Why no Docker? Getting into Docker is easy. Even at a later stage. Getting back from Docker to something else is a hell of a ride.
  45. 45. How to code? How to deploy? How to use? SO, HOW TO GET THERE?
  46. 46. Working software over comprehensive documentation - agilemanifesto.org -
  47. 47. Test-Driven Documentation using spring-restdocs
  48. 48. Swagger UI
  49. 49. WHEN WHY WITH WHOM TO WHAT EXTENT SO, HOW TO GET THERE?
  50. 50. You must overcome Conway‘s Law
  51. 51. Vertical Teams Just get used to it.
  52. 52. Customer Search Card Management Account Management „Backend“ Microservices Mobile App Online Banking Branch „Gateway“ Microservices Mobile App Online Banking Branch Actual Frontends All developed in one team!?!
  53. 53. WHEN WHY WITH WHOM TO WHAT EXTENT SO, HOW TO GET THERE?
  54. 54. There is no need for a big bang
  55. 55. We started with 1 service and 1 client
  56. 56. There are viable migration paths even for legacy code
  57. 57. Bottom Line?
  58. 58. It works. Even in enterprises.
  59. 59. One step at a time, and you´ll be fine.
  60. 60. Thank You! André Goliath Senior Technical Consultant andre.goliath@senacor.de

×