Enhancing developer experience to accelerate network automation

At Ericsson, we are convinced that DX and platform engineering are essential to efficient software development. We recently canvassed our developers and used their input to create an extensive catalog of services and tools, define a set of simplified processes and streamline our workflows.

The Open Radio Access Network (O-RAN) Alliance and the service management and orchestration (SMO) platform enable CSPs to leverage DX and platform engineering for the development of rApps – non-real-time RAN intelligent controller applications – that will accelerate network automation in the telecom space.

The evolution of software development practices

Software development and operations have evolved significantly compared with 20 years ago, when development teams focused on coding and a system administrator handled deployment and maintenance aspects. Before long, it became clear that this siloed way of working had negative consequences for developers and system administrators alike, which led to the emergence of the development and operations (DevOps) methodology. The more integrated DevOps approach improved DX by ensuring that development teams had the skills to both develop and deploy software, which quickly made it the industry standard.

The cloud-native concept emerged during this same time period, which led to significant improvements in scalability, availability and operability, but it also made setups much more complex. As a result, the simplicity of deploying a single-tier application that interacted with a database via a simple script became a thing of the past.

Cloud native increased the load on an already complex developer landscape that includes:

• different programming languages such as Java, Python, Rust, Go and C++
• a variety of integrated development environments (IDEs) such as IntelliJ, Visual Studio Code and Eclipse
• version control systems such as Gerrit and GitHub
• continuous integration/continuous deployment (CI/CD) tools such as Jenkins, Spinnaker and ArgoCD
• observability tools such as Prometheus, Grafana and Jaeger
• security tools such as FOSSA, Trivy and Xray.

As a result, the role of a developer has become extremely complex, and the burden of handling tasks that are not directly related to feature implementation has led to inefficiencies in delivering software.

To overcome these challenges, platform engineering has emerged as a promising solution with the aim of building on the positive aspects of the DevOps approach while also addressing the complexity of the cloud-native landscape. Rather than requiring each developer to understand and operate everything in the end-to-end toolchain, platform engineering aims to streamline the DX by offloading tasks that are not of direct concern to the developer.

Developer personas

As software development practices have expanded, so too have the types of developers and the range of knowledge and skills they have. The table in Figure 1 provides an overview of the three main developer personas. Developer personas range from those who are highly technology focused (pro-code developers) to more solution-focused types who use software as a means to an end but may have limited time and/or knowledge of software best practices (low-code and no-code developers). Some development teams delivering the same solution could have a blend of these personas depending on the solution. For example, the backend developer could be pro-code, but frontend development could rely on low-code or no-code developers due to limitations in time and/or experience. In light of this, platformengineering solutions must meet differing needs and match the various skillsets of a range of developer personas.

Figure 1: Developer personas

From user experience to developer experience

About 20 years ago, software companies began prioritizing user experience (UX), recognizing its impact on how much people liked, disliked and promoted their products. Design thinking [1] is a UX methodology that is used to understand a user’s experience, needs and problems in order to create effective solutions. Figure 2 illustrates the design-thinking process, which includes empathizing with users, defining the problem, brainstorming ideas, prototyping solutions and then testing those solutions with users. This iterative method encourages creativity and collaboration, ensuring innovative and user-centric outcomes.

Figure 2: Design-thinking process super loop

As part of our transition toward platform engineering, Ericsson is using design thinking to improve the experience of our developers. This human-centered [2] approach ensures developers are at the center of any solutions required to automate their non-feature development tasks while they build and deliver software.

Unlike traditional user research methods such as usability testing, A/B testing and field studies, focusing on developers often requires a different approach. Developer tasks can be lengthy, involve multiple teams and utilize various tools, making some traditional methods less effective. Therefore, we employed a mix of qualitative and quantitative techniques, including focus groups, interviews and surveys, to gather attitudinal data. This strategy progresses from general to specific to minimize bias and avoid influencing developer behavior or perceptions.

Research findings and common developer challenges

The only reliable way to improve DX is to actively listen to developers to learn about their needs and pain points and then respond to their feedback. Utilizing design-thinking methodologies and UX principles ensures that the solutions provided are intuitive and effective, reducing friction and enhancing overall productivity. This collaborative approach empowers developers, boosts satisfaction and fosters a culture of continuous improvement and innovation. The data we gathered from platform and rApp developers revealed that while each team is unique and has its own specific expertise, they all face similar challenges. Some teams require more support than others to build and deliver their functionality. On a broader scale, however, three types of challenges stand out:

1. Difficulties with findability and freshness of documentation
2. Incorrect environment setups with brittle delivery pipelines
3. Lack of self-service paths.

1. Difficulties with findability and freshness of documentation

