Over the past few years, we have been assisting Customer X, an education provider offering courses across various levels, including high school, occupational, and higher education, on a significant project to revamp their student- and course administration system. This blog explores the top 5 lessons learned, especially focusing on the shift in system architecture. Despite their obvious advantages, it highlights how microservices are not always the best choice.
Monolithic vs. Microservices: Key Differences
The debate between monolithic and microservice architectures has been common in software development, but recently, there has been a shift from a politicized debate to one that focuses on the best practices and applications of both.
While a Monolithic Architecture is associated with:
- Single codebase managing multiple functions, making it interdependent and tightly coupled.
- Modifications and scaling of the entire application are time-consuming and resource-intensive.
Microservices Architecture is associated with:
- Comprises small, independent components each performing a single function.
- Enhances flexibility by allowing each service to be updated, modified, deployed, and scaled independently.
Learn more: a comprehensive comparison on AWS.
Further on, when it comes to operational impact, choosing microservices can accelerate innovation by allowing the use of different frameworks and technologies, reducing risks associated with deployment and service outages, and speeding up time to market. Moreover, it can decrease the total cost of ownership since services run independently on specific hardware and platforms.
All this being said, you might get the impression that microservices are better? While microservices offer several theoretical benefits, our experience while developing for Customer X was somewhat mixed and highlighted some practical challenges.
Real-World Application
Theoretical claims vs. Reality of the real world:
- It is easier to start with Monolithic architecture: Monoliths are known to be easier to start off due to local dependencies like SQL Server and Azurite, with settings managed through JSON app settings. We experienced this as well.
- Monolithic architecture has increased complexity over time: Monolithic systems are known to become increasingly complex, requiring entire system retesting and redeployment upon updates, leading to potential downtimes. What system does not become more complex as it grows? This is true in any case, size and bad organization will increase complexity no matter the architectural form.
- Debugging and scaling are easier in monolithic architecture: Debugging is simpler with monoliths as it involves one stack trace across services, but scaling requires significant resources that may not be efficiently used across all components. This is true, but it is not applicable if you choose a bad and sequential test architecture for deployment, which we unfortunately did, and has cost us for the remaining of our development.
- Monolithic architecture is easier to deploy and debug: Customer X's need to understand cross-service interactions substantiated the claim that monolithic systems are easier to deploy and debug.
- Monolithic architecture is more costly to scale: Scaling monolithic systems often results in resource wastage since not all parts are at peak capacity. This might be true, but it is also true that microservices that are not monitored may run very high costs. The lesson here is that optimalization before scaling is key no matter what achitecture you are building on.
Top 5 Project Improvements and Lessons Learned
It was a constant discussion and push and pull between monolithic and microservice architectures; pros and cons, in this project, and in the end the team felt they had utilized the best of both worlds. These were our top five improvements during the project as well as lessons learned:
- Adopting Entity Framework: Allowed seamless database updates and simplified data management within migration scripts.
- Isolating Functionality: Despite the monolithic architecture, we isolated certain functionalities like BankID signing into separate microservices to streamline deployment and maintenance.
- Enhanced Developer Onboarding: Simplified onboarding processes enabled developers to begin work almost immediately.
- Reduced Documentation: Leveraged DevOps comments and tasks as a form of live documentation, reducing the overhead of traditional documentation.
- Efficient Migrations: Streamlined migrations emphasized the practical benefits of integrating and testing changes more effectively.
Conclusion
The experience of Customer X underscores that while microservices boast substantial advantages, they come with complexities that may not be suitable for every project. Each architectural decision should be weighed carefully, considering the specific needs and constraints of the project. As demonstrated, the right choices at the beginning of a project can significantly influence both performance and cost-effectiveness over time.
I hope this was insightful 💚 Don't hesitate to reach out if you have any questions!