From fragmented tools to unified platforms

Most enterprise software development teams today work with individual pieces of software. These open-source and proprietary tools promise the flexibility and simplicity of purpose built tools. While powerful individually, a large number of these tools often lead to suboptimal developer and operational experiences. This is where “batteries-included” tools, frameworks, and platforms provide a significantly rich and seamless workflow, improving the pace of software implementation and delivery.

🛠️ Software Development: Flexibility of purpose built tools

Consider a Java project in an enterprise. Its development involves several tools that every developer must handle. We need to choose a build system, either Maven or Gradle. Once the build system is in place, for most software architecture decisions, we must select a library or framework best suited for the use case. These choices, though seemingly obvious, can lead to more complexity later. However, having a choice offers a great deal of flexibility.

If we’re developing microservices, we’ll need to select from options like SpringBoot, Quarkus, Micronaut, or Vert.X. If we want to use GraphQL, need to rely on the support provided by the chosen microservices framework. If features are missing, we might have to integrate another library. For an individual developer working on a smaller startup, these choices are easy, and we have complete freedom. For larger teams, these choices are constrained by security, compliance, and other governance policies. Typically, architecture or security teams may need to whitelist certain libraries for development teams to use.

Then there are modern software development concerns like how to integrate LLMs and agents into the same workflow to improve the software experience.

⚠️ Problem with purpose built dev tools

While we can make all of this work, and you’re probably doing so now, used to the complexity, there are a number of issues.

1. A large amount of “glue code” is needed to wire these systems together
2. It’s very difficult for a new team member to become productive immediately
3. Complexity accumulates over time as the software and systems acquire more functionality

🧰 Software Development: A batteries included platform

Let’s look at what a batteries-included platform looks like and how it improves the quality of life compared to the existing software development landscape we’re used to:

1. Integrated build system: Don’t have to think about or use external tools
2. No external libraries or frameworks for microservices development: Core functionalities are built-in
3. Native support for GraphQL, gRPC and others
4. Native support for fast event streaming without having to use external libraries or frameworks
5. In-built library and dependency versioning support
6. Native support for integrating LLMs and agents into the existing workflow

This is a small set of things enterprise software developers have to deal with.

These problems are precisely what the Ballerina Platform addresses. Ballerina is a programming language and a set of low-code tools designed to improve current software development practices. Learn more about how Ballerina supports incorporating AI into existing applications here.

⚙️ Devops and platform engineering: Flexibility of purpose built tools

While there are varying degrees of complexity in the platform tooling space, I believe the following are fundamental:

1. Infrastructure management: building and managing containers and container orchestrators like Kubernetes. A lot of vendors provide rich toolsets built on top of Kubernetes management and bundle this into packages. Rancher and OpenShift are good examples
2. Infrastructure as code: Automating infrastructure creation is essential when we have to expand the deployment to multiple data centers, cloud providers and support high availability. Terraform is widely used for this purpose.
3. CI/CD pipelines: Taking an existing code repository and building it, running unit/integration tests, security scans, and deploying these into environments. Jenkins is a very popular open source tool used by many for this purpose. There are a lot open source projects with specialized functionality providing CI/CD
4. Observability and monitoring: Logging and log management, tracing and performance monitoring all fall into this category. Prometheus, Grafana and Elastic Stack and a lot of other specialized open source monitoring and observability tools exist with varying degree of features

Although there are many more topics we can add, above I feel is fundamental to any organization that deals with software delivery. Again, all of these purpose built tools provide a lot of functionality but we still need a lot of scripts and glue code to piece everything together and provide a “platform” for the developers.

🧨 Problem with purpose built devops tools

Purpose built tools provide great flexibility and choice when it comes to creating a platform. However there are many problems that come with these.

1. Maintaining custom scripts and “glue code” becomes an issue at scale. For a team of a handful of engineers, sure, it’s easy to comprehend the entire system with a few scripts. As teams get bigger, infrastructure requirements expand, this becomes problematic. We need testing and verification in place to make sure the team accidentally doesn’t make a mistake.
2. No one wants to make radical changes to a complex system. When adopting new tools, everyone consciously doesn’t want to make radical changes because we don’t know what might break as a result. So we incrementally keep on adding tools, scripts and systems that solve very specific point problems. While this maximizes the local optimum this negatively impacts the global optimum. This is a major reason why radical change is hard in large organizations.

🚀 Delivery and operations: A batteries include platform

A batteries-included delivery platform should provide all the major components we discussed earlier.