When interfacing toward or using another system or library, developers require access to developer guides, application programming interfaces (APIs) and architecture information, as well as information about ownership and whether any common vulnerabilities and exposures (CVE) need to be addressed. This is often a problem, however, as many teams store internal software information according to team structures rather than according to functionality, which results in varying formats, levels of detail and quality. Even when developers find the content they need, it is often unclear if it is up to date, as it typically resides outside the software repository on other information sites.

2. Incorrect environment setups with brittle delivery pipelines

Having the correct design and runtime development environment is crucial for efficient software development, but the process of setting up IDEs, dependencies and user privileges can be complex. Properly configured testing environments with good data are also challenging to achieve. Additionally, developers must be able to trust the delivery pipelines to ensure that failures are due to the commit under test, not infrastructure or test errors that require retriggering or troubleshooting.

3. Lack of self-service paths

Process-heavy tasks that require manual handling, meetings and/or approvals are cumbersome for developers. It is important to recognize that not everyone is an expert in every field. Teams can progress without extensive training when sample code, reference architectures, code generators and task wizards are provided to them. Concise directions and clear learning paths make developer onboarding less overwhelming and help developers become self-sufficient as quickly as possible.

A platform-engineering approach to software development

By employing empathetic listening techniques in our interactions with developers, we learned that some development challenges are not just technical but also organizational. Organizations must be open to change to address developer concerns; otherwise, roadblocks will persist. Platform engineering can help overcome these organizational challenges by creating a unified and streamlined environment that minimizes friction between teams. Figure 3 illustrates our platform-engineering-based solution proposal.

Figure 3: Platform-engineering solution

Internal developer portal

One of the key tenets of a platform-engineering solution is an internal developer portal (IDP), represented by the yellow section on the right side of Figure 3. An IDP is essentially a self-service layer that sits on top of a development organization’s infrastructure and development toolchain, abstracting the underlying complexity. In tandem with the software repos where the developers commit code changes, an IDP offers a cohesive interface that allows developers, solution architects and program managers to manage and understand the entire software life cycle by integrating with all of the organization’s software repo. The IDP covers everything from coding to deployment, making it possible to automate numerous routine tasks, enforce best practices, learn about how services work and ensure a uniform experience across an organization based on information. All of this is enabled through the use of plugins as described in the reference plugin-based architecture of industry-provided solutions such as Spotify’s Backstage [3], which is the third-highest adopted project in the Cloud Native Computing Foundation [4] behind Kubernetes and OpenTelemetry in 2023.

Plug-ins

Frontend plugins can be used in numerous ways to provide interconnected and context-aware use cases for the developer, as illustrated by the yellow boxes under the developer portal in Figure 3. They can, for example, be used to make all of an organization’s software (including APIs, libraries, services and systems) discoverable in a software catalog, together with software ownership information. A code generator plugin is a type of plugin that includes a user interface (UI) that enables low-code and no-code developers to build code and thereby quickly deliver business value.

Another plugin could be used to enable a self-service, wizard-based UI that executes self-service use cases such as the provisioning of a code repo to begin coding or Helm deployment to a Kubernetes cluster, for example.

Backend plugins typically provide integration with an external system such as Jira, GitHub, Jenkins, Spinnaker, Kubernetes or other infrastructure as a service (aaS) systems to ensure that the customer delivery pipeline meets developer needs.

Beyond the developer portal

While a developer portal is an important part of DX, there is much more to consider. Improving DX extends beyond the confines of a developer portal to encompass the entire ecosystem in which developers operate. This includes onboarding, optimizing collaboration tools, streamlining communication channels, pipeline resiliency, new code repository management, test environment booking and more. These aspects can and should be addressed independently but all developments need to converge into a unified solution offering through the developer portal. When all of these aspects are integrated into the developer portal for a single view, it is critical that they are context-aware for the developer and their software.

This architecture solution allows entities to be modeled, and it is extendable to capture bespoke organizational information, defined by a metadata schema representing developer-owned software artifacts. That metadata, along with other metadata such as docs and APIs, is stored in the repo of the service in a doc-as-code approach under the autonomy of the developer. Both frontend and backend plugins utilize the captured metadata to provide a contextdriven view for the developer. Depending on the problem being fixed for the developer, plugins can be created to suit various use cases and developer needs, which ensures flexibility and targeted fixes for different developer personas.

Avoid reinventing the wheel

Within platform engineering and in particular developer portals, it is essential to evaluate the integration of a feature required by the target developer to strike the right balance between creating a new plugin versus navigating to the existing functionality that could exist in an external tool. In the developer context, it is critical that the integration is context-aware, but there is no need to reinvent the wheel. If, for example, a full stack developer is building an rApp and they want to test their interaction to a given API, it makes sense to use an industry-wide tool such as OpenAPI Generator rather than rebuilding. The portal can provide OpenAPI Specification files for its APIs that can be used to generate stub servers, which run concurrently with its tests in any test framework of choice. Tight collaboration with developers who will use the feature is the only way to ensure that they will know this.

