Hands-On Microservices with JavaScript E-Book

Tural Suleymani

• Herausgeber: Packt Publishing
• Kategorie: Fachliteratur
• Sprache: Englisch

Seitenzahl: 501

Veröffentlichungsjahr: 2024

Beschreibung

Keep up with the ever-evolving web development landscape by mastering JavaScript microservices with expert guidance from Tural Suleymani—a full-stack software engineer, architect, software development teacher, Microsoft MVP, and three-time C# Corner MVP. He distills over a decade of experience crafting high-performance, scalable solutions into this guide. He’ll walk you through the fundamentals of microservices, providing a solid foundation in architecture, design principles, and the necessary tools and technologies. From beginners to seasoned developers, this book offers a clear pathway to mastering microservices with JavaScript.
With the help of hands-on tasks that simulate real-world scenarios, you’ll learn how to build reliable and scalable microservices. You’ll explore synchronous and asynchronous communication, real-time data streaming, and how to secure and monitor your services. The book’s emphasis on a design-first approach ensures that your microservices are maintainable and future-proof. Detailed case studies from industry experts will enhance your learning experience and provide practical insights into building microservices in production environments.
By the end of this book, you'll be ready to create cloud-ready, high-performing microservices using cutting-edge JavaScript frameworks and tools and tackle real-world challenges, ensuring your applications are secure and efficient.

Leseprobe

Hands-On Microservices with JavaScript

Build scalable web applications with JavaScript, Node.js, and Docker

Tural Suleymani

Hands-On Microservices with JavaScript

Copyright © 2024 Packt Publishing

All rights reserved. No part of this book may be reproduced, stored in a retrieval system, or transmitted in any form or by any means, without the prior written permission of the publisher, except in the case of brief quotations embedded in critical articles or reviews.

Every effort has been made in the preparation of this book to ensure the accuracy of the information presented. However, the information contained in this book is sold without warranty, either express or implied. Neither the author, nor Packt Publishing or its dealers and distributors, will be held liable for any damages caused or alleged to have been caused directly or indirectly by this book.

The author acknowledges the use of cutting-edge AI, such as ChatGPT, with the sole aim of enhancing the language and clarity within the book, thereby ensuring a smooth reading experience for readers. It’s important to note that the content itself has been crafted by the author and edited by a professional publishing team.

Packt Publishing has endeavored to provide trademark information about all of the companies and products mentioned in this book by the appropriate use of capitals. However, Packt Publishing cannot guarantee the accuracy of this information.

Group Product Manager: Kaustubh Manglurkar

Publishing Product Manager: Bhavya Rao

Book Project Manager: Sonam Pandey

Senior Editor: Ayushi Bulani

Technical Editor: K Bimala Singha

Copy Editor: Safis Editing

Indexer: Manju Arasan

Production Designer: Prashant Ghare

First published: December 2024

Production reference: 1221124

Published by Packt Publishing Ltd.

Grosvenor House

11 St Paul’s Square

Birmingham

B3 1RB, UK

ISBN 978-1-78862-540-1

www.packtpub.com

To Elvira, my steadfast companion, whose unwavering love and support has been the bedrock of my life and work. To Turgut and Farah, my beloved children, whose existence fills my world with immeasurable joy and purpose.

Every challenge I’ve faced has been a crucible, forging the strength and resilience necessary for this journey. I am eternally grateful for the trials that have shaped me, and for the love that has carried me through.

– Tural Suleymani

Contributors

About the author

Tural Suleymani is a seasoned software development expert with over a decade of industry experience. Renowned as Azerbaijan’s first Microsoft MVP in .NET and a three-time C# Corner MVP, he has established himself as a leading authority in his field. With a passion for sharing knowledge, Tural has dedicated ten years to mentoring developers through comprehensive programming languages and technology tools instruction. A self-taught pioneer, he empowers a global audience through his TuralSuleymaniTech YouTube channel, where he delivers in-depth tutorials and insights on C#, Apache Kafka, SQL, JavaScript, Domain-Driven Design, software architecture, microservices, and more. His deep technical knowledge and practical insights have empowered countless developers through his work as a mentor, educator, and public speaker. He also holds prestigious certifications including MCP, MCSA, and MSCD from Microsoft. Tural is also a Udemy instructor, further expanding his educational reach. Currently, Tural holds the position of Chief Software Architect at VOE Consulting, where he continues to innovate and lead in the software development industry.

About the reviewer(s)

Rasul Huseynov is a senior software developer and consultant with over seven years of experience in delivering high-quality software solutions. He graduated with high honors in computer engineering and brings deep expertise in Object-Oriented Analysis and Design (OOAD), Extreme Programming, and Distributed Systems. Holding certifications such as MCP, MCSA, and MCSD, Rasul has a solid foundation in Microsoft technologies and has successfully delivered numerous web projects. His experience extends to ensuring that software solutions are robust, maintainable, and efficient while adhering to industry best practices.

Adewole Caleb is a skilled backend engineer with a solid foundation in JavaScript, Golang, and TypeScript. Over his five years of professional experience, he has built a reputation for his curiosity, problem-solving abilities, and dedication to continuous learning. Having recently graduated, Caleb is now exploring a career transition into distributed and system engineering. Beyond his professional work, Caleb is deeply passionate about music. He finds joy in playing the guitar, singing, and participating in other activities that allow him to express his creativity. Caleb volunteers as a boot camp tutor, where he shares his knowledge and experience to inspire budding developers.

