We’ve had a few articles over the years on the differences and similarities between SOA and microservices. Some suggest there is much to be learned from SOA whereas others believe that distancing microservices from SOA is more beneficial. Furthermore, Neal Ford, amongst others, has suggested that moving from monolithic architectures to a services-based approach may be easier than going to microservices. There has not been much activity recently around the overall “SOA or microservices” debate until RedMonk’s Stephen O’Grady published an article on the subject. In it O’Grady suggests that the size of the service is not the deciding factor, similar to what others have argued over the years, such as Dan North, and separately Jeppe Cramon stated:
Tag: advantages of microservice
Microservices Architecture Advantages and Challenges
I was asked to review an architecture diagram for an application that would use MicroServices. I could find few REST APIs in the diagram connecting to a single database.
That raised tons of questions:
1. Only one database?
2. What if the database is down?
3. All services will be hosted in a single server?
4. What if I need to upgrade the server?
What is MicroService?
It will not be an easy task to define MicroService in a single statement. The definition depends on different viewpoints & requirements. However, most of the prominent characteristics of MicroServices are:
• They encapsulate a customer or business scenario.
• They are developed by a small development team.
• They can be written in any programming language and use any framework.
• OOPS concept is implemented in loosely coupled manner
• The Codebase is small that are independently versioned, deployed, and scaled.
• They interact with other MicroServices over well-defined interfaces and protocols.
• They have unique names (URLs) that can be used to resolve their location.
• They remain consistent even after failures.
SOA vs Microservices
Microservice is not only SOA. If Microservices are to be defined, is simply an ideal, refined form of SOA. SOA focuses on imperative programming, whereas MicroServices architecture focuses on a responsive-actor programming style. It’s something like decomposing a large monolithic service into smaller independent services which are self deployable, sustainable & scalable.
Microservice Architecture – Overview
Just as there is no formal definition of the term MicroServices, there’s no standard model that you’ll see represented in every system based on this architectural style. But you can expect most MicroService systems to share a few notable characteristics.
1. Software built as MicroService can be broken down into multiple components, so that each of these services can be deployed, and redeployed independently without compromising the integrity of an application.
2. The MicroServices style is usually business and priorities centric. Unlike a traditional monolithic development approach, MicroService architecture utilizes cross-functional teams. In MicroServices, a team owns the product for its lifetime, as in Amazon’s oft-quoted maxim “You build it, you run it.”
3. MicroServices have smart endpoints that process info and apply logic, and dumb pipes through which the info flows. They receive requests, process them, and generate a response accordingly.
4. Decentralized control between teams, so that its developers strive to produce useful tools that can then be used by others to solve the same problems.
5. MicroServices architecture allows its neighbouring services to function while it bows out of service. This architecture also scales to cater to its clients’ sudden spike in demand.
6. MicroService is ideal for evolutionary systems where it is difficult to anticipate the types of devices that may be accessing our application.
MicroService architecture uses services as small components and is usually business centric; focuses on products functionality; has smart end points but standard input/output mechanisms; is decentralized, as well as decentralized data management; is designed to auto scale & is resilient to failure; and, of course is an evolutionary model.
Knowledge Needed to Implement MicroService
To conclude our brief overview of microservices here, we need to have a basic grasp of the following concepts:
• Object Oriented Programming (OOP) with loose coupling techniques
• Web service / API/ REST—a way to expose the functionality of your application to others, without a user interface
• Service Oriented Architecture (SOA)—a way of structuring many related applications to work together, rather than trying to solve all problems in one application
• Single Responsibility Principle (SRP)—the idea of code with one focus
• Interface Segregation Principle (ISP)—the idea of code with defined boundaries.
Advantages of MicroService
• Evolutionary Design – No need to rewrite your whole application. Add new features as MicroServices, and plug them into your existing application
• Small Codebase – Each MicroService deals with one concern(SoC) only – this result in a small codebase, which means easier maintainability
• Auto Scale – freedom to scale only the loaded service, as that service will handle the bigger load.
• Easy to Deploy – Deploy only the needed codebase, instead of redeploying the entire application.
• System Resilience – If some of the services go down only some features will be affected, not the entire application.
Challenges of MicroService
The MicroService architecture helps a lot, but comes with its own challenges.
• Inter Service Communication – MicroServices will rely on each other and they will have to communicate. A common communication channel needs to be framed using HTTP/ESB etc.
• Health Monitoring – There are more services to monitor which may be developed using different programming languages.
• Distributed logging – Different services will have its own logging mechanism, resulting GBs of distributed unstructured data.
• Transaction Spanning – MicroServices may result in spanning of transactions over multiple services & database. An issues caused somewhere will result is some other issues somewhere else.
• Finding root cause – Distributed logic with distributed data increases the effort of finding the root cause. The performance related root cause can still be managed using APM tools like New Relic & Dynatrace.
• Cyclic dependencies between services – Reproducing a problem will prove to be very difficult when it’s gone in one version, and comes back with a newer one.
Conclusions
MicroServices architectural style is an important idea – one worth serious consideration for enterprise applications. A Monolithic architecture is useful for simple, lightweight applications. It will be a maintenance nightmare if used for complex applications. The MicroServices architecture pattern is the better choice for complex, evolving applications despite the drawbacks and implementation challenges.
MicroServices is prevalent for a long time and recently we are seeing increase in their popularity. There are a number of factors that lead to this trend with scalability being probably the most important one. Utilization of MicroServices by “big guys” like Amazon, NetFlix, eBay, and others, provides enough confidence that this architectural style is here to stay.