Well, you may be wondering what is an event-driven architecture if this is your first time coming across this terminology, if you've been struggling to comprehend this design pattern, well search no more my friend because I about to chop this into pieces so you lovely brain can apprehend all of this jazz and be helpful in your next project.
Before go this odyssey it's essential that we understand why this design pattern was first introduced because every technology my friend exists to solve a problem. I like to think of Microservices aka Event-Driven Architecture like the iPhone pre-smartphone era when we had the Nokia and Blackberry. Thus just like how we had analog phones like Nokia before the smart era, thus we have monolith applications before event-driven architecture but the iPhone forever changed how phones we're built.
I know what you may be thinking now my friend, I came here just to read about EDA but now this article is about monolithic applications. Well it's important you know where you are coming from so you can know where you are heading to. Thus a monolithic application is simply a big chuck program consisting of several functionalities in a single codebase that is chained together. All of us started out with a monolithic application when we tried to design a system with various functionalities. Thus if we're designing an e-commerce system, with various layers or services like authentication, products, and orders. The system would look to design and deploy would consist of a single codebase in a jar file like the one below.
It may seem like it's ok to use this design where all the different services are wrapped in a single jar-like file with one database because it's easy to build, has one tech stack like a coding language, and has fewer problems related to network latency and security. Well in as much as they're advantages they're also disadvantages to this architectural style, so let's look at some of the disadvantages of building a monolithic architecture for building applications.
Coming at number one on our list is the fact that it's difficult to maintain and manage, as the file sizes become too larger with more requirements. More so, because of the jar-like structure deploying becomes cumbersome as any small changes to the application mean redeploying the whole application. Making changes to this application using new technologies looks like a nightmare because of the singleton structure in which services adopt the same tech stack. Thus we can see the interdependent nature of monolithic applications means a breakdown in a single service means a breakdown in the whole system.
Well my friends this doesn't mean that monolithic applications have been extinct like the dinosaurs, they're still many great companies out there still using this and it's always the best design choice for personal projects. However, if you are building a next Facebook, Twitter, or Uber then my friend for something that scales very fast we would have to shop somewhere else. This is where Microservice architecture comes in also commonly referred to as event-driven applications. This design pattern was derived from service-oriented architecture (SOA). However, we're not going to dive into SOA, because this would just shift us from our focus which is EDA. So then with the problems of monolithic applications, how do Microservices come in as the hero to save us, poor developers.
Just as the name implies this are a group of small services which handle a small portion of the functionality and data communicating with others directly through an intermediary commonly known as the Message broker. According to Sam Newman, "Microservices are the small services that work together."
Thus we can see that there's a separation of concern in this design pattern and each application maintains its own database. The diagram below vividly illustrates this design architectural style.
So my friend, you may be asking "what's the big deal with this separation of files?". Well, what this fragmentation means is your application is much more capable of being free in choosing its own tech stacks, independently deployable and so much more. Well let's look at some of the principles of microservices
Single responsibility: It is one of the principles defined as a part of the SOLID design pattern. It states that a single unit, either a class, a method, or a microservice should have one and only one responsibility. Each microservice must have a single responsibility and provide a single functionality. You can also say that: the number of microservices you should develop is equal to the number of functionalities you require. The database is also decentralized and, generally, each microservice has its own database.
Built around business capabilities: In today’s world, where so many technologies exist, there is always a technology that is best suited for implementing a particular functionality. But in monolithic applications, it was a major drawback, as we can’t use different technology for each functionality and hence, need to compromise in particular areas. A microservice shall never restrict itself from adopting an appropriate technology stack or backend database storage that is most suitable for solving the business purpose, i.e., each microservice can use different technology based on business requirements.
Design for failure: Microservices must be designed with failure cases in mind. Microservices must exploit the advantage of this architecture and going down one microservice should not affect the whole system, other functionalities must remain accessible to the user. But this was not the case in the Monolithic applications, where the failure of one module leads to the downfall of the whole application.
Let's take a look at some of the pros and cons of Microservices. Like nothing under the sun there's no disadvantage.
*Advantages of Microservices: *
It is relatively easy to manage due to the separation of concerns and the small size of each service and functionality.
Redeploying is made easy, as a change in any single service doesn't entail redeploying the entire application.
It is fairly easy to onboard new developers as he or she needs to understand only a particular microservice and avoid the stress of trying to understand the Spaghetti code of monolithic applications.
Microservice supports horizontal scaling which may result from too much resource demand from a particular service. Thus only that service can be scale-out, hence optimizing resource allocation.
Microservice are fault-tolerant and resilient to bug, because if one service goes down it doesn't affect the other microservices and the whole system remains intact and continues to function properly by providing other functionalities.
Disadvantages of Microservices:
Being a distributed system, it is much more complex than monolithic applications. Its complexity increases with the increase in a number of microservices.
Skilled developers are required to work with microservices architecture, which can identify the microservices and manage their inter-communications.
Independent deployment of microservices is complicated.
Microservices are costly in terms of network usage as they need to interact with each other and all these remote calls result in network latency.Microservices are less secure relative to monolithic applications due to the inter-services communication over the network.
Debugging is difficult as the control flows over many microservices and to point out why and where exactly the error occurred is a difficult task.
Wow this may seem so much and even confusing to digest given the disadvantages, thus the hard question?
When should you use this architecture?
Firstly it is important to note that Microservice is ideal for improving agility and moving quickly. Thus the following 4 points can be used when considering adopting Microservices in your application.
1. Cross-account, cross-region data replication
When you have teams operating and deploying across different regions, accounts and operations, you can consider adopting this architecture. When using event routers to transfer data between systems, you can develop, scale and deploy services independently from other teams.
_2. Fanout and parallel processing _
When operating numerous systems which need responses from an event in order to operate, you can implement Microservices architecture to fan out the event without having to write custom code to push the event to the systems, each of which can process the event in parallel with a driven purpose.
Resource state monitoring and alerting
This design can be implemented to continuously check on your resources by monitoring and receiving alerts on any changes, events, and updates. These resources can include storage buckets, database tables, serverless functions, compute nodes, and more.Integration of heterogeneous systems
If you have a team working with different tech stacks then you can use this architecture to share information between teams without coupling. The event router establishes indirection and interoperability among the systems, so they can exchange messages and data while remaining agnostic.
This was a high-level design and we would go to a low level in subsequent writeup where we would use NodeJs app and RabbitMq to implement a Microservice architecture in a small eCommerce application. Until then Happy keystroking!!!
Top comments (0)