How Much API Surface Area Before It Stops Being Micro?

I have most of the core platform that I run API Evangelist on re-engineered as individual microservices, defined on Github, and running using Docker instances. I’m using APIs.json for discovery, navigation, and to connect swagger API definitions, to their docker backends. So far I have 18 microservices, which I define as very simple APIs, that do one thing, and focus on doing it well.

I’m very critical about any feature I add in, working hard to keep each service as micro as I can, reducing complexity, and bloat in any single API. However, with each service I reach the point where I have to cut off feature creep, and establish an entirely new API definition--I am at this point with my link service.

I have a pretty bloated link management system in the legacy version of my platform, something which handles links for functions ranging from Pinboard integration, to handling linkrot on my public website. My legacy system runs using an API too, but it is a sloppily designed API, with a wide surface area, something I’m looking to prevent in the next version.

So far I’ve broken out a single API into three separate microservices:

I have about five other simple, link related, microservices I’m planning, but these three designs represent the main link resources I need to make API Evangelist work. All of the microservices I’m designing will be open sourced at some point, but the linkrot implementation is one I may also be offering as a service. I’m enjoying the feature across my sites, and is something that I think has some viability as a basic service.

I’m sure my own definition of what a microservice is--will evolve, ebb and flow, but for now the first rule of microservice club for me, is keep things doing one thing, and doing it very well—enforcing simplicity in every decision.