We’ve been aware for some time now of a growing sentiment of dissatisfaction with the popular microservices and serverless architectures, coinciding with growing skepticism towards the once universally-lauded agile project management methodologies.
I mean, if even Scrum.org writes an article like this one about why agile at times doesn’t work, you know something’s up. As you read the article, you realize that it’s mostly a blame slinging litany (never doubting their methodology, though). When you have to explain away your issues this exhaustively, you know you have a problem.
Let’s examine the advantages and disadvantages of these approaches to identify when they are suitable and when caution is necessary. Let’s first start with a few definitions/descriptions:
Microservices
Microservices excel at breaking down ultra-complex and behemoth applications into manageable components, offering scalability and fault isolation. However, managing communication and consistency across services can be challenging, and for small or simpler applications, the benefits may not outweigh the complexity. Moreover, deploying and monitoring microservices demand advanced tools and skilled operations teams.
Serverless Architectures
Serverless architectures offer automatic scaling and reduced operational overhead. Yet, they’re not universally applicable. Applications with long-running tasks, high performance needs, or constant high loads might not be well-suited for serverless. Limitations like cold start delays and vendor lock-in risks must also be considered. Plus, let’s not even talk about hosting costs.
Agile Methodologies
Agile methodologies are especially well-suited for teams dealing with microservice/serverless builds. Methods like Scrum prioritize collaboration, flexibility, and iterative development, enabling teams to (in theory) adapt quickly. However, in certain scenarios, a structured approach like waterfall may be more suitable…think monolithic applications. Highly regulated industries, large-scale projects with long-term planning, or projects with fixed scope and budget may require a more rigid methodology. Agile relies on strong communication and collaboration with quick reaction times, posing challenges for remote or distributed teams.
When to Reconsider
No approach fits every situation. Microservices and serverless architectures may be overkill for simpler applications that don’t require their benefits and don’t have large budgets for cases of high server traffic. Similarly, agile methodologies may not suit projects with fixed constraints. If you combine both, you’d be looking at high levels of complexity management in your foreseeable future. The decision to adopt any of these approaches should consider project requirements, team capabilities, and business goals. Blind adherence without considering the context can lead to suboptimal outcomes.