Don’t Think like an Engineer When Designing Microservices
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.
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.