Geecon – The Practical Implications of Microservices
Author of this presentation, Sam Newman, is technologist who is trying to improve systems by splitting them into microservices. What is microservice? As I understand it…it is small separate service which can be used by other services via some kind of interface (usually REST). When you implement your system in such a way, you end up with several servers which are connected with each other. Such architecture has some good characteristics but there are some which you have to be aware of.
Good things first System build upon microservices is more stable. If one of the services is down or has some issues you have other services which are unaffected. This can be used for application deployment. You can deploy new versions of microservices practically anytime. Microservice upgrade doesn’t influence other microservices (or just services which are using this one).
Such a pattern also allows better scalability. Microservices which are used more than others can be spread across more nodes. On the other side microservices which aren’t used or used a little can occupy just one or two nodes.
But as always there are disadvantages too. For example error searching is little more complex as you have to investigate several services which could be reason of the error. For this purpose it is a good habit to use some kind of request id which remains the same for all involved services. When you are logging message you should add this identifier to message. You can easily find all relevant logs on all microservices by this way.
Sam had mentioned other tools too. For example:
- Fabric (http://www.fabfile.org) – library and command-line tool for streamlining the use of SSH for application deployment or systems administration tasks
- Dropwizard (https://dropwizard.github.io/dropwizard/) – support for sophisticated configuration, application metrics, logging, operational tools
Posted in programming