Radius Blog – 2023

Posts: Case Study: How Millennium bcp leverages Radius

Wed, 06 Dec 2023 08:00:00 -0800

Millennium bcp is Portugal’s largest privately owned bank, with over 1,300 branches serving more than 6 million customers around the world. In the ever-evolving landscape where finance intersects with technology, we consistently focus on generating business value through innovation and excellence. In our pursuit of delivering exceptional services to our customers, we understand the value of technical leadership and one of the keys to our vision and success has been continued use of the latest technologies to generate business value. We were among the first in our market to introduce ATMs and alternative payment methods, and one of the first to deploy online services like transactional websites and an online financial marketplace.

We have been a leader in the adoption of cloud technologies, and have been using Kubernetes in production since 2019. The bank has also been a strong supporter of open-source software (OSS), and has contributed to multiple OSS projects. The bank’s digital transformation strategy is based on a cloud-first approach, and we have been working to build a platform that can be used by all development teams to accelerate application development and deployment while ensuring security, compliance, and operational excellence.

We also have an extensive and diverse application portfolio that has evolved over the years to serve a multitude of business functions. However, efficiently managing this expansive application portfolio while upholding best practices and principles has posed a difficult challenge.

It is within this context that we are proud to be part of the select group of companies that are early adopters of Radius, seeking to standardize processes, expedite developer workflows, and future-proof our infrastructure and enroll in this transformative journey that has reshaped our approach to application definition, governance, and development. Adopting Radius is more than just an initiative; it is an example of our commitment to excellence in every facet of our technological operations. It signifies our dedication to enhancing customer experiences, streamlining operations, and reinforcing our position as an industry leader.

In this technical case study, we will detail how Radius was adopted at Millenium bcp. We will walk through our target developer experience, the platform we began building on KubeVela, what we learned along the way, and why we decided to move to Radius. Throughout this case study we will highlight our methodologies, tools, and strategies that have empowered us to navigate the intricacies of effectively managing a large, complex application portfolio.

Scoping the problem

It was clear to us that the pressure to deliver new features and applications and the infrastructure to support them was ever-increasing while, unfortunately, the resources to support that drive were not infinite. Aligning expectations between the multiple teams involved was a challenge. We needed to find a way to accelerate the application lifecycle, from implementation to decommissioning while maintaining focus on all requirements that a financial services company has. Clear requirements definition was also a challenge, as development teams and infrastructure teams have different backgrounds and concerns. We needed to find a way to align these teams, and to ensure that the requirements were clear and unambiguous.

Beyond day 1 operations to deploy new features and applications, we also needed to improve decoupling between applications and infrastructure implementations, as those two lifecycles seldomly matched. The need to change an infrastructure deployment pattern should not have an impact in the application lifecycle, as well as the other way around. A common interface between applications and infrastructure was needed to ensure that the two lifecycles could evolve independently.

Additionally, we needed to ensure that the platform would be cloud-agnostic and would allow applications to be deployed and managed across multiple clouds. This would allow us to take advantage of the best features of each cloud provider, and to avoid vendor lock-in, while complying with regulatory requirements.

Finally, a large Terraform code base already existed for infrastructure lifecycle automation, and we needed to find a way to leverage that code base while ensuring that the infrastructure lifecycle was aligned with the application lifecycle.

From 8 days to 8 minutes at Millennium bcp

Prior to leveraging Radius, we decided that it was critical to build a platform that would allow developers to focus on their applications, while allowing infrastructure teams to focus on the underlying infrastructure. Our goal was to improve from days of work to just minutes when deploying an application across all environments. This includes the ability to deploy across multiple clouds, meeting the cloud-agnostic requirements of the bank. This platform is based on a set of application patterns, supported by an internal software framework that generates a clear definition of the application and its infrastructure requirements. These patterns, or abstractions, allow Millennium bcp to make application definitions and lifecycles first-class entities in the IT landscape.

