Over the past few years, many developers (especially corporate ones) have turned their focus to so-called “microservices.” In a nutshell, it’s a way to manage services at a far more granular level—rather than build a massive architecture that attempts to serve as all things to all users, developers and sysadmins focus on a plethora of small applications segmented according to domains (i.e., reporting, checkout, directory). APIs become the glue binding these microservices together. In theory, this sort of system is easier to upgrade and manage than its monolithic predecessor. Last year, David Hardwick, CTO of BetterCloud, blogged on Dice Insights how his company’s embrace of microservices improved his release time and limited the impact of code breaks. “We reached this point at my company when we had about 300,000 lines of code and four different technical teams,” he wrote. “Applications built on microservices are much easier to change and maintain.” But transitioning from monolithic to microservices isn’t for the faint of heart. It requires a black belt in project management, from the initial stages (determining whether the moment is right to move) to the actual migration. In this context, automation is the developer’s best friend—as is clearly defining boundaries and responsibilities for every member of the team. Perhaps recognizing the complexities involved in microservices, a consortium of firms (Google, IBM, and… Lyft?) has released Istio, an “open-source project” that aims to provide “a uniform way to connect, secure, manage and monitor microservices.” The initial release, the Istio.io website added, is targeted at the “Kubernetes environment” (i.e., a container service), with support for environments such as Cloud Foundry and virtual machines rolling out “in the coming months.” The rise of Istio and similar services comes down to a hunger for efficient traffic management. When a lot of small applications attempt to carry out tasks and communicate with one another, there’s an accompanying need for airtight security (such as service-to-service authentication) access controls, and lots of routing and failover rules. If microservices are gaining momentum as a trend, then clearly Istio’s sponsors want a say in how companies manage this brave new world. But not all developers are convinced. “The majority of software systems should be built as a single monolithic application,” Martin Fowler, a British software developer and public speaker on software development, once said. “Do pay attention to good modularity within that monolith, but don’t try to separate it into separate services.” If you’re interested in exploring microservices, and whether it’s actually a good time to adopt them, check out Adam Drake’s highly informative blog posting on the matter. He provides a lot of context, and breaks down thorny issues such as dependencies, scalability, and the problems with things like provisioning and monitoring. And as Istio and other platforms come online, project managers will need to decide which tools fit their companies' needs best.