Platform Engineering 101 for Java developers

Combating the struggles of modern cloud-native Java developers

Moving our applications to the cloud and cloud-native infrastructure can offer many benefits. These can include flexibility, reliability, robustness, access to innovative technologies and current trends, speed, cost efficiencies and more. As developers, it is an exciting environment to work in. However… despite the excitement to move to the cloud, actually completing this move and effectively creating cloud-native applications can be extremely challenging, frustrating, and difficult! Why is this, and what can we do about it? In this article, we’ll explore the tools and technologies that can help us combat the struggles of cloud-native Java developers. We’ll delve into Platform Engineering, Internal Developer Platforms and Portals, and tools like Backstage and Red Hat Developer Hub. 

Struggles of a cloud-native developer

---

There are many challenges that developers face when creating effective modern cloud-native applications.

Challenge 1: Increasing cognitive load

Increasing responsibilities and tools has led to what The State of Platform Engineering Report describes as “increased cognitive load on engineers.” As developers, we now have to focus on more than just app development. In fact, there is what seems to be an ever-expanding list of accumulated-word-descriptions to capture the growing responsibilities developers now have. What started as Dev and Ops and became DevOps has now expanded to FinOps, MLOps, GitOps, DataOps, DevSecOps, BizDevOps, BizDevSecOps, BizDevSecFinMLOps…. The list goes on. As developers, we now face a world of increasing complexity where we are taking on even more tasks and responsibilities.

Challenge 2: Tools – too much choice

A significant contributing factor to the increasing cognitive load we face is the ever-increasing number of complex tools we now have to know and use. We only have to look at the CNCF landscape, or as I affectionately call it, the cloud-native grocery store, to see the vast array of different tools and technologies available for developers to use for each stage of the software delivery lifecycle (SDLC).

From choosing the right database, streaming or messaging tools, to what tools to use for building application images, CI/CD stacks, scheduling and orchestration, service proxies, API gateways, container registries, observability and analysis, and more, how do developers choose the best tools for their specific needs and requirements when there’s so much choice? Even knowing where to get started seems impossible looking at this landscape!

Challenge 3: Steep learning curve

Even once the tools have been selected, it’s often a very steep learning curve to get comfortable with these technologies or master them. And, with this ever-changing landscape and the rate of innovation within these tools, this learning curve never seems to stop growing!

Not only this, but developers are often “expected” to be experts from day 1, getting limited or no time for training on the job, which makes this challenge even more difficult.

Challenge 4: Difficult to manage

As developer’s role starts to include more and more tasks and responsibilities that were more traditionally for ops teams and roles, they are faced with even more challenges associated with effectively managing their distributed applications in the cloud.

Utilizing cloud native infrastructure offers the opportunity to take advantage of increased portability and flexibility for our applications. It enables us to develop applications that utilize containers and can be deployed to any cloud platform, be it public, private or hybrid cloud, or even on the edge, with an abundance of different tools and technologies in servers available across the world. However, as well as offering portability, this cloud-native infrastructure introduces yet another barrage of key decisions – including making decisions on which tools to use, how to configure environments, how best to build applications within a container, and how to ensure consistency and best practices for containers.

As well as making these many critical decisions, developers now also have to contend with “bookmark hell” to be able to manage these build processes, running containers, production images, etc… Developers now have to know how to reach a dozen CI pipelines, countless CD tools, applications, ticketing systems, documentation pages on different source systems (often not findable if you do not bookmark them), have guidelines per application, technology and more!

This is all compounding the issues of Challenges 1, 2 and 3, putting further strain on development teams!

Challenge 5: Security and compliance

Arguably one of the most significant challenges for any application and especially those deployed in distributed cloud-native infrastructure is security and regulatory compliance. We only need look to recent examples (e.g. Log4Shell/Log4J) to grasp the significant risks to our applications when security and compliance is not carefully considered.

Moving towards greater use of open-source libraries, like Log4Shell, means that we need to ensure we are effectively vetting any open source dependencies our applications use and storing an accurate and up-to-date list of these dependencies (like an SBOM – Software Bill Of Materials), so that if a vulnerability is discovered we can act immediately if we know our application is affected. Use of open-source libraries and standards or even adopting architecture styles like hexagonal architecture or clean architecture designs, also enable us to keep our options open if we need to swap out any existing dependencies or elements of our applications with minimal code disruption or effort from developers.

