Editor’s note: In today’s guest post we hear from SAP about their application modernization journey towards a serverless application architecture with Cloud Run. SAP developers partnered with Google Cloud Professional Services to migrate App Engine workloads to Cloud Run in just three weeks by focusing on small but efficient changes to the application, achieving remarkable cost savings.
SAP is a global market leader in enterprise application software with nearly 110,000 employees. As a tech and data driven company, we use Google Cloud to run a variety of our internal applications. Our application stores and processes approximately 250,000 files per day, which are produced and uploaded by SAPs CI/CD pipelines. Core services such as Google Cloud Storage and Google Pub/Sub helped us achieve this with minimum effort on our infrastructure. We started providing our microservices using Google App Engine in 2019. What’s more, we especially appreciated the beauty, efficiency, and simplicity of App Engine, which allowed us to focus on our code and business logic instead of managing servers.
As part of the migration initiative to consolidate Google Cloud workloads, projects and resources to specific regions, we re-evaluated App Engine as our platform for microservices-based applications. Since App Engine is tied to the Google Cloud project and region, we thought about making a strategic move to Google Cloud Run. This had the advantage of avoiding creating a whole new Google Cloud project just to use App Engine in a new region. In addition, Cloud Run retains the serverless value proposition of App Engine, with the added flexibility of containers plus our event-driven architecture, which perfectly fit together with this serverless approach. Our application traffic varies and can have high peaks but can also be near zero. The flexible scalability of Cloud Run helped us serve the traffic while keeping costs low, since it is able to scale down to complete idle.
With Cloud Run’s source-based deployment approach using Google Cloud’s buildpacks, we did not have to define container manifests or build containers ourselves. The buildpacks can automatically detect the language of our source code and transform it into an executable container image that can run on any container platform. The main changes to get our microservices up and running on Cloud Run, involved adjusting the deployment steps in our pipelines — code changes were not needed.
For a smooth migration, we registered a custom domain and leveraged a Google Cloud HTTP load balancer, with a Google-managed SSL certificate. The load balancer initially was pointing to App Engine services and we could easily switch them one by one to Cloud Run, by updating the URL maps without any impact to our API consumers and end-users.
All this has brought us to the point where today we are completely built on open standards.
Each of our eight microservices faced different infrastructure and scaling requirements and Cloud Run allows us to set suitable configurations for each service individually. It was easy to move the application, especially as we were able to leverage our existing pull integrations with Cloud Pub/Sub for the time being.
For all the above reasons, our small team was able to implement this and bring it to production in just four to five weeks. Cloud Run’s more granular billing model helped SAP to save 70% on compute costs for our application. This was directly visible after migration (see visualization above).
With the support of Google Cloud Professional Services, we were able to achieve this without additional resources while all our services continued to work smoothly.
Adopting Cloud Run and moving away from App Engine was a successful step in our journey of maintaining a state-of-the-art event-driven architecture. Cloud Run’s simplicity and source-based deployment option made this transition remarkably smooth, while the cost savings achieved made it an even greater success.
By: Matthias Scudlik (Associate Development Architect, SAP SE) and Mert Safter (Senior Developer, SAP SE)
Source: Google Cloud Blog