Recommended
More Related Content
Similar to DerbyDev_ModMonolith_290323.pptx
Similar to DerbyDev_ModMonolith_290323.pptx (20)
Recently uploaded
Recently uploaded (20)
DerbyDev_ModMonolith_290323.pptx
- 1. Modular Monolith Architecture Aaron White Senior Software Engineer STEM ambassador
- 2. What are we going to cover • Project requirements at FRF • Consideration and decision on architecture styles • Run through common architecture styles such as monolith and microservice. • Our architecture decision, and why its modular • High level designs and decisions • What are the drawbacks and how do you overcome them • Taking the next steps from a modular monolith • Reflection + Q&A
- 3. Build a cloud native account management platform to replace a sunset legacy system.
- 4. Constraint and Considerations • Speed to market • Small Team • Limited DevOps and microservice knowledge in team • Small initial user count • Small initial budget • On premises services and DBs • Team replacing/upgrading another legacy system
- 6. What is a monolith? • Tightly coupled • Single codebase • Deployed as a single unit • Easy to develop and maintain* • Can become difficult to manage and scale effectively. • Remain a popular choice
- 7. What are microservices? • Broken down into smaller components or services. • Each service is designed to perform a specific task • Developed, tested, and deployed independently of one another • More complex than monolithic architecture
- 8. What is modular monolith? • Hybrid of monolithic architecture and microservices architecture. • Each module is designed to perform a specific task or set of related task • Developed, tested, and deployed independently of one another • Can address scalability issues that can arise with monolithic architectures. • Reduce complexity
- 9. Why modular monolith? • Fast to market strategy • Keep deployment model simple • Ability to scale in future to meet user demand – Microservices split • Cost kept low due to single app deployment • Keeps boundaries clear, avoided premature split of microservices
- 10. How we built it!
- 11. Its not all sunshine • Code duplication and work arounds in API layer • EF core migrations • Mass transit or other package configurations • IDE performance
- 12. How we over came it Created Shared module Created readme Move to singular API projects
- 13. What’s next for the team? Own API Project 1 Containerise each module 2 Deploy independently 3 Create individual databases 4 Separate code 5
- 14. Reflection – When to use modular monolith NEED TO BE FAST TO MARKET SMALL APPLICATION TEAM KNOWLEDGE BUDGET FUTURE MICROSERVICES
- 15. Q&A First Response Finance Careers! https://careers.firstresponsefinance.co.uk/ Get in contact with me! https://www.linkedin.com/in/aaronwhi/ Slide Share:
Editor's Notes
- 10 years experience in enterprise software development Various roles STEM ambassador
- Gut reaction - Break legacy system down into microservices and slowly replace them
- Speed to market was critical – business slowed without legacy system User count around 20, however project to increase to thousands
- Gut reaction - Break legacy system down into microservices and slowly replace them
- A monolith architecture is a type of software architecture where all the components of an application are tightly coupled and interconnected within a single codebase . In a monolith architecture, the entire application is deployed as a single unit, meaning that any changes or updates to one component of the application require the entire application to be redeployed. Monolith architectures are often contrasted with microservices architectures, which break an application down into smaller, more modular components that can be developed, tested, and deployed independently of one another. Monolith architectures can be simpler and easier to develop and maintain than more complex architectures like microservices, especially for smaller applications or teams with limited resources. However, as applications grow larger and more complex, monolith architectures can become difficult to manage and scale effectively, leading to performance and maintenance issues. Despite their limitations, monolith architectures remain a popular choice for many applications and development teams.
- A microservice architecture is a type of software architecture where an application is broken down into smaller, independent components, or services. Each service in a microservice architecture is designed to perform a specific task, and communicates with other services through well-defined interfaces. Because each service in a microservice architecture is independent, they can be developed, tested, and deployed independently of one another, which can lead to faster and more efficient development. Microservice architectures are often contrasted with monolithic architectures, which deploy an entire application as a single unit. Microservice architectures are generally more complex than monolithic architectures, and require careful planning and management to ensure that services can communicate effectively and that the application as a whole can be effectively monitored and maintained. Despite their complexity, microservice architectures have become increasingly popular in recent years due to their flexibility, scalability, and ability to support agile development practices.
- A modular monolith architecture is a hybrid approach that combines the simplicity and ease of maintenance of a monolithic architecture with the modularity and scalability of a microservices architecture. In a modular monolith architecture, the application is still deployed as a single unit, but the codebase is organized into separate modules, each of which can be developed and deployed independently of one another. Each module in a modular monolith architecture is designed to perform a specific task or set of related tasks, and communicates with other modules through well-defined interfaces. Because each module in a modular monolith architecture is independent, they can be developed, tested, and deployed independently of one another, which can lead to faster and more efficient development. Modular monolith architectures are designed to address some of the scalability and maintenance issues that can arise with monolithic architectures as applications grow larger and more complex. While modular monolith architectures can be more complex than traditional monolithic architectures, they can also offer many of the benefits of microservices architectures without the added complexity of managing multiple services. Modular monolith architectures are becoming increasingly popular as a way to balance the simplicity of monolithic architectures with the scalability and modularity of microservices architectures.
- Fast to market – Need to replace legacy system, also teams will use our service in future but not now Deployment simple – Limited knowledge in team, helped with getting up to speed Future scale – ability to break way and scale module if needed Boundaries – ability to move to microservice module
- Gateway -> Single entry point into application / handles authentication and auth API -> Simple there to configure cross cutting concerns, downside of modular monolith Event bus -> communication between modules On prem façade- strangulate services
- EF core migrations – had to fully qualify context, not as quick to developer Package configuration only require one single instance made it difficult to fully separate each module – mass transit Merge issue when all working in close proximity IDE performance will decrease over time -
- Can break into more defined modules, i.e. each have own API and startup
- Gateway -> Single entry point into application / handles authentication and auth API -> Simple there to configure cross cutting concerns, downside of modular monolith Event bus -> communication between modules On prem façade- strangulate services