I have been talking about the concept of "miniservices" for some time, and often get asked what miniservices are, and how software teams should think about the ways they are approaching Microservices architecture in general.
A miniservice is taking the pragmatic approach to the concept of microservices architecture. Microservices represent a very specific architectural model, where Martin Fowler and others have clearly described how this architectural model should work and how each service should exist and communicate with those around it. Miniservices are just like microservices in regards to the agility, scalability, functionality, and binding around services without being held to the prerequisites around event-driven design a purist Microservices Architecture would prescribe.
It’s arguable that HTTP inherently doesn't create the level decoupling true to the vision of microservices, where the services should be able to exist completely independently. A RESTful approach by virtue requires your service code to the API of those it needs to interact with - creating coupling.
When choosing your approach, let’s first establish an understanding that you do not always have to follow the purist mircoservices requirements to achieve the same goals. Everything can still be achieved from the integration perspective without following microservice architectural model requirements.
Scalability is a big reason to take the microservices architecture approach. HTTP doesn't solve the problem, but just because you have a hundred services or a thousand services doesn't necessarily mean that HTTP is the wrong choice. It may be just as functional as any other integration technology. But there will be a point where the amount of traffic will make things inconvenient.
"I consider this miniservices thing to be pragmatic microservices, where I'm leveraging the pieces of that practice that makes sense for me, while still getting most of the functional benefits." -- Ross Garrett, VP of Marketing
Another angle around HTTP or within web-centric integration that is useful is the concept of governance. HTTP gives more capability with an easier way of seeing where traffic is coming from and flowing to.
Does it seem to you like microservices are touted as a silver bullet, and that many organizations suffer from unrealistic expectations surrounding microservices?
That's why I consider this miniservices thing to be pragmatic microservices, where I'm leveraging the pieces of that practice that makes sense for me and getting most of the functionality benefits. But I don't have to throw everything away and start again. I don't have to re-train an entire organization of engineers, or architects, or developers. I can get started and enjoy some of the quick wins.
In the integration space, some vendors are pushing technologies not because it's the best solution to the problem, but because it's more self-serving for them.
How are you building Microservices? Get in touch!