Jump to Content
Serverless

Nasdaq’s Metrio team innovates with serverless on Cloud Run

May 23, 2023
https://storage.googleapis.com/gweb-cloudblog-publish/images/finserve_2022_OvLe6x5.max-2500x2500.jpg
Philippe Tremblay

Director of Software Engineering, Nasdaq

Nasdaq is committed to helping our customers efficiently measure, monitor and report on their sustainability performance. In 2022, Nasdaq acquired Metrio, a platform that allows companies to report on their environmental, social and governance (ESG) performance. This platform collects, measures and analyzes corporate sustainability data in real time and generates investor-grade reports designed to be shared strategically and cost-effectively with stakeholders such as ESG Raters, Rankers, Frameworks, Regulators, etc. Nasdaq’s Metrio customers are asked to monitor all dimensions of their sustainability impact including environmental performance (water, energy, emissions), social performance (diversity, corporate philanthropy, volunteering) and governance (governance process and strategy, employees participating in ethics training). This data often comes in disparate sources and formats. Metrio’s ESG reporting platform allows companies to precisely collect, quantify and create investor grade reports on this data that satisfy all frameworks, standards and ratings.

The challenge

We migrated to Google Cloud from a previous stack that included Ruby on Rails on VMs on a different cloud vendor. This architecture was hard to scale because everything was collocated on the same machine. We were looking for a reliable new cloud provider that would allow us to scale in the long run. Our previous cloud provider had an outage that affected our services for an extended period of time, which motivated our migration to Google Cloud for its global coverage, scalability, security and high availability. 

We chose Cloud Run, Google’s serverless compute platform, to fully power Nasdaq’s Metrio sustainability reporting software. Cloud Run allows us to run stateless containers that automatically scale up and down based on demand. This means we only pay for resources when we are serving requests, and we do not have to worry about auto-scaling policies or managing infrastructure. 

As a team, we want to operate with a focus on developer productivity to avoid the burden of managing operations whenever possible. Cloud Run is fully managed, so it removes the burden of patching Kubernetes versions and operating system versions, allowing us to focus on delivering value more rapidly to our customers. Its ease of use and deployment speed also enabled us to create new products as we migrated from the old infrastructure provider to Cloud Run. 

A few of our team members have a Kubernetes background, and we love being able to leverage Kubernetes features on Cloud Run without having to manage nodes or clusters. We have a start-up mentality with ambitious deadlines and product vision. We really enjoy focusing on development, rather than managing Kubernetes resources. Most of our colleagues didn’t have existing container knowledge, and Cloud Run made ramp-up extremely easy. We feel secure knowing that, if Cloud Run isn’t a fit for a workload, we can easily shift to GKE and have the services be interpretable. Before Cloud Run, we would release code a few times per month. Now, we can release multiple times a day, making it a lot easier to spin up sandbox and demo instances for fast product iteration.

Our vision for our cloud transformation was to separate databases from compute, so that storage performance and capacity can be scaled independently from compute. This database segregation also helps us achieve SOC2 certification. At the crossroads of finance and technology, Nasdaq must ensure that data storage takes place in a system built with security in mind, which is further enabled by our new architecture. We leverage Cloud Run as our compute layer, and MongoDB for our legacy data, while also looking to leverage Cloud SQL and AlloyDB for new services. Now, each customer has its own compute resources. We leverage six Cloud Run services per customer and have over 800+ Cloud Run services in production. Our key services include a data transformation tool, custom metrics for each customer and a presentation tool where customers can customize dashboards. 

Transforming our data ingestion tool


https://storage.googleapis.com/gweb-cloudblog-publish/images/1_Nasdaq_Metrio.max-900x900.png

Our data transformation tool powers services for over 120+ businesses, helping businesses keep their data clean and auditable with an edit history and activity log. We allow a wide range of data importing options, including via templates, scripts and APIs. This data can come from various sources, including water consumption, waste disposal, HR and electricity consumption. As our application grew, the need to upload and support download of large files became the biggest blocker for our largest customers. Our customers wanted the ability to upload large data files, including those that have a payload of 32 MB or more. 

Our original architecture used HTTP1 which had a limitation of a 32MB size limit. We needed a way to move to HTTP2 without having to refactor our code. Incoming requests from this application come in through a custom proxy server written in JavaScript. This is required for other parts of the application to serve dynamic pages. 

Now that Cloud Run supports multiple containers, we were able to implement a sidecar pattern with Envoy in front of our frontend server component to manage traffic between our microservices in a flexible and scalable way. Envoy is a high-performance open source edge and service proxy that can be used to manage traffic between microservices. Envoy relays what needs to be chunk encoded or HTTP/2 to the frontend services. By deploying Envoy as a sidecar container alongside the main application container we were able to simplify our management of microservices.

https://storage.googleapis.com/gweb-cloudblog-publish/images/2_Nasdaq_Metrio.max-1500x1500.png

To minimize code change in both our code bases (frontend and backend), we leveraged Envoy to rewrite incoming HTTP2 requests to HTTP1 and forward them directly to our backend service. The experiment was successful, and we were able to redirect incoming HTTP2 traffic to our backend service in HTTP 1. This approach allowed our customers to upload payloads greater than 32MB, giving them flexibility in the size of data they want to bring into our platform. This architecture also helps power our presentation tool, where customers often want to export their web pages in pdf format, for exports greater than 32MB. This has elevated the ability of our biggest customers to upload data, see it in interactive dashboards, and download the data to share with important stakeholders. This change has enabled us to onboard even larger customers. 

Future use cases 

Support for sidecars in Cloud Run unlocks service communication between GKE and Cloud Run. In Cloud Run, we really love that you can create a service account for each service and then grant the invoker to the front end service account to the backend resource. This pattern gives us secure communication channels between services so that we can adhere to the strict compliance standards of financial services. We intend to leverage sidecars to secure communication between our future GKE workloads and Cloud Run. 

The second use case we are planning is around Open Telemetry, an open source observability platform. We use Open Telemetry as a backend service and plan to instrument Cloud Run applications with a collector sidecar. This service will inject data from the workloads directly to Cloud Trace without extra hops to GKE. With this approach, we are also looking at using sidecars to write custom metrics to Cloud Monitoring. The collector sidecar can collect and forward metrics, logs and traces from other containers and services, which can be used for performance analysis, troubleshooting, and capacity planning. 

Metrio’s adoption of Cloud Run for its sustainability reporting software has resulted in numerous benefits, including improved deployment speed, simplified management of microservices and greater scalability. The use of Cloud Run has enabled us to focus on delivering value to customers rather than managing infrastructure, increasing the time it takes us to create new products. Our customers, such as Graphic Packaging, have benefited from our software to work more efficiently and create dynamic reports populated by real-time data. With its innovative roadmap, Cloud Run has become a game changer for our services while helping our customers meet their sustainability goals. Looking forward, we are excited about the potential of sidecar support and the roadmap evolution of Cloud Run.

Posted in