Joel Edmond Nguemeta is a full-stack developer and mentor with expertise in web application development and system design. He has worked as a mentor and evaluator at OpenClassrooms, providing personalized support to numerous students and contributing to their professional growth. As a mobile developer at Tamangwa Shipping, he designed several custom systems tailored to the company’s specific needs. Joel also has solid experience in creating and implementing microservices architectures, ensuring scalability and performance. He regularly shares his knowledge and technical advice on his YouTube channel, which is dedicated to the developer community.

Jean Clayton Seraphin is an accomplished full-stack developer with over five years of experience in the industry. He has honed his skills in building robust APIs using Python and Django, as well as crafting engaging frontend applications with ReactJS. Beyond his expertise in web development, Jean Clayton Seraphin boasts an advanced understanding of servers and cloud services, particularly in the realm of AWS. He is well-versed in Linux administration and proficient in utilizing infrastructure-as-code tools such as Docker, CircleCI, and Nginx to streamline deployment and ensure the scalability and reliability of his projects.

Table of Contents

Preface

Part 1: Fundamentals of Microservices Architecture

1

Introduction to Microservices

Introducing microservices

Moving toward microservices

Understanding a big ball of mud

Understanding the software development process

Exploring the monolith approach

What is service-oriented architecture?

The differences between SOA and microservices

Advantages of microservices

Disadvantages of microservices

Summary

2

Diving into Microservices Internals

Solidifying the communication

Microservice communication techniques

Introduction to APIs

What exactly is REST?

HTTP-based REST implementation

HTTP response status codes

Introduction to GraphQL

Remote Procedure Call

Synchronous microservice communication

Asynchronous microservice communication

Essential communication patterns

Message brokers

Summary

3

What Do You Need Before Getting Started?

Technical requirements

JavaScript essentials

JavaScript engine

JavaScript runtime

Callback-based asynchronous JavaScript

The way to promises

Promise API

Async/await in JavaScript

Microtask queue

Node.js essentials

Summary

4

Stack Development Technologies

Technical requirements

Node.js and its installation

Installing Node.js for Windows

Installing Node.js for macOS and Linux

Node.js frameworks

Express.js

NestJS

Choosing between Express.js and Node.js

Choosing the right IDE

Understanding and installing Docker

Understanding and installing Apache Kafka

Understanding and installing Git

Installing Postman

Installing MongoDB

Summary

Part 2: Building and Managing Microservices

5

Basic CRUD Microservices

Technical requirements

Understanding business requirements

Tools to develop a basic microservice

Preparing our first project

Understanding the concept of packages

Understanding the package.json file

Understanding index.js files

Installing the required packages

Defining the internal architecture of our microservice

MVC architectural pattern

Integrating MVC into our Node.js project

Hands-on account microservice development

Implementing our data-access functionalities

Implementing the M in MVC

Storing configuration

Implementing the business layer

Implementing the controller

Simple data validation for your API

Implementing routing

Constructing our web application

Combining all the elements

Running and testing our first microservice

Creating a new account

Getting an account by ID

Updating an account by ID

Gettings all accounts

Deleting account by ID

Summary

6

Synchronous Microservices

Technical requirements

Understanding the requirements for the transaction microservice

Tools to develop the transaction microservice

NestJS

Docker

Prisma ORM

Hands-on transaction microservice development

Dockerizing your PostgreSQL instance

Modeling the data

Seeding test data

Implementing the transaction service

Configuring Swagger

Working on transaction implementation

Establishing synchronous communication with the account microservice

Summary

7

Asynchronous Microservices

Technical requirements

Understanding the requirements

Exploring asynchronous communication

Implementing an asynchronous transaction microservice

Getting started with Kafka for NestJS

Cluster and brokers in Kafka

Topic and partition concepts in Apache Kafka

Configuring Apache Kafka

Adding an asynchronous nature to a transaction microservice

Adapting an account service to new requirements

Testing our microservices together

Summary

8

Real-Time Data Streaming Using Microservices

Technical requirements

What is real-time streaming?

Why real-time data is essential

Understanding use cases

Relationship between real-time streaming and microservices

Microservices we will develop

Getting started with an earthquake streaming API

Implementing the earthquake stream consumer

Summary

Part 3: Securing, Testing, and Deploying Microservices

9

Securing Microservices

Technical requirements

Security, authentication, and authorization in microservices

Understanding security

Exploring authentication

Defining authorization

Best practices for authorization

Difference between authentication and authorization

Getting started with JWTs

Implementing an Authentication microservice

Integrating token-based authentication for the account microservice

Summary

10

Monitoring Microservices

Technical requirements

Importance of observability

Introduction to logging

Logging levels and node libraries

Log formats

Best practices for logging

Implementing logging in your microservices

Centralized logging with Elasticsearch, Logstash, and Kibana (ELK) stack

A brief introduction to Logstash

A brief introduction to Elasticsearch

A brief introduction to Kibana

Summary

11

Microservices Architecture

Technical requirements

Getting started with an API gateway

How an API Gateway works

Single versus multiple API gateways

Implementing microservices using an API gateway

CQRS and event sourcing

Understanding CQRS

Event sourcing

Event store

Implementing CQRS and event sourcing

Commands and handlers

Implementing an aggregate root

Implementing projection

Implementing API functionalities

Testing an application

Service Registry and discovery in microservices

Understanding Service Registry and discovery

