When building the fact service, I showed how a relatively traditional application built with Java and Spring Boot can make use of Google-specific APIs and services. This is a great way to use Google Cloud if you are fully committed, for example, to a new startup building exclusively on Google Cloud. I also showed how using Spring Cloud GCP libraries that Spring abstracts means that you are not as tied to Google Cloud as you could be. This is the approach Google would encourage because it gives you the best experience on Google Cloud.
However, this is not the only way to use Google Cloud. It is not the only way to use any cloud platform. In some organizations, becoming committed to a cloud in this way can make leaders nervous about lock-in. The question, “What happens if we need to make a forced exit?” can come up. Perhaps Google Cloud suddenly doubles prices or has a major security breach that destroys trust or causes a government or regulator to restrict use. These scenarios are unlikely, but in some industries, they are risks that need to be considered.
You also saw that there are limitations in both Cloud Run and Cloud SQL regarding how they scale. For most applications, these limitations are not a problem. However, if you are building a new application that you expect to scale to millions of users globally, you may need to consider other options. Therefore, let’s assume a situation where an organization requires a cloud-agnostic approach and scaling beyond the limitations of Cloud Run and Cloud SQL. Consider how you can take the fact service and deploy it in a way that meets those requirements.
Requirements
Let’s look at the specific requirements for this scenario.
User Story
The user story for this requirement is shown in Figure 14-1.
Figure 14-1. Scaling user story
Elaborated Requirements
This example also has the following specific requirements:
- Avoid using any Google-specific APIs or services in code.
- There should be no changes to the code required to host the application on another cloud provider.
- The application should be able to run on any Kubernetes platform.
In this chapter, you will look at how you can take the fact service and host it in a way that is even more agnostic to the underlying cloud provider but still follows cloud native principles. This is a great way to calm nerves by building applications that can be deployed to multiple cloud providers or even on-premises if the emerging topic of “cloud repatriation” takes off.
