Microservices: A fallacy or the real future? the nodejs advantage?

Microservices: A fallacy or the real future? the nodejs advantage?
0

#1

Just gathering opinions about this architecture? Is this the only future? Are there other architectures? Which ones?

Also wondering if nodejs advantages other technologies regarding micro/nano services?

For those who don’t know what microservices are:

Definition (wikipedia)
modern interpretation of service-oriented architectures (SOA) used to build distributed software systems.

Similar to SOA in:

  • microservice architecture: processes that communicate with each other over the network in order to fulfill a goal.
  • these services use technology-agnostic protocols.

Different to SOA in:

  • microservices gives an answer to the question of how big a service should be and how they should communicate with each other
  • services should be small and the protocols should be lightweight

Microservices architectural style is a first realisation of SOA that has happened after the introduction of DevOps and this is becoming the standard for building continuously deployed.

Pro’s and Con’s (wikipedia)
Pro’s:

  • technology-agnostic protocols.
  • enhances the cohesion and decreases the coupling.
  • reduces the need for a big up-front design and allows for releasing the software early and continuously.

Con’s:

  • services form information barriers
  • the architecture introduces additional complexity and new problems to deal with, such as network latency, message formats, load balancing and fault tolerance, ignoring one of these belongs to the “fallacies of distributed computing”
  • testing and deployment are more complicated
  • inter-service calls over a network have a higher cost in terms of latency and message processing time than in-process calls within a monolithic service process
  • moving responsibilities between services is more difficult; it may involve communication between different teams, rewriting the functionality in another language or fitting it into a different infrastructure
  • the complexity of a monolithic application is only shifted into the network, but persists

#2

Development fashion, like clothing, comes and goes in cycles, so the answer to “is this the future” is “Yes, as long as you’re willing to wait for it to become popular again”. There are still a few larger trends that seem pretty consistent over time, and division of large systems into independent services is one of them (helped along by underlying techs like Docker and rkt). The way in which those systems are assembled varies though, ranging from complex orchestration platforms, to detailed service description languages, to simple orthogonal APIs cooperating through mere convention.

NodeJS platforms (and others in the same niche) have tended to focus entirely on the last, and paradoxically enough, systems tend to be more robust for it. I think that has to do with the fact that such platforms are forced to address concerns about interop directly rather than place the burden on some “glue layer” that may have its own set of problems.

That said, it’d be nice if we could stop reinventing the wheel when it comes to queueing, broadcasting, caching, storage, and so on. Sure, there will always be better implementations that come along every year, and everyone’s going to have their preferred APIs, but I keep seeing platforms spring up that don’t seem to benefit from even the most basic history lessons. I suppose It’s just part of the maturation process for any language ecosystem.