What DevOps Teams Need in an Integration Platform, Part 1: Customization

This is a 3-part series exploring what DevOps teams need in an integration platform. Download the eBook, Not All Integration Platforms Are Built the Same, to learn more.

In my previous post, Digital Transformation and Why Integration Platforms Are on the Rise, I detailed why integration platforms have become a necessity for modernizing organizations and DevOps teams. The emergence of cloud computing and APIs have fundamentally changed the way we release and manage infrastructure. APIs are now the building blocks that we piece together to make finished applications that run on componentized software.

While this means faster innovation and delivery of software, it's also created an explosion of APIs and SaaS tools. Teams are looking for manageable ways to tie their stack together, but it's not as easy as it may seem. The integration platforms of the past decades are no longer keeping up with the modern way of working. DevOps teams need a new approach to handle the diversity of APIs, customization requirements, and the specific needs of developers writing code.

In this post, we'll focus on what customization looks like in integration platforms and what requirements DevOps teams have.

Every organization and team has unique tools, processes, and datasets. The ease and depth of customization is directly proportional to how productive teams can be. While most organizations have skilled engineers that can customize any system, it’s important to evaluate the resource cost of using them for even simple customizations. Often, operations teams are made up of non-engineers who are technical but less inclined to write code. The best platforms will ensure that everyone across engineering and operations teams can customize a platform for their needs.

No-code, low-code, or code#

Integration platforms take varied approaches to customization, whether it’s no-code, low-code, or code (i.e. a developer platform). Any integration platform will require some level of customization so it’s important that organizations take time to evaluate what level of customization they’ll need.

No-code customization#

• Pros: No-code enables non-technical people to customize software without writing a line of code. These tools usually have a user-friendly interface and drag-and-drop capabilities, allowing users to envision the implementation process and describe the overall logic with ease.
• Cons: While no-code platforms are great for non-technical users and allow more people to participate, there are likely limitations to the depth of customization.

Low-code customization#

• Pros: Low-code has similar elements to no-code in that it often uses drag-and-drop capabilities with a user-friendly interface. But it differs in that it still requires a technical user to customize it. Typically, users must set up process control blocks using data tables to identify the process state, numbers, counter, memory limit, etc.
• Cons: While low-code may seem like a good middle ground between code and no-code, it still presents challenges. It won’t provide the deep customization abilities that code gives while also excluding non-technical team members from customizing.

Code (developer platform)#

• Pros: Most organizations will have specific requirements that aren’t met with off-the-shelf platforms. A developer platform provides the extensibility that organizations need to customize integrations and workflows. Using common languages like Java, Go, PowerShell, C#, SQL, Python, or JavaScript, developers can modify or add to existing features and elements so that the platform is tailored for their requirements.
• Cons: A developer platform enables deep customization but often requires either dedicated staff or the need for people with specialized skills in the tooling. Whether it’s work done internally or outsourced, it can consume resources quickly.

The sweet spot: no-code customization plus a developer platform#

Ultimately, each of these options has its strengths and weaknesses. The best solution will combine both a developer platform that is code-based with a no-code interface that can be used by people of any skill level. This not only enables non-technical people to participate but also reduces the time engineers need to spend on coding for smaller customizations and workflow automation.

Versioning#

Change is a constant in DevOps — integrations and workflows are no exception. As processes and tooling change, integration platforms should handle versioning seamlessly. Making updates without versioning can lead to broken automation and a poor user experience. Without knowledge of the changes that have been made, a user could have no understanding of why something no longer works or functions differently.

Versioning handled “as code” ensures that changes are recorded and visible to everyone using the platform. It also ensures that updates can be made to integrations and workflows without impacting the current version being used. If something is updated, the old version won’t disappear or become unusable. Multiple versions of a workflow can exist, and making updates and changes won’t break the version people are currently using. Users can choose what version they want to use, meaning that updates can be made without affecting the whole system.

Data parsers for data mapping and transformation#

Integration platforms can handle large amounts of data, but how this data is handled and presented to the human operator makes a significant difference. Integration platforms need to consume tons of streamed data that is usually exposed in the form of webhooks. To handle this data and execute DevOps processes well, platforms should provide a lightweight way to transform that data. Additionally, platforms should make that data available as context at the right time for operational tasks, whether that is debugging an incident or planning deployments to minimize change risk.

Ease and depth of customization is the key#

It is clear that the explosion of SaaS tools and APIs is not slowing down. Integration platforms will be essential to managing this complexity and enabling agility, actionability, and scalability across the modern stack. However, not all integration platforms are built the same, and many are not equipped to support the needs of DevOps teams.

Many solutions today offer low-code customization, which doesn't offer the deeper customization of code-based or the ease of use of no-code. Other solutions that do offer developer platforms often require people trained in that particular tool to handle the complexity of the code, and can even have their own proprietary language. Furthermore, many solutions have what we call "customization cliffs" whereby the more code you add, the more difficult it will be to change. This is a game stop for agile DevOps teams.

To meet the evolving needs of DevOps teams, integration platforms need to keep up with the continuous change of infrastructure, tooling, and APIs. Engineers must be given the power to customize extensively without hitting customization cliffs, while non-engineers require a no-code user interface to be productive and add value. Integration platforms must easily integrate with new and custom APIs and make it easy to create new connectors.

DevOps process orchestration platforms like Transposit offer this mix of elements that enables the flexible and powerful customization that DevOps teams needs. Combining both a no-code runbook builder and a developer platform for deeper customization, anyone across development and operations can automate processes, reduce toil, and get work done faster.

Transposit also offers versioning of integrations and workflows, handled as code, so all changes are recorded and visible to users. Lastly, Transposit offers data parsers that seamlessly transform large amounts of data into human-readable and usable data so that the information teams need is available as context in real-time.

Mixed together, Transposit offers both the depth and ease of customization that DevOps teams need to stay agile and deliver value at speed.