Microservice Stories

This article reflects on the challenges of implementing microservices in software development, specifically focusing on the difficulties of data sharing and sorting data across multiple services. The author, a tech lead with experience in microservices, discusses a scenario where their team transitioned from a monolithic architecture to microservices, only to encounter complexities in handling tasks like displaying and sorting a list of data from different services.

This article critiques the current trend in tech culture of unnecessarily complex microservices architectures, likening it to a form of professional overkill. It argues that the push towards microservices, often influenced by the practices of large tech companies and a surplus of venture capital, leads to inefficiency and complexity without necessarily solving the real problems at hand. The author suggests that simpler, more straightforward systems (like monoliths) are often more effective and efficient, and that the industry's focus should shift back to pragmatism and simplicity in system design.

In this video, the creator of Ruby on Rails discusses why he thinks microservices are overused in web application development teams. He argues that microservices solve an organisational problem, not a code problem, and that Monoliths are better for most organisations.

The article emphasizes that choosing an architecture should not be binary; both microservices and monoliths have their merits, and a mixed approach can be beneficial. The article also highlights that while microservices offer flexibility and scalability, they also add complexity, suggesting that not all parts of an application need to be microservices-based.

This post discusses Amazon Prime Video's transition from a microservices-based system to a more efficient solution, initially labeled as monolithic, highlights the evolving nature of software architecture. This case underscores the importance of choosing an architecture based on specific business needs rather than rigid adherence to a particular style, demonstrating that effective solutions can blur traditional distinctions between monolithic and microservices approaches.

In this video, William Brander explains how trying to migrate to microservices often leads organisations to build terribly architected systems. It includes plenty of diagrams explains the concepts and various pitfalls involved in building microservices well.

This post discusses how the Prime Video team used a Serverless First approach to rapidly prototype a real-time user experience analytics engine, ultimately refactoring it into a horizontally scaled microservice. This demonstrates that while microservices can be oversold as the answer to everything, they are still an effective way to build, manage and operate at scale with a large team.

This post demonstrates that there is not one architectural pattern to rule them all, and that the choice of microservices or monoliths should depend on the product design, skillset of the team, and customer experience. Additionally, it emphasizes the importance of regularly evaluating systems and allowing for evolvable architectures in order to keep up with the ever-changing technology landscape.

This post discusses the concept of microservices, and emphasizes that while it may be a viable option in some cases, it should not be blindly pursued as replacing existing method calls and module separations with network invocations and service partitioning can be madness.

This article discusses a technique for making a monolith more scalable and reliable without the complexity of microservices, which is to split workloads into separate tiers of deployment. It also details how to use guardrails and limits around resources such as databases to protect against rogue or timed code consuming too many resources.

This post discusses how GitHub has been able to upgrade Rails and Ruby regularly, resulting in a faster and more reliable monolith application. Furthermore, it emphasizes the importance of investing in frameworks such as Rails, which can provide greater stability for monoliths compared to microservices.

This post discusses how Prime Video used a monolith architecture to reduce infrastructure costs and improve scaling capabilities for their video quality analysis tool. This was an alternative to using microservices and serverless components, which were originally implemented but caused expensive data transfer and orchestration problems.

This post provides 12 tips for transitioning from a monolith to microservices, emphasizing the importance of proper preparation and research before making the change. It discusses the different technical aspects of the migration such as implementing CI/CD, setting up containers, and refactoring the monolith.

This post discusses the revenue threshold companies must reach before it is beneficial for them to move from a monolith architecture to a microservices one. It outlines the various stages of architecture that can be implemented, such as service-based, macroservices, miniservices, and microservices.

This article is a generic overview of microservice and monolithic based architectures, outlining the pros and cons of each.

This article discusses the pros and cons of using a microservices architecture versus a monolithic structure. It explains how a well-designed, modular monolith can provide many of the same benefits as a microservices architecture while avoiding some of the complexity.

This post discusses the pros and cons of implementing microservices versus monoliths in web software architecture. It argues that while microservices offer additional flexibility, for most teams, it is often more cost-effective to stick with a monolith and improve upon its design instead.

This post discusses how monolithic applications can cause problems such as degrading system performance, stability, and slow development cycles that can be alleviated by transitioning to a microservice architecture.

This post discusses how microservices architecture can be used to improve the performance of top-of-funnel pages on a website by using Command Query Responsibility Segregation (CQRS) and event sourcing, as well as an asynchronous alternative.

This post explains that choosing between monolithic and microservices architectures depends on specific project needs. Monolithic applications are simpler to develop but can struggle with scalability and complexity as they grow. Microservices offer more flexibility and easier scaling but are more complex and require specialized skills. The decision should consider factors like application complexity, team size and expertise, anticipated growth, and budget.