By having known patterns and contracts, the bank can provide a self-service experience to developers, allowing them to focus on their applications and not on the underlying infrastructure. This self-service experience is also available to infrastructure teams, who can now focus on the infrastructure and not on application details.

Our original platform

In the first design of our platform, we decided to use a mix of current and new technologies to support our initial use cases, focusing on targeting the most commonly used resource types by container-based applications:

The developer story

In this version, application developers use a Backstage-based portal to define their applications and their infrastructure requirements. Developers select from well-known patterns the one that applies to their task, along with a set of options and dependencies to be provided to the application. These can range from a simple database in any of the available database engines, to caching mechanisms, messaging resources, identity and observability resources. In any of these resource types only IT business related variables exist (such as the SKU), with all implementation details hidden from developers and handled by the platform.

Developers can select from pre-defined patterns the one that meets their needs

Only business-related configuration is exposed to developers, instead of the underlying implementation

In about 3 minutes, the initial setup for an application is ready, including the setup of Azure DevOps resources (teams, projects, repos, pipelines, etc.) and the initial code commit. Within the repo is a JSON file that describes the application, including the previously selected infrastructure dependencies.

Developers can, at any time, change the application infrastructure requirements by changing this JSON file and commit it to the git repo. Focusing on this application abstraction, developers do not concern themselves with wiring up the application to the infrastructure dependencies, as that is always handled by the platform.

As CI/CD pipelines deliver the application to multiple target environments, that JSON file is converted to an Open Application Model representation and pushed to a git repo, triggering the infrastructure story when Flux delivers it to a Kubernetes cluster.

The infrastructure story

Upon delivery of the Application OAM resource to a cluster, KubeVela would, based on custom component and trait definitions by Millennium bcp, create the required resources to support the application. These resources are created either directly (Kubernetes objects), or leverage Crossplane compositions and Terraform modules. On successful creation of the infrastructure resources, KubeVela would then wire up the application to those resources by injecting environment variables into the application deployments. Infrastructure dependency updates follow the same path, with existing resource state being compared to the desired state, and any change being automatically implemented.

At this time, there was also a decision to start moving the existing Terraform code base that existed to Crossplane, so that a process of continuous drift detection and remediation could be implemented. This would allow us to ensure that the infrastructure was always in the desired state, and that any drift would be automatically corrected.

What we learned

This initial version of the platform allowed us to validate the concept of using a common language to define applications and their infrastructure requirements and the concept of using a common framework to generate the application code base. Adoption of the platform was also very positive, with developers being able to focus on their applications and not on the underlying infrastructure and achieving the performance goals initially set.

However, we also learned that the initial design had some challenges, namely:

Maintaining the Backstage-based portal was a challenge, as it required a lot of custom code to support the desired workflows within the Backstage framework.
Some design choices behind KubeVela did not align with our requirements, as we wanted this component to focus on infrastructure orchestration and choreography, rather than trying to address the entire application lifecycle with its own internal algorithms.
The number of moving parts was high, generating complexity and increased cognitive load to the teams involved in designing, implementing and maintaining the platform.

The role of the Radius project

We found our same vision in Radius, where challenges such as multi-cloud, architecture best practices, multiple release cadences for apps and infra, and cognitive overload are addressed using concepts like Recipes and Environments.

With Radius, infrastructure implementation details can be handled exclusively by internal infra product teams, exposing only IT business variables to our IT customers in Recipes, abstracting complexity, and ensuring design decisions are made by the right people. Developers can also focus on identifying what is relevant for their applications, without having to go into implementation concerns, knowing that those Recipes available to them have already taken care of those. This common contract correctly refocuses teams: developers focus exclusively on evolving the application and infrastructure teams can now manage infrastructure with a clear understanding of application dependencies. Also, a Radius environment is created for each internal product team’s target environment, providing the required isolation for each team and their workloads but also allowing for resource sharing within that team.

