In applications built from cooperating components or where applications move among themselves in organized business-directed...
flows, it's critical that all the pieces actually work together. Development managers and architects, who pay a lot of attention to this kind of coordination in their own development, often fail to consider the foundation of their components -- the operating system and middleware -- and compromise their application environment as a result. Coordinating OS and middleware platforms means taking a 3D view of platform management, carefully aligning management practices with cloud integration goals, and picking the tools that best address your specific approach.
One of the complications in managing OS and middleware tools in the cloud is the multiple dimensions of the challenge. The first dimension is the exercise of "normal" management practices on cloud-resident platform components. That's largely a matter of building current tools into machine images and addressing them. The second dimension is "vertical" -- application-to-OS -- version control in building systems of components and services, and the third is "horizontal" integration of interfaces and workflows that depend on OS and middleware platforms. It's these latter two dimensions that pose the real management challenge.
To accompany these dimensions of management challenge, we have dimensions of possible management practices -- three, again. One is to apply management techniques at the development level, building applications and selecting OS and middleware components for ease of cloud management. Another is applying management at the time machine images are built for deployment and the package of applications, OS and middleware are created. Last is applying management in real time to deployed systems of components, including their OS and middleware platforms.
There are also layers of change involved. In most cloud deployments, operations personnel will still have access to the same management interfaces as they'd have used in the data center and will still be able to use the same tools. The challenge lies in multiplicity -- there are just too many different systems and platforms running for normal practices to manage. The trend in the industry is to support middleware management aggregation tools that will provide a centralized view of middleware and OS status and performance. With these middleware tools, pay particular attention to how cloud-aware they are -- many might not support correlation of performance issues vertically between application components and managed platform tools.
Overcoming vertical and horizontal integration roadblocks
Vertical integration is a particular challenge in VM-based clouds because each machine image carries its own OS and middleware; thus, it's easy to accidentally get out of sync across machine images, particularly during periods of application change. Many users will apply limited localized mechanisms for version control even after moving to the cloud, when distributed version control is essential. Every machine image has to be coordinated in terms of the compatibility of its platform elements and its application elements. This should be tested as a routine part of application lifecycle management (ALM).
Vertical integration can be simplified by setting a standard for platform elements across all components and staging the middleware and OS version selected to a common library for integration. This will insure that everything runs the same version of the platform, as long as all component machine images are rebuilt each time the platform changes. That often seems like a lot of work, but it is very difficult to resolve the details of middleware dependencies to the point where you can risk having different versions running on different machine images.
Horizontal integration can multiply these integration challenges because so many component communications and workflow interfaces are supported through OS and middleware platforms. Here, best practices are not only to apply the version-control techniques associated with vertical integration, but also to use centralized cloud platform management tools to verify installed versions in real time. The latter is particularly important if multiple companies or independent development groups are deploying components that could be connected.
Your integration goals are overall drivers of cloud platform management practices and tools. These goals are often set based on whether your applications are developed in-house or deployed from purchased packages and whether your cloud components are based on a common middleware platform -- Java, for example -- or whether you have multiple platforms in place. In-house-developed applications can rely more on development-and-ALM-level version and integration controls, where applications containing significant outside elements will change as these elements are updated, so you'll either have to expand your ALM scope to include them or rely more on real-time version management.
The specific way in which components are addressed may also be important. Tightly coupled workflow systems using service/message busses and SOA interfaces require more management attention at all levels because the coupling creates massive dependencies. Microservices and RESTful flows will require less management, but they encourage the creation of dynamic applications whose runtime state is harder to determine.
Businesses with a major commitment to the cloud -- hybrid clouds in particular -- are finding a suite of management tools from a single vendor -- BMC, IBM, Microsoft, Oracle -- easier to adopt and use. This is because these suites have an intrinsic platform management strategy that unifies a cloud user's own practices.
The biggest risk in a suite-based approach is not loss of "best-of-breed" capabilities for each aspect of platform management, but, rather, the selection of a suite whose features are aimed at a specific platform. Java is an example; it may dominate cloud use today but will that always be the case? If not, you have to plan to adapt or change your tools if your middleware and OS change.
If there's a single rule that can simplify middleware and OS management in the cloud, that rule is to think of your application platform as part of your application. Nobody would make version changes to application components without considering the performance or stability impact and testing extensively to uncover problems. Don't do that with OS and middleware tools either.
Four questions for cloud integration vendors
Integrating SAP with middleware tools
Addressing security issues caused by middleware tools
Try hitching apps to the cloud for legacy modernization