Introduction to Microservice Architecture
Hey, what’s going on guys! Welcome to this new YouTube series called "Microservices Fundamentals”. In this series you will learn the core microservice architecture concepts, regardless of the technology stack you use. In this lecture, I will introduce the “Microservice Architecture”.
I’m Driss, a Professor at INPT, an engineering school in Morocco. I have an academic and professional background in software engineering. If needed, you can email me, or maybe contact me via LinkedIn. The promise of this introductory video is to help you be able to determine and have an idea on what is a microservice architecture. In addition to being aware of its main characteristics, advantages and challenges. The second aim is to distinguish between microservices and other standard architecture styles such as monoliths and Service Oriented Architecture.
And the third objective is to take the right decision on when to adopt the microservice architecture style. If you are interested in this, let’s jump-in to the presentation agenda. Before introducing the Microservice architecture, let’s first get an idea of the most used architecture style in industry. I’m talking here about Monoliths.
The aim is to well understand its main limits and problems in order to have a good understanding of the WHY we are thinking about microservices as a new and different architecture style alternative. To properly begin our talk, let’s introduce the right context of our topic. It’s about “Software Architecting”.
Actually, the main activities a software architect can do would be roughly summarized in 3 elements: The first one is about analyzing business requirements to extract and define the architectural characteristics of the software we are intending to build. What I mean by “architectural characteristics” is “the non-functional requirements” or what we are also calling the “quality attributes” such as the Maintainability, the Evolvability or the Testability of the software. Sometimes, we are also calling them the “-ilities” of the system. The second activity concerns the selection of the architecture patterns and styles that would fit the problem domain we are working on.
Remember one thing. Choosing the right architecture style is very useful to ensure the “-ilities” of the system. And once the architecture style is defined, the architect begins creating the needed components (the building blocks of the system). Our focus today is the architecture style of the software.
What I mean by this, is whether we are talking about monoliths or microservices, both are in the end, examples of the architecture style we have to follow. And the purpose of following such architectures is to help meeting the software requirements defined for the project. Now things are placed in their right context, let’s discover together what is the “monolithic architecture”. A Monolith is an application that follow the monolithic architecture. It’s an application
built as a single deployable unit. For instance, all the Java code we write to create an application will be packaged and deployed as a single file called the JAR file. Since the monoliths are using a client-server architecture, they are usually built in 3 parts: the Clientside (or what we call the frontend) , the Serverside (or the backend) and the database. A typical monolith will follow an internal architecture which could be for example, the “layered architecture”. And this last is mainly composed of:
The “data access layer” which is responsible of the connection to the database. The “business logic layer” in which we implement all the business logic of the application. And the “user interface layer” responsible for handling all user interface and browser communication logic. I have to mention that a monolith can also follow different internal architectures like the hexagonal architecture. If you wanna get more details about both,
the layered and the hexagonal architectures, you can check the links I put in the description. Another thing to consider in monolithic applications, is when they are relatively small, they are: Simple to develop. Easy to maintain. Easy to scale. And straightforward to test and deploy However, in most cases, monolithic applications are usually long-lived. And they become what we are commonly calling the “Majestic fat monoliths” So, this means that they grow over time and the bigger their size become, the more problems we can get.
As an example of these problems, monoliths lacks of reliability. This means that we have more chance to have frequent production outages. This is due to the fact that testing a large application becomes much more difficult. To make things worse, the application lacks fault isolation. In other words, if one module crashes, the entire application will be down. There is no way to isolate the other healthy parts of the application since it is packaged as a single deployable unit.
One another big problem is the difficulty to properly scale a monolith when needed. For example, one module may need a lot of memory to run at scale. But another one, will instead require more CPU. And finding the compromise on the server configuration when scaling vertically, is a painful headache. In addition to that, sometimes we need to scale just one or two modules which are the only ones needed to respond to the spiky calls of the clients. With a monolith, we are unfortunately obliged to scale the entire application.
A further problem would concern the development and the deployment velocity. In general, developing a new feature in a large monolith takes a lot of time. And the path from the commit to the deployment is long and very tough. This badly impact the productivity. And As we know, time is money!
The last but not least issue, is to be locked into an obsolete technology stack. Due to the huge size and complexity of the large monolith, it is almost impossible to think about a migration to a new language or framework that suits better the technical needs of the application. This action will cost a lot. So, it is better to forget about it! At this level, it would be wise to ask ourselves : what impact these technical problems can have on the business side? The following chart presents the relationship we have between the size and the complexity of the application from one hand, and the architectural characteristics on the other hand. The correlation between them says that : The more the monolith size and complexity are increasing, the more the quality attributes will decline over time. I can also say: that we absolutely have to keep a certain high level of these “quality attributes” to remain competitive in the market. Why ? Give me a minute to explain you that ! I believe that business people are seeing things from a specific perspective in which they are convinced that software is eating the world.
They are also convinced that the marketplace is so volatile, uncertain, complex and very ambiguous. And that business innovation must go faster and faster. Keeping all that in mind, we can conclude that we have no more options, We are under the obligation to deliver software more rapidly, more frequently and reliably. That’s the only way to survive! How this can be reached ? It’s possible by ensuring the quality attributes of our system. And one way to reach these requirements, is by choosing the right architecture style for your project application.
To sum-up this first part of the lecture, here are some key takeaways to note: Monoliths are applications that follow a classical architecture style considered as a single deployable unit. When monoliths are still small, they provide simplicity in development, tests and deployment. Once the monolith begins to grow, its complexity grows too and then the quality attributes of the application begin to decrease. Loosing quality of service requirements means negatively impacting the development velocity and reliability. Being aware of that, one legitimate question a person can ask could be: Is there any architecture style that helps avoiding the aforesaid monolithic hell and reaching the enterprise business objectives ? In a nutshell, the answer is YES … adopting the microservice architecture.
Alright ! In this part, I will explain what are microservices ? I will provide an illustrative example for that. To eliminate any eventual ambiguity, I will compare microservices to Service Oriented Architecture. Then, I will focus on microservices pros and cons.
And finally, I will present an overview of the problem areas to solve when using microservices. As I said in the first part, monoliths are applications composed of a single deployment unit. With the evolution of technologies, modern monolithic applications split the frontend from the backend, being then separate applications that communicate through an API. The frontend could be implemented using a modern JavaScript framework or library such as Angular, React or Vue. And the backend, which is still a single deployment
unit could be created using technologies like Spring boot, Node.js, Laravel and so on. Now, Splitting the backend of an application into small, distributed and independent services, each having its own database and each of which communicating over well defined APIs is exactly the main idea of the microservice architecture. You probably noticed that I used the term “service”, as the unit of modularity, to present the microservice architecture. Personally, I prefer defining a service as a mini application that implements a narrowly focused functionality. Now, saying “microservice” or even “small service” doesn’t give much information about the size of a service. This point will be discussed in more details in the next parts
of the series. Inspired by the idea of splitting the backend into small services, one modern way to implement the frontend of an application is to split it into small parts called “micro frontends”. This way of doing things may be interesting in some use cases. But again, if you want more details about this, I invite you to check a link I put in the description since I’ll not cover this topic in this video. Now, if we are looking for "a more formal and structured” definition of microservices, I’ll choose the definition proposed by James Lewis and Martin Fowler.
In which they said: [READING THE DEFINITION FROM THE SLIDE] Well, I think that it contains many similarities with what we have introduced a few seconds ago. But instead of commenting and explaining this definition word by word, I will rather talk about the key characteristics of a microservice. I can say that Microservices are sharing some common characteristics since they are all : Decentralized – We all know that Microservice architectures are distributed systems with decentralized data management. Microservices are also decentralized in the way they are developed, deployed, managed, and operated. Microservices are all Independent – Which means, each component service in a microservice architecture can be changed, upgraded, or replaced independently without affecting the function of other services. Which means that services do not need to share any of their code or implementation with other services. And with the same way, the teams responsible
for different microservices can act independently from each other. Microservices are Specialized – Each component service is designed for a set of capabilities and focuses on a specific domain. If the code for a particular component service reaches a certain level of complexity, then the service can be split for example into two or more services. We can say that microservices are also Polyglot – Microservices don’t follow a single approach. Teams have the freedom to choose the best tool for their specific problem. As a consequence, each microservice
can be created using a different programming language, database, and tools. And this approach is called the “polyglot persistence and programming”. Individual component services are designed to be black boxes, which mean that the details of their complexity are hidden from other components. Any communication between services happens through well-defined APIs to prevent implicit and hidden dependencies.
You build it, you run it – I can say that DevOps is a key organizational principle for microservices, where the team responsible for building a service is also responsible for operating and maintaining it in production. Here we go ! Now, I’ll stop the abstract definitions and I’ll begin presenting an example to take a closer look on what microservices look like in real world. This example is a case study presented in Chris Richardson’s book “Microservices Patterns”. FTGO which stands for “Food to Go” is an online food delivery company.
Basically, Consumers use the FTGO website or mobile application to place food orders at local restaurants. FTGO coordinates a network of couriers who deliver the orders. It’s also responsible for paying couriers and restaurants. Restaurants use the FTGO website to edit their menus and manage orders. The application uses various web services, including Stripe for payments, Twilio for messaging, and Amazon Simple Email Service for emails. As you can notice, the monolith version of the FTGO application uses the hexagonal architecture with 6 core business logic modules and some Inbound adapters, the REST API and the Web UI that handle requests by invoking the business logic.
Outbound adapters like MySQL, Twilio, Stripe, or AWS SES enable the business logic to access the database or invoke the cloud services. This was the monolithic architecture of the FTGO application … But, How does actually the microservice architecture look like ? A preliminary design of the FTGO application using the microservice architecture will look like this. The FTGO application’s business logic consists of numerous backend services.
Each backend service has a REST API and its own private database. The backend services include : The Order Service : to manage orders The Delivery Service that manages delivery of orders from restaurants to consumers The Restaurant Service that Maintains information about restaurants The Kitchen service for managing the preparation of orders The Accounting Service to Handle billing and payments In addition to the Notification service to send messages and emails As I said, all these services collaborate via APIs. And the external requests from the mobile applications are routed via an API Gateway. It’s an additional microservice that we will implement to play the role of a facade and provide the REST APIs that are used by the consumers’ and couriers’ mobile applications. We will see more details about the API Gateway in the next videos of this series. The Restaurant Web UI implements the web interface used by the restaurants to manage menus and process orders.
I hope that this example let you see things clearer … And don’t worry about some details, we will fore sure explain everything in the right moment ! Alright ! One more thing I would love to talk about is comparing the microservices to the Service Oriented Architecture (or SOA for short). The reason why I’m insisting on this point is that many people claim that microservices it’s nothing new, and that it’s only a new way to implement SOA. In my opinion … at a very high level, there are some similarities. Both are architectural styles that structure a system as a set of services. But once you dig deeper, you encounter for sure significant differences.
Before to begin the comparison, I will invite people who never heard of SOA before, to check the link I put in the description to have an idea about that concept. Concerning the purpose and the philosophy of each architecture, I can say that SOA tries to maximize the application service reusability. In turn, microservices focuses more on decoupling. I can add that SOA is an enterprise-wide approach to architecture, while microservices is an implementation strategy within application development teams. The second difference is that SOA applications typically use heavyweight technologies such as SOAP (which stands for Simple Object Access Protocol) and other Web Service standards. In addition to that, SOA often use what we call ESB (or Enterprise Service Bus) which is a smart pipe that contains business and message-processing logic to integrate the services. Applications built using the microservice architecture tend to use lightweight and open source technologies. The services communicate via dumb pipes, such as message brokers or
lightweight protocols like REST or gRPC. The next point is that SOA applications typically have a global data model and share databases. In contrast, in the microservice architecture each service has its own database. Concerning the teams. In SOA, teams are working by following common governance and standards, while teams are more focused on collaboration with having the freedom to work on your way in microservices. The size of services in SOA are different from microservices.
SOA is typically used to integrate large and complex monolithic applications. An then, a SOA application usually consists of a few large services in which making changes is very tricky and difficult, in opposition to the microservices. As a conclusion, we can say that microservices and SOA have the concept of services in common but each of these architecture styles has its own purpose and practices.
Now that we have a clear idea on : what is a microservice architecture ? The next question would be, What are its main benefits ? One quick answer could be : avoiding the monolithic hell introduced earlier in this presentation. But if we want to provide a detailed answer, we can say that its first benefit is providing more agility. Microservices foster an organization of small and independent teams that take ownership of their services. These teams act within a small and well understood context, and are empowered to work more independently and more quickly which shortens the development cycle times (which is very very important).
The second benefit is about the technological freedom. Microservices architectures don’t follow a “one size fits all” approach. Teams have the freedom to choose the best tool to solve their specific problems. As a consequence, teams building microservices can choose the best tool for each job. Flexible Scaling is also an interesting point to consider. Microservices allow each service to be independently scaled to meet demand for the application feature it supports. This enables teams to right-size infrastructure needs, accurately
measure the cost of a feature, and maintain availability if a service experiences a spike in demand. The fourth benefit is about Reusable Code Dividing software into small, well-defined modules enables teams to use functions for multiple purposes. A service written for a certain function can be used as a building block for another feature. This allows an
application to bootstrap off itself, as developers can create new capabilities without writing code from scratch. The fifth advantage is the Easy Deployment Microservices enable continuous integration and continuous delivery, making it easy to try-out new ideas and to roll-back if something doesn’t work. The low cost of failure enables experimentation, makes it easier to update code, and accelerates time-to-market for new features. And the last and not least benefit, is Resilience Service independence increases an application’s resistance to failure. In a monolithic architecture, if a single component fails, it can cause the entire application to fail. With microservices, applications handle total service failure by degrading functionality and not crashing the entire application.
As a conclusion, we can say that it’s easier to have a successful software development equation when the microservice architecture is present as one of its parameters. In fact, going microservices enables your company to adopt a specific organization that recommend working with small, agile, autonomous and cross functional teams. This way, organizations will design systems that mirror their own communication structure, as the Conway’s law states. Now both, the microservice architecture and its adequate organization will enable a more fluid process that take advantage of the continuous delivery benefits. The final result, is a software created and delivered rapidly, frequently and reliably.
Certainly, no technology is a silver bullet, and the microservice architecture has a number of significant drawbacks and issues. The first one you can encounter is that there isn’t a concrete and well-defined method for decomposing a system into services. There is some recommendations that we will present in the next videos but the quality of the output is not always guarantee ! To make matters worse, if you incorrectly decompose your system, you will generate a lot of architectural anti-patterns that they will make your life difficult. The second issue is that microservices is a distributed system. And it’s well known that distributed systems are complex and harder to develop, test and deploy.
Another challenge with using the microservice architecture is that deploying features that span multiple services requires in general careful coordination between the various development teams. That’s quite different than a monolithic architecture, where you can easily deploy updates to multiple components atomically. The last issue is deciding at what point during the lifecycle of the application you should use the microservice architecture. In other words, is a microservice architecture a good choice for the system you are working on ? Anyone else will begin his answer with “it depends”. And this is something common when it concerns answering an interesting technical question.
But we will try here to be more pragmatic and say that when developing the first version of an application, you often don’t have the problems that this architecture solves. In addition to that, using such elaborated and distributed architecture will slow down development. And knowing that the biggest problem of startups is to rapidly evolve the business model and the accompanying application. Using the microservice architecture makes it much more difficult to iterate rapidly. In my opinion, a startup should begin with a monolithic application. Later on, when the problem is how to handle complexity, that’s when it makes sense to functionally decompose the application into a set of microservices.
An then obtain all the desired outcome from this architecture style. But in general, for complex applications, such as engagement systems or a Software as a Service, microservices are usually the right choice ! Another question could be asked before starting a journey with microservices is : Is your team ready enough to start using microservice architecture ? Martin Fowler already answered to this question by saying that a rapid provisioning of your infrastructure is a must. Actually, you should be able to fire up a new server in a matter of hours. Generally, this could be done using the strengths of
cloud computing and automation. The second condition is basic monitoring. With many loosely-coupled services collaborating in production, a monitoring regime must be in place to quickly detect some technical and business issues to rapidly recover your system. Always according to Martin Fowler, rapid application deployment is another condition to be met. With many services to manage, you need to be able to quickly deploy them, both to test environments and to production. Usually, this will involve a Deployment Pipeline that can be executed in no more than a couple of hours, or maybe less.
By the end, keep in mind that these 3 conditions are the bare minimum to begin your journey creating microservices applications. After deciding to use a microservice architecture for your project, many other questions could be asked about a lot of problem areas to solve. We can divide these problem areas into three main layers. The first one is the infrastructure : in which we solve problems that are mostly infrastructure issues outside of development. the second layer is the application in which we solve problems faced by developers.
And between them, the third layer that concern infrastructure issues which also impact development. First of all, deciding how to decompose a system into a set of services is very much an art, but there are a number of strategies that can help. You can keep an eye on the next video of this series to discover that. Another important area concerns the database architecture to use. In addition to how to query data in a microservice architecture that use a database per service.
Ways to ensure data consistency when implementing transactions is another big question to ask. Testing, is another activity that concern developers. One thing is sure, testing a single service is relatively simple. However, testing that the different services work well together
is quite different from usual tests techniques and strategies used in monoliths. Observability is a large discipline that provide insight into the application behavior and gathers many other activities such us health check API, application metrics, distributed tracing, logging, exception tracking and so on. Doing this in a distributed system has for sure its own particularities. In a microservice architecture, there are numerous concerns that every service must implement. (For example, some configurations we can do that are related to the databse.) When developing a new service, it would be
too time consuming to reimplement these concerns from scratch. A much better approach is to build services on top of a framework that handles all these concerns. Security is a priority for each company. Especially dealing with the security issues including
the authentication and authorization in a distributed application is for utmost importance. When building microservices, You must make a variety of architectural and design decisions about how your services communicate with one another and how they communicate with the outside world. Transactional messaging— or sending messages and publishing events when using database transactions is one aspect of communication. Communication style— or What kind of communication mechanism should you use? Reliability— or How can you ensure that communication between services is reliable even though services can be unavailable? Discovery— or How does a client of a service determine the IP address of a service instance (to make, for example, an HTTP request)? External API—or How do clients of your application communicate with the services? Finally, deploying dozens or maybe hundreds of services with traditional ways used for monoliths doesn’t make sense. We have to consider the particularity of the microservice architecture and take advantage of many other technologies such as VMs, containers and the Serverless paradigm to do a better deployment process.
To sum-up this part of the lecture, here are some key takeaways to note: Microservices are an architectural approach to software development where applications are composed of independent services that communicate over well-defined APIs. The microservices approach fosters innovation and ownership and improves the quality attributes of software applications. Microservices share many characteristics and come-up too with different challenges to overcome.
Great ! All what you have learned in this video and all what we will see in the next ones, is basically a knowledge and experience gathered from different resources including The two books of Sam Newman : “Building Microservices” and “Monolith to Microservices” Of course, Chris Richardson’s book “Microservices patterns” and his blog “microservices.io” are great resources that I recommend in addition to some blog articles written by Martin Fowler. On the other hand, many whitepapers, blog articles and videos from the big cloud vendors were used to enrich the content of this series. I can also say that some videos from “goto”, “devoxx” and “infoq” were very helpful to prepare this presentation.
That’s it ! Let me know in the comments section if you have any questions. And don’t forget to like the video and subscribe to the channel. See you in the next video !
2021-09-15 05:37