Approaches for implementing Service Registry and Discovery

Implementing Service Registry

Summary

12

Testing Microservices

Technical requirements

Understanding testing in a microservice architecture

Understanding unit tests

Introducing unit testing packages

What should we test in unit testing?

Implementing unit tests for the account microservice

Writing unit tests for the transaction microservice

Comparing mocks, stubs, and spies in unit tests

Mocks

Stubs

Spies

Understanding and implementing integration tests

Summary

13

A CI/CD Pipeline for Your Microservices

The essentials of CI/CD processes

Understanding CI

Understanding CD

Integrating CI/CD into microservices

Working with Azure Cloud

Working with GitHub Actions

Understanding Secrets

Building a pipeline

Summary

Index

Other Books You May Enjoy

Preface

Hello there! Welcome to Hands-On Microservices with JavaScript, a journey through the fascinating intersection of one of the most popular programming languages and the ever-evolving world of microservices architecture. JavaScript, with its versatility and ubiquity, combined with the modular, scalable power of microservices, forms the perfect duo for modern software development. This book is designed to bridge these two worlds, offering a comprehensive guide to building, managing, and scaling microservices with JavaScript.

The rise of microservices has revolutionized the way we think about software architecture. Gone are the days when monolithic applications dominated the landscape, offering simplicity but at the cost of scalability and flexibility. Microservices, with their promise of independent, self-contained units, have brought about a new era of development: agile, resilient, and highly scalable. However, with great power comes great responsibility, and the challenges of adopting a microservices architecture should not be underestimated.

In this book, we’ll take you step by step through the process of understanding and implementing microservices using JavaScript. Each chapter is crafted to not only introduce you to the theoretical concepts but also to provide hands-on guidance that you can apply in real-world scenarios.

We will start with an introduction to microservices, exploring their core principles, benefits, and challenges. From there, we will delve into the internals of microservices, focusing on communication techniques and patterns that are essential for building robust systems. We’ll also cover the foundational knowledge you need in JavaScript and Node.js before diving into more advanced topics, such as real-time data streaming, securing your microservices, and deploying them to production.

This book is not just about writing code; it’s also about understanding the architectural patterns and best practices that will allow you to build scalable, maintainable, and efficient microservices. Whether you’re an experienced developer looking to expand your skill set or a newcomer eager to explore the world of microservices, this book is designed to be your guide.

Thank you for embarking on this journey with me. I hope this book will not only enhance your technical skills but also inspire you to push the boundaries of what you can achieve with microservices and JavaScript.

Let’s dive in!

Who this book is for

This book is designed for software developers, architects, and IT professionals who are eager to dive into the world of microservices using JavaScript. Whether you’re new to microservices or looking to enhance your existing knowledge, this book provides practical insights and hands-on experience to help you build, manage, and scale microservices in a real-world context.

You are likely to benefit from this book if you belong to one of the following groups:

JavaScript developers: If you’re a JavaScript developer interested in expanding your skill set into the microservices architecture, this book will guide you through the process. You’ll learn how to apply your existing JavaScript knowledge to build scalable and resilient microservices, gaining insights into best practices, common challenges, and effective solutions.

Software architects: For architects looking to design and implement microservices architectures, this book offers a comprehensive exploration of patterns, tools, and strategies. You’ll learn how to make informed decisions on structuring and deploying microservices, ensuring that your systems are both flexible and robust.

DevOps and IT professionals: If you’re involved in the deployment, monitoring, and maintenance of microservices, this book will equip you with the knowledge to manage these systems effectively. You’ll gain a deep understanding of CI/CD pipelines, containerization, orchestration, and monitoring techniques that are critical for running microservices in production environments.

This book will provide you with the practical knowledge and tools you need to successfully navigate the complexities of microservices architecture with JavaScript, positioning you for success in today’s fast-paced development landscape.

What this book covers

Chapter 1, Introduction to Microservices, provides an introduction to microservices architecture, exploring its core principles and defining microservices as small, independent units focused on specific functionalities. This chapter also contrasts microservices with traditional monolithic architecture, highlighting the pros and cons of each approach and setting the stage for the rest of the book.

Chapter 2, Diving into Microservices Internals, delves deeper into the internal workings of microservices. It covers microservice communication techniques, including REST, GraphQL, and Remote Procedure Call (RPC), and explains both synchronous and asynchronous communication methodologies. The chapter also explores popular communication patterns such as API gateways and message queues, providing a theoretical foundation that is essential for practical implementation.

Chapter 3, What Do You Need Before Getting Started?, focuses on the essential concepts of JavaScript and Node.js that you need to understand before building microservices. This chapter covers JavaScript engine internals, asynchronous programming, the Node.js runtime environment, and the crucial role of threading and runtime management in building effective microservices.

Chapter 4, Stack Development Technologies, introduces the essential tools and technologies required to develop and manage microservices with JavaScript. This includes a deep dive into Node.js and various frameworks, choosing the right IDE, and the installation and use of Docker and Git. The chapter also covers Postman, a key tool for testing APIs and interacting with microservices during development.

Chapter 5, Basic CRUD Microservices, takes a practical approach by guiding you through the development of your first microservice using Express.js. This chapter covers the tools required, the internal architecture of microservices, and the step-by-step process of creating and testing a basic CRUD (Create, Read/Retrieve, Update, Delete) microservice, preparing you for more complex implementations.

