In a simpler world, every CI/CD pipeline would need to support only one deployment platform.
In the real world, multiplatform deployment (which means deploying an application to run on multiple OS platforms) is a must-have for many organizations. We live in an age of diverse operating systems and deploying for only one platform is often not an option.
With that challenge in mind, let’s take a look at best practices for achieving multiplatform deployment in DevOps.
Dealing with Multiplatform
Maybe you’re designing a container-based multiplatform app from scratch. Perhaps you’re thinking of converting a traditional, monolithic, client-server application to microservices with continuous delivery. Or, it may just be time to expand your existing DevOps delivery pipeline to include multiple platforms. The truth is that sooner or later, most DevOps teams will need to understand and deal with multiplatform deployment and how it impacts continuous delivery and continuous integration.
What are the basic problems DevOps teams face in orchestrating automated deployment for multiple platforms? Let’s look at the key issues involved in multiplatform deployment, and the most effective ways to deal with those issues within the context of an automated DevOps continuous delivery chain.
But first, we’ll consider one of the most basic distinctions in multiplatform architecture.
Multiplatform, Single-Tier
In the single-tier model, the same stand-alone application is deployed to multiple platforms. This is, of course, the standard model for releasing traditional desktop applications. The update process for many of those applications, however, has shifted toward frequent, automatic push updates to the point where it now constitutes a form of continuous delivery. This is typically the case for web browsers, for desktop office suites and for more specialized applications. It is also the rule for stand-alone mobile apps.
Multiplatform, Multi-Tier
In multi-tier and multiplatform deployments, different platforms have different roles, and the elements of the program deployed to a platform depend on its role. Typically, this involves some sort of client-server architecture, with the client part of the application installed on mobile and/or desktop devices, and the server functionality deployed in a cloud or hybrid cloud environment, or an on-premises server. At the enterprise level, on-premises hardware is likely to consist of one or more mainframes.
We’ll focus mostly on multi-tier applications; much of what’s covered here should, however, also be relevant to single-tier multiplatform deployments.
Designing for Multiplatform Deployments: Overall Architecture
Fundamental decisions about application architecture will inevitably have a major impact on your deployment strategy. Key members of your DevOps team should ideally be active participants in decisions regarding overall architecture; at the very least, your team needs to be kept up to date on the design process.
This is particularly true when the application has a hybrid backend, with key tasks split between cloud services and on-premises hardware, since the allocation of tasks is likely to shift as the design team develops a better understanding of both the resources required for those tasks and the load-handling ability of each platform.
Example: Cloud Transactions, Mainframe Database
Suppose, for example, that you have a very large and complex database that includes both customer and transaction records. It must be maintained on a mainframe because it includes legacy elements, or for security reasons, because of company policy, or (as is often the case) for all three reasons. Your application is likely to involve a high volume of transactions and other customer traffic, most of which will be stored in the database. In order to shift traffic away from the mainframe, customer interactions will be processed in the cloud, with transaction data initially stored in a cloud database, then transferred to the mainframe database.
- Will the cloud database represent an actual field-for-field subset of the mainframe database, or will data need to be cleaned up and parsed before it’s transferred to the mainframe?
- Will you be porting database code from the mainframe to the cloud, or creating a cloud-native database (i.e., COBOL vs. SQL)?
- Will all user access be through the cloud interface, or will the app switch between the cloud and direct access to the mainframe, depending on the load?
Questions like these are likely to have a major effect, not just on microservice and code-level design, but also on deployment strategies, since they will determine such things as how closely database microservices must be coupled on the two platforms.
Designing for Multiplatform Deployments: Platform-Specific Issues
In order to design a multiplatform application at the end-user and backend microservice levels, and deploy it using automated tools, it is crucial to have a clear and detailed understanding of the resources available on each platform, and of the dependencies they require.
For the frontend, this may mean maintaining separate versions of your app for Android, iOS, Windows, OSX and Linux. For the cloud-based parts of your back end, you may be able to work in a relatively standardized container environment. Even here, however, you will need to be familiar with the resources and requirements of the specific cloud provider.
On mainframes, you will need to have a good working knowledge of the mainframe environment, including the operating system and the available resources. This is a necessity for native mainframe operating systems such as z/OS, and it is still largely true if you intend to use a virtualized OS such as Linux on Z, since it is likely to have significant interaction with the underlying system resources.
Designing for Multiplatform Deployments: Automating the Pipeline
Keeping track of platform-related issues and managing their impact on your continuous delivery pipeline may seem like a formidable task, but it doesn’t have to be that difficult.
The key is to develop an adequate understanding of the platforms involved, to incorporate that understanding into your automated tools and all of the target platforms into your automated delivery chain. This means (for example) automated testing across platforms, dependency checking for each platform, coordinated deployment and integrated monitoring.
A variety of tools, both open source and proprietary, are available for all of these purposes and they can often be integrated into an automated continuous delivery system.
Integrated Tools for Multiplatform Deployment
There are, however, considerable advantages to using a highly integrated suite for fully orchestrated deployment. For example, if you are working with IBM Z, UrbanCode provides you with an integrated suite of DevOps tools that is fully integrated into the z/OS ecosystem. It is an agent-based system that includes tools for design of automation processes, multiplatform deployment, dependency checking, inventory and integrated monitoring; and it is specifically designed to manage multi-tier deployments.
The advantage of working with a highly integrated deployment suite such as UrbanCode is that you do not need to spend time learning what to automate, learning how to automate it or putting together the basic automation infrastructure. You can concentrate on managing the specific automation components and settings your continuous delivery system needs. When you are dealing with a large, complex and business-critical platform such as a mainframe, an automated deployment suite that is highly integrated with that platform, can be an extraordinarily valuable (and time-saving) resource.
Automated multiplatform deployment for DevOps may be challenging, but it’s eminently possible. The tools are there, and you can make it work.
