How enterprise developers are moving from fragmented tools to unified platforms [Q&A]
Across large organizations, developers and DevOps teams rely on an ever-growing collection of specialized tools. But while these offer valuable flexibility, they can also create significant pain points.
We spoke to Chintana Wilamuna, VP of solutions architecture at WSO2, about how the landscape is changing from fragmented, purpose-built development tools toward comprehensive, unified platforms.
BN: How does the proliferation of specialized, single-purpose tools negatively impact an organization's security, compliance, and operational efficiency?
CW: Security is increasingly becoming challenging because each of these single purpose tools provide a potential entry point for malicious actors. When it comes to cloud native tools, it's impossible to keep track of security standards and correct configuration. Cloud Security Posture Management (CSPM) tools are approaching a $10B market cap in 2028 driven by this chaos.
All of these tools have their own ways of processing, storing and transmitting data. Most time, it's opaque or needs integrations with robust observability solutions to get a holistic view of how sensitive data is being handled. It's also hard to consistently apply governance policies across these systems.
BN: What are the primary business drivers pushing the move from a fragmented toolchain to a unified platform?
CW: Taking control of the budget and trying to reduce TCO of licenses, subscriptions, time and effort of internal teams. Apart from obvious budgetary concerns, there's a lot of integrations or glue code that's required to develop and maintain across updates and versions. Over time, this adds a huge strain on platform engineering teams and ultimately leads to older versions with unpatched security vulnerabilities. It's easy for vendors and open source projects to release new versions. However, it's very hard and time consuming for enterprises to move to these versions because you need to plan, upgrade and make sure existing functionality works with all the other systems they're using.
The second biggest driver is security and minimizing risks. A unified platform centralizes most of the security controls and allows enforcing consistent security policies across all enterprise services, APIs, events and integrations. Unified identity and access management prevents siloed, non-standard authentication processes and makes user provisioning seamless.
BN: What specific features, like self-service portals and standardized environments, are most effective in improving the developer experience?
CW: Standardized environments are a big one. Using a unified platform, platform engineering teams can provision environments with one click. An environment that captures the same configuration that's in production or staging without having to go through an error prone playbook. This gives developers a consistent environment to deploy and test their apps.
A service catalog is important for developers to discover and reuse existing enterprise services like databases, caching services, existing APIs and connections to LLMs. For enterprise wide services, platform engineering teams or administrators can provision these connections once and allow developers to reuse them without having to share passwords and API keys which is a massive win.
Automatically running unit, integration and security tests on every commit is also a powerful feature for providing immediate feedback and catching bugs early.
An integrated observability stack provides developers self-service access to logs, metrics and traces for services and apps they own. This allows them to quickly debug issues without having to talk to another team.
BN: Does moving to a unified platform change the roles and responsibilities of different teams (e.g., development, operations, security) and how can businesses ensure a smooth transition?
CW: Yes, this is a great question.
Development teams are used for just writing code and letting another team worry about deployment and maintenance. This approach makes developers own and run the apps they develop. The platform gives them the necessary tools to build, test, run, debug and govern their apps.
Operations teams are used to manually provisioning servers and other resources based on tickets raised by other teams. The unified platform approach raises the abstraction level they dealt with. Now they're responsible for building and maintaining the platform developers use. Their role is more towards designing, maintaining organization wide network and governance policies. However, they still have the flexibility to provide pipeline, environment and other project or use-case specific modifications. It's the exception, not the norm.
For a smooth transition, it's important to understand that it's a shift in mindset as well along with new technology adoption.
BN: Are there risks in becoming dependent on a single vendor's platform and how can they be addressed?
CW: Absolutely! It's all too common where once you're in a vendor's ecosystem, they change policies, processes, and prices and consumers and enterprises have to accept these changes. We all know the promise of the cloud. In reality, if you're married to one cloud provider or pretty much any SaaS service, it's extremely difficult and expensive to switch. Every IT leader should consider if a vendor supports or builds their products or platform on open standards. Better yet, there's an open source version of a SaaS service available from the same vendor. That offers ultimate freedom from vendor lock-in.
It's equally important to understand the runtime architecture to make sure there's no single point of failure. If there's a downtime from the vendor does that mean your critical business services will be unavailable as well? The runtime architecture should support redundancy between multiple cloud providers as well to mitigate possible loss of service.
Image credit: everythingposs/depositphotos.com