Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Using Apache Geode: Lessons Learned at Southwest Airlines


Published on

SpringOne Platform 2019
Session Title: Using Apache Geode: Lessons Learned at Southwest Airlines
Speakers: Brian Dunlap, Solutions Architect, Southwest Airlines

Published in: Software
  • Be the first to comment

  • Be the first to like this

Using Apache Geode: Lessons Learned at Southwest Airlines

  1. 1. Using Apache Geode: Lessons Learned at Southwest Airlines 1 Brian Dunlap – Solutions Architect @brianwdunlap
  2. 2. About my current Southwest focus… Data strategy, governance, and tools Integrated data initiatives Architectural patterns Proof of concepts DATA ARCHITECTURE
  3. 3. About my GemFire experience… Flight scheduling modernization Optimization and data integration Reactive and streaming data patterns SYSTEM MODERNIZATION
  4. 4. Thank you!
  5. 5. At Southwest, we’ve used GemFire for several years…
  6. 6. If we could go back in time, what tips would we share with ourselves?
  7. 7. GemFire
  8. 8. Tip #1: Set Expectations For GemFire cloud migrations, set team expectations early.
  9. 9. Tip #1: Set Expectations Align GemFire infrastructure goals with your cloud thinking.
  10. 10. Tip #1: Set Expectations How will managing your GemFire services be like managing your other cloud services?
  11. 11. • Documentation • Multiple environment configs • Right sizing components • GitOps • Monitoring • Observability • Repeatability • Economics • Increase deployment velocity • Reduce deployment risk • High availability • Self healing • Security • Network topology • On-prem integration • Manage cattle not pets • Configure block storage • Clean up un-used disk storage • Dynamic DNS • Transient servers • Containerization • Containing failure impact • Immutable infrastructure • Infrastructure as code • Image provisioning • CI/CD • Process management • Pipeline repeatability • Automated configuration • Automated testing • Automation tooling • No direct server access • Cloud security controls • Security groups • Cloud training
  12. 12. Tip #2: Learning and Time You’ll be consuming from the knowledge firehose. Work will take longer than you think.
  13. 13. Tip #2: Learning and Time Don’t forget to share what you learn with the right people.
  14. 14. Tip #3: Team requirements GemFire teams need cross- functional players and coaches.
  15. 15. App Team Cloud Team Network Team Monitoring Team Architecture Team GemFire Platform Team
  16. 16. Tip #4: Team shape Think about your team shape. Should you spread out or get close? Based on what’s happening, it should change a lot.
  17. 17. “I wish we had all worked together sooner.”
  18. 18. Tip #5: Grid shape Your cloud grid shape will probably look different from on- prem.
  19. 19. 20 VPC AWS Cloud Availability Zone 1 Availability Zone 3 Instance Instance Instance Instance Availability Zone 2 Instance Instance Instance Instance Instance
  20. 20. Tip #6: Ask questions Ask lots of questions.
  21. 21. Tip #6: Ask questions How are cloud servers different from your on-prem servers?
  22. 22. Tip #6: Ask questions How are cloud availability zones different from your on-prem availability zones?
  23. 23. Tip #7: Experiment Experiment with options. Does each AZ need X or Y cache nodes? Test it!
  24. 24. Tip #8: Understand Capacity Understand your I/O bandwidth. It’s very tricky.
  25. 25. Always read the ‘*’s.
  26. 26. Tip #8: Understand Capacity How is your cloud network different from your on-prem network? Hint, hint… It’s probably very different.
  27. 27. AWS Transit Gateway vs. AWS Transit VPC vs. AWS VPC Peering vs. AWS Direct Connect
  28. 28. Tip #9: Reduce Spend How are cloud economics different from on-prem datacenter economics? Turn off the lights!
  29. 29. Tip #10: Embrace cloud differences Different players. Different strengths. Different fields. Different architecture!
  30. 30. Tip #11: Respect cloud differences GemFire components make frequent security calls. Make sure your environment is prepared for them.
  31. 31. Tip #12: Ask Why? Why use GemFire?
  32. 32. Tip #12: Ask Why? Why use caching?
  33. 33. Tip #13: Quantify data flow Observability is important. How often? How much? What kind of data flow profile?
  34. 34. Tip #13: Quantify data flow GemFire metrics. Application metrics. Tools. Tell a data flow story.
  35. 35. Tip #14: Beware of “because it’s there” Why are you using GemFire for caching XYZ? Because it’s there.
  36. 36. Tip #15: Beware of the “too many” problem Too many GemFire CQs. Too many things in a single cluster. Too many complex queries. Too many apps coupled to a region.
  37. 37. Tip #16: Balanced Planning Balance between tech debt, features, and creating your tech future. Plan for creating the right place for the right data.
  38. 38. Tip #16: Balanced Planning You want to be good at the short, medium, and long term game. Some “lifts” are heavy!
  39. 39. Tip #17: Upgrades Take advantage of cloud capabilities that benefit GemFire upgrades.
  40. 40. Tip #18: Performance testing Automate performance testing. Catch “order by” version upgrades.
  41. 41. Tip #19: Skills Development Cache development skills are unique. Intentional learning. Be aware of old habits.
  42. 42. Tip #20: Automation “If I did it twice, I automated it.” On-prem scripts will get integrated into your cloud perspective.
  43. 43. Tip #21: It’s OK It’s OK to simplify which GemFire features you use.
  44. 44. Questions? Brian Dunlap Solutions Architect @brianwdunlap 45