How Spring and Java Shaped Internal Developer Platforms
I’ve long noticed that Java promotes an unusually consistent approach to writing code. The language has a comparatively small surface area with relatively few rough edges, which makes it pretty straightforward for a developer to move from one Java project to another. The lesson for anyone building or maintaining an internal developer platform (IDP) is that promoting consistency really matters.
While that has always been true for Java SE, it wasn’t always so for its extensions. Enterprise Java developers today have many excellent frameworks to choose from, but those of a certain age may remember what it was like programming with J2EE in the early 2000s. Introduced in late 1999, the J2EE standards extended Java SE with specifications for web and distributed enterprise applications, which could be deployed on an application server such as BEA WebLogic or IBM WebSphere.
The J2EE standards saw wide adoption but acquired a reputation for being hard to use. Some parts of the specification, particularly the original Enterprise JavaBeans (EJB) spec developed by IBM, were genuinely complex and came with a considerable performance penalty. For example, EJB allowed remote method invocation only through protocols such as Common Object Request Broker Architecture (CORBA), in contrast with most other business applications.
Furthermore, application servers of the era were designed to be started once and left running for months, or even years, without an outage. As Java Champion Holly Cummins explained, BEA, IBM and other vendors who supported the full J2EE specification did some remarkable engineering to make this work. The downside was that starting them up, as you often did when developing code, took several minutes. This made it hard for a developer to maintain flow; being English, I used to make (and often drink) a cup of tea every time I had to restart my development server, which probably did more for the sales of Twinings than my coding productivity.
Cumbersome, Slow and Expensive
In addition, packaging and deploying J2EE applications for production was cumbersome. “I was a part of that,” explained DaShaun Carter, research development software engineer and Spring developer advocate at VMware Tanzu, a division of Broadcom. When Carter worked as a J2EE developer for an energy company, his role was to do the build. “When I started, the build took a week and the specification had 12 people to take the J2EE application to production,” he said. Carter was able to shrink the process using Apache Ant and various custom plugins. “We were on a weekly cycle of build and test, but it still took four hours to generate all the WSDLs [Web Services Description Language documents] and build the application.”
Developer tools were also expensive. Carter said one of their tools, the unified modeling language tool Rational, costs $20,000 per seat to have everything each developer needed. “It was ridiculous,” he said.
The Rise of Spring Changed the Paradigm
The Spring Framework, introduced in 2004, did a number of important things. First and foremost, it popularized the idea of dependency injection with an inversion of control (IoC) container at its heart. It also showed it was possible to build simpler web and distributed applications on top of more lightweight servlet containers such as Apache Tomcat. These fired-up faster, enabling developers to get going quickly and successfully, and were also open source and free. At around the same time, open source integrated development environments (IDEs) such as Eclipse and NetBeans began replacing proprietary IDE offerings, further driving down costs.
Spring also provided a way to build enterprise apps with the same coding consistency Java SE provided.
It wasn’t perfect though. Spring had the misfortune to be developed at the height of XML’s popularity, and its reliance on XML created issues around configuration. As more features were added to the framework, Spring also became perceived as overly complex.
Adopting annotations as an alternative to XML in Java SE 6 in 2006 helped the Spring team mitigate configuration complexity to a certain extent. However, it was the Ruby on Rails-inspired Spring Boot, which provides a highly opinionated view of how to build Spring applications, in 2014 that ultimately minimized configuration concerns.
How an IDP Reduces Friction
Spring Boot also pushed the idea of templating through the Initializr and start.spring.io. “This was my introduction to the idea of an IDP,” Carter said. “I could grab the things that I need, like Spring Data and Spring Web, and put them together as I wanted. With the IDP approach, the patterns and the reasons for them are well defined, so it creates a good developer experience.”
The Initializr provides guardrails and allows a developer to get up and running quickly. “I can hit the ground running and expect fast delivery because the IDP is providing so much information with examples — how we handle logs and metrics and so on,” Carter explained.
Seen in this context, the IDP acts to propagate patterns within a company, breaking down silos and reducing friction. As James Watters, senior director of research and development for VMware Tanzu at Broadcom, said, “it reduces boundaries between the security, architecture and development teams.” Ultimately, the goal is to have the IDP act as a real point of fast feedback, composability and pattern diffusion, particularly in larger organizations.
An IDP modeled after Spring reduces some developer flexibility but, drawing a parallel with cloud computing, Watters explained why this may be a good thing:
“Cloud computing trimmed off the dependency on Layer 2 networking by and large. You don’t get to customize your Layer 2 network, as you might have in a data center. But you do get a scalable model that you can consume elastically. I think that the Pareto efficiency for networking keeps applying all the way up the stack until you get to the app patterns, which is where the IDP excels. Cloud Foundry was one of the early indicators of the power of patterns, and I think we’ve seen the emergence of a number of others, including the power of app templating, security by default and build service templating. If you think about Google Cloud Run or Azure Container Apps, the whole industry is starting to say patterns are pretty good ways of achieving efficiency and security by default.”
In addition, because the Initializr is open source and has the complete Spring framework underneath it, an organization can adapt it to its needs and culture.
How Companies Use Patterns and Automation
Jonathan Regehr, private cloud platform architect at a U.S.-based consumer electronics firm, said this is the approach it took. As part of a hackathon, the company built a tool best described as an early backstage type of portal. It generates a skeleton codebase and loads it into a Git repo. It also creates the Jenkins job, runs it for the first time and pushes the app skeleton all the way to production, so all the developer has to do is write code. “The joke was you filled in a form, took a nap and when you woke up you were ready to start coding,” Regehr said.
The tool is getting rather old now, he admitted, and his team is looking for a replacement. Even so, this demonstrates the power of using templates and automation to get started. “If you think through something like a listener, it’s a pattern. I shouldn’t have to care about how I get the event or handle consistency; let the pattern deal with that, and I’ll just oversee the business value part,” Regehr said.
This method of propagating patterns has further advantages when engineers move between teams because it increases consistency. As Suhail Patel, senior staff engineer at Monzo Bank, explained in 2022, “[At Monzo] there is a defined paved road when you start work on a microservice, and as a result, they all look very uniform. You can contribute to another team’s service because the structure is entirely familiar to you.”
Regehr echoed this idea. “I don’t think you can expect to drop someone into a project and have them be immediately effective. People will have a learning curve after joining a team. But if the deployment is the same, the codebase looks the same and everything is laid out the same, they say, ‘OK, I need to understand your business logic, but the rest of this is easy.'”
Scalability Depends upon Decisions
These companies also illustrate the importance of making choices within the platform. “The at-scale players building platform teams tend to have two to four key patterns,” Watters said. “They outline how to scale a Java service or a Go service, rather than trying to build a portal for every open tab a developer might have. The two are very different approaches.”
Regehr’s company takes a similar approach with cluster configuration. From a language and runtime perspective, the environment is mixed. Around 70% of their code, a mixture of web apps and listeners, is written in Java. The company also runs a lot of Node.js and .NET, some Python and a little bit of PHP.
It runs two platforms: Red Hat OpenShift is used for Kubernetes workloads and VMware Tanzu Application Service, still referred to as Pivotal Cloud Foundry (PCF) by some customers, is used for the rest. With hundreds of developers using the VMware Tanzu platform, the company runs over 9,000 app instances across one non-production and four production foundations. It uses a multicloud infrastructure, partly as a result of acquisitions, and also runs a large private cloud.
Regehr’s team works completely on-premises, and they follow an “automate everything” paradigm. To manage their Kubernetes clusters, for example, they have written 140,000 lines of automation code. Developers contribute a small amount of configuration code, and from this and their automation, they generate all the required cluster configs and put them into a repo.
“We’re automatically generating 1.1 million lines of cluster configuration that Argo CD is spraying out and building clusters with,” Regehr said. “We do this using a generated repo, which means that if I make a mistake, I can see what it is and fix it, as opposed to the cluster just dying on me.”
Advantages of Ephemeral Infrastructure
This level of automation allows the infrastructure team to treat everything as ephemeral. “One example is Concourse,” Regehr explained. “We have a Concourse instance paired with every Tanzu platform deployment that handles automation specific to that foundation. If Concourse runs out of disk space or its database gets corrupted, the solution is always the same — burn down the Concourse, run the automation script to redeploy the Concourse, then run our ‘UpdatePipeline’ pipeline. This Concourse looks exactly like it did 10 minutes ago minus some job run history.”
Taking this approach also helps with security, Regehr said. “If you want to give a hacker no quarter, one of the ways to do it is to rebuild your infrastructure so fast that, even if he gets on a server and builds his ‘framework of evil,’ it goes away so fast he can’t rebuild it before it’s gone again.”
That may be effective for the infrastructure, but what about the code itself? James Watters said, “The number one topic that resonates in the conversations that I’m having is: How do we become more secure by default at an at-scale organization?”
Watters believes that the developer platform acts as the starting point, giving standardized app patterns and integration libraries that allow you to authenticate your app. “We’ve also got a secure-by-default build system, which is hydrated back into the IDP, and we can provide a quick security scorecard for the exact moment the app was created,” he said. The IDP can also alert the developer to say, “Did you know there’s a vulnerability in this app and there is a fix available? Would you like to apply it?”
The VMware Tanzu team is exploring the impact that AI is having on the industry, and some of that work is already visible via Spring.ai. Watters said he is “blown away by just how important AI already is,” but he also sees plenty of unfinished business in security as well. “Doing more to automate security tasks and build more patterned and secure systems, is something that our customers want to see more of,” he said.
