BMC Software is gearing up to formally release an instance of its Control-M application workflow orchestration platform in the form of a Docker container.
Gur Steif, president for digital business automation product line for BMC, says that since the company added an application programming interface (API) to Control-M, the automation platform is now being embraced as a framework for integrating microservices at scale. The next logical progression in that DevOps journey is to make Control-M available as a Docker container that will enable IT teams to deploy Control-M on-premises or in a public cloud more easily.
In addition, DevOps teams should be able to deploy Control-M on a more granular level. Rather than having one centralized instance, multiple instances of Control-M might be deployed to optimally orchestrate specific groups for microservices.
Steif says IT organizations are starting to recognize that providing developers with access to self-service portals to access IT services isn’t enough. Developers have made it clear they primarily want to interact with those services via APIs. At the same time, IT organizations are embracing multiple clouds. The challenge IT organizations will face now is providing a consistent set of API-driven services across multiple clouds that soon could consist of thousands of microservices, he says.
It may be a while before IT organizations are able to deploy microservices routinely on any cloud at will. However, many of them are gearing for the inevitable. Microservices based on containers make developers more productive. However, from an IT operations perspective, that adds a lot of management complexity. The BMC Control-M platform addresses that issue by enabling DevOps teams to run jobs as code across the infrastructure on which large numbers of microservices are running.
The rise of containers and microservices is clearly transforming integration. Rather than being dependent on a single centralized platform based on an app server of cloud service, developers are embracing more distributed frameworks that they can invoke as needed without waiting for permission from the IT operations team. IT operations expertise might be tapped to optimize those integrations by the days when IT organizations relied on “centers of excellence” to determine what applications could be integrated with another are coming to an end.
In the meantime, IT organizations should prepare for an unprecedented level of integration. As each microservice gets deployed, the level of dependencies between components of an application service increases. IT organizations will need to not only continuously monitor those integrations to ensure service levels are met, but also make sure each integration is secure. The role the IT operations team plays in governing integrations is likely to be more critical than ever.
Of course, the biggest challenge IT organizations are likely to face has little to do with the underlying technology. As is the case with almost every major shift in IT architecture, it’s the internal IT culture that winds up being the biggest inhibitors of change.