Take a deep dive into two of the most common software architecture patterns.
Startups are guilty of building software products without a formal architecture in place. Developers, too often, go for the traditional layered architecture pattern. What’s the problem with this? Well, it creates implicit layers by separating source-code modules into packages.
And, what’s the result?
Spaghetti code jungle.
This is often the result of an unstructured system or architecture in place. It lacks a clear direction, is difficult to change & maintain, and is brittle.
Read more about the big ball of mud on Wikipedia.
Points to be covered in this article -
Hence, it's super-important to pay attention to the architecture of any product/software you intend to build.
Some experts might refer to software architecture as a blueprint of a product. Others might want to call it a roadmap for developing software.
No matter how you want to define software architecture as it encompasses the following -
There are various architecture patterns available to help define the basic characteristics and behavior of an application. For instance, some architecture patterns naturally gravitate towards making highly scalable applications, whereas other architecture patterns are inclined towards highly agile applications.
Hence it is very essential to understand the pros and cons of each architecture pattern.
Some common architecture patterns include -
As a product owner, you must understand these patterns and make sure to have solid reasons for a pattern you intend to choose.
Many owners/tech founders face issues when it comes to choosing an architecture pattern. Try out the golden circle method by Simon Sinek to choose the right pattern.
This article discussed the key difference between microservices architecture and the monolith pattern. Let’s get started.
Biggies across the globe including Amazon, Netflix, Etsy and Uber have witnessed immense business gains going the microservices way. So much so that, microservices, now, is the default architecture of countless companies worldwide.
By 2022, 90% of all new apps will feature microservices architectures that improve the ability to design, debug, update, and leverage third-party code; 35% of all production apps will be cloud-native. (Soure: IDC)
But what exactly is it?
Let me begin by describing an interesting fact about Sweden.
If you have been to Sweden or stay there, you will come across variations of the same road markings, road signs, and traffic signals that are used everywhere else in the developed world.
So, how come this country has one of the lowest road accident rates. Could it be better drivers, the ways roads are designed, or stringent traffic laws? Well, these factors certainly do play a role, but as it turns out the credit goes to the Vision Zero program.
I know you must be wondering what has road safety got to do with software architecture or microservices?
Hold on a minute. You will know.
Vision Zero is all about reducing road accident-related deaths to zero. It aims to achieve this by designing road systems that prioritize safety above all other factors, while still recognizing the importance of keeping traffic moving. In other words, a road system that is designed first and foremost with safety in mind.
The core belief is — that the safety of pedestrians and drivers is more valuable than the need to move from place to place as quickly as possible.
Traffic designers apply speed limits, road signs, and traffic movement patterns in a way that benefits the overall safety of the system. For example, while it is necessary to ensure the movement of cars on the road, speed is limited to a level that the human body could withstand in a collision given the technical standards of the vehicles and roads that exist.
While speed limits may impact drivers’ ability to get to their destination as quickly as possible, the design decision is always driven by the requirement to protect human life.
Instead of solely relying on skilled drivers who know how to avoid common mistakes, Vision Zero designers create roads that account for the errors and miscalculations that many human drivers inevitably make. While it is the driver’s responsibility to adhere to the rules of the road, the system designers must do their best to protect humans even in situations where drivers do not conform.
(Source: Microservices Architecture Book, O’Reilly)
Similar to traffic systems, software products grow complex as these scale in the form of scope, volume, and user interactions. So, just like road designers, software architects must know to strike the balance between speed and safety.
Companies use the microservice architecture for faster delivery while at the same time paying attention to safety.
As a variant of the service-oriented architecture structural style, microservices arrange an application as a collection of loosely coupled services. In a microservices architecture, services are fine-grained and the protocols are lightweight.
Functionalities deployed together in a single unit are considered a monolith. There are 3 types of monolith structures — the single-process system, the distributed monolith, and third-party black-box systems.
Simpler deployment — Monoliths result in much simpler developer workflows. Hence, monitoring, troubleshooting, and activities like end-to-end testing become easier & simpler.
Code Reuse —Ever wanted to reuse code within a distributed system? You know what I am talking about. You might have to wonder about breaking out libraries, copying code, pushing shared functionality within a service. With a monolith architecture, the code is just there to use it.
No major re-architecting — It’s way easier to fix monolith-based systems since they have a simpler, singular deployment. Shopify, one of the well-known e-commerce store builders, was deployed using a monolith architecture in its initial days. It is based on Ruby on Rails. However, they have now shifted to a microservices architecture based on their ever-growing engineering needs.
Easy Maintenance — Maintaining an entire codebase in a single base definitely has its advantages. No complexities whatsoever. Just maintain one repository and you are done. Only one test and deployment pipeline needs to be taken care of.
No API worry — With monoliths, developers can call into different components directly instead of using APIs. So, you don’t need to maintain those versions and worry about backward compatibility.
Here’s an interesting conversation that includes why monoliths are the future.
Taking the example of Shopify further, its monolith-based architecture was no longer serving its purpose in 2016 when both the platform and team grew.
Kirsten Westeinde, Developer at Shopify, explains in detail as -
The application was extremely fragile with the new code having unexpected repercussions. Making a seemingly innocuous change could trigger a cascade of unrelated test failures.
For example, if the code that calculates our shipping rate called into the code that calculates tax rates, then making changes to how we calculate tax rates could affect the outcome of shipping rate calculations, but it might not be obvious why. This was a result of high coupling and a lack of boundaries, which also resulted in tests that were difficult to write, and very slow to run on CI.
Developing in Shopify required a lot of context to make seemingly simple changes. For example, a new developer who joined the shipping team should only need to understand the implementation of the shipping business logic before they can start building.
However, the reality was that they would also need to understand how orders are created, how we process payments, and much more since everything was so intertwined. That’s too much knowledge for an individual to have to hold in their head just to ship their first feature. Complex monolithic applications result in steep learning curves.
Sam Newman, a renowned, independent microservices consultant tells one should answer the following questions before going the microservices way.
1. What are you hoping to achieve?
This should be a set of outcomes that are aligned to what the business is trying to achieve, and can be articulated in a way that describes the benefit to the end-users of the system.
2. Have you considered alternatives to using microservices?
There are often many other ways to achieve some of the same benefits that microservices bring. Have you looked at these things? If not, why not? Quite often you can get what you need by using a much easier, more boring technique.
3. How will you know if the transition is working?
If you decide to embark on this transition, how will you know if you’re going in the right direction?
Both monolith and microservices architecture are suited in specific circumstances based on what business you operate & at which stage is it. When doing microservices, make sure you are crystal clear about the goals you are trying to achieve. Those can’t be vague or else it might be a nightmare for your business. What’s your experience like with monolith and microservices? Did you migrate? Feel free to share your experience and outcomes with these software architecture patterns.