Cloud Zone is brought to you in partnership with:

Mitch Pronschinske is the Lead Research Analyst at DZone. Researching and compiling content for DZone's research guides is his primary job. He likes to make his own ringtones, watches cartoons/anime, enjoys card and board games, and plays the accordion. Mitch is a DZone Zone Leader and has posted 2576 posts at DZone. You can read more from them at their website. View Full User Profile

How CloudBees Uses the Emerging Pattern of Microservices

10.16.2013
| 9493 views |
  • submit to reddit

What are microservices?  They're like little modular pieces of an application that can all be built, maintained, and deployed separately so that if one goes down, it doesn't bring down the whole app.  A few features or sometimes or sometimes one feature of an app are all the constitute a microservice.  Think of it like a single-purpose unix app.

This is an emerging pattern on cloud platforms given the occasional volatility of the shared infrastructure.  Netflix uses microservices and has separate development teams for each one.  CloudBees is a PaaS provider that has also embraced this pattern.  Michael Neale recently gave a presentation about this (see slides below).  Latency was the main concern with these services, and Neale addressed these questions saying:

"the assumption was that you would end up with a chain of remote (http?) calls with accumulated latency - but in practice the services fall out so that there aren't too many "chains" like this (so far)."


Comments

Martin Vaněk replied on Wed, 2013/10/16 - 6:24am

While I generaly agree with breaking monolits, article does not mention some important drawbacks that needs to be considered before jumping in.

I will completely ignore FP aspect since comparing to architectural changes it is quite insignificant.

For example, slide 18 is dagerously simplified. There should many many arrows connecting those haystacks creating oriented graph of dependencies (even transitional) of them. Debugging at the beginning is actualy harder, because you have to figure out failing haystack first and only then you can benefit from smaller heap to look in. If this haystack belongs to another team, you can do nothing but wait while your log is flooded by errors.

Changes into APIs are harder to introduce, because you've lost benefit of "single compile check" and all your service clients are now remote and needs to be upgraded in same time, otherwise will became broken after you deploy your new version of service.

Other thing is performance. You will probably have little control about clients of some service and you cannot foretell amount of request you service will handle in future. One day they might frequently overload and bring the service down. Usually it is caused by one or few (often badly designed) clients and your service have to be able to identify them - proper monitoring must be part of service from the beginning.

Again this caveats might be less significant comparing to benefits that microservices will give you, but be aware of rocketing organizational and operating costs.

Mitch Pronschinske replied on Wed, 2013/10/16 - 7:19am in response to: Martin Vaněk

Good points, Martin.  It's good that you shared some risks that need to be highlighted in this article as well.

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.