BT
x Share your thoughts on trends and content!

Anti-Patterns Working with Microservices

by on Mar 15, 2016 | NOTICE: The next QCon is in London, March 6-10, 2017. Join us!

The main problem with monolithic applications is that they are hard to scale, in terms of the application, but more importantly, in terms of the team. The main reason for a switch to microservices should be about teams, Tammer Saleh claimed at the recent QCon London conference when describing common microservices anti-patterns and solutions he has encountered.

With a small application and a small team there is no problem with a monolithic application, but as the application grows and with dozens, or more, of developers they can’t all work on the same code base. Moving to microservices enables us to make use of Conway’s law in our own favour.

Saleh claims that building with microservices is incredibly complex with a lot of ways that it can go wrong. The most common mistake for him is to just start with microservices. He emphasizes that for all systems you should start as simple as possible and slowly migrate to more complex solutions only when there is need, from a team or business perspective. He notes that the most important thing for a company is to get to the market and make money, not to explore interesting architectural patterns. His solution is instead to start monolithic and extract when necessary, and notes that microservices add a constant tax to development.

With spikes in traffic enough servers must be maintained to handle the peak loads, but with increased traffic and more servers eventually the database will be overloaded instead. One solution to this is to even out the load using queues, basically the queue is a buffer that smooth the traffic out. This makes the communication asynchronous with an increase in complexity since the request-response lifecycle is broken and clients are forced to deal with asynchronous responses. For Saleh this a necessary step though to avoid spending too much money on computing resources.

Services trying to connect to one specific service which is not responding is from an operational perspective a problem. It’s hard to do diagnostics and work on the service that is down because of all the requests coming in. With tens or hundreds of other services sending requests this can cause all sorts of problem. A solution is a Circuit breaker which prevents requests reaching the service that is down. When working normally the circuit breaker allows all traffic go through but as soon as it discovers a failure it will prevent further access until the failing service is responding again, at which time the traffic is allowed to pass the circuit breaker again.

With microservices comes a whole new set of testing patterns. One common pattern is mocking the services a service under test is consuming. A team testing a specific service will then instead of communicating with the consuming services write mocks for these services. In the end this means that each team will write their own mocks for all services they consume. This may create a lot of extra work and in Saleh’s experience a common solution is to let each team write a common mock for each service they are responsible for, resulting in one mock for each service. An improvement to this that he suggests is that each team writes language specific clients to be used by the consuming services. This client then handles the actual communication with the service and may also include a mock. One advantage Saleh sees in this is that a service has full control over the protocol used and may change it as needed. He also believes this to be a nicer interface.

In a blog post from 2015 Stefan Tilkov argued against always starting with a monolith, instead arguing that for a large enough system we should think about individual subsystems from the beginning.

In a presentation earlier this year Ben Christensen talked about the risk of using a client library, written by the service team, which is the only official way to access a service.

Saleh’s presentation is already available for QCon attendees, and will later on be available for readers of InfoQ.

Rate this Article

Relevance
Style

Hello stranger!

You need to Register an InfoQ account or or login to post comments. But there's so much more behind being registered.

Get the most out of the InfoQ experience.

Tell us what you think

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

The tao of Microservices by Roland Heimdahl

I would love to see the author of "The tao of microservices" to comment this article. Since he argues that you really should aviod the monolith and start with the microservices at the very beginning of the project.

Re: The tao of Microservices by Adrian Ivan

I watched that author's talk at microxchange and I found some of his opinions very unrealistic in larger systems. Everything seemed to be very ad-hoc from his perspective, "just define the messages" and everything will work. And of course, he is re-inventing the wheel in NodeJS, which may be good for variety.

I agree that starting with a monolith properly modularized is the way to start, unless you have a bunch of Architects, Consultants and legions of developers to develop the microservices framework from the start.
You can even leverage a MessageBus inside a monolith in order to ensure modularity and decoupling.

Service teams publishing client libraries is a bad idea by Vishal Naik

"An improvement to this that he suggests is that each team writes language specific clients to be used by the consuming services." -- This is exactly the anti-pattern that is talked about here www.microservices.com/ben-christensen-do-not-bu...

Using client libraries to talk to services defeats the isolation provided by microservices, increases coupling, and introduces strict version dependencies. Instead, rely on contract testing to detect incompatibilities.

Re: The tao of Microservices by Amel Music

I totally agree with you. Properly modularized rest API based "monolith" that is easily decoupled is easiest way to go.

Now I see examples of simple two endpoints like Account and AccountType are microservices where AccountType is simple codetable.

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

4 Discuss
General Feedback
Bugs
Advertising
Editorial
Marketing
InfoQ.com and all content copyright © 2006-2016 C4Media Inc. InfoQ.com hosted at Contegix, the best ISP we've ever worked with.
Privacy policy
BT

We notice you're using an ad blocker

We understand why you use ad blockers. However to keep InfoQ free we need your support. InfoQ will not provide your data to third parties without individual opt-in consent. We only work with advertisers relevant to our readers. Please consider whitelisting us.