Chapter 6, Synchronous Microservices, explores the creation and orchestration of synchronous communication between microservices. This chapter focuses on building a second microservice using NestJS and establishing communication between services.

Chapter 7, Asynchronous Microservices, delves into the world of asynchronous communication, a crucial aspect of building scalable systems. The chapter covers the implementation of Apache Kafka for asynchronous messaging, setting up the infrastructure for Kafka with NestJS, and building an asynchronous transaction service. It also breaks down Kafka’s core concepts and explains how to incorporate asynchronous communication into your microservices architecture.

Chapter 8, Real-Time Data Streaming Using Microservices, explores the power of real-time data streaming within a microservices ecosystem. This chapter covers the concept of streaming, its benefits, and how to implement stream processing microservices using Node.js. It also demonstrates how to integrate these services with Apache Kafka to build a real-time data pipeline.

Chapter 9, Securing Microservices, focuses on the fundamental aspects of securing microservices by implementing robust authentication mechanisms. It covers the use of JSON Web Tokens (JWT) for stateless authentication, discusses centralized and decentralized approaches to security, and demonstrates how to build a dedicated authentication microservice. Additionally, best practices for ensuring your microservices' confidentiality, integrity, and availability are provided, offering a solid foundation for secure microservice architectures.

Chapter 10, Monitoring Microservices, focuses on equipping your microservices with robust observability and monitoring practices. This chapter covers the importance of logging and monitoring in microservice architectures, ensuring that you can effectively track the health and performance of your system. It introduces essential observability concepts such as logs, metrics, and traces and explores centralized logging with the ELK Stack (Elasticsearch, Logstash, and Kibana). By the end of this chapter, you’ll have a strong foundation for implementing logging and monitoring strategies to keep your microservices resilient and responsive.

Chapter 11, MicroservicesArchitecture, provides a deep dive into advanced architectural patterns for microservices. This chapter explores the API gateway, event-sourcing, and Command Query Responsibility Segregation (CQRS) patterns to separate reads and writes.

Chapter 12, Testing Microservices, emphasizes the importance of testing in maintaining microservices’ stability and reliability. This chapter covers essential testing strategies, including unit tests and integration tests, ensuring that your microservices can withstand any demand and work seamlessly together.

Chapter 13, A CI/CD Pipeline for Your Microservices, unveils the process of automating microservices development through Continuous Integration (CI) and Continuous Delivery (CD). This chapter covers the essentials of CI/CD processes, working with GitHub Actions, building a robust pipeline that streamlines the transition from development to production and deploying your application to Azure Cloud.

To get the most out of this book

To fully benefit from this book, you should have a foundational understanding of JavaScript and basic programming concepts. Familiarity with Node.js, including its runtime environment and asynchronous programming model, will be advantageous as you dive into microservices development. Additionally, a basic knowledge of web development and RESTful APIs will help you grasp the communication techniques and patterns discussed in the book. While not mandatory, experience with Docker, Git, and CI/CD processes will enhance your ability to follow along with the practical examples and deployment strategies covered in the later chapters.

Software/hardware covered in the book

Operating system requirements

Node.js (Windows version v20.12.1)

Windows, macOS, or Linux

Docker Desktop (Windows version 4.33.1)

Windows, macOS, or Linux

VS Code (Windows version 1.92.2)

Windows, macOS, or Linux

Postman (Windows version 11.8)

Windows, macOS, or Linux

While the aforementioned versions are specific to Windows, Node.js, Docker Desktop, Visual Studio Code, and Postman also work seamlessly on macOS and Linux. Users of these operating systems should download their appropriate versions from the official websites. The core functionality remains consistent across all operating systems, ensuring a similar experience regardless of your platform.

Important note

If you are using the digital version of this book, we advise you to type the code yourself or access the code from the book’s GitHub repository (a link is available in the next section). Doing so will help you avoid any potential errors related to the copying and pasting of code.

For your convenience, you can download the source code to follow along with the book. However, most chapters also provide detailed instructions to guide you in writing everything from scratch, ensuring that you understand each step of the process.

Download the example code files

You can download the example code files for this book from GitHub at https://github.com/PacktPublishing/Hands-on-Microservices-with-JavaScript. If there’s an update to the code, it will be updated in the GitHub repository.

We also have other code bundles from our rich catalog of books and videos available at https://github.com/PacktPublishing/. Check them out!

Conventions used

There are a number of text conventions used throughout this book.

Code in text: Indicates code words in text, database table names, folder names, filenames, file extensions, pathnames, dummy URLs, user input, and Twitter handles. Here is an example: “To track changes, we are going to add createdAt and updatedAt fields.”

A block of code is set as follows:

{     "name":"AccName1",     "number":"Ac12345",     "type":"root",     "status":"new" }

Any command-line input or output is written as follows:

$ cd transactionservice

Bold: Indicates a new term, an important word, or words that you see on screen. For instance, words in menus or dialog boxes appear in bold. Here is an example: “Go to the Terminal menu, select New Terminal.”

Tips or important notes

Appear like this.

Get in touch

Feedback from our readers is always welcome.

General feedback: If you have questions about any aspect of this book, email us at [email protected] and mention the book title in the subject of your message.

Errata: Although we have taken every care to ensure the accuracy of our content, mistakes do happen. If you have found a mistake in this book, we would be grateful if you would report this to us. Please visit www.packtpub.com/support/errata and fill in the form.

Piracy: If you come across any illegal copies of our works in any form on the internet, we would be grateful if you would provide us with the location address or website name. Please contact us at [email protected] with a link to the material.

