How DZ BANK improved developer productivity with Cloud Workstations

Editor’s note: DZ BANK is the second largest bank by asset size in Germany. It is also the central institution for all cooperative banks in Germany, which number around 700. Read on to learn how it used Cloud Workstations to improve the developer experience — onboarding them faster and making them more productive — while making it easier to adhere to its cybersecurity goals.

At DZ BANK, developer experience is given the utmost importance. However, at the same time, the security profile of the development environment shouldn’t be compromised. As part of our partnership with Google Cloud, we embarked on a journey to dramatically improve the developer experience while also enhancing our security posture. Here’s how we achieved our goals using Cloud Workstations.

Missing developer experience focus

Historically, we lacked a standardized way to automate developer environments and provide automated project setup. Depending on a project’s complexity, the onboarding of new developers could take days or weeks. They had to manually set up their projects, which involved digging through multiple sources of internal documentation, provisioning infrastructure, and consulting peers if they ran into issues — a significant toil that can and should be automated.

Moreover, the developers didn’t have a prescribed process for accessing specialized container tools, such as Docker runtime and the tooling around it. As a result, many teams were working in isolation and not sharing best production practices with each other. From a security posture perspective, standardizing development environments is critical to understand how to protect them better and provide transparency around the tools and frameworks used by the development teams. We wanted to have control over what tools developers use and be able to continuously scan them for any possible vulnerabilities.

Cloud Workstations to the rescue

As a fully managed service, Cloud Workstations provide an easy way to standardize our development environments. We can leverage preconfigured base images to manage infrastructure, OS patches, and security patches without requiring any extra effort. It’s also possible to directly access Workstation tools using SSH (or any other TCP protocol), enabling users to forward traffic between ports on a local machine and ports workstation without exposing it to the internet. CMEK support allows us to encrypt resources using a customer-managed encryption key.

In addition, Cloud Workstations provides several base images that contain preconfigured Integrated Development Environments (IDEs) commonly used by developers and supports persistent disks, allowing us to store data between sessions. These base images can be further customized and come with Docker-in-Docker support. For example, we could install standardized IDE extensions and plugins for workstation configurations, such as JetBrains IDEs.

• Cloud Workstations also gave us a variety of options to help us accelerate the developer experience. For instance, the infrastructure-as-code tool Terraform can be used to provision resources and permissions for Cloud Workstations, enabling us to automate the setup of the whole development environment. We also configured a set of pre-warmed workstations to reduce startup times and allow developers to get started more quickly. It’s also possible to configure inactivity time limits, which will automatically shut down workstations that are idle for a specified period of time. With Cloud Workstations, you only pay for workstation uptime, so this has also helped us to keep our costs under control.

DZ BANK deployment architecture

We run our workstations in a private workstation cluster without public IPs inside of a Shared VPC network, which is part of our secure Google Cloud landing zone — our deployed cloud environment. Reaching the private network and workstation cluster requires two Private Service Connect (PSC) endpoints:

• A PSC endpoint to connect the control plane to workstations in our private network, which is created by default for workstation clusters with a private gateway.

• An additional PSC endpoint that allows developers to connect to workstations running in our VPC. We also use the IP address of this PSC endpoint to create a DNS record for the workstation domain DNS record in our private DNS zone.

Continuous developer feedback

Once our Cloud Workstations were accessible inside of the Google Cloud landing zone, we set out to customize them to fit our purposes. We created our own custom Docker images using the preconfigured base images provided by the Cloud Workstation team, which included the following:

• A central proxy setup

• An artifact server that handles all package and tool downloads, which is regularly scanned by the cybersecurity team

• Language-specific package manager setups (e.g., mvn, pip, npm, etc.)

• Additional standardized tools based on programming language and other project needs

• Automated pre-installation and updates of IDE plugins and extensions

• OS package manager repositories that are run through the artifact server the artifact server (i.e., no internet access)

• A fully automated environment setup, including IDE configurations, Git certificates, the Java Keytool, and other common environment variables

• X11 enablement using SSH, so that the developers can also access GUI applications, such as tools for UI testing

• Specialized bash scripts

We also conducted multiple proofs of concept with various developer teams in DZ BANK, each representing different challenges and tooling landscape. Using their feedback, we further improved and customized our Cloud Workstations environment.

One example is project-specific customizations. While standardized images address most developer needs, there are still project-specific requirements which can’t be put into the standardized images, such as project-specific tools and environment variables. To automate these, we use bash scripts on startup to customize images.

For each project, we create a custom file in workstation.yaml with all of the automation commands needed and checked in our Git repository. We wrote a bash script, which looks for this file when a Cloud Workstation starts and runs the commands mentioned in it. This helps us completely automate our project setups, so that a new developer can start contributing right from day one.

We also created an order CI pipeline for Cloud Workstations. The custom image code is kept in our Git repository, which triggers a CI pipeline upon commit. This pipeline builds all the necessary container images based on the hierarchy of images represented in our Dockerfiles.

Docker images are scanned for vulnerabilities according to DZ BANK’s cybersecurity guidelines and pushed into an Artifact Registry of our Google Cloud project designated for testing by our testers and developers.Once images have been successfully scanned and tested, they are integrated and deployed to production.

Cloud Workstations can be ordered internally by developers through an automated workflow, which triggers our order CI pipeline to create all the necessary infrastructure and required permissions. No more searching in documentation is necessary! And with Gemini Code Assist now powering Cloud Workstations, we’re also looking forward to exploring gen AI-enabled code development to accelerate and empower our developers even further.

Lessons learned

Our partnership with Google Cloud leveraging Cloud Workstations has allowed us to significantly improve developer productivity of teams inside DZ BANK. 

“Onboarding new developers takes only one day vs. one week, pre Cloud Workstations. Developers get a fully standardized, secure, automated, cloud-native development environment and can start contributing to the code base from day one. The standardization and automation features enable a better developer experience.” – Gregor Otto Milenkovic, Product Owner, DZ BANK AG

We learned many lessons along the way that you might find useful for your own journey:

• The continuous developer feedback loop is critical for achieving a final outcome that satisfies all stakeholders.

• Finding the right balance between the freedom afforded to developers and the security profile of the development environment is an imperative.

• Google Cloud Customer Engineers and the Product Engineering team are instrumental in seeing projects through to the end. We had consistent contact with them to answer our queries, report bugs, and feature requests.

• Automate everything and eliminate toil!

Ready to take your first step? Learn how to create your Cloud Workstation or try this Cloud Skillboost lab! 

^{We would like to thank Yuriy Babenko for technical contributions to this blog post.}