Following the example of companies like Uber and Netflix, many organizations are pushing harder than ever to make...
microservices a reality in their software ecosystem. The promised benefits of increased agility and faster deployment are often too tempting to ignore. However, this rush causes some to approach microservices in a way that may not stay aligned with what are considered to be "proper" practices.
Enter miniservices, a term technology consultants like Ross Garrett use to describe this nonpurist form of a microservice architecture. And according to him, it's not so bad. In fact, it may be just the thing many companies need to realistically achieve at least some part of what microservices can do for an organization's development and deployment capabilities.
In this Q&A, Garrett, head of product marketing at Cloud Elements, explained more about what miniservices are and how software teams should think about the way they are approaching microservices in general.
What's a miniservice?
Ross Garrett: A miniservice, from my perspective, is taking a pragmatic approach to the content of microservices architecture. From a purist perspective, microservices represent a very specific architectural model. And event-driven architecture is a sort of prerequisite to delivering a complete vision there. Whereas miniservices are perhaps just a way to say, 'Well, I'm doing everything I wanted to do from the microservices prospective in terms of agility and scalability and the sort of functional binding around services, but I'm not going to be tied to the prerequisites around event-driven design.'
So, you could argue that HTTP inherently doesn't create the level of decoupling [that is] true to the vision of microservices, where the services should be able to exist totally independently. I think if you have this notion of an HTTP and API connecting together, inherently, you have to know where there is an end-point out there to talk to. That's, again, breaking the purist model. So, while people are taking big steps forward in terms of service composition and reuse and scalability, they're doing so with surrounding technologies like HTTP, which makes their lives easier.
Where do you draw the line between where a microservice approach should be taken versus a miniservice approach?
Garrett: I think it's less about drawing a line. I know for sure a lot of [my customers] would say, 'We're doing microservices.' And, I think, in their view, they are. It's just that if you were to refer back to Martin Fowler's books, he would say you're not … if you're still using HTTP.
But the flip side is that, at least, it allows them to achieve their objectives around individual services and independent scalability. And it's giving them an opportunity, too, to break up that long list in a way that they can easily understand and bite off little bits as they go.
So, again, it's less about drawing a line, but just understanding that you don't have to be a purist in order to achieve some of the goals here. The same could be said, actually, in the world of RasDial APIs. I know that … over the years, high-RasDial interfaces have been widely debated amongst purists here, too. Yet, we've achieved everything really that we've wanted to from the integration perspective without having to sit in the bucket of ticking all the boxes that were set out in terms of that architectural model.
At what point does a company have to consider the scalability aspect if they are still, for instance, using HTTP and question if this approach will still work for them?
Garrett: Scalability is probably one of the big reasons why we've kind of been looking at moving toward a microservices architecture. I think, in that case, it's fair to say HTTP doesn't solve the problem. I'm not sure that there's a firm line in the sand here. [But] just because you've got 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, you will get to a point, I'm sure, where the amount of traffic starts to get in your way.
And then the other angle around HTTP or within web-centric integration that's perhaps useful is the concept of governance. HTTP affords us more capability there simply because with an easier way of seeing where traffic is coming from and flowing to. And these message queues are a little bit more of a black box. We don't really know, or a lot of the products out there in their offering that aren't giving us a clear indication of who subscribed to what and what data have they got, and what data didn't they get. So, I think governance becomes the key concern -- the more services you have, the more that concern is going to arise.
Does it seem to you like microservices are touted as a silver bullet, and that many organizations suffer from unrealistic expectations surrounding microservices?
Garrett: I think this has always been the case. This notion of the silver bullet has existed across many vast practices or reference designs or new technologies. For many organizations, they have to take a more pragmatic approach. 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 retrain an entire organization of engineers or architecture developers. I can get started and enjoy some of the quick wins.
I think we do this time and time again, especially in the integration space. Some vendors are pushing technologies not because … perhaps it's the best solution to the problem, but because it's quite self-serving for them. I think we're always going to be guilty of that in the integration world.
Access our handbook on the integration challenges of microservices
Put your knowledge of microservice architectures to the test with our quiz
Learn everything you need to know about keeping microservices secure