If you are interested in becoming an author: If there is a topic that you have expertise in and you are interested in either writing or contributing to a book, please visit authors.packtpub.com.

Share Your Thoughts

Once you’ve read Hands-On Microservices with JavaScript, we’d love to hear your thoughts! Please click here to go straight to the Amazon review page for this book and share your feedback.

Your review is important to us and the tech community and will help us make sure we’re delivering excellent quality content.

Download a free PDF copy of this book

Thanks for purchasing this book!

Do you like to read on the go but are unable to carry your print books everywhere?

Is your eBook purchase not compatible with the device of your choice?

Don’t worry, now with every Packt book you get a DRM-free PDF version of that book at no cost.

Read anywhere, any place, on any device. Search, copy, and paste code from your favorite technical books directly into your application.

The perks don’t stop there, you can get exclusive access to discounts, newsletters, and great free content in your inbox daily

Follow these simple steps to get the benefits:

Scan the QR code or visit the link below

https://packt.link/free-ebook/978-1-78862-540-1

Submit your proof of purchaseThat’s it! We’ll send your free PDF and other benefits to your email directly

Part 1:Fundamentals of Microservices Architecture

In this part, we will gain a comprehensive understanding of the foundational principles and internal workings of microservices architecture. We will explore what microservices are, how they compare to traditional monolithic architectures, and the various communication techniques and patterns that make microservices a robust and scalable solution. Additionally, we’ll learn the essential JavaScript and Node.js concepts that are necessary to develop microservices.

This part contains the following chapters:

Chapter 1, Introduction to MicroservicesChapter 2, Diving into Microservices InternalsChapter 3, What Do You Need Before Getting Started?Chapter 4, Stack Development Technologies

1

Introduction to Microservices

As human beings, we all go through various stages of development. With each stage we reach, even if it seems like the best at the time, we later realize we still have a long way to go. Each period has its problems, and depending on their size and nature, they require different solutions.

We humans tend to simplify things. That is why we build our lives around problems and their corresponding solutions. Finding solutions to problems has been our main goal throughout history, perhaps due to our instinct to survive.

If we consider each piece of software as an individual, they also have problems to solve. Depending on the size and shape of the problems, software has a different structure, which we call architecture. The size and nature of the problems directly affect the architecture of the software. One of these architectural approaches we use is called microservices.

Microservices are important when it comes to building scalable distributed applications that respond to modern-day concerns. It is also a de facto requirement for most huge companies when they interview you as a developer. The vast majority of technologies we use nowadays try to support microservice development out of the box. So, being a software engineer without microservice knowledge doesn’t make you an ideal candidate in the modern IT world.

Starting from this chapter, we’re going to dive into the world of microservices. We will build strong theoretical knowledge before moving on to practical sections.

First, we will go back and try to understand what type of popular approaches were there before microservices. Microservices are important, but understanding the need to apply them is foremost.

In this chapter, we’re going to cover the following topics:

Introducing microservicesExploring the monolith approachWhat is service-oriented architecture?The differences between SOA and microservicesAdvantages of microservicesDisadvantages of microservices

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 buildingmicroservice 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.

Exploring the monolith approach

Say we have an e-commerce site with a single code base that was developed years ago. Over time, features and functionalities were added randomly, leading to messy code that contains duplication, is hard to maintain, and is difficult to troubleshoot. Here is the first suggested transition so that you can make your application responsive or alive again:

Analyze the current state of your application: You need to identify key pain points affecting developer productivity and user experience. Try to divide the problem into smaller pieces. Trying to cover everything at once will lead you to more difficulties. Focus on specific modules or functionalities within the larger code base for initial refactoring. You need to understand dependencies, duplication, and complexity in your application.Communication and collaborative planning: The next steps are identifying the areas for improvement and agreeing on common architectural principles. Emphasize the phased approach, starting with small, isolated modules and demonstrating progress before moving on.Choose a monolith architecture: Decide which architectural style and pattern (layered, tiered, MVC, MVVM, and so on) aligns best with your needs in the given context.Start small and iterate: Set small goals and apply iterative development.Make improvements: Eliminate code duplication, clean up spaghetti code (a term that’s used for unstructured and difficult-to-understand programming code), and improve documentation.Application: After each refactoring step, it is better to apply unit, integration, and regression testing to ensure code functionality and identify potential regression in your application.Feedback: Gather feedback from developers and users throughout the process to adapt and refine the approach.

Welcome – you’re in the world of monoliths! But what is the concept of monolith?

Figure 1.3: Monolith architecture

Many online articles delve into the specifics of monolith architecture but rarely touch upon the broader concept, called the monolith approach. This isn’t surprising as the architecture has clear-cut characteristics. We love to be concrete and as developers, we are rarely theory lovers. However, it’s important to keep in mind that the monolith approach covers a greater variety of options.

The monolith approach is a broader concept that refers to a general way of building software as a single, self-contained unit. It can be implemented using various architectures, not just the traditional monolith architectures we know. It highlights simplicity, rapid development, and tight integration. The monolith approach is architecture-agnostic, meaning it can be implemented using various architectural styles or patterns, or even without a specific architectural framework at all, so long as the core principle of consolidating components into a single unit is maintained.

On the other hand, monolith architecture (see Figure 1.3) is a specific software architecture where everything, from UI to business logic to data access, is built as a single, tightly coupled unit. It often uses a single code base, programming language, and database.

