An easier way to approach microservices is through the notion of miniservices, according to Ross Garrett, technology evangelist at Cloud Elements. A miniservice takes the pragmatic approach to microservices, but enables users to take a simpler integration technique between services without having to learn new integration patterns.

“The purist notion of a microservice follows a very specific model. It should really be an event driven architecture. There is a need to ensure all your services are loosely coupled, and in truth a lot of organizations that think they are doing microservices actually have this inherent coupling between services that is forced upon them simply because of how each of those services communicate with one another,” he said. “A miniservice enables a user to take some of the architecture purist out of the picture and think about what they are really trying to achieve. What business objectives they are trying to meet. Quite often, they will find they want that loose coupling, but what they really need are services that can be managed and scaled independently.”

Traditional integration patterns like HTTP via APIs is the simplest approach because it enables you to build individual services that can be written in different environments and supported on different platforms, but HTTP requires you to know something about other services, and that is counter to the true notion of microservices, Garrett explained.

With the pure notion of microservices, you would have to learn new integration patterns, and rethink the messaging infrastructure of event driven infrastructure that interconnect the services you are building.

“Microservices are an architectural construct that perhaps doesn’t really account for the real world very well,” said Garrett. “Purist believe each service should have no knowledge of the services around it, and the reality is that it is just not practical in many cases. There are no additional business benefits created by that level of decoupling. The business benefit is derived by being able to scale and manage independently.”

Event driven design is complicated and requires people to learn new skills that isn’t always ideal for every organization, Garrett explained, however it is becoming more and more mainstream, he pointed out. For instance, the Open API specification now has support to document event driven components of a web API inside version 3 of their standard.

“There is definitely a shift or a desire at least to think about integration from an event driven perspective, but without having to totally move away from the simplicity that HTTP offers,” said Garrett.