New life inside monolithic application
9 likes2,882 views
The document presents the journey of evolving a monolithic Java application from its inception as a startup to a more modular, multi-tenant architecture due to growth challenges. It discusses the issues encountered, solutions implemented to improve internal quality and customization, and outlines a new architecture aimed at lowering maintenance costs and enhancing flexibility. The conclusion emphasizes that while monolithic applications can be successful, careful consideration is required before transitioning to microservices.
New life inside monolithic application
- 1. New Life inside Monolithic Application This presentation will be useful to those who would like to get acquainted with lifetime history of successful monolithic Java application By Taras Matyashovsky Taras Matyashovsky, Software Engineer/Team & Tech Lead, CSM, @tmatyashovsky
- 2. Introduction
- 3. About me • Software engineer/TL • Worked for outsource companies, product companies and tried myself in startups/freelancing • 8+ years production Java experience • Fan of Agile methodologies, CSM • Founder of Morning@Lohika tech talks in Lviv Introduction
- 4. This Presentation • shows architectural and technical evolution of one Java web startup that is beyond daily coding routine • contains a lot of • simplifications • Captain Obvious • internet memes Introduction
- 5. Notice • business domain is not important • this presentation is not intended for monolithic vs. micro services architectures comparison Introduction
- 6. Agenda • You’ve decided to build a startup • You’ve built a startup • Early issues • Solutions • Still not enough • New solution • Proof of concept • New life inside monolith • Next goals • Groupon way • Conclusions • Instead of epilogue Introduction
- 7. You’ve Decided to Build a Startup
- 8. You’ve Decided to Build a Startup about 5 years ago You’ve decided to build a startup
- 9. Product Overview • business model – B2B •main product flow: • import data from customer • process data, e.g. validate, filter, pre-calculate • show different analytics to end users You’ve built a startup
- 10. Technology Stack 4-5 years ago you’ve probably have chosen: • Java 6.x • JDBC/Hibernate • Spring with emphasis on Spring MVC • HTML/CSS/JSP • JS/jQuery • MySQL 5.x You’ve built a startup
- 11. Tools 4-5 years ago you’ve probably have chosen: • Maven 2.x • Jetty 6.x • Jenkins • Subversion • JIRA • Confluence You’ve built a startup
- 12. You’ve Built a Startup You’ve built a startup
- 13. Architecture Not thinking about: •scalability •performance • customization • l10n, i18n You’ve built a startup
- 14. SaaS Maturity Model (Level 2) You’ve built a startup
- 15. Architecture You’ve built a startup
- 16. Architecture You’ve built a startup
- 17. Architecture You’ve built a startup
- 18. You’ve Built a Startup Single tenant monolithic stateful application with no thought on cost of future scalability, customization, l10n/i18n and performance You’ve built a startup
- 19. You’ve Built a Startup with reasonable trade-offs and compromises You’ve built a startup
- 20. You’ve Built a Startup And it became a successful product You’ve built a startup
- 21. Early Issues
- 22. Internal Quality •time to market vs. internal quality •business logic becomes more and more complicated Early Issues
- 23. A Lot of Customers •each customer wants specific features •seamless integration •l10n, i18n Early Issues
- 24. Early Issues Early Issues
- 25. Issues => Challenges Early Issues
- 26. Solutions
- 27. Internal Quality “A well-written program is a program where the cost of implementing is constant thought-out the project lifetime” Solutions
- 28. Internal Quality •formal code review process via Atlassian Crucible •integration with CheckStyle/PMD with strict set of rules Solutions
- 29. Internal Quality •unit/integration tests •functional tests bases on htmlunit/jwebunit written and maintained by developers Solutions
- 30. Internal Quality •automation tests framework based on Ruby/Selenium/Cucumber written and maintained by QA engineers •performance tests using NewRelic Solutions
- 31. A Lot of Customers Still continue with maturity level 2 and tackle customization, i18n, l10n problems separately Solutions
- 32. Maturity Level 2 Solutions
- 33. Internal Customization •is implemented via hierarchy of application.properties files Solutions
- 34. Ruby Scripts • start application per default “demo” customer • start application in debug mode • start application per specific customer using local/remote db • load fixtures data to main/test local database • start application in web tests mode • run specific web test Solutions
- 35. Specific Features •created additional Spring contexts per customer •introduced unique Spring beans per customer and injected them via aliases Solutions
- 36. External Customization • each customer had specific static assets, e.g. styles, images, js, etc. • Sass framework was used to reasonably generate CSS files per customer Solutions
- 37. Storage •one database schema per all customers •patches per customer during deployment Solutions
- 38. Code Organization •maintained one repository for default “demo” customer •created separated repositories per each customer Solutions
- 39. Customer Repo Contains: • java files • Spring contexts • database patches • static assets, e.g. styles, images, tags, etc. Web app for each customer is unpackaged and customized at deploy time Solutions
- 40. So •code and product complexity is controlled in certain bounds •internal product quality is high Solutions
- 41. So •build, testing, deployment, customization, localization processes are automated Solutions
- 42. Summary Successful product that overgrew startup stage and is delivered to more than 90 customers all over the globe Solutions
- 43. Still not Enough
- 44. Business Issues •customization is limited • as business domain is unique product is hard to be sold to more than 1 customer in region/country Still not Enough
- 45. DevOps Issues •high maintenance cost •not effective utilization of resources Still not Enough
- 46. Engineering Issues •it is impossible to develop/test new features without the entire stack running •high cost for even tiny change Still not Enough
- 47. Unfortunately Current application is expensive to maintain, customize and configure Still not Enough
- 48. New Solution
- 49. New Solution Redesign existing web solution as a multi-tenant widget-based application with easier customization and configuration support New Solution
- 50. •lower maintenance cost •easier customization via configuration and static assets that can be re-deployed without releasing software Goals New Solution
- 51. Goals •modular architecture with well-defined contracts •split of front-end and back-end with possibility to easily provide public API New Solution
- 52. Vision
- 53. Vision Z 1.2.4 Widget YX 21.0.01 WWiiddggeett YZ 12..20..30 New Solution Widget Container X 1.0.0 1 Container 2 Container 3
- 54. Skeleton •will describe header, footer, as well as main page loader •unique per application New Solution
- 55. Page Layout •will be defined via templates that describe containers in which appropriate widgets will be loaded New Solution
- 56. Widget •separated web application representing some major feature of application New Solution
- 57. Widget • is a consolidation of html, css, js plus all necessary images and localized message properties • is going to be stored on static assets server • should be built according to unified web application framework New Solution
- 58. Targeting API •will provide data essential to build page layout based on a template with widgets to be loaded in particular containers New Solution
- 59. Sequence Diagram HTML Skeleton Common (branded) CSS Common Code: • targeting call • page layout New Solution Static Content Server CDN Layout / Targeting API Widget Specific API(s) Widget HTML Widget CSS Widget Code 1 3 2 4
- 60. Looks Great New Solution
- 62. Nuance That should be done in parallel with the existing application development New Solution
- 63. Nuance One proof-of-concept widget with corresponding APIs should be implemented to prove future architecture New Solution
- 64. Proof of Concept
- 65. Widgets Technology Stack • Angular • Node.js • Bower • Grunt • Karma (ex. Testacular), Mocha, Jasmine, PhantomJS • Additional custom libraries for mocking and localization were also built Proof of Concept
- 66. API Technology Stack Created essential APIs inside existing web application using: • Spring Restful services • Spring rest template/JSON assert for testing Proof of Concept
- 67. Targeting API • provides targeting page layout for particular customer and logged-in user • provides information if user is currently logged in • provides authentication endpoint URL • provides static assets endpoint URL Proof of Concept
- 68. Authentication API •is used by page loader to force user authentication Proof of Concept
- 69. Static Assets API • handles all GET requests and serves up static assets either from file system or from Amazon S3 • combines expiration and validation caching strategies, supports gzipping Proof of Concept
- 70. Current Sequence Diagram Monolithic Web App Page Loader Common (branded) CSS Common Code: • dependencies • client for targeting API • client for authentication API Proof of Concept Static Content Server CD N Static Assets API Layout / Targeting API Widget Specific API(s) Widget HTML Widget CSS Client for Widget API Authentication API Redesigned Page 1 2 3 4 5 6
- 71. New Life inside Monolith
- 72. Temporary Architecture New Life inside Monolith
- 73. New Approach •one widget in production using described APIs that live inside existing monolith •web framework for front-end developers to build more widgets New Life inside Monolith
- 74. So Selected architecture, technology stack and tools were proven New Life inside Monolith
- 75. Next Goals
- 76. Next Goals •improve web framework, e.g. repository management, end to end tests, etc. •rebuild other pages using widgets approach when needed Next Goals
- 77. Next Goals •dismantle the monolith using SOA-like services •create mobile clients connected to redesigned unified API Next Goals
- 78. Possible Architecture Next Goals
- 79. Groupon Way
- 80. •migrated frontend from Ruby to Node.js infrastructure •the old monolithic frontend was split up into ~20 separate web apps Groupon Way “Dismantling the Monoliths”
- 81. •ability to deploy changes to applications independently •ability to make site-wide feature and design changes much more quickly Groupon Way “Dismantling the Monoliths”
- 82. Groupon Architecture Groupon Way
- 83. Conclusions
- 84. Conclusions •monolithic applications can be successful Conclusions
- 85. Conclusions •you should have a good reasons for dismantling as well as for choosing micro services architecture Conclusions
- 86. Conclusions •gradual dismantling the monolithic application is doable Conclusions
- 89. A Good Architecture Enables Agility By Simon Brown, @simonbrown, http://www.simonbrown.je/
- 90. Just Think If you can’t build a structured monolith what makes you think micro services is the answer? Don’t blindly copy what everybody else seems to be doing By Simon Brown, @simonbrown, http://www.simonbrown.je/
- 91. Monolith vs. Micro Services By Aviran Mordo, https://twitter.com/aviranm/status/531925339518148609/photo/1
- 92. Monolith vs. Micro Services Instead of Epilogue
- 93. Thanks! Questions? New Life inside Monolithic Application by Taras Matyashovsky Design by
- 94. References • http://martinfowler.com/articles/microservices.html • http://www.infoq.com/news/2014/08/microservices-monoliths • http://www.infoq.com/news/2014/08/microservices_ballmud • http://www.infoq.com/presentations/development-deployment-collaboration-etsy • https://twitter.com/aviranm/status/531925339518148609/photo/1 • https://thecloudworld.wordpress.com/tag/maturity-model/ • http://highscalability.com/blog/2014/7/28/the-great-microservices-vs-monolithic- apps-twitter-melee.html • http://www.codingthearchitecture.com/presentations/devday2014-software-software- architecture-vs-code • http://www.simonbrown.je/ • https://engineering.groupon.com/2013/misc/i-tier-dismantling-the-monoliths/ References
Editor's Notes
- #34: introduced notion of host, tier (local, dev, qa, stage, prod), client (i.e. customer) created hierarchy of application.properties files and corresponding values that were capable to change behavior of the application for specific host/tier/client provided correct general (default) values as well as client specific per each host/tier that will be overridden during deployment
- #35: Pure Maven was not enough now to easily support such differentiation of application startup.
- #36: Some customers required existing functionality to behave differently as well as some specific new functionality.
- #37: Sass framework was used in order to reasonably generate CSS files per client using variables, nesting, imports, inheritance, etc.
- #38: one database schema per all customers, but some customers needed additional tables, columns, etc. created an internal tool capable of automated execution of some patches to the existing schema per customer during deployment
- #51: lower maintenance cost easier support for "standard" customizations via configuration that can be re-deployed without releasing software easier support for "extended" customization by enforcing a modular architecture with well-defined contracts separated front-end from back-end API move from single-tenancy to multi-tenancy
- #52: lower maintenance cost easier support for "standard" customizations via configuration that can be re-deployed without releasing software easier support for "extended" customization by enforcing a modular architecture with well-defined contracts separated front-end from back-end API move from single-tenancy to multi-tenancy
- #57: Web application framework should be built that would include common features needed by each widget to make it easy for front-end developers to build out these individual web apps with maximum isolation from current stack and back-end engineers
- #58: Web application framework should be built that would include common features needed by each widget to make it easy for front-end developers to build out these individual web apps with maximum isolation from current stack and back-end engineers
- #59: will be single point of knowledge whether use default message properties or client specific, file structure on static assets server, locale to be used by end-user, etc.
- #67: Benefits: reused existing SSO solution
- #68: provides targeting site layout for particular customer and logged-in user in multi-tenant environment as well as targeting site layout for current customer in single-tenant environment provides information if currently user is currently logged in provides URL that should be used to authentication provides URL for static assets endpoint
- #71: 1. visit redesigned widget-based page that has URL under static assets endpoint, e.g. static_assets/redesigned_page. Static assets API will provide page loader if resource is not found. 2. fetch page loader including common skeleton, css customized per customer, common dependencies, clients for main APIs 3. call the targeting API to figure out what tabs to show and what widget to use 4. if widget requires user to be logged in then perform authentication via authentication API 5. fetch widget assets, e.g. markup, css, message properties, client for specific API 6. widget will make further calls to widget specific APIs in order to get data
- #74: one widget in production using described APIs that live inside existing monolith web framework that includes common features needed by each widget to make it easy for front-end developers to build out these widgets with isolation from current stack and back-end engineers