Uploaded byTaras Matyashovsky
New life inside monolithic application
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.
More Related Content
Similar to New life inside monolithic application
![5G Explained! A High Level Overview [Introduction]](https://cdn.slidesharecdn.com/ss_thumbnails/5gexplainedahighleveloverview-260119165306-cc137a3e-thumbnail.jpg?width=640&height=640&fit=bounds)
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.
- 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 • businessdomain is not important • this presentation is not intended for monolithic vs. micro services architectures comparison Introduction
- 6. Agenda • You’vedecided 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 toBuild 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-5years 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 yearsago you’ve probably have chosen: • Maven 2.x • Jetty 6.x • Jenkins • Subversion • JIRA • Confluence You’ve built a startup
- 12. You’ve Built aStartup You’ve built a startup
- 13. Architecture Not thinkingabout: •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 builta startup
- 16. Architecture You’ve builta startup
- 17. Architecture You’ve builta startup
- 18. You’ve Built aStartup 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 aStartup with reasonable trade-offs and compromises You’ve built a startup
- 20. You’ve Built aStartup And it became a successful product You’ve built a startup
- 21.
- 22. Internal Quality •timeto market vs. internal quality •business logic becomes more and more complicated Early Issues
- 23. A Lot ofCustomers •each customer wants specific features •seamless integration •l10n, i18n Early Issues
- 24. Early Issues EarlyIssues
- 25. Issues => Challenges Early Issues
- 26.
- 27. Internal Quality “Awell-written program is a program where the cost of implementing is constant thought-out the project lifetime” Solutions
- 28. Internal Quality •formalcode review process via Atlassian Crucible •integration with CheckStyle/PMD with strict set of rules Solutions
- 29. Internal Quality •unit/integrationtests •functional tests bases on htmlunit/jwebunit written and maintained by developers Solutions
- 30. Internal Quality •automationtests framework based on Ruby/Selenium/Cucumber written and maintained by QA engineers •performance tests using NewRelic Solutions
- 31. A Lot ofCustomers Still continue with maturity level 2 and tackle customization, i18n, l10n problems separately Solutions
- 32. Maturity Level 2 Solutions
- 33. Internal Customization •isimplemented 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 •createdadditional 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 databaseschema per all customers •patches per customer during deployment Solutions
- 38. Code Organization •maintainedone 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 andproduct 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 productthat overgrew startup stage and is delivered to more than 90 customers all over the globe Solutions
- 43.
- 44. Business Issues •customizationis 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 •highmaintenance cost •not effective utilization of resources Still not Enough
- 46. Engineering Issues •itis impossible to develop/test new features without the entire stack running •high cost for even tiny change Still not Enough
- 47. Unfortunately Current applicationis expensive to maintain, customize and configure Still not Enough
- 48.
- 49. New Solution Redesignexisting 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 architecturewith well-defined contracts •split of front-end and back-end with possibility to easily provide public API New Solution
- 52.
- 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 describeheader, footer, as well as main page loader •unique per application New Solution
- 55. Page Layout •willbe defined via templates that describe containers in which appropriate widgets will be loaded New Solution
- 56. Widget •separated webapplication representing some major feature of application New Solution
- 57. Widget • isa 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 •willprovide data essential to build page layout based on a template with widgets to be loaded in particular containers New Solution
- 59. Sequence Diagram HTMLSkeleton 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 NewSolution
- 61.
- 62. Nuance That shouldbe done in parallel with the existing application development New Solution
- 63. Nuance One proof-of-conceptwidget with corresponding APIs should be implemented to prove future architecture New Solution
- 64.
- 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 •isused 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 NewLife inside Monolith
- 73. New Approach •onewidget 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.
- 76. Next Goals •improveweb framework, e.g. repository management, end to end tests, etc. •rebuild other pages using widgets approach when needed Next Goals
- 77. Next Goals •dismantlethe monolith using SOA-like services •create mobile clients connected to redesigned unified API Next Goals
- 78.
- 79.
- 80. •migrated frontend fromRuby to Node.js infrastructure •the old monolithic frontend was split up into ~20 separate web apps Groupon Way “Dismantling the Monoliths”
- 81. •ability to deploychanges to applications independently •ability to make site-wide feature and design changes much more quickly Groupon Way “Dismantling the Monoliths”
- 82.
- 83.
- 84. Conclusions •monolithic applicationscan be successful Conclusions
- 85. Conclusions •you shouldhave a good reasons for dismantling as well as for choosing micro services architecture Conclusions
- 86. Conclusions •gradual dismantlingthe monolithic application is doable Conclusions
- 87.
- 88.
- 89. A Good Architecture Enables Agility By Simon Brown, @simonbrown, http://www.simonbrown.je/
- 90. Just Think Ifyou 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. MicroServices By Aviran Mordo, https://twitter.com/aviranm/status/531925339518148609/photo/1
- 92. Monolith vs. MicroServices Instead of Epilogue
- 93. Thanks! Questions? NewLife 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