Introducing microservices

A microservice architecture decomposes an application into loosely coupled, independently deployable services that own their data and communicate through lightweight protocols. It breaks down large applications into smaller, self-contained business capabilities, enabling faster development, easier scaling, and better fault tolerance. Microservices enable continuous delivery and agile development by allowing teams to independently build, test, and deploy features. You can imagine an application as an orchestra, where each microservice is a musician playing their part, but in perfect harmony with the others, to create a beautiful symphony.

What we’ve just mentioned sounds like a silver bullet but as you know, nothing is free and there is no one-size-fits-all solution to the problems we face. The same applies to microservices.

We, as software developers, love to learn new trends and try to apply them to our practice. But after delving into the details, we understand that every trend is just an encapsulation of old knowledge. Before applying any architecture to software, it is always better to engage in careful planning, discussion, collaboration, and analysis.

Moving toward microservices

Creating software is more than just learning a programming language and applying syntactical elements of it to code, to build things. It’s like wielding a hammer and nails; having them in your arsenal doesn’t make you a skilled builder. Similarly, having all the tools doesn’t make you a good software developer.

As you embark on creating a basic hello world type application, it remains just that – basic. However, it is important to understand that such simple applications don’t warrant payment. If you want your application to have value, it must address tangible real-world challenges – in short, it should hold business value. Adding more business value also brings complexity. In most cases, more business means more complexity. After some time, you’ll realize that instead of dealing with a business, you’re starting to deal with the complexity that your business brought to your application.

In navigating complexity, we aim to break it down into smaller, maintainable, extensible, and reusable components. Only by doing so can we effectively handle the complexity and future changes. In programming, the only true constant is the need to embrace changes, a principle that remains as-is, not just during the process of creating the application, but until the end.

This constant change forces us to not only master the selected programming language but also to have an understanding of the business domain. Naturally, this leads to us adopting a design-oriented mindset. Without having good knowledge of business, it is almost impossible to develop valuable software.

Although the simple applications we write to learn a language may seem useless, when we connect the dots, we get closer to the truth. Isn’t our whole life spent in search of truth? Soon, you’ll realize that the software that meets the customer’s business requirements is the software that matters, and that reflects the truth.

If you start your development process without carefully analyzing and designing, you’re going to pay a higher price throughout the development itself. The earlier you start with design and analysis, the less likely you are to run into a bigger problem at a later stage. We call our first not properly analyzed and designed application a big ball of mud that uses spaghetti-driven development:

In software design, the phrase a big ball of mud is used to draw attention to an anti-pattern or a design approach that produces undesirable results. Let’s understand this phrase in more depth.

Understanding a big ball of mud

The main issue with a big ball of mud is the lack of structure and organization. The absence of modularity and distinct issue separation in the code base leads to a complex network of interconnected files and functions. Imagine a house that is just a disorganized jumble of rooms and materials with no walls or other distinguishing features. Because everything in it is connected, changes that are made in one part could have a disastrous effect on other parts. It’s like pulling on a loose thread in a badly tailored sweater – you run the risk of the entire garment coming apart. Similarly code fragments are dispersed throughout the code base, which causes inefficiencies when performing maintenance.

Due to the absence of structure and documentation, maintaining the code base and adding new features is challenging for developers. Imagine attempting to navigate a house devoid of layout or labels; it’s nearly impossible.

Because of their close coupling, changes in one area can unintentionally disturb seemingly unrelated components. Because of its fragility, the software is prone to mistakes and regressions. Imagine a house built with weak, interconnected supports so that even a small outside force could result in serious harm.

A big ball of mud may seem like the right choice at first in small, simple projects, but as the project grows and develops, its complexity quickly increases. To guarantee long-term maintainability, scalability, and developer satisfaction, this design approach must be avoided at all costs.

Guess what? I already know that you’ve gone through this stage – the stage of applying and failing with a big ball of mud. These difficulties helped you learn more rather than learn from success.

Every difficulty teaches us something, right? Until one year in my life, I was always grateful for the good things in my life. But over time, I realized that it was those difficulties that made me who I am. After I changed my way of thinking, I began to thank the difficulties in my life and those who made me suffer. If you could go back and remove the difficulties in your life, believe me, you would also remove your present self. Difficulties strengthen you and make you a strong person.

