Within the software systems, most often than not we wanted to spin up some temporary services or jobs that can be terminated as soon as it performed a specific task. For example, if we want to send out user notifications everyday morning, then we don't want that service to be running all day long, rather a service can spin up at a specific time, perform the task, and shutdown thereby effectively saving resources & cost.

As with any other long-running services, these ephemeral (or in Kubernetes term Batch or Cron) Jobs also needs to be monitored to gather critical metrics and for Altering when something goes wrong. …

At the beginning of last year, I wrote an article titled How to secure and manage secrets using Google Cloud KMS, explaining how we can use Google Cloud KMS (Key Management System) to encrypt secrets and securely use it in our applications.

I mentioned it is a decent approach because of the lack of support for good secret management solutions within the Google cloud ecosystem. It is kind of, a hacky way to get the job done, because,

• it requires a lot of code setup
• had to keep the encrypted version within version control
• no easy way to manage these secrets (like a console…

Welcome to another article on Google Cloud Platform. If you are building services using GCP then you might already know the several limitations that come with it. One of them being a lack of support for gRPC in their easy to use solutions such as Google AppEngine (Standard and Flexible), Cloud Functions or in the initial days of Cloud Run.

So if we need to support or have our own gRPC services then we need to use either Google Compute Engine or Google Kubernetes Engine, which is not an easy solution for several small use cases.

An alternate question would be why gRPC? and what benefits does it offer over REST?

If you are new to gRPC, then I highly recommend giving a readout, https://grpc.io. …

“Password” this crazy piece of string worth a lot, get a lot of attention but yet very hard to process & hide. Even with the multi-factor approach, it is crucial to design the first step right (which is what the user knows).

It becomes increasingly harder for the software systems to securely authenticate their users, process the sensitive password in a right & secure way. One of the most common approaches is,

Password-Hashing:

Storing the hashed version of the password using algorithms like Argon2, bcrypt, etc and use it for authenticating the users. By now, this is the minimum baseline for handling sensitive secrets like password, anything below this (like as plain-text or encoded) means you are probably doing the bad thing, stop it, go back to safety!. …

For a successful business, it is important to know who your customers are. Knowing your customers helps to understand your business better, build better versions of your ideas, and can make effective decisions for the successful long run. Everyone knows it right!

When it comes to software infrastructure, it remains important. Knowing your customers greatly improves the performance of your application, makes it more resilient, after all, no one likes to wait for the response :)

Okay getting to the point, if your services are being used by a wide range of audiences across the globe, but your servers are located within a single region, then your users from other parts of the world are going to experience high latency resulting in bad user experience. …

With the increasing number of adoption towards service-oriented architecture and for better integrations with external systems, it became a necessity to write Restful APIs for our services. While building so we might often find several challenges such as,

• Standard & Consistent API design
• Better documentation
• Client Libraries
• Playground (better developer experience)

So while writing APIs, we have to make sure it sticks to a standard design principle, update documentation (hosted elsewhere) and finally write client libraries (harder if you have to support multiple languages). Doing all of this manually is a painful job.

Likely we have OpenAPI Specification (formerly known as swagger), which offers us a standard, language-agnostic interface to write RESTful APIs which allows both humans and computers to understand the service capabilities. …

Hello there! If you are using AppEngine for hosting your application, then you will be using one or more of their infrastructure services like Datastore, Memcache, TaskQueues, UserService, etc.

And you will be needing to write unit tests to make sure your application functionality is working as expected with these services. For that, you need to set up some configurations to test these services in your local environment.

If you are new to AppEngine service testing, then Google has great documentation on how to set up this configuration with sample codes. Take a look at Local Unit Testing for Java.

For example, here is a sample code from Google to perform datastore…

Let’s jump right in. We all know it’s a bad idea to store application secrets within our code. So why we are storing there it still? Let’s take an example.

We could store those secrets in a file and add it to the gitignore so it’s not added to version control. But there are a couple of hurdles:

• How do we manage those secrets?
• What happens when the local copy is deleted?
• How do we share it with other developers?
• How do we manage versioning of those secrets during changes and an audit log of who changed what?

A lot of questions! So we end up storing it within the code since it’s too much complexity to deal with. …