Monolith architecture refers to the specific architectural design or pattern that’s used to implement the monolith approach. It includes all of the technological choices and structural design of the monolithic system, including the arrangement of modules, the interactions between components, and the data management process.

The monolith approach itself doesn’t dictate a specific architecture. However, certain architectural styles and patterns naturally align with and support the monolith approach more effectively than others. Examples include the layered architecture, the MVC architecture, and the N-tier architecture. The monolith approach can also be implemented without strictly adhering to a specific architecture, especially for smaller projects. The key feature here is to maintain a single code base and deployment unit. Whether you choose a structured style or a more organic approach, the core principle remains: build a cohesive software unit. Understanding this distinction forces you to make informed decisions when navigating the vast world of software architectures. So, while the monolith approach promotes the development of software as a unified entity, the monolith architecture determines how that unity is achieved and maintained. Knowing this difference allows you to navigate the wide world of software architectures with knowledge and confidence.

While not without its drawbacks, the monolith approach offers several advantages, particularly for certain types of projects. These advantages are listed here:

Simplicity and speed: Monolith architecture enables faster development and deployment cycles by consolidating the entire system into a single codebase, reducing the overhead of managing multiple services.Maintainability and control: Having everything in one place allows for easier management, control over application performance, and a unified approach to maintaining and securing the systemPerformance and cost: This architecture offers the advantage of reduced complexity, leading to lower infrastructure costs and optimized performance for applications with straightforward requirements.Additional benefits: It provides practical advantages for simpler projects, making it easier to manage data and application operations, especially for smaller teams.

Even though the monolithic approach has benefits, such as speed and simplicity, not all projects can benefit from it. To help determine whether the monolithic approach is right for your project, consider these general guidelines:

Simple and well-defined applications: A monolith works well in applications that have a defined scope and few functionalities. Simple mobile apps, internal tools, and basic e-commerce sites are a few examples.Quick product launches and idea testing: This is made possible by the agility of a monolithic architecture, which is useful if your project requires for quick development cycles or frequent prototyping.Small teams with limited experience: Initially, managing and maintaining a monolith may be more manageable for teams that lack experience with distributed systems or microservices.Tight data coupling and consistency: Monolithic architectures are advantageous for applications that rely heavily on consistent data across multiple functionalities. It guarantees data integrity throughout the application and simplifies data management.Limited scalability requirements: Without the hassle of scaling microservices, a monolithic architecture might be able to satisfy your scalability requirements if your application expects stable user traffic and moderate growth projections.

The best architecture depends on your specific application’s requirements. Here, you must consider factors such as scalability, complexity, technology needs, and development team structure. As we mentioned previously, there’s no one-size-fits-all solution in software development.

While the monolith approach has its benefits, it’s not suitable for every application. It’s better not to use monolith when it comes to the following aspects:

Building a highly scalable applicationApplications with constantly evolving features, modularity, and independent deploymentIf your application requires integrating diverse technologies or frameworks, also referred to as heterogeneous technologiesIf high availability and resilience are critical and one of the important attributes for your system is fault-toleranceIf different teams work on distinct functionalities – that is, if there is independent development and deployment across teamsWhen you have large teams and distributed development

Besides its pros and cons, Monolith is usually a preferable architecture for getting started but not the only architecture to build better applications. We have another preferable architecture called service-oriented approach (SOA) that we plan to dive into details starting from the next page.

What is service-oriented architecture?

A monolithic architecture unifies all of the components/elements – including the user interface and data access – into a single code base, promoting simplicity and quick development. Although it’s not impossible, combining different technologies into one system can be difficult to maintain and unfeasible at times. In the absence of contemporary methodologies such as feature flags and blue-green deployment, it becomes necessary to deploy the entire application every time you want to update a monolithic application. There are difficulties with organizing and delivering the application smoothly, which could mess up its launch.

On the other hand, SOA (see Figure 1.4) focuses on modularity and reuse, breaking down functionalities into independent services that communicate with each other through application programming interfaces (APIs).

SOA can be defined as multiple, smaller, and often coarser-grained services, each with a specific function. This modularity offers advantages such as flexibility and scalability. Services in SOA can be deployed and scaled independently, meaning you can update or scale one service without affecting others. This is a key benefit of SOA.

The analogy from moving from monolith to SOA can be described like this: You have a big method/function that does everything (similar to a monolith). After some time, some other parts of your functionalities are required so that these functionalities can be reused. Instead of copying it, you’re breaking this giant method into reusable parts (similar to SOA). In this case, the method calls are going to be our API calls:

Figure 1.4: An overview of service-oriented approach

Consider multiple applications (as shown in Figure 1.4 – account management, CRM, and sales management) that need to share common functionalities. Instead of duplicating them for every application, we provide a service-oriented approach. At first glance, it may look like they are perfect grained services, but our focus is just to share common behavior that supports scaling and reusing.

To encapsulate communication complexity, we may use a service bus, which allows us to write additional logic and move the complexity to the outside of the application, which acts as a mediator. This is one of the signs that we should use architectural mediators in applications.

Think of two functions within a single program and one directly calls the other. In SOA, each function becomes a standalone service, communicating through a defined interface. This enables independent deployment, updates, and even development by different teams.

Imagine building with Lego bricks instead of monolithic blocks. That’s the essence of SOA: breaking down applications into reusable, independent services, each focused on a specific task. Instead of hard-coded connections, they communicate through standard protocols such as REST or SOAP, making them platform-agnostic and adaptable.