Mankind is a creature that rarely listens to advice. We have to get into trouble – we have to experiment with trouble. I know that the downsides I mentioned about a big ball of mud in this section only make sense to those who have gone through this difficulty. In the end, we all learn through experimenting.

As a novice software developer, it’s beneficial to experiment with a big ball of mud at some point. You’ll quickly discover that while it provides a swift start, its efficiency dwindles over time.

Let’s try to summarize the disadvantages of a big ball of mud:

• Unplanned and chaotic: The appearance of a big ball of mud is the result of poor design and coding techniques rather than a deliberate architectural decision.
• Tight coupling: The code is tightly interconnected; changes that are made to one section run the risk of having unexpected effects in unrelated areas.
• Difficulty in understanding and maintaining: The code base is messy and lacks documentation, making it hard for developers to grasp and modify.
• Error-prone and fragile: The code base leads to unpredictable errors and regressions with modifications. In a big ball of mud system, everything is tightly connected like a big mess of wires. This makes it hard to know what happens when you change one part, like trying to fix one loose wire in a tangled mess. This can easily lead to unexpected problems and things breaking, like causing a short circuit in the tangled wires, making it harder to develop and maintain the system in the long run.
• Reduced developer productivity: You spend more time on maintaining the code base instead of focusing on new features.
• Limited scaling and growth: A rigid code structure makes it difficult to introduce new features or adapt to changes:

Figure 1.1: A quality diagram of a big ball of mud

When writing a program, we see that it becomes more of a problem than a solution within a short time (see Figure 1.1). The preceding graph tracks how a project progresses over time. Time is on the bottom (X-axis) and features added are on the side (Y-axis).

Starting a project without a clear plan, such as using the big ball of mud approach, might seem easy at first. Imagine building with blocks – no instructions are needed and you can put things together quickly. But for these projects, as they get more features (higher Y-axis value), the overall quality suffers (gets worse).

In the short term (a few weeks), both well-designed projects and big ball of mud projects might seem similar. But over time, the quality of the messy project goes downhill.

Overall, while a big ball of mud approach might seem faster initially, it ultimately creates more problems in the long run. It’s like taking a shortcut that might save you time now but leads to bigger issues later on.

One of the factors that turned our code into a big ball of mud over time was a lack of planning and organization. Planning and organizational structure are the attributes we usually use when building microservice architecture.

Understanding the software development process

The development process not only covers coding – it is also about business, communication, discussion, analyzing, designing, testing, and deploying. Let’s call these the attributes of the software development process (see Figure 1.2). Software development is much more than just writing code lines. While coding is certainly an important part, it’s only one piece of the puzzle. Because of that, it is essential to understand the core needs and goals of the business:

Figure 1.2: Software development life cycle

The following list provides comprehensive insights into the software development process:

• The need to solve specific problems and think in terms of the business landscape is what drives software development. For developers to create software solutions that are not only relevant, but also meaningful, they must have a deep understanding of market dynamics, industry, and user requirements.
• Effective collaboration and transparent communication are the backbone of success at every stage. Developers engage with a range of stakeholders, including business analysts, designers, testers, and clients. Clear communication ensures that everyone is on the same page regarding objectives, requirements, and project milestones.
• Discussing the ideas, obstacles, and potential solutions is very important. Effective brainstorming sessions, code reviews, and attentive user feedback all contribute to the quality of software. Open communication makes problem-solving more efficient.
• It is essential to carry out a thorough analysis of the requirements, user behavior patterns, and data insights. To create a solid software design strategy, developers must carefully analyze existing solutions, identify user needs, and break down complex problems.
• Careful consideration must be given to the architecture, functionality, and user interface of the software. Software that has been carefully designed is easy to use, effective, and maintain. A friendly user experience is the result of close collaboration between developers and designers.
• Strict testing procedures are essential to guarantee the functionality, dependability, and conformity of the software regarding user expectations. Different testing approaches address different areas, such as performance benchmarks and core functionality.
• Ensuring that end users can access the software is the last step. This is usually called deployment. This includes setting up the infrastructure, taking stringent security precautions, and, if needed, providing thorough user training to optimize usability and adoption rates.

Now that we understand the software development process, let’s take a deeper look at the monolith approach to software development.