Is Your DevOps Team Ready For Microservices?

Listen closely. Close your eyes. I know you hear it coming. It's the microservices buzz. Well, by now it is more of a quake.

I've been on 2 enterprise level microservices implementations. One was greenfield and the other was a migration from a FAT service. It turns out that the 2 easiest things to do when moving to microservices are to DECIDE to do it and to WRITE THE CODE. If you stick around after that, you better be ready for a ride!

I'd like to share my team's story with anyone who is thinking about going down this path or who has experienced it themselves.

Transcript

1. != • Not THAT “Michael Winslow” • Core Applications • Spaces > Tabs Is Your DevOps Team Ready For Microservices? @michaelswinslow michael_winslow@comcast.com michaelswinslow
2. Some background: 1. I was on a team that built web services using Spring MVC 2. At some point, the team and leadership decided to pursue microservices 3. We took some time to “Strangle the Monolith” 4. Things worked out well, but it was not always sunshine Now you have a choice: • Hear about the lessons my team learned! (red) • Hear about how great your team is at making microservices! (blue) @michaelswinslow
3. This is a MONOLITH Service Controller Repository (DAO) account user device @michaelswinslow
4. Controller device Service Repository This is a MICROSERVICE @michaelswinslow
5. Controller device Service Repository This is a MICROSERVICE Controller user Service Repository Controller account Service Repository @michaelswinslow
6. Controller device Service Repository Controller user Service Repository Controller account Service Repository API Gateway @michaelswinslow
7. Controller device Service Repository Controller user Service Repository Controller account Service Repository API Gateway @michaelswinslow
8. Scale / Service Discovery @michaelswinslow
9. Controller device Service Repository Controller user Service Repository Controller account Service Repository API Gateway “Oh no! For some reason requests to the ACCOUNT API have gone way up! At least 3x the traffic of any other API!” @michaelswinslow
10. Controller device Service Repository Controller user Service Repository Controller account Service Repository API Gateway Controller account Service Repository Controller account Service Repository @michaelswinslow
11. Controller device Service Repository Controller user Service Repository Controller account Service Repository API Gateway Controller account Service Repository Controller account Service Repository Discovery @michaelswinslow
12. Controller device Service Repository Controller user Service Repository Controller account Service Repository API Gateway Controller account Service Repository Controller account Service Repository Discovery @michaelswinslow
13. Controller device Service Repository Controller user Service Repository Controller account Service Repository API Gateway Controller account Service Repository Controller account Service Repository Discovery Note: Unless you are using containers and/or cloud orchestrations tools, these additional microservices will not scale automatically. But Eureka will discover them once they are running. @michaelswinslow
14. Fault Tolerance / Circuit Breaker @michaelswinslow
15. Controller device Service Repository Controller user Service Repository Controller account Service Repository API Gateway Controller account Service Repository Controller account Service Repository Discovery @michaelswinslow
16. Controller device Service Repository Controller user Service Repository Controller account Service Repository API Gateway Controller account Service Repository Controller account Service Repository Discovery @michaelswinslow
17. Controller device Service Repository Controller user Service Repository Controller account Service Repository API Gateway Controller account Service Repository Controller account Service Repository Discovery Retry 3/3 @michaelswinslow
18. HYSTRIX Controller device Service Repository Controller user Service Repository Controller account Service Repository API Gateway Controller account Service Repository Discovery Bye Felicia! @michaelswinslow
19. Summary: 1. Monolith vs Microservice 2. API Gateway - Zuul 3. Service Discovery - Eureka 4. Software Load Balancer – Ribbon 5. Circuit Breaker - Hystrix Now you have a choice: • That was amazing! Now tell us what your team learned! (red) • That was amazing! Now tell us what your team learned! (blue) @michaelswinslow
20. “Being able to scale and distribute your application resources is certainly alluring. However, this doesn't come for free. Complexity begets complexity. Soon tools are needed to manage the complexity. Then tools are needed to manage the tools.” – Ryan E, Principal Engineer @michaelswinslow
21. Is There a Need To Move to Microservices? Are you Netflix? Do we need microservices? No no @michaelswinslow
22. Have a Monolith Conversion Plan we did… @michaelswinslow
23. The New Employee 1. There was one developer on the team I did not like 2. We brought him on board in late 2016 3. He wrote about 500K lines of code IN ONE HOUR 4. Didn’t explain any of it to the rest of the team 5. And then…HE QUIT His name was … J-Hipster! @michaelswinslow
24. What is J-Hipster? JHipster is a development platform to generate, develop and deploy Spring Boot + Angular/React Web applications and Spring microservices. website: https://www.jhipster.tech/ @michaelswinslow
25. CONS with J-Hipster 1. Code Generator 2. No one knew even the basics about microservices 3. Security vulnerability scans stopped working 4. Tons of additional wasted code generated to be a generic solution (DockerFile, Liquibase, etc.) 5. Developers did not know what they could safely remove 6. Not great for TEAM development @michaelswinslow
26. PROS with J-Hipster 1. Major improvements @ https://www.jhipster.tech 2. Time saver if you already understand the code 3. Can really help in understanding of Microservices 4. Sets up a great Spring Cloud Config instance I would certainly recommend J-Hipster for a top- notched lead developer. He/She could generate the microservice code and trim away the unneeded stuff. Once the code is curated, store it in GIT as an initial commit and formal template for future microservices. @michaelswinslow
27. What you did for ONE you now have to do for MANY @michaelswinslow
28. @michaelswinslow
29. @michaelswinslow
30. @michaelswinslow
31. Suggestions: 1. Do not create all of your microservices at once 2. Monitor the usage to find your most utilized endpoints and use that to prioritize your migration @michaelswinslow
32. Traceability finding a needle in a haystack is easier @michaelswinslow
33. Figure 1. Microservices Architecture. As presented by SogetiLabs, 2016, retrieved from http://labs.sogeti.com/microservices-architectures-stay/ @michaelswinslow
34. Figure 1. Microservices Architecture. As presented by SogetiLabs, 2016, retrieved from http://labs.sogeti.com/microservices-architectures-stay/ API Gateway @michaelswinslow
35. Change Management Team wants their release notes @michaelswinslow
36. @michaelswinslow
37. Security Team wants their Vulnerability Scans @michaelswinslow
38. @michaelswinslow
39. Version Control and Compatibility can be a nightmare @michaelswinslow
40. @michaelswinslow
41. “…when you publish a new version of a mobile app, the old version doesn’t just magically go away.” – Mark D, Senior Android Developer @michaelswinslow ”Future Proofing Mobile Applications” (Medium, 2018) - https://medium.com/datadriveninvestor/future-proofing-mobile-applications-56f37e80cd4c
42. Burnout is real @michaelswinslow
43. I caution against moving to microservices in situations when you MUST be successful in your implementation AND you are still actively adding complex features to meet a deadline There is a human side as well @michaelswinslow
44. Recap with DOs and DON’Ts: DO have a reason to move to microservices (Resiliency, Cost-Optimization, etc.) DON'T practice RDD (Resume-Driven Development) DO reference other microservice implementations DON'T allow a generator to write production code DO peel off one microservice at a time (Strangler Application pattern) DON'T refactor everything at once DO understand that all teams are impacted (QA, Release Management, Security, etc.) DON'T say “we're doing microservices” #YOLO DO staff appropriately and monitor employee health DON'T ignore the human impact of your decision @michaelswinslow
45. Questions / Discussion / Feedback Content Management System Open Discussion (ideas) 1. Discuss Specific Tools 2. Microservices vs MicroService Oriented Architecture (MSOA) 3. (Anything you want) @michaelswinslow
46. != • Not THAT “Michael Winslow” • Core Applications • Spaces > Tabs Is Your DevOps Team Ready For Microservices? @michaelswinslow michael_winslow@comcast.com michaelswinslow Thank You!