Developers now need to ensure that security is a part of every aspect of the SDLC and is baked into their practices when developing the applications (i.e. eliminating credentials in code, ensuring proper authentication and authorisation is enabled, making use of role-based access control principles, etc). Couple these security concerns with the growing list of compliance regulations (e.g. data privacy laws and regulations, data storage regulations, etc) and developers have even more to keep in mind!

The result of these challenges

Developers are being asked to do more and more, with a confusing landscape of tools and libraries to select from, while contending with the risks and dangers posed by security and compliance.

Put simply, developers are burnt out!

And this isn’t just us claiming this; recent studies back up these findings… For example, JetBrains’ 2023 State of the Developer Ecosystem report showed that nearly three-quarters (73%) of developers have experienced burnout at some point in their career. Similar research from Haystack Analytics in 2021 found that 83% of developers suffered from work-related burnout.

When it comes to explaining the cause of this burnout, many of these studies cite the challenges we’ve detailed in this article. For example, Salesforce’s Mulesoft Study in April 2022 showed that the top three causes of developer burnout were: Increasing workload/demand from other teams, pressure of digital transformation, and requirement to learn new skills. Harness and Haystack’s research also supported the role of heightened workloads in developers’ burnout.

But what can we do about it? How can we help relieve developers of some of the pressures they are under and reduce developer burnout? This is where platform engineering and the use of Internal Developer Platforms (IDPs) can help…

---

What is Platform Engineering?

According to platformengineering.org:

“Platform engineering is the discipline of designing and building toolchains and workflows that enable self-service capabilities for software engineering organizations in the cloud-native era. Platform engineers provide an integrated product most often referred to as an “Internal Developer Platform” covering the operational necessities of the entire lifecycle of an application.”

It is an emerging discipline focused on enhancing developer productivity. Platform Engineering aims to reduce complexity and overheads while enabling frictionless, self-service capabilities for organizations trying to develop cloud-native applications. It involves designing and creating toolchains, workflows and automated infrastructure operations that

help to address some of developers’ biggest challenges: e.g., reducing the burden of managing multiple tools, technologies and infrastructure and aligning development practices with business priorities and compliance requirements.

You may be wondering, but how does this fit in with DevOps? Does this now mean that DevOps is dead and that platform engineering is the future? Well, not quite. Many in the community believe that platform engineering doesn’t necessarily supplant DevOps, rather, they view it as the next evolution of DevOps. In fact, Daniel Bryant, a platform engineering advocate from Syntasso, has highlighted that platform engineering is positively grounded in the three ways of DevOps (as described inThe DevOps Handbook):

• Concentrating on flow and systems thinking to deliver end-to-end business value
• Even shorter feedback loops
• Continuous experimentation, learning and improvement

---

How can we use platform engineering?

As the definition provided above suggests, platform engineering is less of a tangible, physical thing and more of a discipline that is enabled by a platform engineering team. Platform engineering teams can implement the principles of this discipline by designing and creating Internal Developer Platforms to provide approved golden work paths (curated sets of tools and workflows) for developers and Internal Developer Portals for developers to access these golden paths.

It’s a bit like creating a recipe book and working out the best ingredients for your organization to use… like baking your own platform. When it comes to selecting ingredients, the platform engineering team would need to consider the majority of use cases for each stage in the SDLC and map out which tools would be best for their organization for each of these stages. This can include making choices about which IDEs to use, version control systems, resources, container registries, observability tools, vulnerability scanners, CI/CD tools, GitOps tools, etc.

Once this list of ingredients has been selected, the recipes can be created as golden paths. A golden (or paved) path consists of a defined set of tools and workflows for developers to pick up and use through an Internal Developer Platform and Portal.

What is an Internal Developer Platform (IDP)?

An Internal Developer Platform (IDP) is a central collection of tools, services and automated workflows that enable development teams to be able to rapidly deploy and deliver software. These platforms provide a service layer that abstracts away the complexities of infrastructure management and application configuration.

Internal Developer Platforms (or IDPs for short), as the name suggests, are platforms that are designed for internal use by developers (their primary users) within an organization. IDPs are custom-built by a platform team by combining different tools and technologies (services, open-source, self-developed, etc.), those ingredients we mentioned earlier, with the intent to increase developer productivity and velocity.

IDPs integrate into existing workflows which usually remain a git-push deployment workflow but add further automation. The entire deployment process is now at the disposal of the developer. They can request resources, spin up fully provisioned environments, rollback, deploy and set deployment automation ruling autonomously. Essentially, a modern developer uses an IDE to code, git to merge, and an IDP to ship.

