A wise man once said: Don’t believe the hype. “Despite the buzz, 2017 will not be the year that microservices start to take over the world,” said Carson Sweet, CTO and cofounder of CloudPassage. Microservices, he said, often require lots of micromanagement.

Microservices are like cloud-based software nanobots. The small, single-task focused sub-processes communicate inside larger application packages. Microservices are built around service oriented software architecture and help devops teams manage perpetually updated applications. The applets interoperate over networks and are designed to make software flexible and scalable.

It’s easy to understand the appeal of microservices. In many ways, Sweet said, “writing lots of little applications that work together” is the opposite of the monolithic application development processes that most developers detest. Microservice architecture is theoretically faster, more scalable across application components, and easier to maintain. “The idea is that instead of one super-complex set of code that becomes a house of cards, a microservice architecture uses dozens of sub-applications that are individually small and simple. The microservices are truly loosely coupled in that they work together to deliver the same functionality, but they work independently of one another.”

SEE: Internet of Things policy (Tech Pro Research)

In reality, granular software applets add unnecessary complexity that stymies growth, increases overhead, and is at odds with how most contemporary cloud systems operate. This is “because [microservice] applications must be refactored to realize their value,” Sweet said. “It’s easy to get containerization mixed up with microservices,” he said. “But where a traditionally monolithic application can be delivered in a large container model, moving an application from a traditional monolithic architecture to microservices requires complete refactoring. And as many enterprises learned when they tried to build private clouds, just because a new technology is hot doesn’t mean there’s enough engineering talent to go around.”

Microservice systems also demand a skilled employment ecosystem. Market demand and interest in microservices currently exceeds the pool of available, trained workers. “There’s a need for developers, QA engineers, and infrastructure architects who actually understand microservices,” Sweet said. “It’s unlikely there will be enough of these talents to go around for at least several years, and in the short term the large service providers and hot startups will snap [workers] up.”

The microservice concept is appealing because it’s simple, Sweet said. “The hard part is finding talent who knows how to take those big, monolithically coded applications developed 15 years ago and rebuilding them as microservices, because as is the case with many new technologies, the implementation is much more complex than the idea.”

SEE: How risk analytics can help your organization plug security holes (Tech Pro Research)

High overhead costs and a limited talent pool means microservices might exclude SMBs and be limited to large corporations. “Enterprises are the most likely to be able to execute on [a microservice] strategy because it’s new and complex, and still not commoditized,” Sweet said. “In general the only contingent of smaller companies who will be able to execute on microservices will be startups because they don’t have lots of legacy applications to deal with. They can also attract the talent they need with promises of equity, fortune, and glory.”

Sweet anticipates years of refinement and learning before the talent pool meets industry demand. “But be careful,” he warned. “It doesn’t take a prediction to know there’ll be five unqualified people claiming to be microservices engineers for every real one.”

Read more