Hello there, hope you’re doing good. Usually, I write technical content related to software engineering, programming and best practices. But this time I would like to share my personal experience with something different, something that everyone deals with every day, Money and Investments 💰. This is not the money lesson kind of thing, Am no expert in this space, just sharing my experience and findings on various investment options being in a new country.
Although the title says the Netherlands the concepts we talk here are common and most of the platforms are available in several other countries.
A little bit of background, am a software engineer and I am from India. Last year I relocated to the Netherlands due to work. I like Personal finance & money management, after all, it's our hard-earned money, then why not put in an extra effort to properly manage it. It's not the money that attracts me (well you know am lying :), let's say not just the only reason), rather the work & effort we put in, it's like a puzzle or game (a real one), and the joy of learning & finding solutions for it. As a software engineer, I find it quite similar to solving business & code challenges. …
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,
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.
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,
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,
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:
A lot of questions! So we end up storing it within the code since it’s too much complexity to deal with. …
In the previous story Dynamic AppEngine Configurations using Gradle Part 1, we discussed how we can easily deploy to various environments like (prod, stag, test) using simple gradle argument. If you haven’t read before, would recommend to read it before proceeding.
These configuration files control optional features that apply to all the services in an application:
queue.xml (task processing)
In order to have different configurations for each environment, we are going to create one folder called gaeconfigs in the root folder, and under which create one folder per environment, like…