igoralves1 · December 6, 2016 03:39
diff --git a/gistfile1.txt b/gistfile1.txt
 http://risebird.tumblr.com/post/142205462000/node-microservices






 A couple of months ago, I saw a great presentation by Laurie Voss (@seldo), cofounder of NPM, on Node Microservices. Here’s a nice summary of what I got out of it:

 Microservices (AKA Service Oriented Architecture) work well in the Node environment. The microservices paradigm essentially splits your ginormous monolithic app into smaller applications that run on separate machines, and interface with each other. Such a distributed system usually comes with technical and organizational advantages, as well some some improvements in resource efficiency. It does, at the same time, introduce some new problems, most of them stemming from the need for concurrency/synchronization between services.

 Right off the bat, it’s clear that you save some cost by having a more stable architecture: If one service goes down, it doesn’t mean the whole system goes down; and often there are ways to work around a “partial outage” before the whole system is back in full swing. It’s also good to create microservices that can come back online individually, even during a “cold start”, when some vital initialization data might be missing.

 Having separate services in your architecture also means you will be able to specialize in each one: Each microservice can be tuned for efficiency, improving overall performance. The entire architecture itself becomes simpler and a nice separation of concerns means that it will be easier to debug and isolate problems. Having smaller modules makes it easier to understand and refactor functionality. Metrics are also easier to enforce and organize, and dashboards can monitor individual services and alert you about problems as necessary; and of course, knowing where the problem originates speeds up the debugging process. It also helps to try to keep uniformity across services, such as consistent error formats, which will make it easier to implement analytics and diagnose problems without too much extra effort.

 As with most code, it’s a best practice to share logic across services. With NPM, it becomes easy to separate logical modules into packages which can be easily deployed to separate microservices in a very programmatic way. No code should ever be repeated between microservices, and if it is, you need to make it a deployable module right away; however, each module instance should still be using one source of truth when it comes to data. For actual deployment, everything should be automated, and NPM will help you download and deploy mircoservice dependencies using its registry, which can be accessed at any time with a simple command-line interface.

 When going from a monolithic application to a service oriented architecture, keep in mind that communications between services should be asynchronous. This makes the services function as individual workers which can be more easily repurposed as fits architectural needs. You should envision all microservices working simultaneously, instead of being part a waterfall-like flow. This improves overall system efficiency but does add complexity because of possible race conditions. Another important thing to implement is graceful failures between services. Upstream services need to handle downstream failures correctly and be ready to recover from uncommon issues such as bad network connectivity.

 …hopefully you switch to Node Microservices today :)
	http://risebird.tumblr.com/post/142205462000/node-microservices






	A couple of months ago, I saw a great presentation by Laurie Voss (@seldo), cofounder of NPM, on Node Microservices. Here’s a nice summary of what I got out of it:

	Microservices (AKA Service Oriented Architecture) work well in the Node environment. The microservices paradigm essentially splits your ginormous monolithic app into smaller applications that run on separate machines, and interface with each other. Such a distributed system usually comes with technical and organizational advantages, as well some some improvements in resource efficiency. It does, at the same time, introduce some new problems, most of them stemming from the need for concurrency/synchronization between services.

	Right off the bat, it’s clear that you save some cost by having a more stable architecture: If one service goes down, it doesn’t mean the whole system goes down; and often there are ways to work around a “partial outage” before the whole system is back in full swing. It’s also good to create microservices that can come back online individually, even during a “cold start”, when some vital initialization data might be missing.

	Having separate services in your architecture also means you will be able to specialize in each one: Each microservice can be tuned for efficiency, improving overall performance. The entire architecture itself becomes simpler and a nice separation of concerns means that it will be easier to debug and isolate problems. Having smaller modules makes it easier to understand and refactor functionality. Metrics are also easier to enforce and organize, and dashboards can monitor individual services and alert you about problems as necessary; and of course, knowing where the problem originates speeds up the debugging process. It also helps to try to keep uniformity across services, such as consistent error formats, which will make it easier to implement analytics and diagnose problems without too much extra effort.

	As with most code, it’s a best practice to share logic across services. With NPM, it becomes easy to separate logical modules into packages which can be easily deployed to separate microservices in a very programmatic way. No code should ever be repeated between microservices, and if it is, you need to make it a deployable module right away; however, each module instance should still be using one source of truth when it comes to data. For actual deployment, everything should be automated, and NPM will help you download and deploy mircoservice dependencies using its registry, which can be accessed at any time with a simple command-line interface.

	When going from a monolithic application to a service oriented architecture, keep in mind that communications between services should be asynchronous. This makes the services function as individual workers which can be more easily repurposed as fits architectural needs. You should envision all microservices working simultaneously, instead of being part a waterfall-like flow. This improves overall system efficiency but does add complexity because of possible race conditions. Another important thing to implement is graceful failures between services. Upstream services need to handle downstream failures correctly and be ready to recover from uncommon issues such as bad network connectivity.

	…hopefully you switch to Node Microservices today :)