How ING Cut Time to Market via a Better Developer Experience
We say it time and again, platform engineering is inherently socio-technical. The technology cannot enable developers without a true understanding the developer experience.
This is the lesson ING learned during the Dutch financial services company’s technical time of transition, as it looked to enable 15,000 DevOps engineers to release products faster to 30 million customers worldwide — all via a series of platforms.
“Our primary objective was to provide our users with the capabilities to concentrate on their core objectives and effortlessly operate applications, without worrying about the underlying technology,” Amir Abadir, product lead on ING’s technologies platform, said on the virtual stage of PlatformCon. “In doing so, our developer community could build on top of the platform and align it with their unique propositions, leveraging the benefits of products and service reusability.”
Read on to learn about how ING engineering set technical goals but then, as the platform solutions first built only added to complexity and context switching, they refocused on developer experience and adopting a platform as a product mindset.
How the Platform Was Built, Round 1
“Our primary focus is to enhance developer experience on the technology platform through journey automation, easier solution assembly and integration, and streamlining of processes for developers to build solutions on top of our platform,” Abadir said.
The approach, his team assumed, should result in:
- Shorter time to market.
- Consistently high-quality products and services.
- Increased productivity.
- Reduced cost associated with maintaining services.
In the end, he said their main goal was “to empower the developer community reach their customers evermore faster and evermore meaningfully.”
This led to the creation of foundational services, including:
- More than 800 applications running on the API, web and mobile pipelines
- Service mesh with more than 1,000 APIs running
- SDKs with 1,200 service applications, 300 web and mobile applications, more than 2,000 frontend components
- More than 5,000 topics on Kafka Events with 700,000 messages per second
- 1.4 million notifications monthly across email, SMS and InApp
ING also released a unified design system (UDS) including all the tools, guidelines and reusable components necessary to create a unified developer experience.
The platform team also released authentication and authorization services across all apps for the more than 400 million customer logins per month — or 400 logins per second — all with a million transactions approved daily.
But this technological feat didn’t translate to increased developer productivity — if anything, it may have led to increased context switching.
Platform Challenges at Scale
While ING was able to significantly improve time to market with hundreds of reusable components in its developer catalog, the complexity of integrating services together and the amount of time spent on manual, repetitive configuration only served to slow development right back down.
Platform engineering, in part, aims to give decision-making and ownership to engineering teams. However, it’s important to remember that centralized management is key to fostering communication and setting of expectations. The complexity of the varying platform integrations, Abadir explained, initially offset almost all of the benefits of the platforms and resulted in high lead time.
“Engineers didn’t know where to start, what to do next, who to talk to when they are integrating a service, which team is providing which part of the platform. It resulted in an incoherent experience.” Engineers, he continued, still hadn’t unlocked joy in their work and that impacted the ability to innovate. It ended up taking six to seven months to deploy a “simple application” into production with all the necessary configurations and controls.
Abadir’s team realized it had to work on creating a more unified developer experience — not just another developer portal bandaid, he noted — which came down to prioritizing the overall developer experience. Namely, they had to focus on people before they continued building on the technology.
Before they were providing a selection of services, but now they aimed to provide a comprehensive platform.
“The whole experience of our developers is what is most important, rather than our view as the platform provider looking at it as a bunch of collective services” and their consumers they having to try and stitch incongruent products and services together. He continued that “Our success is subject then to the overall experience of the platform, rather than the products that were being developed in isolation.”
Strategies for a Self-Service Developer Experience
The platform team turned its attention to the main tools interacted with to look to rebuild a better developer experience. That started by extending the CI/CD pipelines in order to make them “richer,” tailoring and standardizing them around the shared resources that development teams were trying to deploy, like web and mobile apps, services via APIs, widgets and streams.
ING’s newer strategy concentrates on all opportunities to automate, where engineers are no longer required to manually configure products and services. Instead, they can use the pipeline with a command line interface (CLI) to self-configure services. They use the “shift left approach,” which Abadir explained is configuration as code, “instead of disconnected portals that we are trying to configure things inconsistently.”
For example, if a developer is trying to build a backend service application, they would define it in a YAML file stored in the repository, and then it gets pushed to the pipeline in the configuration manager, which, he noted, is highly influenced by the Kubernetes API. This configuration manager receives all the incoming requests for the configuration changes, and then authorizes and authenticates — or not — the configuration request against the Open Policy Agent (OPA). If everything checks out, the configuration manager then moves this code to the Kafka event bus — “and then this is where the magic happens,” Abadir said, “where all the different controllers of our different resources would then process this request,” including the creation of namespaces and provisioning of virtual machines or CHP instances, all automatically configured by developer user preferences.
Platform Team Creates Wizards
On top of all that, they have a “management cockpit” where developers are able to monitor and manage all their applications and dependencies, as well as wizards that aim to avoid any developer building something from scratch.
“Think of this [the wizards] as a simple step approach where we take the developers through the intention of trying to see what they would like to build,” Abadir said. “These are optimized paths that further enhance the engineer experience and the end of these wizards would be the bunch of YAMLs that the users need to have stored in the repo,” with all changes to be made there in the YAML, which is then kickstarted back to the wizards.
Now, it’s still not all under a single platform, but they have created integration to facilitate collaboration and consistency across the technology, infrastructure, and engineering platforms.
“This collaboration allows for the swift configuration of the resources and the spinoff and setup of environments within minutes,” he said.
Finally, they have a developer portal to self-service it all with a directory of services that encourages reusability and consistency, along with extensive support across the solution lifecycle — from discovery and design through development, all the way through distribution.
Their overall goals for developer experience became to:
- Reduce lead time to less than 15 minutes.
- Eliminate manual, inconsistent ways of configuring services and products (like emails and tickets).
- Unify the developer experience.
- Focus on the developer journey with more of a platform as a product mindset.
- Improve overall documentation, training, feedback management and support.
But then, via achieving these goals, Abadir says they are better set up to accomplish their original goals of shorter time to market, higher quality, increased productivity and lower cost to serve.