1. Infrastructure management: Usually modern devops experience is that this part should be completely automated. Creating a container and K8s artifacts for a given app is a well defined problem. Automating this is easy
2. Infrastructure as code: A lot of the platforms, specially delivered as SaaS, masks the infra complexity away from the platform engineers. They make life easy by not having to write automation scripts at all. The environment abstraction is there where we can either clone or create environments from standard template
3. CI/CD: A SaaS service, in particular, simplifies the CI/CD aspect easy by allowing us to plug in a source repository and provide a simple interface for managing the pipeline and deploying code into environments
4. Integrated monitoring, tracing and logging: This is provided without having to write a lot of glue code and integrate multiple projects together

All of these fundamental things are addressed by Choreo, an internal developer platform. Choreo aims to simplify platform engineering and delivery operations by providing a simplified workflow that integrates best of breed open source projects in a simplified package.

For setting up an internal developer platform on-premises or cloud provider account, look at OpenChoreo, a complete open source internal developer platform.

While many projects offer a delivery platform through SaaS, one crucial component is often missing from many of them. This is what makes Choreo stand out: a complete software engineering framework.

🚧 Software engineering problems

Having automated the delivery operations gives us improved velocity when delivering a platform. This is true regardless of the vendor we decide to go with. However, when the software gets more complex and evolves with more functionality, another set of problems starts to emerge.

Problems we have to deal with scale,

1. Grouping Microservices: With many different microservices, how do we group them effectively?
2. Enforcing Consistency between Development and Deployment: There are various methods and processes to group services and treat them as a unit during development. How do we enforce the same grouping at deployment time? During development, we typically have a good idea of the application’s composition (front-end, backend APIs, other microservices). While Kubernetes namespaces can be used for grouping, we need to build tooling around this to make it seamless
3. API-First Development and APIOps: How do we enforce API-first development and APIOps within an existing workflow?

Choreo solves this problem by implementing cell-based architecture and brings in gitops based approach for APIOps.

🧠 Choreo’s unique software engineering framework

The software engineering framework sits on top of the delivery framework reducing barriers as the code and architecture evolves over time. A major problem with just delivery frameworks is adopting to changes and software growth over time. They tend to be simple when things are simple and impossible to suit to complexity of software and team growth.

🧳 Treat a project as a single unit

At development time, we have the option to create a monorepo. A monorepo approach stores all related applications, services, and libraries within a single, centralized source repository. Each of the related services or libraries can be implemented using different technologies, and Choreo supports polyglot development of projects.

This approach guarantees that a project modeled at development time can be deployed the same way at runtime.

🔗 Wiring up related apps, services and APIs

One crucial point here is that when there are related components interacting with each other, a dynamic URL or an environment variable have to be used. At deployment time, the environment variables should be injected into the runtime so the apps work as expected.

Choreo’s solution to this problem is called Connections. Connections literally means a connection between 2 things. Once a connection is made,

1. Choreo will handle authentication, if they’re secured with OAuth and inject consumer key/secret info
2. Automatically inject the correct URL based on the environment
3. A mapping can be created to map the Choreo generated environment variables to the environment variables used inside the app. The code can stay as is without any modification when it’s brought into Choreo

🧬 The cell boundary (or the project boundary)

Another unique characteristic of Choreo is that, a project automatically maps into a “cell” in the cell-based reference architecture. This does a few things at the infrastructure level,

1. A namespace for the apps, services and APIs
2. Micro segmentation at the infrastructure level to keep things completely isolated
3. Automatic traffic encryption within services using Wireguard
4. Apps, services and APIs are automatically deployed on service mesh

The platform engineers can then define ingress/egress policies to map incoming and outgoing traffic to trusted endpoints.

🔒 RBAC and Policy management

Role based access to projects provide a seamless way for teams to own project and platform teams to enforce and govern developer access to systems. Platform teams can provision dependent services like databases, LLM connections, vector DB connections once and allow developers to reuse these without having to share credentials. This eliminates an entire class of access issues.

Defining organizational level policies, teams should comply also brings policy driven enforcement without having to integrate expensive policy management solutions.

Purpose built tools are great if we take the responsibility of managing the complexity involved. A unified platform relieves organizations of this complexity and increases velocity of software development and delivery.

🔚 Summary

Purpose built tools offer flexibility but introduce significant complexity in managing fragmented systems. A unified, “batteries-included” platform like Choreo makes software development, DevOps, and delivery operations more efficient. By providing integrated tools, native support for modern functionalities, and a unique cell-based architecture, Choreo simplifies complexity, enhances consistency from development to deployment, and ultimately increases the velocity of software engineering and delivery.