We know nowadays there is a great demand for microservice architecture. The big companies such as google, microsoft, Uber they already moved to microservice architecture. Here over this article lets have a look at different types of architecture such as Monolithic, service-oriented architecture and microservice architecture.
Monolithic Architecture
In the case of Monolithic Architecture the entire application composed in a single unit. In the case of Monolithic architecture, the components are tightly coupled to each other. So if any program component to be updated, then the entire application should be rewritten. Monolithic architecture is good for small and simple projects.
Advantages of Monothilc
Easy to develop
The currently available IDEs and development tools will help to develop Monolithic application very easily
Easy to deploy
The result of Monolithic become mostly a single war. So it is very easy to deploy the application on a server.
Easy to Scale
Easy to scale by deploying the same application(war) on different servers and connect all servers via the load balancer.
Disadvantages
The monolithic architecture only fit for the small and simple project. If the architecture is large then it is difficult to proceed with Monolithic architecture. The following disadvantages mainly affecting the large scale application
Development slow down if code base become large
The large monolithic code base intimidates developers, especially ones who are new to the team. The application can be difficult to understand and modify. As a result, development typically slows down. Also, because there are not hard module boundaries, modularity breaks down over time. Moreover, because it can be difficult to understand how to correctly implement a change the quality of the code declines over time. It’s a downwards spiral.
Slow down performance of IDE for a the large code base
the larger the code base the slower the IDE and the less productive developers are.
Long time taken for starting the server
the larger the application the longer it takes to start up. This had have a huge impact on developer productivity because of time wasted waiting for the container to start. It also impacts deployment too.
Dificult to deploy the application
a large monolithic application is also an obstacle to frequent deployments. In order to update one component you have to redeploy the entire application. This will interrupt background tasks (e.g. Quartz jobs in a Java application), regardless of whether they are impacted by the change, and possibly cause problems.
Scaling the application can be difficult -
a monolithic architecture is that it can only scale in one dimension. On the one hand, it can scale with an increasing transaction volume by running more copies of the application. Some clouds can even adjust the number of instances dynamically based on load. But on the other hand, this architecture can’t scale with an increasing data volume. Each copy of 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.
Obstacle to scaling development -
A monolithic application is also an obstacle to scaling development. Once the application gets to a certain size its useful to divide up the engineering organization into teams that focus on specific functional areas. For example, we might want to have the UI team, accounting team, inventory team, etc. The trouble with a monolithic application is that it prevents the teams from working independently.
Requires a long-term commitment to a technology stack -
a monolithic architecture forces you to be married to the technology stack (and in some cases, to a particular version of that technology) you chose at the start of development . With a monolithic application, can be difficult to incrementally adopt a newer technology. For example, let’s imagine that you chose the JVM. You have some language choices since as well as Java you can use other JVM languages that inter-operate nicely with Java such as Groovy and Scala. But components written in non-JVM languages do not have a place within your monolithic architecture.
Service Oriented Architecture
the SOA evolves for resolving the issues of Monolithic architecture. This architecture is recommended for mid scale applications. A service-oriented architecture is essentially a collection of services. These services communicate with each other. The communication can involve either simple data passing or it could involve two or more services coordinating some activity. Some means of connecting services to each other is needed
The SOA is designed to provide services to other applications through the protocol. It is a concept only and not tied to any programming language or platform. Web services is a technology of SOA most likely.
In the case of SOA a service is well-defined, self-contained function that represents unit of functionality. A service can exchange information from another service. It is not dependent on the state of another service. The figure given below illustrates the service oriented architecture. Service consumer sends service request to the service provider and service provider sends the service response to the service consumer. The service connection is understandable to both service consumer and service provider.
There are 2 main roles in SOA, a service provider and a service consumer. A software agent may play both roles. The Consumer Layer is the point where consumers (human users, other services or third parties) interact with the SOA and Provider Layer consists of all the services defined within the SOA. The following figure shows a quick view of an SOA architecture.
Enterprise Service Bus (ESB) is a style of the integration architecture that allows communication via a common communication bus that consists of a variety of point-to-point connections between providers and consumers . In addition to above, the data storage is shared within all services in SOA.
Advantages of SOA
Service Reusability
In SOA, an application is built by assembling small, self-contained, and loosely coupled pieces of functionality. Therefore, the services can be reused in multiple applications independent of their interactions with other services.
Easy Maintainability
Since a service is an independent entity, it can be easily updated or maintained without having to worry about other services. Large, complex applications can thus be managed easily.
Greater Reliability
SOA-based applications are more reliable since small, independent services are easier to test and debug as compared to massive chunks of code.
Location Independence
The services are usually published to a directory where consumers can look them up. This approach allows a service to change its location at any time. However, the consumers are always able to locate their requested service through the directory look up.
Improved Scalability and Availability
Multiple instances of a single service can run on different servers at the same time. This increases scalability and availability of the service.
Improved Software Quality
Since services can be reused, there is no scope for redundant functionality. This helps reduce errors due to inconsistent data, and thereby improves the quality of code.
Platform Independence
SOA facilitates the development of a complex product by integrating different products from different vendors independent of the platform and technology.
Increased Productivity
Developers can reuse existing legacy applications and build additional functionality without having to develop the entire thing from scratch. This increases the developers' productivity, and at the same time, substantially reduces the cost of developing an application.
Disadvantages of SOA
Increased Overhead
Every time a service interacts with another service, complete validation of every input parameter takes place. This increases the response time and machine load, and thereby reduces the overall performance.
Complex Service Management
The service needs to ensure that messages have been delivered in a timely manner. But as services keep exchanging messages to perform tasks, the number of these messages can go into millions even for a single application. This poses a big challenge to manage such a huge population of services.
High Investment Cost
Implementation of SOA requires a large upfront investment by means of technology, development, and human resource.
Microservices
Microservices is a kind of shrink the SOA services, make them as small and indipendent as possible and create a hell lot of them; the only difference I see between traditional SOAs and microservices is that the latter clearly states that the size of a service should be minimal, else it needs to be split in multiple services. In other words, microservices are an implementation of SOA.
Basically, this architecture type is a particular way of developing software, web, or mobile applications as suites of independent services – a.k.a microservices. These services are created to serve only one specific business function, such as User Management, User Roles, E-commerce Cart, Search Engine, Social Media Logins, etc. Furthermore, they are completely independent of each other, meaning they can be written in different programming languages and use different databases. Centralized services management is almost non-existent and the microservices use lightweight HTTP, REST, or Thrift APIs for communicating among themselves.
Comparison between SOA and microservice
| SOA | Microservices |
| Built on the idea of “share-as-much-as-possible” architecture approach | Built on the idea of “share-as-little-as-possible” architecture approach |
| More importance on business functionality reuse | More importance on the concept of “bounded context” |
| Common governance and standards | Relaxed governance, with more focus on people collaboration and freedom of choice |
| Uses enterprise service bus (ESB) for communication | Uses less elaborate and simple messaging system |
| Supports multiple message protocols | Uses lightweight protocols such as HTTP/REST & AMQP |
| Common platform for all services deployed to it | Application Servers not really used. Platforms such as Node.JS could be used |
| Multi-threaded with more overheads to handle I/O | Single-threaded usually with use of Event Loop features for non-locking I/O handling |
| Use of containers (Dockers, Linux Containers) less popular | Containers work very well in MSA |
| Maximizes application service reusability | More focused on decoupling |
| Uses traditional relational databases more often | Uses modern, non-relational databases |
| A systematic change requires modifying the monolith | A systematic change is to create a new service |
| DevOps / Continuous Delivery is becoming popular, but not yet mainstream | Strong focus on DevOps / Continuous Delivery |
Advantages of Microservice
Improve fault isolation: Larger applications can remain mostly unaffected by the failure of a single module.
Eliminate vendor or technology lock-in: Microservices provide the flexibility to try out a new technology stack on an individual service as needed. There won’t be as many dependency concerns and rolling back changes becomes much easier. With less code in play, there is more flexibility.
Ease of Understanding: With added simplicity, developers can better understand the functionality of a service
The Disadvantages of Microservices
Developing distributed systems can be complex. Since everything is now an independent service, you have to carefully handle requests travelling between your modules. In one such scenario, developers may be forced to write extra code to avoid disruption. Over time, complications will arise when remote calls experience latency.
Multiple databases and transaction management can be painful.
Testing a microservices-based application can be cumbersome. In a monolithic approach, we would just need to launch our WAR on an application server and ensure its connectivity with the underlying database. With microservices, each dependent service needs to be confirmed before testing can occur.
Deploying microservices can be complex. They may need coordination among multiple services, which may not be as straightforward as deploying a WAR in a container.
No comments:
Post a Comment