With a difficult year 2020, companies are more focused on what they spend, and, because the cloud becomes bigger and bigger every year in companies, the cloud billing is getting a lot of interest.
For all the companies, the ideal model is to pay only what they use; and not more. The serverless products perfectly fit this expectation.
However, some services can’t adopt this model, especially for technical reason. Relational databases for example are liked for their low latency achieved thank to, at least, 2 factors
Routing and load balancing are the pillars of the Internet and its scalability. On Google Cloud, these aspects are great due to a global networks and anycast IP deployed on Global HTTPS load balancers.
Like the other cloud services, serverless compute products (App Engine, Cloud Functions and Cloud Run) have been getting the load balancing capacity few month ago.
One of the most interesting load balancing feature is the capacity to route the traffic from the Load Balancer to the deployed services the closest to the user location. And thus to have the best latency, wherever the users are.
The data are the new goldmine of all companies, and this treasure must be kept secure and protected. That’s why, for many years, a common good practice of any database administrator is to remove all public access to the database, especially the public IP, and to grant only access from the private IP.
This “golden” rule is enforced by all security teams and they requires the same pattern for any cloud deployment.
Cloud SQL service, the managed database service on Google Cloud, allows you to:
Serverless paradigm, in its ultimate design, allows to pay only when you use the service. With Cloud Run, you pay only with a request is being processed. The rest of the time, you pay nothing. It’s the same with other services such as Cloud Functions, App Engine (standard), or even on other clouds Azure Functions or AWS Lambda.
To make this possible and sustainable, Cloud providers need to save the resources when the service is idle, and thus to stop the idle instances and, therefore, to scale down to 0.
From 0, when a new request comes in, your app need to be loaded on an instance, started/initialized, and then ready to serve the traffic. …
Container packaging is very popular today: it allows a full customization of the execution environment and is language agnostic. More and more applications use it.
So now, to validate the production environment behavior, the developers need to test the containers, not only the workload with unit tests.
In some cases, the containerized app can required to access to Google Cloud API and thus, to be authenticated. When deployed on Google Cloud services, metadata server is reachable and provides the Application Default Credentials (ADC).
How to get authenticated locally with ADC for testing?
By definition, the container run in an isolated environment. That means that your local configuration isn’t known from inside the container, and thus your credentials aren’t…
CSV (Comma Separated Value) format is one of the most common text file format to share structured data and easily readable by humans, any software such as Google Sheet and Microsoft Excel, or by database engine such as MySQL, PostgreSql or BigQuery.
However, the popularity of this format leads to use it for large volume of data being difficult to manage locally and to load them into a software or a local database. Therefore, some basic operations become impossible to perform manually and quickly by keeping the CSV format:
IAM (Identity and Access Management) is a pillar of Google Cloud. It authenticates and authorizes accounts (user account or service account) to access to resources. I already mentioned some limitations of this service, especially when you want to avoid the service account key file usage, and thus to avoid major security risks.
To help on this, Google Cloud has introduced a new API: Service Account Credentials API. Actually, not really new (release in June 2018 in Beta), but poorly known or understood. However, it can help in 2 typical use cases.
id_tokenwithout metadata server (locally for example)
Cloud Run is a serverless product that allows to serve containers at scale. The team is very active, and since the Beta release (in April 2019), the number of new features is impressive! Among them, the configurable number of CPUs.
A one or two-CPU configuration is now available and 4 are coming soon.
But, does more CPUs mean better performance?
To evaluate the CPU efficiency, we can’t use millisecond, or microsecond endpoint, it will be too difficult to compare, the metrics not enough sharp and the standard deviation too important. …
The security is paramount in cloud environments and IAM (Identity and Access Management) service helps on any cloud provider (you can find IAM service on Azure, AWS and GCP for example).
On Google Cloud, this IAM service uses OAuth and OpenID protocols. It allows to authenticate and to authorize the account (user account or service account).
The authorization is performed only for Google Cloud components; you can’t add your custom authorization/permissions for your own app in IAM service.
The authentication part uses OAuth protocols to generate a credential. …
On Google Cloud, PubSub is the event message queuing platform. Serverless, global, high throughput (up to 1 millions of message per seconds), affordable, customizable retries, PubSub is one of pillars of all applications on Google Cloud.
You can use PubSub as an event bus in your architecture and asynchronously trigger different other serverless services, such as Cloud Run, Cloud Function or App Engine. You can also consume these events in streaming with Dataflow.
There is a Youtube video series on PubSub that explains the core behavior