Is Your DevOps Team Ready For Microservices?

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.

D2985b36fb510e4b37ec87d7b9ac979b?s=128

Michael Scott Winslow

August 24, 2018
Tweet

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!