SOA offers numerous advantages that can significantly improve the flexibility, agility, and efficiency of your organization’s IT infrastructure. Let’s discover its key benefits:

Business agility: SOA supports fast development and deployment, helping businesses quickly adapt to market changes and align their software with evolving business objectives.Technical advantages: SOA offers flexibility and scalability, allowing for easier integration, upgrades, and reuse of components across the system without disrupting the overall functionality.Operational benefits: SOA streamlines operations by reducing maintenance overhead and improving system reliability, while enhancing security through centralized management.

Although SOA has many advantages, there are drawbacks as well:

Enhanced complexity: SOA introduces more complexity by requiring careful coordination between independent services, demanding skilled personnel, and detailed planning for development, testing, and maintenance.Possible problems with performance: SOA can introduce latency due to network-based service interactions, adding complexity when ensuring secure and efficient communication between services.Other difficulties: SOA comes with high upfront costs and requires skilled professionals, making it challenging to maintain service coordination, manage responsibilities, and ensure smooth integration as the system evolves.

SOA is one step toward microservices. Most of the core ideas of microservices come from SOA.

In the final section of this chapter, we’ll understand the benefits and challenges of the microservices architecture.

The differences between SOA and microservices

Microservices architecture simplifies building distributed, flexible, and scalable software. Instead of one monolithic system, it divides an application into small, standalone services, each of them focused on a specific task. These services communicate through simple interfaces, allowing for independent deployment and easy integration. When developing properly designed microservices, we get loosely coupled, reusable, extensible, and easily maintainable applications.

When comparing microservices to SOA, they may seem similar in concept. SOA and microservices architecture are both architectural styles that are used for building distributed systems, but they have some key differences. Let’s compare them:

Scope and granularity: Services in SOA are like big boxes containing multiple functionalities that are meant to be reused across different applications. Microservices are like tiny, specialized tools, each focusing on one specific task or feature within an application.Communication protocols: Services in SOA mostly communicate using strict protocols, such as SOAP, XML-RPC, WSDL, and UDDI. Microservices prefer lightweight protocols such as RESTful HTTP or messaging queues, allowing for more flexible communication.Technology stack: SOA can work with different technologies and platforms. Microservices often use containerization tools such as Docker and orchestration tools such as Kubernetes for easier deployment and management.Dependency management: Services in SOA can have intricate dependencies that require careful coordination. Microservices strive for loose coupling, reducing dependencies between services to simplify development and deployment.Deployment and scaling: Services in SOA are often centrally deployed and scaled at the service level. Microservices are deployed separately, allowing individual scaling and better resource utilization.Organizational impact: Once SOA is implemented, significant organizational changes may be required for coordination and management. Microservices promote decentralization of management by giving small, cross-disciplinary teams the autonomy to control their services.

The difference between approach and architecture, especially regarding microservices, is important.

The microservice approach is all about how we think when designing software. It’s like having a mindset or philosophy of breaking down big, complicated systems into smaller, easier-to-handle parts. Each of these parts focuses on one specific task. It’s somewhat abstract and emphasizes concepts such as modularity (allowing for simple replacement), scalability (allowing for increased work), and flexibility (allowing for change adaptation):

Figure 1.5: Microservices architecture

Every approach has its pros and cons. Nothing is ideal. To identify it from the Microservices perspective, let’s talk about the advantages and disadvantages of Microservices.

Advantages of microservices

In this section, we’ll look at the many reasons that make microservices an important part of software development:

Scalability: You can scale each microservice independently based on demand, ensuring resources are allocated where needed for optimal performance and cost-effectiveness.Flexibility and agility: Teams can work on different services simultaneously, speeding up development and making updates easier. Being agile is essential to adapting to the ever-shifting demands and markets of businesses.Fault isolation: If one microservice fails, it doesn’t necessarily affect others, thanks to their independence. This isolation improves system reliability by minimizing downtime.Technology diversity: Multiple programming languages and technologies can be used in a single application thanks to microservices. Teams are encouraged to explore and be creative by selecting the finest tools for each service.Easy maintenance and updates: Compared to huge monolithic programs, smaller services are easier to comprehend, manage, and update. Risks are decreased because modifications to one service won’t inadvertently affect others.Scalable developmentteams: Small, cross-functional teams can now own separate services thanks to microservices. This configuration promotes creativity, accelerates decision-making, and heightens accountability.Improved fault tolerance: Microservices make it simpler to implement redundancy and failover techniques at the service level. This increases the system’s ability to withstand setbacks.Improved deployment practices: Continuous integration and continuous deployment (CI/CD), two contemporary deployment techniques, mesh nicely with microservices architecture. Time to market is shortened by the release process being streamlined by automated deployment pipelines for every service.Improved use of resources: Resource allocation based on the unique requirements of each service is made possible by granular scaling, which maximizes resource efficiency and reduces costs.Encouragement of cooperation: Encouraging cooperation between the development and operations teams through microservices makes it easier to implement DevOps principles. At the service level, feedback loops, automation, and monitoring can be put into place to improve overall quality and efficiency.Huge and complicated systems: Microservices can help you simplify huge and complex applications as you can divide them into smaller, more manageable parts.Handles many users: Because microservices allow you to scale each component individually to effectively handle the load, they are ideal for apps that experience high traffic or a large number of users.Requires frequent updates or new features: Microservices allow you to swiftly react to changing needs by allowing you to change individual components without affecting the entire application.Uses different technologies: Microservices let you use different tools and programming languages for different parts of your app so that you can pick the best one for each job.Built by many teams: If your app is being worked on by lots of different teams, microservices let each team work on their part, without getting in each other’s way.Needs to stay running: Microservices help your app stay up and running, even if one part fails. This is because each part is separate. As a result, problems in one area don’t crash the whole thing.Works in the cloud: Microservices are a good fit for apps that run in the cloud because they’re designed to work well with cloud technology. Plus, tools such as containers and orchestrators make it even easier to manage them in the cloud.

