BT
x Share your thoughts on trends and content!

Don’t Think like an Engineer When Designing Microservices

by Jan Stenberg on Feb 29, 2016 |

When designing microservices and their APIs, you need to think like a designer focusing on the users, Nic Benders claimed in his presentation at the recent Microservices Practitioner Summit. Design the API first, then build your services with an outside-in approach.

Benders is chief architect at New Relic, a company that started off with a single application, a monolith. As the customer base grew, the feature set and, most importantly, the services grew. With this growth, problems started to appear more and more frequently. After years of thinking on how to overcome these problems they decided to move from a monolithic to a microservices architecture.

During this move towards a new architecture Benders believes the biggest mistake they made was thinking as engineers. Building services inside-out, starting with the data layer, then moving outwards from the data layer through business logic means the design of the API is made last. That will favour an API making sense for the business logic instead of fulfilling the needs of the users. With a lot of decisions taken during the design, some of them may also put constraints on the API and hamper adaption to users' needs. Instead Benders believes they should have thought like designers.

When designing a system, you need to think like a designer

With such approach you start the design of a new product with the problem a user is trying to solve, how the new product will solve it and finally you test the assumptions with real users. User have very concrete tasks which may not be related to the model within a service which makes it important to design the API first using an outside-in design, with the API defined it’s up to the developers to implement a service supporting the API. Benders compares this to Test-Driven Development (TDD) where tests are written first driving the implementation.

Often when designing an API Bender starts by writing down some pseudocode simulating programming against the API. If the API feels awkward, he can then change the arguments or the methods available. Another way he has found useful is writing the documentation first, simplifying a discussion with those who will actually use the API.

Benders also notes that the design of a system changes the way people uses it, a system that simplifies creating services will encourage users to build services, a system that makes it easy to report logs centrally will get logs centrally. Design decisions is not only about solving existing problems, it's also a way to steer the long term usage by making some tasks easy, and others harder to accomplish. By changing the design, you can encourage users to follow a particular pattern of behaviour without mandating it.

Recently Anders Jensen-Waud wrote about Thinking Outside-In: How APIs Fulfil the Original Promise of Service-Oriented Architecture.

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

Interesting by William Smith

Found this an interesting view point but I’m not sure I agree with it, at least, not entirely. Building distributed systems is still hard, so surely some engineering discipline is very much required.

I also find it odd that so many engineers can’t design an API - that seems to me to be a pretty important skill.

So to me the argument of thunking about the consumers of your services is entirely valid, but I just think that be an engineering discipline anyway.

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

1 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.