Subscribe / Unsubscribe Enewsletters | Login | Register

Pencil Banner

How to succeed with microservices architecture

Eric Knorr | April 1, 2015
Developer empowerment is a key part of the microservices trend, says Nginx's Owen Garrett, who offers lessons learned from real world implementations

You might call this devops in the real world: Part of both the microservices and devops trends is that developers end up shouldering responsibilities that operations once held. But how, I asked, can such basic requirements as the reliable delivery of messages among services be guaranteed in this new model?

I think what you're referring to is the old architecture of strong consistency. Developers now accept eventual consistency ... We don't have to have lots of large transactions, we don't have to have the system blocked while a number of transactions go through and they're all connected before the state is changed. Instead, for each piece of data, various architectures nominate one microservices component to be in charge of that piece of data ... If something is out of sync, it is often decided by a rule developers created. That gives the developer a lot more control.

As Garrett implies, a key best practice in developing a microservices architecture is to begin by breaking down data into different types -- and then build microservices to handle each type. Behind the scenes at, for example, one microservice is responsible for deciding the price for each item in inventory. "That data will sit purely under the control of that one microservice, and it's responsible for pushing updates to other microservices that need that information," says Garrett.

There's no escaping, however, that the end result is a whole bunch of services to manage. Whether dev or ops maintains those services, keeping them all spinning seems like a formidable challenge. Garrett acknowledges this point:

People are still feeling their way to understand the right solutions. The patterns that we see are that microservices are split up to be as independent as possible, so that the relationships between them are minimized and clear. There is a clear contract of how one microservice depends upon another.
We see solutions like circuit breakers deployed. A circuit breaker is something thatAdrian Cockcroft talks about quite a bit: The idea that if an individual microservice fails catastrophically, then the application needs to be able to isolate that component and somehow work around the failure ... If [a microservice that recommends related products] fails, then you might end up with a small blank space on the Web page, but the application as a whole would continue to operate.

With so much written into the application, however, how do you manage the development of so many services at scale? The problem of ensuring developers are "doing it right" across thousands of microservices goes to the heart of a cultural change in application development as a whole:

That brings us to a people problem. You have to be prepared to give up some control. You can't afford to be too restrictive over your development staff. There is a great saying that I believe came from Amazon, the "two-pizza" team. Two pizzas should be enough to feed a development team. With three or four people you can have a small, independent team that can focus on building the service ... Then, if they're given the freedom to implement that as they see fit using the skills and tools they have at hand, the expectation is that they will do it quicker, they will be more satisfied as employees, and you will have a more reliable system as a result.


Previous Page  1  2  3  Next Page 

Sign up for CIO Asia eNewsletters.