Applying DX to service management and orchestration

As a contributor to the O-RAN Alliance [5], Ericsson can enable CSPs to build software to automate network use cases through our rApps and our SMO ecosystem. We expect this capability to lead to a significant evolution in our relationships with CSPs: where we have traditionally provided applications to execute use cases for runtime users, we can now provide functionality and support for developers with varying focus and capabilities to implement their use cases. This evolution means, for example, that the low-code developers who build their own automation scripts at many CSPs today could soon be using a more “productified” and controlled set of rApps to automate network use cases. rApps will be required to meet certain standards (such as security), adding more development tasks. Much like improving DX for the pro-code developers in the shift to cloud native, it is critical to make it easy for low-code and no-code developers to adopt and build rApps while staying focused on solutions.

Applying our findings to address the needs of our customers

A developer is a developer, whether that person is creating value in an rApp running on top of an SMO or creating a service exposing a platform capability by the SMO. In both cases, the developer faces the same challenges with respect to testing, pipeline execution and documentation as we at Ericsson do, but they also face some additional ones. These additional challenges can include diversity with respect to software development kit documentation, app portability, the maturity of O-RAN standards to facilitate app portability and the development skill set of their developers. Low-code and no-code developers require more support, and there is a need to integrate with the SMO and rApp vendors. Our customers also need to integrate their own software including rApps, rApps from other vendors and SMO software, as well as various engineering and CI practices.

By ensuring that our documentation (API, developer guide, release notes and so on) for a service is “fresh,” “discoverable” and written in a format that any developer can consume, we have sharpened our ability to “write it once and write it well” servicing both an internal and CSP developer community.

With respect to the pain points experienced by CSP rApp developers when it comes to “environment setups” and “self-service,” however, there is an important distinction. While their pain points are similar to ours, they have different aaS offerings based on their own commercial and free opensource agreements, all of which need to be taken into consideration when creating a solution. We must, however, ensure we support the same self-service aspects (faster onboarding, streamlined workflows and enhanced productivity). The solution needs to be context-aware to enable the different developer personas, from no-code to procode, to create an rApp with correct security and deployment alignment to ensure it can deliver business value at speed.

Case study: A low-code developer builds an rApp

Imagine that a low-code developer in a CSP with strong knowledge of Python and telecoms needs to build an rApp to provide insights into the performance of its network utilizing machine learning. The rApp must include a graphical user interface (GUI) to report insights, but the developer is not an experienced GUI developer.

This developer will require several things before getting to the coding line, along with some other things later on. First, they will need details of the required SMO platform APIs. If the CSP has specific internal libraries, they will also require information on what they do and how. They will need a laptop setup so they can develop with their chosen technologies for this rApp (such as JavaScript and Python). When the time comes to test their rApp, they will need an environment provisioned with the required data and services. Once implementation starts, they will need a CI/CD framework for continuous software releases to automate the delivery of new features, bug fixes and so on, and before the rApp can go to live production it needs approval that it meets security and quality standards.

This is a great deal of work for any developer, but a developer portal with the right plugins can streamline several aspects. For example, it would likely be useful for this developer to have an API catalog available so that they can look up API docs or find CSP-specific libraries. It would also be helpful to have a developer container with a developer environment playground or sandbox preconfigured to avoid having to install software locally to trial some ideas. Having a code generator that can build a simple GUI that ensures compliancy to UX rules such as accessibility is also beneficial.

A developer portal can also streamline flows that otherwise require significant organizing by the developer. For example, while there may be some automated checks when approving software to ensure that it meets security and quality standards, in most cases there are also various people who need to approve certain stages. A self-service flow can speed up this process by gathering the right information and notifying the right people for approval.

Conclusion

The efficient creation of high-quality software is critical to achieving higher levels of network automation. By prioritizing developer experience (DX) in the development of rApps, communication service providers (CSPs) can ensure that the tools and platforms their developers use are optimized for efficiency and effectiveness, leading to improved productivity and faster time to market.

Platform engineering is essential for any organization that wants to enhance its technological capabilities and streamline operations, and CSPs are no exception. By adopting platform-engineering practices, businesses can create robust, scalable and efficient platforms that support diverse applications and services. A platform-engineering approach not only accelerates development cycles but also ensures consistency, reliability and security across the entire technology stack. An investment in platform engineering is a strategic move that drives operational excellence, supports business growth and positions CSPs to thrive in an increasingly digital world.