What is an Internal Developer Portal?

An Internal Developer Portal provides a single interface to your developer platform – it serves as the “face” or UI of the Internal Developer Platform. It allows developers to perform self-service operations and actions and offers visibility into the infrastructure. Depending on the maturity of the IDP, it can provide several interfaces and access points for developers to make use of. That can be a CLI, different kind of User Interfaces (UIs), or a developer portal with a service catalog to unify the developer experience.

So, it’s important to understand and acknowledge the difference between these two acronyms. Internal developer portals serve as the interface through which developers can discover and access internal developer platform capabilities. An IDP on the other hand, is the sum of all tech, tools and processes that a platform engineering team binds into a golden path for developers. Golden paths reduce cognitive load and drive standardization by design. So, an IDP doesn’t necessarily need a developer portal to deliver value to developers. However, using the two together effectively can help to deliver one cohesive platform and UI to ensure ease of use for developers.

Benefits for Developers

Qualitative Benefits

So, why use platform engineering and IDPs? What benefits can it bring to developers?

From an organisational perspective, utilising IDPs and having a dedicated Platform Engineering team can help to spread out the responsibilities and concerns of cloud-native application development in a healthier manner across development, ops, and platform engineering teams, without (importantly) compromising on security, compliance, or best practices. Allowing each of these teams to focus on where their strengths lie and having clear distinction between responsibilities. It’s important to note here that this platform engineering team does not necessarily have to be new hires, but can instead be a reshuffle of the current organisation to help separate out these responsibilities clearly.

Other qualitative benefits gained include:

• Standardizing and securing key delivery processes (Golden Path), reducing the risk of shadow IT and the burden of operational complexity placed on developers.
• Enabling Internal Developer Platforms, resulting in self-sustainable and self-responsible teams.
• Simplicity of DevX, reducing cognitive load and complexity for development teams and enabling greater productivity.

Quantitative Benefits

External studies showing measured quantitative benefits further supports the actual impact of these qualitative benefits. For example, a recent Forrester Opportunity Snapshot, showed that 74% of DevOps leaders saw that improving their developer experience with an IDP boosted developer productivity, 77% reported that it can shorten time to market, and 85% that it drives revenue growth. Studies by Humanitec also showed that developers were able to deploy 4x more frequently with 0 minutes of waiting time, platform engineers had a 95% reduction in config files and 75% less maintenance overheads, and organizations saw a 30% increase in time to market.

However, that’s not to say that platform engineering and the creation of IDPs is something that every company should be doing. As with all methodologies, guidelines, architecture types, etc. there are both pros and cons to utilizing these principles and tools and you should carefully consider these for your own organization and applications to determine if it would be suitable. If, for example, you are part of a small organization and it would not be feasible to create a dedicated platform engineering team, then this perhaps may not be something you would want to implement.

Tools to help

Thankfully, there is already a range of tools, architectures, libraries and references you can use to start creating your own IDP and introduce platform engineering into your own organization.

Reference architectures

There are reference architectures available from companies like Humanitec and McKinsey. These companies researched hundreds of real-life platform setups, uncovering common patterns in IDP architectures. They then distilled these patterns into five architectural planes: Developer control plane, integration and delivery, monitoring and logging, security plane, and the resource plane. Starting from a blueprint like this could be a big help to rapidly construct IDPs.

IDP tooling landscape

PlatformEngineering.org expanded McKinsey’s original IDP reference architecture to create a tooling landscape that adopts the same umbrella subgroupings but includes other pluggable tools.

Backstage

The CNCF incubating project Backstage is arguably one of the most popular platform engineering tools. In fact, this project has the second largest number of contributers within the CNCF, behind Kubernetes! Backstage provides an open platform for building developer portals, powered by a centralized software catalogue, customizable with plugins. This is a fantastic OSS project that has really gained momentum and adoption lately, with over 3,000 companies having adopted Backstage for their own developer portals, including companies like Capitol One, CVS Health, Siemens, LinkedIn, REI, Vodafone, Lego, and more.

As standard, Backstage provides the following core components:

