MICROSERVICES – A lifeline for developers and enterprise scale businesses. Over the last few years, Microservice Architecture emerged out to be on top of conventional SOA(Service Oriented Architecture). This much more precise and smaller architecture brought in many benefits along with it. Enough to make the business more scalable in a fly by paralleling development, testing and maintenance across various independent teams.
What are Microservices?
A collection of focused and small services which, on execution develops a complete application. A single responsibility of the application which you are developing is represented by an instance of a microservice.
How is a Microservice Architecture different from SOA(Service Oriented Architecture)?
Broadly speaking, Instead of making a large application and then adding more functionalities via code in it. The present times demand Micro Service Architecture wherein we create multiple individually focused modules with well-defined interfaces and then combine them together to make a scalable, testable product. The product or software which might have taken a year to deliver can now be delivered in weeks with the help of Micro Service Architecture.
Speed of communication - SOA uses ESBs a.k.a Enterprise Service Buses which is comparatively a lot slower with respect to messaging mechanism used in Microservice Architecture.
Database - SOA consists outsized RDBMS whereas Microservice Architecture use micro-SQL
While SOA focuses on imperative programming, the microservices architecture uses a programming style that focuses on a responsive-actor as its base. While SOA models usually have an outsized RDBMS, microservices frequently use databases such as NoSQL or micro-SQL that can be connected to conventional databases. That said, the real difference lies in the architecture methods that are used for creating an integrated set of services.
Typical & well-managed architecture based on Microservices should display the following attributes.
Decoupling of Databases - Each microservice helps to establish a single business capability and should have its own separate database.
Increased Flexibility for Programmers - It is true that microservices provide developers with the freedom to not be dependent on a specific programming language, increasing their flexibility. However, you would have to face the hassle of maintaining multiple libraries and database versions.
Specific API endpoints- API endpoint must be provided by every microservice in order to communicate either synchronously or asynchronously with other microservices. These endpoints work on HTTP verbs say get request, post request and delete request etc.
Correlated calls with the help of various methods like IDs, tokens or headers.
Optimized fault tolerance and consistent performance monitoring with the effective use of caching to help speed up the response time.
Devops more integrated than they ever were. Security more robust and unbiased as the diversified structure provides hackers with the opportunity to hit the soft target of your system.
Standardized development practices along teams call for a bigger investment on a platform basis. This is where cloud-based providers come into the picture like AWS(Amazon Web Services), Heroku, Google cloud etc.
Remember that not all microservices are bound to provide some form of UI. Some are there to support the integrated interaction such as middleware team.
How can you achieve data consistency in a typical microservice architecture?
Every microservice is responsible for its own data model. Ideally, each database model should be 100% decoupled from another. The idea behind this is to know what persistence model is needed for the team working on facilitating a single microservice?
Achieving data consistency can be very challenging, I hope the below-mentioned tips may help you.
Come up with a system design which won’t need distributed consistency. Although, this seems impossible for highly compound or complex architecture.
Plan ahead on how to handle the failure scenarios in the future as you aim to acquire data consistency in an early design stage.
Go for event-driven architecture.
Modifying one data source at a time, this will help you in reducing the number of inconsistencies.
Consider reversible service capabilities.
There are different strategies that need to be followed while testing a typical microservice architecture.
1.Scalability Testing - In order to check whether the microservice is independent and agile, testing scenarios should be executed to check whether its scalable or not. Testers need to ensure whether:
a. With an increase in load, the microservice replicates effectively to balance the load. b. To check whether replicated microservices can collectively accomplish a task.
2.Functionality Testing - Individual testing is required to ensure whether it can implement the feature it was designed for. If an implementation is done in a container, it becomes easier to pull and test the functionality of an individual microservice.
3.End to End Testing - A proper strategy for an end to end testing is to limit the number of times test cases are executed. A healthy balance between end to end along with other testing strategies will filter out even smallest issues.
4.User Interface Testing - It is probably the highest order since it allows the tester to understand how the application will behave when used by an end user.
1.Integration Testing and Debugging - A quality assurance engineer should have thorough knowledge regarding each of the various services that a software is delivering. Analyzing logs across multiple microservices can be very twitchy and mentally taxing.
2.Struggling Coordination - With so many independent teams working simultaneously on improving different functionalities, it becomes very challenging to coordinate the overall development of the software. For instance, it is tough to spot out an idle time window for extensive testing of the entire software.
3.Performance tracing - If you are transitioning from monolithic to microservice architecture then a large number of tiny components are bound to be generated. These components should communicate consistently.
4.Difficult to visualize after effects - Involving numerous distinctively functioning teams, requires a top-notch interface for communication. If all interfaces aren’t properly updated in a software then it may doom the collaboration. It becomes very strenuous to consider the after-effects of bringing any enhancement in the existing communication platform.
There are many more challenges if things aren’t properly planned in a Microservice Architecture.
I drafted this answer by keeping all the data that I feel should be conveyed to develop a good understanding for microservice. This is a bit too long but I hope this provides you with enough clarity related to Microservice Architecture.