This post explains the journey of merging microservices back into the monolith at InVision to "right size" the system and reduce friction, while also discussing the benefits and disadvantages of Conway's Law in a post-microservices world.

This post explores how Picnic 'went microservices', discussing the various considerations and decisions that had to be made for a successful transition from monolithic to microservice architecture. It also looks at some of the ways that developers can maintain their workflow and how databases can be included in the microservice design process.

This post is not available or is entirely undefined, therefore it cannot be summarized or related to topics of microservices and/or monoliths.

This post discusses how monoliths can be leveraged to provide the performance benefits of service-based architectures, while also allowing for scalability and flexibility. It outlines how the servicecore framework allows applications to be coupled or decoupled easily for better maintainability, without sacrificing features.

This post explains how a development team, after investigating and preparing to move to microservices, decided to stay with their monolithic architecture instead. It highlights how microservices may not be the ideal architectural solution for every business, and that careful consideration should be taken before making any major changes.

This post details the experience of an experienced CTO in a top digital product agency, and how they use agile methodologies to create solutions for complex problems. It is relevant to microservices and monoliths, as the CTO's experience is valuable when deciding between these two software architecture patterns.

This article outlines the process of breaking out a monolith into microservices, including the technical steps and considerations necessary to do so. It also explains the cost savings and improvements in code quality, speed, and bug fixing that can be achieved by transitioning from monoliths to microservices.

This post discusses how the hype around microservices is starting to subside and some companies are considering migrating back to a monolith. It examines the complexity of onboarding new engineers and debugging with microservices, as well as the challenge of testing multiple services at once.

This post compares microservices and monolith architecture, discussing which type of architecture is best suited for certain teams and projects. It outlines the advantages and disadvantages of each, including scalability, cost, and deployment time.

This article discusses the difference between a monolith and a distributed monolith, which is a set of physically distributed services that are intertwined. It also emphasizes the importance of baby steps when considering a microservices implementation and starting off with a monolith, as it allows developers to figure out where the natural boundaries are in their system and design service boundaries more efficiently.

This article explores the considerations which should be made when deciding whether to start a project with microservices or a monolith, using an example of Darby Frey's experiences at Gamut. It provides general guidelines on when each approach might be more suitable, and stresses the importance of evaluating one's own circumstances before making a decision.

This article emphasizes that the choice depends on specific context, particularly considering scalability and domain complexity. For simpler domains with high volume needs, microservices are suitable, whereas complex domains with limited volume are better served by modular monoliths. Building a modular monolith requires thoughtful implementation to avoid issues like cyclic dependencies and "JAR hell". The article also suggests that in some cases, starting with a modular monolith and transitioning to microservices as volumes increase can be an effective strategy

The article highlights the implementation challenges with microservices, such as loss of transactions and referential integrity. It points out that both monoliths and microservices need a supportive platform, with microservices focusing on network complexities and monoliths on technical concerns. The concept of "Monolith First" is also introduced, emphasizing the importance of well-defined modules for future transition to microservices.

This article discusses the dangers of a micro-monolith anti-pattern, which can arise when teams create a single-page application from fragments of frontend code provided by different microservices. It also offers solutions to ensure that each service remains independent and is able to be tested in isolation.

This post emphasizes that both microservices and monoliths have their place when it comes to developing applications. It provides multiple examples of how each approach can succeed or fail depending on the execution, and also outlines best practices for transitioning to microservices.

This article explains that, while microservices are a great pattern for large organizations, smaller teams should embrace the monolith and make it majestic in order to maximize productivity and create beautiful, understandable code.

This post explains how to start developing a server-side application either with a monolithic architecture or by breaking it down into microservices. It also outlines the benefits and challenges of both approaches and explains how the microservices pattern corresponds to the Y-axis scaling of the Scale Cube model of scalability.

This post discusses the transition of Wix from a monolithic architecture to a service-level driven microservices architecture. It also outlines the tools and processes used to develop, deploy, and scale in this model.

This post discusses the pros and cons of starting a new project with either microservices or monoliths, suggesting that while microservices are useful, they come with a cost and should only be used when more complex systems are at play. It suggests a monolith-first approach for simpler applications.

This post describes Sourcegraph, which helps dev teams to search and navigate code, allowing them to find answers quickly. By facilitating code navigation, Sourcegraph is useful for both microservices and monoliths architectures, enabling developers to understand the structure of their codebase better.

This post emphasizes that the decision to adopt microservices should be based on the specific needs and capabilities of an organization, cautioning against blindly following trends without considering factors like the increased operational (Ops) work and resource scarcity. It suggests that while microservices can reduce resource contention and coordination friction, they also introduce more complexity and risk, making it vital to balance these aspects against an organization's ability to effectively manage the increased Ops/Dev ratio and operational challenges.