Google Kubernetes Engine (GKE) is a popular container orchestration platform that allows developers to deploy and manage containerized applications at scale. However, a recent security vulnerability has been discovered in GKE that could allow attackers to gain access to clusters and steal data or launch denial-of-service attacks.

The vulnerability is caused by a misunderstanding about the system:authenticated group, which includes any Google account with a valid login. This group can be assigned overly permissive roles, such as cluster-admin, which gives attackers full control over a GKE cluster.

AWS Lambda and Google Cloud Run are both serverless computing platforms that allow you to run code without provisioning or managing servers. However, there are some key differences between the two platforms:

• Supported languages: AWS Lambda supports a wide range of programming languages including Node.js, Java, Python, Go, Ruby, and C#. Cloud Run supports Docker images, which can be written in any language.
• Cold start: When a Lambda function is first invoked, it takes a few milliseconds to start up. This is known as a cold start. Cloud Run also has a cold start, but it is typically shorter than Lambda’s.
• Concurrency: Lambda functions are limited to a maximum of 100 concurrent executions. Cloud Run has no such limit, so you can scale your applications more easily.
• Pricing: AWS Lambda charges you based on the amount of memory your function uses and the number of times it is invoked. Cloud Run charges you based on the amount of CPU and memory your container uses.

I recommend trying both and seeing which one works better for you.

Serverless

Serverless is great. You create your services and hand them over to AWS Lambda/GCP Cloud Run/Azure Functions and let them rip. Your system can scale up to hundreds of instances and quickly service your clients. However, you must consider

• how will your downstream clients respond to such peaks in volume? Will they be able to cope?
• how must will auto-scaling cost?
• how portable is your code between serverless platforms?
• how will you handle bugs in the serverless platform? You can file a support ticket however this is unlikely to go down well with your users.

Since 2017 I’ve been involved in a wide variety of “cloud” projects and there’s some common myths I’ve observed.

Migrations are just containers

Change is hard and unless you’re working for a startup, most cloud transformations start as lift and shift exercises. Contracts have been signed and everyone has been sold the myth that all you need to do is “dockerise” your containers and away you go.

Unfortunately, most of the hyperscalers (cloud provider - GCP, AWS, Azure, etc) will dazzle you with the way they’ve been doing things for years and just tell you and will instruct you to “do as they say”. However, for most regulated institutions there’s far stricter governance around things like Disaster Recovery and Data locality. For example, on a recent project we discovered that a certain cloud provider had two data centres located less than 50 miles apart. This simply wasn’t good enough for the regulated entity, a natural disaster could easily wipe out both data centers. I was amazed.