Microservices and Software Development
Преглед
Microservices are getting lot of attention in the recent years. It has become a very popular architectural style followed by the developers to build scalable, re-usable, modular applications. The concepts behind microservices are nothing new, but it is a step ahead of service oriented architecture (SOA). The software world is continuously moving towards ‘service oriented paradigm’ and the microservices are the representation and manifestation of this service oriented development. Each microservice performs a particular activity and deployed independently. It has end-point to communicate with other services. So, a monolithic application can be developed by combining number of microservices performing certain activities. Като резултат, the application becomes scalable, portable, modular and manageable.
Microservices, although not exactly a novel concept or practice, have been redefining software development in a lot of ways. Microservices have the potential to replace the monolithic applications and is more aligned to changing business needs of enterprises. Monolithic applications are viewed as inflexible systems and enterprises expend a lot of resources to maintain such applications. Microservices on the other hand, are proving to be more agile and flexible. For example, to implement a change in a monolithic system, the entire system needs to be redeployed and restarted which is a costly proposition. On the other hand, Microservices are small, independent and reusable services which can be modified and independently deployed. This allows enterprises to save a lot of investments. Although it cannot be said that Microservices are being universally used, there are some encouraging case studies already.
Must Read – Предимства на API за агрегация на социални медии,en
What are Microservices?
Microservices is an architectural style of developing a single software application which is a combination of independent, small services. The idea is to be able to work or modify each service in an isolated manner so that unlike in the case of monolithic application, the whole software application is not impacted because of the update. Each service has its own processes and communicates in a lightweight mechanism – often with the help of an HTTP resource web service.
To understand the features of Microservices architecture, it may be relevant to compare it with the Monolithic software systems. The following table provides the main differences between a monolithic and Microservices software systems.
| Mechanism | Monolithic | Microservices |
| Process | Puts all functionalities in a single process. | Puts individual functionalities into separate services. |
| Scaling | Replicates the monolith in multiple servers. | Distributes the services across services and replicates whenever needed. |
Why is it gaining popularity?
The Microservices way of developing and managing software applications is more aligned to changing business needs and that is the most important reason enterprises are gradually embracing it. In a challenging and dynamic business scenario, businesses need to quickly respond to changing needs but monolithic software systems do not allow them to do so. Microservices are more agile and responsive to changing situations. The main reasons for the popularity are given below:
- Microservices applications allow fault isolation. Whenever, there is an issue, the isolated, independent nature of the services allow separation from the main software and assessment. The software application remains unaffected while the fault is being fixed.
- Enterprises do not need to commit for a long term to a particular technology stack because they can replace it with another one that fulfills their needs.
- Since the services are isolated and independent, it is easy to gain knowledge and start working.
What are the architectural components?
The architectural components of a Microservice architecture can also be called as its defining characteristics. The main components of the architecture are described below.
Simple request processing architecture
Unlike complex systems such as the Enterprise Service Bus (ESB) that employs advanced systems for performing tasks such as message routing, choreography, and applying business rules, the microservice architecture processes a request in a simple manner – it accepts requests, processes the same and generates a response.
Decentralization and flexibility
Microservice architecture allows enterprises to add independent services from anywhere regardless of the language or program used to develop those services. This provides the software developers to choose the most suitable services according to their needs.
Robust issue management
Since the architecture may comprise several disparate services that interact with one another constantly, there will always be a possibility of issues. In such cases, the problematic service can be isolated from the whole software system and fixed or replaced while the software system continues to operate smoothly.
Must Read – Steps to work with Java Persistence API?
Как работи?
Microservices architecture works on the basis of its principles which can be applied across software applications, regardless of technology or platform. The way Microservices work is described below:
Build it and run it
It kind of follows Amazon’s philosophy of “build it and run it”. Software applications are built and it is assumed that the development team is responsible even after the software has been delivered. This is unlike in the case of software projects where the development team is dismantled after the software is delivered and handed over to the maintenance team. In this case, the development team takes full responsibility even after the software is delivered.
Componentizing software into services
While the Microservice architecture can work like the monolithic software system does – calling libraries – it brings a unique feature. Libraries are components that are linked to a program which is called with the help of in-memory function calls. But Microservices use services that are out-of-process components that communicate with the software with the help of stuff such as web services or a remote procedure call.
Must Read – Какво е Референтен Архитектура и Fit / Gap Analysis
Why it is different from SOA?
While both SOA and Microservice architecture share common principles in componentizing a software application in the form of services, те не са същите. The main differences between SOA and Microservice architecture are described below.
Communication mechanism
While the SOA allows you to develop services in diverse technology stacks and deploy them to develop a software application, it also requires each service to communicate using a common communication mechanism. However, in the case of Microservice architecture, there is no such requirement. Services can be deployed and operated independently.
Impact of communication failure
In SOA, the Enterprise Service Bus (ESB) is used for communication across all services deployed. In the case of a failure of the ESB, the communication between services can break down. Очевидно, there is total dependence on ESB. In the case of Microservices, each service can be differently built and in case of a fault or bug, only that particular service is affected and not the others.
Size and scope
Each service in a microservice architecture tends to be significantly smaller than that in an SOA architecture. Microservices are independently deployable service while an SOA can be a part of a monolith application or small deployable services.
Some examples of Microservices
Many prominent organizations have been leaving the monolithic system for microservice architecture which include Netflix, eBay, Amazon, the UK Government Digital Service, realestate.com.au, Forward, Twitter, PayPal, Gilt, Bluemix, Soundcloud, The Guardian and many more.
Netflix has been using microservices in SOA architecture with great success. It receives more than one billion calls every day through APIs from more than 800 diverse kinds of devices and then makes five additional calls to the backend service.
eBay has moved to microservice as well with their core application comprising several smaller, autonomous applications. Each small application executes the business logic for different business areas of the application.
Заключение
It is obvious that microservices are much favored because they are more aligned to changing business scenario. However, it needs to be kept in mind that putting together so many diverse services to fulfill a single objective is no cake walk. Enterprises will still have to manage clear, timely communication in the system which can be a challenge. Also, managing teams or people who have knowledge of managing so many diverse services can be a challenge. All things considered, microservice architecture still seems a much better option than monolithic architecture.
