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
Build a cloud native account
management platform to replace a
sunset legacy system.
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
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
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
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
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
Its not all
sunshine
• Code duplication and work arounds in API layer
• EF core migrations
• Mass transit or other package configurations
• IDE performance
How we over came
it
Created Shared module
Created readme
Move to singular API
projects
What’s next for the team?
Own API
Project
1
Containerise
each module
2
Deploy
independently
3
Create
individual
databases
4
Separate code
5
Reflection – When to use modular monolith
NEED TO BE FAST
TO MARKET
SMALL
APPLICATION
TEAM
KNOWLEDGE
BUDGET FUTURE
MICROSERVICES
Q&A
First Response Finance Careers!
https://careers.firstresponsefinance.co.uk/
Get in contact with me!
https://www.linkedin.com/in/aaronwhi/
Slide Share:
Notas do Editor
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