• Backstage Software Catalog for managing all your software (microservices, libraries, data pipelines, websites, ML models, etc.)
• Backstage Software Templates for quickly spinning up new projects and standardizing your tooling with your organization’s best practices
• Backstage TechDocs for making it easy to create, maintain, find, and use technical documentation, using a “docs like code” approach
• Plus, a growing ecosystem of open source plugins that expand Backstage’s customizability and functionality

Traditionally, Backstage plugins are static (i.e. code-based). So, when you want to integrate any new plug-ins and features, it involves modifying the core codebase of Backstage and then re-compiling, re-packaging and re-releasing the entire application stack. This process can be time-consuming and suffers from drawbacks including introducing increased complexity, dependency headaches, and increased time to production. However, this is starting to change and the Backstage community is currently working on enabling dynamic plugins.

Red Hat Developer Hub (RHDH)

Building on the success of Backstage, Red Hat launched the Red Hat Developer Hub (RHDH), a downstream project of Backstage.io. It offers an enterprise-grade, open developer platform for building developer portals, containing a supported and opinionated framework.

So, what the difference between RHDH and Backstage?

RHDH extends the functionality of Backstage through a set of predefined supported dynamic plug-ins providing extensions and components to make it easier for developers to design and build applications. The “dynamic” plugin approach taken by Red Hat Developer Hub addresses the challenges of static plugins head-on by employing a “configuration over code” approach. This allows the loading of plugins dynamically at runtime and negates the need for complex code recompilation or container rebuilds. This approach to plugins enables many benefits, including immutability by design, enhanced flexibility and customization, simplified plug-in management and improved scalability and maintenance. However, as mentioned, this difference is changing as Red Hat have been contributing to Backstage with implementations and suggestions of how to enable dynamic plugins in this portal too.

One other difference to note is that when using RHDH, your app’s configuration is now in YAML definitions, and not in the source code anymore (which is the case for Backstage). This offers much closer synergy with the principles of methodologies like the 12 and 15 factor app methodologies, that state that config should be separated from code for effective cloud native applications.

Kratix

Taking a slightly different approach to IDPs, Kratix is another open-source project (contributed by Syntasso) that can be used. It is an open-source cloud-native framework for building internal platforms, this time, specifically on Kubernetes. It enables the creation of a flexible platform with your paved paths as ‘Promises’ – any kind of abstraction that increases developer productivity, efficiency and security (e.g. developer portals, Databases as a Service, Kubernetes namespaces, etc). Kratix enables co-creation capabilities by providing a clear contract between application and platform teams through the definition and creation of these Promises. Where Kratix stands out from other OSS projects in this space, like Backstage, is that it supports platform teams to easily deliver a curated Kubernetes-native platform.

Other proprietary offerings

There are, of course, also a range of proprietary offerings, tools and services that can be used to create IDPs within an organization. Helpfully there is a list of these on the internal developer platform website: https://internaldeveloperplatform.org/developer-portals/. Many of these tools are SaaS offerings.

Summary

In summary, what we’ve tried to capture in this article is the fact that cognitive load and demands on developers are ever-increasing as we move towards cloud-native development, leading to burn-out, lower productivity, and demoralized teams. However, the use of Platform Engineering, Internal Developer Platforms (IDP), Internal Developer Portals, and Golden/Paved Paths can help developers with the challenges that they now face.

What this looks like will be specific to your organization because the ingredients you use to bake together your platform will be unique to the tools, libraries and technologies needed by your applications and your teams. But, the good news is that there are many examples, references, architecture maps and recommended tools and technologies out there that you can use if you’re diving into this in your own organization.

Next Steps

Now that we’ve covered the theory, if you’re interested in getting hands-on with these technologies, you can follow our workshop on GitHub. It takes you through how you can set up an IDP with the portal, Red Hat Developer Hub, on OpenShift using the free developer sandbox environment. In this workshop, we’ve provided you with an example software template you can use, utilizing GitHub actions and Open Liberty. Try it for yourself: https://github.com/grace-maarten/platform-engineering-101

In this GitHub repository you can also access a list of real-world examples of companies implementing platform engineering and their own IDPs into their organizations and what impact this has had for them. We’ve included a range of companies of differing sizes and structures in this list, so hopefully you’ll be able to learn from or relate to them, to help with you own journey potentially implementing this in your own organization.

Alternatively, you can access a whole community of support focused on platform engineering with the following links…

• https://www.infoq.com/minibooks/platform-engineering-guide/
• https://platformengineering.org/slack-rd
• https://platformweekly.com/
• https://www.youtube.com/@PlatformEngineering