Many enterprises not ready for 'microservices tsunami'

Most IT operations teams today are "ill-prepared for the rise of microservices," which threaten to overwhelm their shops.

That's the word from XebiaLabs' Sunil Mavadia, who recently cautioned that many current-day IT systems may be overwhelmed as microservices are poised to "unleash an application release tsunami."

The good news, he adds, is that there is still time to adapt, as we're only in the early stages of microservices adoption, so there's still time to get ahead of the wave. Still, Mavadia warns, with the accelerating demand for digital capabilities, "the rate at which applications will be released and updated is about to exponentially increase as more and more organizations are moving to embrace microservices architectures." More applications and services are needed, and they need to be constantly updated as well.

As a related XebiaLabs white paper puts it:

"Handling complicated, monolithic applications is replaced by the need to deal with a complex network of distributed, comparatively simple components that have to work together."

The primary vehicle for a microservices architecture is containers, which house code and protocols within a portable environment that can be swapped out as needs and processes change -- which is often. "Rather than updating applications by essentially patching them, a microservices architecture based on containers delivers new functionality by replacing one set of containers with another," Mavadia states. "As the number of applications that access any given set of containers increases, so too will the challenges associated with identifying and managing dependencies between various containers."

He urges greater automation in container release management -- which falls into XebiaLabs' bailiwick, of course. But the increasingly frenzied pace of application or service releases, and the proliferation of containers within microservices architectures, "may very well exacerbate application backlogs," he states. "Developers will simply be cranking out more code at a rate IT operations teams will not have a means of being able to keep pace with." Time to embrace automation and continuous delivery approaches in a big way, he advises.

The XebiaLabs white paper makes the following recommendations:

Adopt tools that manage changing deployment patterns from monolithic to larger sets of individually simpler components. "Workflow tools - which map out what needs to happen in a process step by step - are poorly suited to this challenge because they're designed to string together a complicated set of steps for one large deployment... but they don't handle many small deployments, dependencies between components or concurrent releases," the paper's authors explain. "Your deployment tooling needs to be able to handle multiple related deployments simultaneously. In order to make the most of microservices architectures, you need a single overview of your deployment dependencies and configuration. This allows your microservices deployment tooling to offer the speed and efficiency benefits we've grown accustomed to with continuous delivery pipelines."

Address dependencies between services: "As architectures become more complex and include more components become involved, it becomes impossible for a human to track all the dependencies without automation. If a dependency is missed, the system will fail, and it is difficult to figure out why or track down the source of the issue. You need simple insight into the bigger picture - and the ability to modify or remove individual services - with dependencies taken care of automatically.There will still be plenty of manual tasks to handle as you approach production, so it's very important that your tooling can support manual activities. But automation where appropriate will always reduce error and increase efficiency."

Avoid getting stuck with the wrong implementation technology: "Docker will be a great solution for many situations, but who knows what might be around the corner? You can implement microservices with technologies other than containers. It makes sense to ensure that your tooling and your process work seamlessly regardless of the underlying implementation technologies your teams choose to employ. With the market evolving so quickly, it's wise to keep your implementation options open and flexible until you can settle on a mature solution that works for you."