In summary, microservices provide a modern, flexible method for developing software, allowing businesses to innovate rapidly, grow effectively, and release high-caliber software products into the market more quickly. However, don’t attempt to use them for every kind of application you’re creating.

Although microservices offer many advantages, you should be aware that they also come with some additional complexity, such as having to manage several moving components and more communication being required between services.

Disadvantages of microservices

Throughout this chapter, we learned that the main reason for having various architectures in software development is a sign that there is no single truth and that depending on the requirements, architecture may vary. Every approach in design has its disadvantages and before applying any architecture, you should carefully analyze and understand them.

Here are some important disadvantages of microservices:

Increased complexity in development: Breaking down a system into smaller services can lead to increased complexity in development, deployment, and testing.Interservice communication: Managing communication between microservices can become complex, requiring careful design and implementation of APIs and protocols.Infrastructure complexity: Managing and deploying a large number of microservices can introduce operational overhead, including the need for sophisticated orchestration and monitoring tools.Infrastructure cost: The overhead of managing multiple services and the associated infrastructure can lead to increased costs, particularly in terms of hosting and operational expenses.Security issues: A larger number of services means a larger attack surface, potentially increasing the security risk.Communication security: Securing communication between microservices requires additional attention to prevent unauthorized access.Coordination and communication: Teams need to coordinate effectively to ensure that changes in one service do not adversely affect others.Data consistency: Maintaining consistency across microservices can be challenging, especially when dealing with distributed databases. Ensuring data integrity and consistency becomes a complex task.Team expertise: Developers need expertise in both the domain and technology stack of their specific microservice, potentially limiting flexibility in task assignments.

Therefore, we should carefully consider if microservices are the correct choice for our project based on the expertise of our team, the requirements of our application, and the readiness of our organization for the shift.

Summary

This chapter introduced you to microservices. We talked about coding without proper design and analysis, which brings us to a big ball of mud. Having no clear architecture is similar to having no map in the middle of the ocean.

Our first step was starting with monoliths. We talked about the advantages and disadvantages of the monolith approach and tried to understand the differences between approach and architecture.

Nowadays, requirements for applications are broader and more complex, and always trying to deal with them using a monolith approach may not be a good solution. To add important attributes, such as “distributed,” to the architecture, we considered SOA while discussing its pros and cons.

The final destination for us was microservices. We provided a clear definition for it and tried to understand the advantages and disadvantages of using them.

Microservices bring a lot of interesting challenges to our lives and one of them is communication. Dividing a big problem into smaller chunks is good but making proper communication between the chunks isn’t easy. When you’re ready, turn to the next chapter to explore it with me.

2

Diving into Microservices Internals

Microservices aren’t just about breaking down a large application into smaller, more manageable ones. They also introduce challenges, one of which is communication between services. Monolithic applications, which we discussed in the previous chapter, make communication between elements relatively straightforward. However, in microservice architecture, we have physical isolation between services. Even though we want microservices to be independent, as well as easy to reuse, maintain, and grow, getting them to talk to each other effectively becomes a major challenge.

Effective microservice communication is crucial for the overall success of architecture. It enables services to exchange data, coordinate actions, and trigger events. If microservices can’t communicate effectively, they become like isolated islands, stopping the application from working properly and keeping it running slowly. Well-designed communication patterns ensure that microservices can collaborate effectively to deliver the desired functionality. This communication strategy also promotes loose coupling, which means that changes in one service have minimal impact on others, thereby making the application more resilient and easier to maintain.

This chapter is about establishing a strong foundation for the next practical chapters, along with providing comprehensive information about microservice communication. A solid understanding of microservices communication will help you build reliable, consistent, scalable, and fault-tolerant microservice applications.

In this chapter, we’re going to talk more about the following topics:

Microservices communication techniquesSynchronous microservice communicationAsynchronous microservice communicationEssential communication patterns

Solidifying the communication

As your application grows, managing its complexity becomes increasingly challenging. To tackle this, developers rely on best practices, design patterns, and various approaches. In traditional software design, techniques like abstraction, encapsulation, and decomposition help us deal with complexity.

The microservice architecture offers a provides a powerful solution to complexity through the Separation of Concerns (SOC) principle. This principle breaks down a complex system into smaller independent parts, each with a well-defined responsibility. Imagine a monolithic application as a mountain; microservices allow us to break it down into smaller, more manageable hills through bounded contexts. However, this freedom comes at the cost of somehow figuring out how to establish communication between microservices. Of course, it is not as easy as it was with the monolithic approach, because with that, everything was inside one codebase. Creating a connection between elements of a monolith was as simple as calling any method.

The best way to explain the relationship between monoliths and microservices is by using the first two principles of S.O.L.I.D, the Single Responsibility Principle (SRP) and the Open-Closed Principle (OCP), as metaphors.