Microservices Introduction (Monolithic vs. Microservice Architecture)
Microservices Introduction (Monolithic vs. Microservice Architecture)
Learn about the disadvantages of monolithic architecture and how they're solved by microservices.
Join the DZone community and get the full member experience.Join For Free
Containerized Microservices require new monitoring. Read the eBook that explores why a new APM approach is needed to even see containerized applications.
Recently, there has been a lot of fuss about microservices. There are a lot of discussions happening about microservices in almost all the IT companies. Microservices architecture can be easily understood when we compare it with traditional monolithic architecture.
Almost every enterprise application has a similar kind of layered architecture:
- Presentation: The user interface.
- Business logic: The application’s internal business logic.
- Database access: Almost all applications need to access DB, either SQL or NoSQL.
- Application integration: Quite often, the application needs integration with other applications. This is usually achieved via web service calls (SOAP or REST), or via messaging.
Even though applications have clear, logically modular architecture, but usually, most of the application is packaged and deployed as a monolith. There are actually some advantages to doing this.
Advantages of Monolithic Architecture
- Development is quite simple.
- Testing is very simple. Just launch the application and start end-to-end testing. We can also do test automation using Selenium without any difficulty.
- Deploying the monolithic application is straightforward; just copy the packaged application to the server.
- Scalability is simple. We just need to have a new instance of the monolithic application and ask the load balancer to distribute load to the new instance as well. However, as the monolithic application grows in size, scalability becomes a serious issue.
Monolithic architecture worked successfully for many decades. In fact, many of the most successful and largest applications were initially developed and deployed as a monolith. Many large-scale enterprise applications of big companies are still being deployed as a monolith. But with the changing market and with the emergence of new technologies, there has been a paradigm shift in the way IT industries work. There are some serious issues with monolithic architecture, which most companies are trying to address these days.
Disadvantages of Monolithic Architecture
- Flexibility: Monolithic architecture is not flexible. We can’t use different technologies. The technology stack is decided at the start and followed throughout. Once development matures, sometimes it becomes difficult to upgrade the technology stack versions, let alone incrementally adopt a newer technology.
- Reliability: It's not reliable. If one feature goes down, the entire application might go down.
- Development speed: Development is really slow in monolithic architecture. It's difficult for new team members to understand and modify the code of a large monolithic application. Code quality declines over time. With the increasing size of the code base, the IDE is overloaded and becomes slower. The larger the application, the longer it takes to start up. All these factors have a huge impact on the developers' productivity.
- Building complex applications: It's difficult to build a complex application because of the limitations in terms of technologies.
- Scalability: Monolithic applications are difficult to scale up once they get larger. We can create new instances of the monolith and ask the load balancer to distribute traffic to the new instances, but monolithic architecture can’t scale with an increasing load. Each copy of the application instance will access all of the data, which makes caching less effective and increases memory consumption and I/O traffic. Also, different application components have different resource requirements — one might be CPU intensive while another might memory intensive. With monolithic architecture, we cannot scale each component independently.
- Continuous deployment: Continuous deployment is extremely difficult. Large monolithic applications are actually an obstacle to frequent deployments. In order to update one component, we have to redeploy the entire application.
Because of all the above drawbacks of monolithic applications, microservice architecture is becoming more and more popular day by day. So what is microservice-based architecture?
In short, the microservice architectural style is an approach to developing a single application as a suite of small services, each running in its own process and communicating with lightweight mechanisms, usually via RESTful web services or messaging. These services are built around business capabilities and independently deployable by fully automated deployment machinery. There’s a bare minimum of centralized management of these services, which may be developed in different programming languages and use different data storage technologies. Microservices are small, independently deployable units which are cloud-enabled.
How Microservice Architecture Tackles the Drawbacks of Monolithic Architecture
- Flexibility: Microservices architecture is quite flexible. Different microservices can be developed in different technologies. Since a microservice is smaller, the code base is quite less, so it’s not that difficult to upgrade the technology stack versions. Also, we can incrementally adopt a newer technology without much difficulty.
- Reliability: Microservices architecture can be very reliable. If one feature goes down, the entire application doesn’t go down. We can fix the issue in the corresponding microservice and immediately deploy it.
- Development speed: Development is pretty fast in microservices architecture. Since the volume of code is much less for a microservice, it’s not difficult for new team members to understand and modify the code. They become productive right from the start. Code quality is maintained well. The IDE is much faster. A microservice takes much less time to start up. All these factors considerably increase developers' productivity.
- Building complex applications: With microservice architecture, it's easy to build complex applications. If the features of the application are analyzed properly, we can break it down into independent components which can be deployed independently. Then, even the independent components can be further broken down into small independent tasks which can be deployed independently as a microservice. Deciding the boundaries of a microservice can be quite challenging. It’s actually an evolutionary process, but once we decide on a microservice, it’s easy to develop, as there are no limitation in technologies.
- Scalability: Scalability is a major advantage in microservice architecture. Each microservice can be scaled individually. Since individual microservices are much smaller in size, caching becomes very effective.
- Continuous deployment: Continuous deployment becomes easier. In order to update one component, we have to redeploy only that particular microservice.
As I mentioned earlier, microservice architecture can be easily understood when we compare it with traditional monolithic architecture, but prior to microservices, there’s already similar kind of architecture available. Yes, I’m talking about SOA (Service-Oriented Architecture). SOA has been here for two decades. If you have already worked with SOA and are familiar with its concepts, it could be quite confusing to understand the differences between SOA and microservice architecture. In fact, the two have more in common than differences. In my next post on microservices, I will write about SOA, similarities between SOA and microservice architecture, and of course, the differences between them.
Published at DZone with permission of Jahid Akhtar . See the original article here.
Opinions expressed by DZone contributors are their own.