MongoDB.local Seattle 2019: File – New – Legacy - Project
•Download as PPTX, PDF•
1 like•152 views
Lane McLaughlin discusses experimenting with MongoDB to address issues with a legacy architecture and slow performance. Some key benefits of using MongoDB included increased development velocity, operational efficiency, and better support. It helped solve real problems and became Lane's new default by meeting basic needs simply and allowing for growth. Examples are provided of use cases like reporting, user input, and caching that saw improvements with MongoDB. Lane encourages cultivating innovation by addressing team needs and experiencing the benefits of MongoDB.
Recommended
Recommended
More Related Content
Similar to MongoDB.local Seattle 2019: File – New – Legacy - Project
Similar to MongoDB.local Seattle 2019: File – New – Legacy - Project (20)
More from MongoDB
More from MongoDB (20)
Recently uploaded
Recently uploaded (20)
MongoDB.local Seattle 2019: File – New – Legacy - Project
- 1. File -> New -> Legacy -> Project A conversation about experimentation (and mongodb) By Lane McLaughlin – VP Software Engineering @ Parametric For mongodb.local.2019.Seattle
- 2. Spoiler alert • If I forget to tell you later, I wanted to say: • Experiment – improve – grow – be brave • You need “Maslow’s approval”, so check in • MongoDB is my new “default”
- 3. About Lane and Parametric • https://www.linkedin.com/in/lane -mclaughlin-56b91428/ • mailto:lmclaughlin@paraport.com • https://twitter.com/spacattac
- 5. Monolith -> Micros ~ Relational -> Documents
- 6. Current State – precisely this … https://www.datacenterdynamics.com /opinions/the-three-ps-of-successful- legacy-software-modernization/
- 7. Are you expected to innovate
- 8. So what’s the issue
- 9. I get you – it’s human nature • Behavior influenced by needs and motivations • Can’t move up without a more basic need met • Think of the “corporate” versions of these needs • How do you get from a “j-o-b” to a peak experience
- 10. When will he plug the mongo My experiment with MongoDB was one of those “game changing” experiences. It’s become my “new default!” -- Lane McLaughlin 2018 • Basic needs: address a dreaded problem, easy startup • Safety: known vendor with great resources • Belonging: custom + player coach + motivated team • Esteem: 3 month delivery on 10 year old problem, gaining control over legacy problems • Actualization: individual and team growth, customer delight
- 11. Challenges that forced change • what business challenges were you encountering and how you applied Mongo- why the need for a change/experimental approach? • Address issues with legacy architecture and slow performance • Keep it simple and Go-faster! • Talent pool of the future – “why are the ‘cool kids’ using these other technologies”
- 12. Use Cases • Account Setup • Client submitted Activities • Reporting Data • Usage Tracking (BI connector) • Investment Proposals • Caching • View Models • Reporting Data • User Input & Sagas • Background Data
- 13. Real Problems Solved – modern living • Increased velocity • Operational efficiency • Great Support • Developer / Tester “delight”
- 14. Example – Quarterly Reporting View
- 15. Example – Proposals – inputs + results
- 16. Examples
- 17. Examples
- 18. Examples
- 19. A call to action Circling back, please join me … • Cultivate a culture of innovation • Address people/team needs (Maslow) • Experience the delight of dev/test/operations with MongoDB
- 20. Let’s continue the conversation – Questions?
Editor's Notes
- That moment of regret when you just plow ahead How often do you get the opportunity for “New” And do you do “New” or “Familiar” And when does “Familiar” become “Old”, i.e., Legacy
- A bit of a “corporate” dude Yet I’ve been called a cowboy Developer – Manager – Director – Veep Focused on Delivery: Domain Driven Design, Agile, DevOps, CD – continuous improvement Feel free to contact me: linkedin, parametric, twitter We’re hiring
- Ingenuity Implementation solutions Customized Disciplined Researched, Formulaic Other 30+ years Risk averse: regulatory, trade errors, reputational risk
- 30+ years in Asset Management Rapid growth in recent years Development community embraces agile, devops, software craftsmanship, microservices Core systems architected with patterns from the past and smaller workloads Started “digital transformation” journey around 2016 Resource strain to handle maintenance, re-work and strategic initiatives across the application portfolio
- Core systems architected with patterns from the past and smaller workloads Resource strain to handle maintenance, re-work and strategic initiatives across the application portfolio
- From Parametric Performance Management – Competencies Same at “Brand X” How does it apply to Technology unit in non-Technology Industry Tension between “maintenance” (previous slide) and “innovation”
- Private joker – the duality of man – born to kill vs. peace “Corporate/Enterprise Conflicts” got you down? Corporate paradox Innovation vs. play it safe Time budget Drifting standards How often do you/we really get to do “new” Speed to market vs. Time learn Standards vs. Innovation Current investments vs. New investment How are people rewarded Gaining consensus can be tough – paralysis-by-analysis is often too big of hurdle and the demise of an experiment Openness vs. secrecy
- Maslow and what motivates our behaviors Corporate edition -- Ask the crowd … Basic needs: does this matter, do I have time, do we have money Safety: what is the true risk and fail culture Belonging: is there enough consensus, secrecy vs. transparent Esteem: Accomplishment - are you getting results Actualization: Achieving Potential - Did you discover a “game changer” on something that mattered Peak experiences – ask the crowd … Achievement/Success New/winning business Learning and growing Life/game-changing Myth-busting
- Examples: Account Setup SRI Performance More Account Management Usage Tracking Scenarios – inputs, parameters, results Caching
- Started with safe examples – not invasive to existing apps Not afraid to tackle transactional systems in the future
- Remove relational data modeling and data mapping / ORM goo (and wars) Remove TSQL code and migrations Easy for Testers to manipulate data Easy for users to review data Self-service Upgrades mongoUniversity Mongo as a partner Online support
- Talk though the different tabs Some are the online data entry intake Some more are reporting view models
- Talk though the different tabs Some are the online data entry intake Some more are reporting view models