This blog series explains how to engineer applications for DevOps.
Topics covered in this blog series:
• Factors to decide whether an application is a good candidate for DevOps.
• Practices to engineer designs for DevOps.
• DevOps applied to enterprise apps and software services.
• DevOps applied to COTS systems.
• DevOps applied to manufactured (embedded) systems software.
• Five levels of application maturity.
This blog covers DevOps applied to commercial off-the-shelf (COTS) systems. You can read part one here, part two here and part three here.
DevOps Applied to COTS Systems
I often hear that DevOps does not apply to systems that use commercial off-the-shelf (COTS) software. The idea that DevOps cannot be used with COTS systems is, frankly, a cop-out. Just because someone else designed and developed an application’s source code is not a sufficient reason to avoid engineering a DevOps solution.
Consider the value stream chain of activities from the source vendor through integration and deployment in your environment. There are limitations and constraints to the level of automation allowed, the return on investment in automation and influence over the development life cycle that DevOps practices can introduce when dealing with COTS applications.
COTS applications will typically have predefined and supported interfaces for managing configuration or accessing data. These endpoints may not be accessible or compatible with your existing toolchain or automated change management practices.
Types of COTS Applications
COTS applications typically come in one of three flavors; namely, closed, open and platform, and each should be evaluated differently.
Closed COTS applications allow little to no customization to their functionality and/or interfaces. They typically have predefined management consoles and a published list of commands or APIs that will allow external applications to interact with the COTS applications. A good example of a closed COTS application is Microsoft Exchange.
Key considerations for DevOps with closed COTS applications are as follows:
• Can configurations be scripted and integrated with existing automation and orchestration toolchains?
• Can configuration scripts be managed and maintained in external version control systems?
• How are updates, patches and service packs applied and managed? Can these practices be automated?
• What developer tools (APIs, software development kits [SDKs], etc.) are available to extend and/or interact with the application and/or data?
• Are these tools compatible with existing tools and expertise in the enterprise?
• Can these developer tools be integrated within the existing toolchain?
• How frequently are changes made to the base product?
If these applications can be managed by external systems and code developed to automate deployment and configuration and/or integration can be managed through a version-controlled pipeline, closed COTS applications make good candidates for DevOps and continuous delivery (CD). By applying CD principles, COTS binaries are versioned and stored in an artifact repository; installation and configuration scripts are managed through version control and IaaS workflows and applications and integration endpoints are auto-tested through deployment pipelines.
This is only made possible when consumers of the COTS application collaborate with operators of the COTS platform to ensure that the solution is aligned with enterprise goals, objectives and standards related to portfolio management.
Open COTS applications allow significant modifications to functionality, data and/or interfaces. These platforms typically have rich SDKs, APIs and embedded developer utilities that enable users and developers to modify all layers of the applications; namely presentation, business logic and data. Open COTS applications typically have a large, complex footprint consisting of core services, data and/or GUI customizations, embedded applications, etc. Classic examples of open COTS solutions include ERP/ CRM platforms (like SAP or Oracle) or portal platforms (like SharePoint, ServiceNow or WebSphere).
Key questions to ask when considering whether DevOps can be applied to an open COTS application:
• How are customizations (created through internal design editors, logic builders or data schema extensions) version controlled? Are these configurations stored in a database or code?
• How are customizations created through internal tools and packaged, installed and configured in higher-level environments like staging or production?
• What does the development life cycle for customization created with internal tools look like? What quality gates are required? How about architectural standards?
• How are custom, embedded applications/applets packaged, installed and configured?
• Can these custom applications/applets be run and tested separately from the underlying COTS application?
• What does the development life cycle for customizations created with external tools look like? What quality gates are required? How about architectural standards?
• Does the COTS application provide testing frameworks, mocks and/or stubs for testing external dependencies?
• What automated test suites are supported by the platform (unit, functional, regression, capacity tests, etc.)?
• What is the upgrade path for customizations (historically)? As you can imagine, open COTS applications add layers of complexity.
When considering DevOps and CD with open COTS solutions, it is recommended that you build multiple pipelines to support each layer of the application in the dev or continuous integration (CI) stage of the value stream. Subsequent stages, like staging and production, will use a converged pipeline built from known good artifacts of the dev and CI stages.
Before implementing a solution, it is important to study the development life cycle and practices of the target COTS application before building your toolchain. Understanding how the end-state platform is created and how change is introduced will strongly influence your toolchain and pipeline design.
Platform COTS Applications provide a set of services and tools, as well as proprietary runtimes, that enable users to build and run custom applications on the platform. These are the most difficult type of applications to integrate into existing DevOps practices and CD toolchains because common practices like version control, testing and build are done through the platform rather than using external tools.
Platform COTS are packaged applications that enable customers to build applications on top of the base platform. As a blend of closed and open systems, all the previous considerations are valid. In most cases, the base platform acts as a closed system, whereas the custom-developed applications on top act like open systems.
For this type of application, it is critical to understand what hooks and services are available to support DevOps practices and CD. Many of these platforms are not going to fit within your existing toolchain and may not be able to employ the workflows, dashboards and reporting you have grown accustomed to from your current toolchain.
What This Means
This blog one of a series that explains how to engineer applications to be most suitable for DevOps. This blog series explains how to engineer applications for DevOps including:
• Factors used to decide whether an application is a good candidate for DevOps.
• Practices to engineer designs for DevOps.
• DevOps applied to enterprise apps and software services.
• DevOps applied to COTS systems.
• DevOps applied to manufactured (embedded) systems software.
• Five levels of application maturity.
This blog covered DevOps applied to COTS systems. You can read part one here, part two here and part three here.
For more information regarding how to engineer applications for DevOps refer to my book Engineering DevOps.