In this new approach, instead of our JSON application definition we leverage the Bicep language. Developers interact with Bicep application definitions using the rich set of available tooling and validation, providing a first-class application experience. For infrastructure management, Recipes allow our infra product team to leverage our existing Terraform and Crossplane codebase. Radius extender resources plus Recipes meet us where we are today by supporting any resource type, even our custom resources that are not yet supported natively in Radius.

Radius becomes our main infrastructure orchestration and choreography tool, with the ability to target multiple cloud (and on-premises) providers through multiple infrastructure implementation patterns for the same infrastructure resource types, allowing us to bind multiple release cadences for applications and infrastructure in an agile and well-governed way.

While Radius does not yet support a GitOps approach, we are working together with the Radius maintainers and community to make this a supported scenario. Until that is available, the Radius CLI is used from CI/CD pipelines to deploy infrastructure requirements to the target environments.

Moving forward

As our Radius adoption journey continues, we are looking forward to continue leveraging Radius to support our application development and deployment needs. There are interesting challenges ahead, such as supporting additional resource types and decoupling resource management control planes from clusters running business workloads. We are looking forward to working with the Radius maintainers and community in the monthly community calls and in Discord to address those challenges.

Posts: Introducing Radius, a new open-source application platform for cloud-native apps

Wed, 18 Oct 2023 00:00:00 +0000

Developers and IT operators today know all too well the pain involved with deploying, managing, and making sense of applications in an ever-evolving and increasingly complicated cloud-native landscape. While it’s true that advancements in cloud infrastructure and platforms like Kubernetes have been gamechangers for developing flexible, scalable, and portable microservice applications, they have also made things more challenging for developers and operators alike. For developers, the complexity of managing infrastructure and lack of visibility into the resources that make up their applications are major roadblocks for productivity. For operators, the lack of standardization and automation in the deployment process can lead to loss of control over the infrastructure, and degradation of confidence in the applications that are deployed. At the end of the day, development teams are left with a disjointed experience between platforms and cloud providers. Developers and operators alike find themselves struggling to make sense of how their application comes together across disparate sets of tools that provide little more than a list of their deployed artifacts.

Applications are, of course, so much more than just Kubernetes and flat lists of resources. The Microsoft Azure Incubations team is excited to announce a new open application platform called Radius that places the application at the center of every stage of development—redefining how applications are built, managed, and understood. With features like Recipes and Connections that standardize deployments and automate resource provisioning, Radius provides a centralized toolset for developer and operator teams to effectively collaborate. And because the relationships between resources are inherently captured in application authoring and deployment activities, Radius enables a comprehensive view into an organization’s architecture via its application graph data. Furthermore, Radius is open-source and multi-cloud from the start, allowing for applications that can be written once and, using the same toolset and workflows, deployed to any cloud or on-premises infrastructure. To get started or learn more about Radius, visit radapp.io, join the discussions on Discord, or dial into an upcoming community meeting.

A single tool to describe, deploy, and manage your entire application

Radius is focused on solving platform engineering challenges involved in supporting application deployments across on-premises infrastructure and cloud providers like Microsoft Azure and Amazon Web Services. Meeting developers and operators where they are today, Radius offers built-in support for some of the most popular app development tools like Dapr, and infrastructure as code (IaC) languages like Terraform and Bicep. Designed to fit into, rather than disrupt, existing development tasks and CI/CD pipelines, Radius works to help developers better understand all the components that comprise their applications and takes care of platform configurations like permissions, connection strings, and more to simplify their tasks. As a result, operators can ensure that all applications are deployed in compliance with organizational policies, then use Radius to manage the application and its resources.

Radius features available in this first open-source release

In this first release, the focus is on the features that are most foundational to the Radius platform and its goals of improving the productivity of application development workflows. These include:

Simplified and consistent application development experience: Deploy to any cloud provider or on-premises using the same application definition, all with a consistent set of tooling and experience. These include capabilities to automate resource access and provisioning, as well as the ability to configure environments that meet the needs of each phase of development.
Recipes and environments: Standardize and scale deployments with clear separation of concerns between developers and operators. Radius Recipes are pre-definable templates that automate the provisioning of infrastructure resources and environment configurations that can be designed to adhere to cost, security, and compliance standards.
Application graph: Gain visibility into the resources and relationships that make up an application. Radius captures the relationships between resources in an application as a part of the development activities, which can in turn be queried and understood.

Consistent experience across platforms, cloud providers, and on-premises

To meet the growing business and technical needs for multi-cloud architectures, applications defined and managed with Radius can be deployed and run on any cloud using the same set of tools, meaning that the application code, definitions, and development workflows remain consistent. Agnostic to whether the application is deployed to Azure, AWS, or on-premises the authoring, deployment, and management experience remains the same. Furthermore, Radius makes it easy to connect and leverage many popular services such as Redis, Mongo, Dapr, and SQL, with more to be added as the needs and requirements of the community grows.

For example, imagine an application that leverages a SQL database. When running locally, the developer may want to use a SQL container and when running in production, operators may want to enforce the use of high-throughput databases. With Radius, developers can model a SQL resource in their app and use its connection string during their development and testing stages. When it comes time to deploy in production, developers can swap their application resources by changing just their app definition connections to services like Azure SQL DB or AWS RDS that have been pre-configured by operators. In other words, changing the backing infrastructure for an application in Radius no longer requires app code or configuration changes.

Automate environment configurations and resource provisioning with Recipes

Collaboration between developers and operators today requires detailed coordination, resulting in back-and-forth manual processes that slow down development velocity. Most organizations have resorted to building custom pipelines or ticketing systems for infrastructure deployments, but these only ease part of the pain without addressing the core need for manual processes. This is where Radius Recipes adds new value: operators are able to configure IaC templates (Terraform modules and Bicep files) that developers can use for self-service resource provisioning and deployments. Recipes also allow operators to define and enforce corporate policies, such as which cloud resources can be used, how they are configured, and who can deploy them. This means that developers no longer need to worry about the details involved in deploying appropriate infrastructure when building out their applications, allowing them to focus on writing application code.

For example, an operator can define a Recipe that deploys a Redis cache that meets the production requirements of their organization: minimum of two nodes and a minimum of two replicas. The operator can also specify that the Redis cache must be deployed to a specific region and be pre-configured with the correct connection string and necessary credentials. Once the Recipe is defined, developers can use it to deploy a Redis cache without having to worry about the details of how to deploy it, or whether it is configured correctly. This separation of concerns enables operator teams to scale their support for developer teams, while ensuring that applications are deployed in compliance with organizational policies.

Manage infrastructure leveraging the Radius application graph

One of the biggest challenges of managing cloud-native applications is ensuring that the cloud infrastructure used by applications meets cost, operations, and security requirements. However, IT operators are often in the dark when it comes to having a clear and accurate representation of the deployed application resources, limiting their ability to effectively manage their corporate infrastructure. Radius introduces an application structure that includes environments, resource groups, and connections, resulting in an application graph that shows precisely how the application and its infrastructure are interconnected, enabling teams that support developers to build views and intuitively understand what makes up an app. Furthermore, Radius integrates with popular infrastructure tools like Terraform, and existing CI/CD systems like GitHub Actions to provide a seamless operator experience.

Learn more and contribute

Fully committed to achieving industry-wide impact via open-source, the maintainers are in the process of submitting Radius as a new project to the Cloud Native Computing Foundation (CNCF). Enterprises like Microsoft, BlackRock, Comcast, and Millennium BCP have already been working together to ensure Radius evolves along with the broader cloud native community. The Radius maintainers are excited to continue collaborating with the open-source community to grow its feature set and welcome all contributions from the community.

We’re looking for people to join us! To get started with Radius today, please see:

Learn more from the documentation.
Explore the open-source code repositories.
Engage with the community.