Is Your DevOps Team Ready For Microservices?

Slide 1

Slide 1 text

!= • Not THAT “Michael Winslow” • Core Applications • Spaces > Tabs Is Your DevOps Team Ready For Microservices? @michaelswinslow [email protected] michaelswinslow

Slide 2

Slide 2 text

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

Slide 3

Slide 3 text

This is a MONOLITH Service Controller Repository (DAO) account user device @michaelswinslow

Slide 4

Slide 4 text

Controller device Service Repository This is a MICROSERVICE @michaelswinslow

Slide 5

Slide 5 text

Controller device Service Repository This is a MICROSERVICE Controller user Service Repository Controller account Service Repository @michaelswinslow

Slide 6

Slide 6 text

Controller device Service Repository Controller user Service Repository Controller account Service Repository API Gateway @michaelswinslow

Slide 7

Slide 7 text

Controller device Service Repository Controller user Service Repository Controller account Service Repository API Gateway @michaelswinslow

Slide 8

Slide 8 text

Scale / Service Discovery @michaelswinslow

Slide 9

Slide 9 text

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

Slide 10

Slide 10 text

Slide 11

Slide 11 text

Slide 12

Slide 12 text

Slide 13

Slide 13 text

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

Slide 14

Slide 14 text

Fault Tolerance / Circuit Breaker @michaelswinslow

Slide 15

Slide 15 text

Slide 16

Slide 16 text

Slide 17

Slide 17 text

Slide 18

Slide 18 text

HYSTRIX Controller device Service Repository Controller user Service Repository Controller account Service Repository API Gateway Controller account Service Repository Discovery Bye Felicia! @michaelswinslow

Slide 19

Slide 19 text

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

Slide 20

Slide 20 text

“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

Slide 21

Slide 21 text

Is There a Need To Move to Microservices? Are you Netflix? Do we need microservices? No no @michaelswinslow

Slide 22

Slide 22 text

Have a Monolith Conversion Plan we did… @michaelswinslow

Slide 23

Slide 23 text

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

Slide 24

Slide 24 text

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

Slide 25

Slide 25 text

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

Slide 26

Slide 26 text

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

Slide 27

Slide 27 text

What you did for ONE you now have to do for MANY @michaelswinslow

Slide 28

Slide 28 text

@michaelswinslow

Slide 29

Slide 29 text

@michaelswinslow

Slide 30

Slide 30 text

@michaelswinslow

Slide 31

Slide 31 text

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

Slide 32

Slide 32 text

Traceability finding a needle in a haystack is easier @michaelswinslow

Slide 33

Slide 33 text

Figure 1. Microservices Architecture. As presented by SogetiLabs, 2016, retrieved from http://labs.sogeti.com/microservices-architectures-stay/ @michaelswinslow

Slide 34

Slide 34 text

Figure 1. Microservices Architecture. As presented by SogetiLabs, 2016, retrieved from http://labs.sogeti.com/microservices-architectures-stay/ API Gateway @michaelswinslow

Slide 35

Slide 35 text

Change Management Team wants their release notes @michaelswinslow

Slide 36

Slide 36 text

@michaelswinslow

Slide 37

Slide 37 text

Security Team wants their Vulnerability Scans @michaelswinslow

Slide 38

Slide 38 text

@michaelswinslow

Slide 39

Slide 39 text

Version Control and Compatibility can be a nightmare @michaelswinslow

Slide 40

Slide 40 text

@michaelswinslow

Slide 41

Slide 41 text

“…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

Slide 42

Slide 42 text

Burnout is real @michaelswinslow

Slide 43

Slide 43 text

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

Slide 44

Slide 44 text

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

Slide 45

Slide 45 text

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

Slide 46

Slide 46 text

!= • Not THAT “Michael Winslow” • Core Applications • Spaces > Tabs Is Your DevOps Team Ready For Microservices? @michaelswinslow [email protected] michaelswinslow Thank You!