Von JavaEE auf Microservice in 6 Monaten - The Good, the Bad, and the wtfs...
0 likes663 views
This document summarizes a talk about transitioning from JavaEE monoliths to microservices architecture in 6 months. It discusses the reasons for moving to microservices (faster development and deployment, lower costs), and the challenges including organizing configuration, communication between services, and deployment. It then outlines the steps taken to implement microservices at a company, including setting up continuous integration, using Spring Boot and Cloud, and establishing vertical feature teams to overcome organizational barriers. The key lessons are that the transition does not require a "big bang", can start with a single service, and works best by automating the development and deployment process from development to production.
Von JavaEE auf Microservice in 6 Monaten - The Good, the Bad, and the wtfs...
- 1. Von JavaEE auf Microservice in 6 Monaten The Good, the Bad, and the wtfs... André Goliath
- 4. MY VISION (AND MY KEY HOLDER, TOO)
- 6. SO, HOW TO GET THERE?
- 7. WHEN WHY WITH WHOM TO WHAT EXTENT SO, HOW TO GET THERE?
- 8. WHEN WHY WITH WHOM TO WHAT EXTENT SO, HOW TO GET THERE?
- 9. Now!
- 11. „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
- 12. „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
- 13. WHEN WHY WITH WHOM TO WHAT EXTENT SO, HOW TO GET THERE?
- 14. Because we can!
- 15. 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?
- 16. 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…
- 17. 6 Monoliths. 600 Services. 15 Clients. 25 Backends. Featuring code from 1995 till today. (Anyone remember J2EE1.2 ?)
- 18. Don´t get me wrong. Monoliths are not bad. (at least not all of them)
- 19. WHEN WHY WITH WHOM TO WHAT EXTENT SO, HOW TO GET THERE?
- 20. How to code? How to deploy? How to use? SO, HOW TO GET THERE?
- 21. How to code? How to deploy? How to use? SO, HOW TO GET THERE?
- 22. Spring Boot
- 23. But be careful!
- 24. How to catch a 404 error and wrap it in your own JSON response?
- 25. 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.
- 26. 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?
- 27. Share framework code, nothing else.
- 28. Share framework code, nothing else. If you have no regrets about sharing your code on github, it is probably framework code
- 29. 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
- 31. Customer Search Card Management Account Management „Backend“ Microservices Mobile App Online Banking Branch „Gateway“ Microservices Mobile App Online Banking Branch Actual Frontends
- 32. 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
- 33. Spring Cloud „Production-Ready“ Features… … but only in an ideal world.
- 34. 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.
- 35. How to code? How to deploy? How to use? SO, HOW TO GET THERE?
- 37. 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.
- 38. The most important rule Use the same deployment toolchain for development, UATs, and production!
- 39. So here is what we did.
- 40. Step 1: Prepare everything for coding
- 43. Step 2: Code and Test
- 44. 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
- 45. Step 3: Deploy to Production
- 46. 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
- 47. Why no Docker?
- 48. 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.
- 49. How to code? How to deploy? How to use? SO, HOW TO GET THERE?
- 50. Working software over comprehensive documentation - agilemanifesto.org -
- 55. Swagger UI
- 57. WHEN WHY WITH WHOM TO WHAT EXTENT SO, HOW TO GET THERE?
- 58. You must overcome Conway‘s Law
- 59. Vertical Teams Just get used to it.
- 60. 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!?!
- 61. WHEN WHY WITH WHOM TO WHAT EXTENT SO, HOW TO GET THERE?
- 62. There is no need for a big bang
- 63. We started with 1 service and 1 client
- 64. There are viable migration paths even for legacy code
- 65. Bottom Line?
- 66. It works. Even in enterprises.
- 67. One step at a time, and you´ll be fine.
- 68. Thank You! André Goliath Senior Technical Consultant andre.goliath@senacor.de