Forem: Jonathan ES Lin

Managing background jobs with Cloud Tasks

Jonathan ES Lin — Tue, 23 Jun 2020 08:10:00 +0000

This post was originally posted on JonCloudGeek

Introduction
Overview
Relationship with App Engine
Targets
Create a queue
Configuring a queue
Rate-limit parameters
Retry parameters
Scheduling a task
Security
Cloud Tasks vs Cloud Pub/Sub
Cloud Tasks vs Cloud Scheduler
Summary

A queue.

In this blog post, I will give an overview of Cloud Tasks with the aim of enabling you to start using it in your own applications.

Introduction

Cloud Tasks is a fully managed service that allows you to execute, dispatch, and deliver a large number of distributed tasks. Use Cloud Tasks to perform work asynchronously outside of a user or service-to-service request cycle.

Well, that's a paraphrase of the documentation intro. What exactly is Cloud Tasks? In a nutshell, Cloud Tasks helps you manage queues of tasks that are performed outside a request cycle (in the background).

Cloud Tasks

Overview

A task is the encapsulation of information representing an independent piece of work that triggers a request to a handler to complete the task (handler is the code that runs on a certain endpoint target). The task remains in the queue which persists the task until the triggered handler completes with a successful status code. If the handler suffers from a failure or an error, the queue will retry the task again later (with backoff). It will also rate-limit the number of concurrent tasks that is simultaneously executed, hence saving your worker endpoint from certain "drowning" otherwise.

As a simple example, sending an email based on a user action should ideally be done asynchronously as a task, allowing you to return from the request more quickly, and ensuring that the email is actually sent in the event of a failure in the sender gateway.

You will first create and configure the queue, which is then managed by Cloud Tasks. Complexities associated with task management such as latency, server crashes, resource consumption limitations, and retry management is handled by Cloud Tasks.

Each task is made up of:

A unique name (generated for you by client SDKs, usually)
Configuration information (e.g. url, timeout, HTTP method)
(optional) Payload of data necessary to process the request. The payload is send in the request body, thus handlers that process tasks with payloads must use POST or PUT as the HTTML method.

Relationship with App Engine

Historically, Cloud Tasks had its origins in App Engine. Indeed, if you use the first generation App Engine standard environment, you should use Cloud Tasks via the App Engine Task Queue API (if you are new to App Engine standard you should use the second generation instead). All other users (second generation App Engine standard, App Engine flex, Compute Engine, Cloud Run, etc.) should use the Cloud Tasks API, which we are interested in.

At time of writing, Cloud Tasks requires you to have a project with App Engine configured. The App Engine app hosts the Cloud Task queues that are created (note that this "App Engine app" is really internal Google infrastructure that is somewhat coupled with App Engine, but you can disable App Engine in your project). Particularly, the App Engine app is located in a specific region which serves the location of your queues in Cloud Tasks. Hence, you should give some thought to where your App Engine app is going to be, because once it is set for your project you cannot change it without creating another project. This limitation kinda sucks because it would be nice to just be able to spin up queues wherever I like, like how I can spin up a function in Cloud Functions in any supported region.

Note that, because of this, disabling App Engine in your project will cause Cloud Tasks to stop working, whether or not you use App Engine handlers or HTTP handlers (see next section).

Targets

A target.

The endpoints that process the tasks are called targets, where the handlers are defined. Cloud Tasks supports two types of targets:

(Generic) HTTP targets are hosted at any generic HTTP endpoint.
App Engine targets are hosted in a service on App Engine.

In both cases, all handlers must send a 2xx HTTP response code before a certain timeout. For HTTP targets, the deadline is 10 minutes by default (extendable to 30 minutes). For App Engine targets, the deadline depends on the scaling type of the service.

In this blog post, I will solely focus on HTTP targets, as it is the more generic and likely use case for most users.

Create a queue

Create a Cloud Tasks queue via the Cloud SDK:

gcloud tasks queues create [QUEUE_ID]

Use describe to inspect your queue:

gcloud tasks queues describe [QUEUE_ID]

The output should be something like:

name: projects/[PROJECT_ID]/locations/[LOCATION_ID]/queues/[QUEUE_ID]
 rateLimits:
   maxBurstSize: 100
   maxConcurrentDispatches: 1000
   maxDispatchesPerSecond: 500.0
 retryConfig:
   maxAttempts: 100
   maxBackoff: 3600s
   maxDoublings: 16
   minBackoff: 0.100s
 state: RUNNING

Note the available configuration above which we will explore below: maxBurstSize, maxConcurrentDispatches, maxDispatchedPerSecond, maxAttempts, maxBackoff, maxDoublings, and minBackoff.

Configuring a queue

There are three aspects to configuring your queues:

Rate limits allow you to define the maximum rate and maximum number of concurrent tasks that can be dispatched by a queue.
Retry parameters allow you to specify the maximum number of times to retry failed tasks, set a time limit for retry attempts, and control the interval between attempts.
Routing (App Engine targets only, not covered here)

Rate-limit parameters

Cloud Tasks uses the token bucket algorithm to enforce rate-limiting. In essence, we have a bucket that have a fixed capacity of tokens. A token represents a single unit added to the bucket at a fixed rate. Note that a token does not represent a task, it is just a token.

Conceptually:

A token is added to the bucket every 1/r seconds, at rate r.
The bucket can hold at the most b tokens. If a token arrives when the bucket is full, it is discarded.
When a task is scheduled, if there is at least 1 token in the bucket, a token is removed from the bucket, and the task is executed. If no tokens are available in the bucket, no tokens are removed from the bucket, and the task remains on the queue.

If multiple tasks are generated within a short time, the tasks are dispatched concurrently subject to token availability, up to the value set in maxConcurrentDispatches.

Therefore, we now have a better understanding of what we are configuring:

maxDispatchesPerSecond is the rate at which tokens are continuously added into the bucket. While related, is it not the rate at which tasks are dispatched (they are equivalent only if there is a relatively steady flow of tasks, or if there is a backlog in the queue).
maxConcurrentDispatches is the maximum number of tasks in the queue that can run at once (concurrency).
maxBurstSize is the bucket size. It is set automatically by Cloud Tasks API based on maxDispatchesPerSecond (you cannot change it). Cloud Tasks will set this to a number that ensures an efficient rate for managing bursts. It is possible to change this number manually by using a queue.yaml, but this is not generally recommended (see Using Queue Management versus queue.yaml for more information).

Use update to configure the above via Cloud SDK:

gcloud tasks queues update [QUEUE_ID] \
  --max-dispatches-per-second=[MAX_DISPATCHES_PER_SECOND] \
  --max-concurrent-dispatches=[MAX_CONCURRENT_DISPATCHES]

Retry parameters

If a task fails (e.g. handler timeout, handler error), Cloud Tasks will retry the task with exponential backoff according to the parameters shown below.

Unlike rate-limits, retry paramaters are more straightforward, so let's jump straight into it:

gcloud tasks queues update [QUEUE_ID] \
  --max-attempts=[MAX_ATTEMPTS] \
  --min-backoff=[MIN_BACKOFF] \
  --max-backoff=[MAX_BACKOFF] \
  --max-doublings=[MAX_DOUBLINGS] \
  --max-retry-duration=[MAX_RETRY_DURATION]

where:

MAX_ATTEMPTS is the maximum number of attempts for a task, including the first attempt. You can allow unlimited retries by setting this flag to unlimited.
MIN_BACKOFF is the minimum amount of time to wait between retry attempts. The value must be a string that ends in "s", such as 5s.
MAX_BACKOFF is the maximum amount of time to wait between retry attempts. The value must be a string that ends in "s", such as 5s.
MAX_DOUBLINGS is the maximum number of times that the interval between failed task retries will be doubled before the increase becomes constant.
MAX_RETRY_DURATION is the maximum amount of time for retrying a failed task. The value must be a string that ends in "s", such as 5s.

Scheduling a task

You would usually create a task using one of the Google Cloud Client Libraries from within your own server application.

Below is a code sample for Node.js (see Creating HTTP Target tasks for source and samples in other languages):

const { CloudTasksClient } = require('@google-cloud/tasks');

// Instantiates a client.
const client = new CloudTasksClient();

// Construct the fully qualified queue name.
// TODO(developer): Uncomment these lines and replace with your values.
// const project = 'my-project-id';
// const queue = 'my-queue';
// const location = 'us-central1';
const parent = client.queuePath(project, location, queue);

const task = {
  httpRequest: {
    httpMethod: 'POST',
    url: 'https://example.com/taskhandler', // Full URL path to task handler endpoint
  },
};

const payload = 'Hello World!'
task.httpRequest.body = Buffer.from(payload).toString('base64');

if (inSeconds) {
  // The time when the task is scheduled to be attempted.
  task.scheduleTime = {
    seconds: inSeconds + Date.now() / 1000,
  };
}

// Send create task request.
const request = {parent, task};
const [response] = await client.createTask(request);

Interestingly, you can schedule a task in the future with scheduleTime. Also, with dispatchDeadline you can change the default timeout for the task handler. See the documentation for more options.

Once a task is created, attempts will be made to call the task handler at the given URL. There is nothing special about the task handler, but it will have to anticipate the format of the request (JSON or otherwise?) in the request body (if present). In other words, it is just like any HTTP handler in your API.

The task name is not given explicitly here, so the client library will generate one for us. I did not test this out, but I expect that if I generated the task name myself, subsequent task creations with the same name will be deduplicated. This feature might be useful in your use case.

Security

The biggest security concern which I will address here is ensuring that no one else but Cloud Tasks is allowed to invoke the task handlers.

In the case of App Engine targets, this is easy. App Engine will set specific headers such as X-AppEngine-TaskName and X-AppEngine-QueueName, which are set internally and if an attacker tries to set it externally it will be removed by App Engine. If any of the headers are present in your task handler, you can trust that the request is a Cloud Tasks request.

In the case of HTTP targets, however, similar headers are also set by Cloud Tasks, but they are for information only and cannot be trusted as sources of identity. Instead, you need to validate an OIDC token provided by Cloud Tasks. This is out of the scope of this blog post for now; I may come back and update later.

Cloud Tasks vs Cloud Pub/Sub

Pub/Sub

Pub/Sub decouples publishers of events and subscribers to those events. Publishers do not need to know anything about their subscribers; the invocation is implicit.

Cloud Tasks is aimed at explicit invocation where the publisher retains full control of execution. Particularly, the publisher specifies and endpoint where the message is to be delivered.

In addition to this philosophical difference, Cloud Tasks provides the following mechanisms that aren't supported by Pub/Sub:

Scheduling specific delivery times
Delivery rate controls
Configurable retries
Access and management of individual tasks in a queue
Task/message creation deduplication

On the other hand, Pub/Sub allows for the following which are not supported by Cloud Tasks:

Batch insertion of messages
Multiple handlers per message
Max size of message is 10MB vs. 100KB in Cloud Tasks
No upper limit to the delivery rate vs. limit of 500 qps/queue in Cloud Tasks
Global availability vs. Regional availability in Cloud Tasks

See Choosing between Cloud Tasks and Pub/Sub for a more detailed comparison.

Cloud Tasks vs Cloud Scheduler

Cloud Scheduler

The main difference is that Cloud Scheduler initiates actions on a fixed periodic schedule (cron), which Cloud Tasks initiates actions from a queue, which is usually populated from a user or service request.

Cloud Scheduler does not retry a failed cron job, while Cloud Tasks retries a task until it succeeds.

I like to use Cloud Scheduler to trigger a periodic job that creates a bunch of tasks in Cloud Tasks in one go, delegating rate-limit, concurrency, and retry handling to Cloud Tasks.

See Cloud Tasks versus Cloud Scheduler for a more detailed comparison.

Summary

Cloud Tasks is GCP's fully managed solution for handling queues of background jobs (tasks). It provides rate-limiting and retry capabilities that are not present in Pub/Sub. Before reaching out for Pub/Sub you may want to consider if Cloud Tasks suits your application's use case better.

Cloud Tasks also provides a great alternative to third-party queues such as Resque or Sidekiq, if not better. Unlike these third-party queues, there are no workers or queues to manage; it is serverless apart from the task handlers which you will have to provide.

My GCP Books and Courses

If you found this blog post helpful, kindly check out my books and courses on GCP!

What is Anthos by Google Cloud?

Jonathan ES Lin — Mon, 08 Jun 2020 09:35:01 +0000

This post was originally posted on JonCloudGeek in Sep 2019. Details below may have changed in the meantime.

Introduction
Anthos Components
Technicals
Pricing
The Good
No new hardware necessary
On-Premises
Development and Operations
Security
The Bad
GKE vs Anthos Lines Blurred
Cloud Run on GKE is no more?
Binary Authorization, not available on GKE without Anthos?
A bad sign for GKE and GCP
Comparison with AWS and Azure offerings
Summary
Related Links

Anthos, the bridge between on-prem and Google Cloud.

Introduction

It's no secret that Google Cloud is still catching up with AWS and Azure in terms of market share. Anthos, first announced at Google Cloud Next in April 2019, is Google Cloud's gambit to gain market share in the enterprise.

Even as of this year, 80% of workloads are still on-premises. With Anthos, Google is hitting this need by giving enterprises a uniform interface that abstracts away the complexity of deploying to on-premises and/or in the cloud.

In other words, Anthos is Google Kubernetes Engine (GKE) deployed either on-premises or in the cloud (including third-party clouds like AWS and Azure). As far as enterprise developers are concerned, everything should be running on containers, and where these containers end up at (on-premises or cloud) is just a matter of configuration on Anthos. It brings enterprises toward the utopia of write once, run anywhere, without learning diffirent environments and APIs.

Anthos by Google Cloud

Anthos Components

Anthos is really a branding name for a collection of software components rather than a piece of software by itself. Collectively, the components work together to achieve the above. Let's take a look at the components that make up Anthos (according to their documentation):

GKE On-Prem. "GKE On-Prem is hybrid cloud software that brings Google Kubernetes Engine (GKE) to on-premises data centers. With GKE On-Prem, you can create, manage, and upgrade Kubernetes clusters in your on-prem environment and connect them to Google Cloud Platform Console." (https://cloud.google.com/gke-on-prem/docs/overview)
GKE. GKE is Google Cloud's managed Kubernetes offering. Given that Kubernetes originated from Google, GKE is arguably the best managed offering for Kubernetes out there.
Migrate for Anthos. "A tool to containerize existing applications to run on GKE." Basically a fancy name for scripts that help you generate Kubernetes yaml configs for your existing VMs.
Multi-cluster management overview. A lacklustre name to represent a collection of tools to connect between your GKE On-Prem with other clusters on the Google Cloud Platform.
Anthos Config Management. The one configuration to rule over Kubernetes clusters both on-premises and in the cloud.
Istio. "Istio is an open platform to connect, secure, control, and monitor microservices." (https://cloud.google.com/istio/docs/)
Stackdriver. Google Cloud's managed logging and monitoring solution.
Cloud Run. Deploy serverless containers. In the context of Anthos, you can deploy your serverless containers to GKE On-Prem or in the cloud.
Kubernetes apps on GCP Marketplace. You can even install Kubernetes containers found in GCP Marketplace to your GKE On-Prem.
Traffic Director. GCP's fully-managed traffic control plane for service meshes. This gives you an idea of what it does: "Traffic Director allows you to easily deploy global load balancing across clusters and VM instances in multiple regions and offload health checking from the sidecar proxies" (https://cloud.google.com/traffic-director/docs/traffic-director-concepts)

Technicals

GKE On-Prem requires a VMware vSphere environment, along with a layer 4 network load balancer.

As for site-to-site connection between on-premises and cloud, the options are either Cloud VPN, Dedicated Interconnect or Partner Interconnect.

Pricing

Here's where we get into the juicier parts of the discussion. The Anthos Pricing page redirects to "Contact sales". That implies $$$$.

However, in Anthos FAQ, we get an indication of the pricing:

Anthos will be available to enterprises via a term-based monthly subscription, entitling users to ongoing updates and security patches across hybrid environments.

Anthos can be purchased in blocks of 100 vCPUs requiring a minimum one year term (at $100 per vCPU/month). These vCPUs can be allocated in any combination across environments. Please contact sales for pricing.

The pricing listed above is in addition to core infrastructure charges including, but not limited to CPU, networking, infrastructure support, etc.

In other words, it starts from $10,000 per month.

There's a problem with that. I think that even the largest of Malaysian enterprises would not want to spend RM45,000/month on something like this. The target market for Anthos is not just enterprise, but enterprise with a big E, for which $10,000/month is pocket change. Think the likes of HSBC, which Google shows off as an early customer in the Anthos launch blog post.

The Good

The promise of Anthos sounds compelling, but I can't speak on behalf of Enterprise.

No new hardware necessary

Anthos is a software solution. Companies do not need to buy hardware from Google in order to leverage Anthos. They can start with their existing on-premises machines.

On-Premises

Writing once and running it anywhere you choose, here today, there tomorrow, and back here again the day after, is now possible with Anthos. Enterprises can plan out their timelines for gradual migration to the cloud, while maintaining the ability to keep workloads on-premises for compliance and other reasons.

And they can now do all this using the cutting-edge managed Kubernetes offering from Google, with Istio and other bells and whistles, while maintaining presence on-premises. It's an enterprise's dream, perhaps?

Development and Operations

Developers get to run GKE on-premises. Operations gets a single unified dashboard and configuration for their applications, not to mention a whole lot less work mitigating server problems given that Kubernetes is more robust and has self-healing and auto-scaling capabilities.

Security

Anthos Config Management allows centralized cluster configuration. Istio provides code-free securing of microservices.

The Bad

GKE vs Anthos Lines Blurred

Over the past few weeks the lines between what is GKE and what is Anthos have blurred. It seems that some parts of GKE have been absorbed into Anthos and placed behind the Anthos paywall, such as the examples shown below. I believe that at this stage, GCP is still trying to figure out the exact pricing of GKE add-ons for non-Anthos users, but it could also be the case that GCP effectively draws a strict line between vanilla GKE and Anthos-branded GKE add-ons, requiring payment to use the latter.

Cloud Run on GKE is no more?

What's the verdict now? Lay devs can't run Cloud Run in their own GKE cluster without an Anthos subscription? Not sure if many are affected, but the choice was nice to have, and now gone?
— Jonathan Lin 👨🏻‍💻🇲🇾 (@ernsheong) September 27, 2019

When Cloud Run was announced, it had an option in the Console to deploy to "Cloud Run on GKE". Today, it just says "Cloud Run for Anthos". Cloud Run is in Beta, so Google has the right to make such changes, but the trend seems to be making the add-on features of GKE a part of Anthos, which presumably requires a subscription of some sort (this is unclear in the documentation).

You must have Cloud Run for Anthos enabled in your cluster. Do I have to pay for that?

Binary Authorization, not available on GKE without Anthos?

With Binary Authorization, images are to be signed by trusted authorities during development, and these signatures are validated on deployment. This was touted as a security feature at a local Cloud Summit event recently. But it seems clear right now that this feature will only be part of an Anthos subscription:

The General Availability (GA) version of Binary Authorization is a feature of the Anthos platform. Use of Binary Authorization is included in the Anthos subscription. Please contact your sales representative to enroll in Anthos.

A bad sign for GKE and GCP

All these does not harbinger well for GKE itself. Google wants to reach out to the Enterprise, but it should not alienate non-Enterprise users who are already champions of GKE as the best managed Kubernetes offering. Granted, you can't really make everyone happy all the time, but taking away or limiting features from the vanilla GKE core is a bad taste that makes us think twice about recommended GKE to others.

GCP is treading dangerously. IMO, purely-GKE customers (no on-prem) should not be subject to the “Anthos tax”. Withholding features in Anthos from purely-GKE customers is a slippery slope that might backfire as people realize GKE itself is handicapped on purpose.
— Jonathan Lin 👨🏻‍💻🇲🇾 (@ernsheong) September 27, 2019

Comparison with AWS and Azure offerings

From what I gather, the VMware vSphere requirement plays well with existing setups on-premises. In other words, customers would not need to purchase new hardware in order to leverage Anthos.

In contrast, AWS Outposts and Azure Stack require you to purchase hardware from AWS or Azure in order to leverage their hybrid cloud solutions.

AWS Outposts FAQs:

Q: Can I reuse my existing servers in an Outpost?

A: No, AWS Outposts leverages AWS designed infrastructure, and is only supported on proprietary AWS hardware that is optimized for secure, high-performance, and reliable operations.

Azure Stack - How to Buy:

Azure Stack is sold as an integrated hardware system, with software pre-installed on validated hardware.

However, it seems that with AWS Outposts and Azure Stack you can use many more service offerings from AWS and Azure, whilst with Anthos you are limited to basically GKE On-Prem and GKE itself.

Summary

Anthos is Google Cloud's gambit to lure enterprises to use Google Cloud with a single consistent interface for application deployment to both on-premises or in the cloud. Google Cloud is betting that containers will be king in the enterprise world. If Google plays it right, the rewards via Anthos will be great, and Anthos has the potential to be the Trojan Horse of the cloud wars.

At the same time, with Anthos, Google Cloud risks alienating users of GKE by withholding Anthos-only features from GKE users. GKE is one of Google Cloud's strongest offerings. Google Cloud should not handicap GKE in other to hide features behind Anthos.

My GCP Books

If you found this blog post helpful, kindly check out my books on GCP topics!

What Cloud Native Is and Isn't

Jonathan ES Lin — Mon, 08 Jun 2020 08:36:59 +0000

This post was originally posted on JonCloudGeek

Introduction
Citizen-Country Analogy
Official definition?
What Cloud Native Isn't
What Cloud Native Is
What Cloud Native Infrastructure Is
What Cloud Native Applications Are
Summary
Related Links

High performance applications in the cloud.

Introduction

Cloud native is a phrase we are beginning to hear more and more in recent days. From a language standpoint, "cloud native" seems to imply that some applications do not fit very well in the cloud (like a tourist in a foreign land), while other cloud native applications are very much at home and thriving in the cloud (like a citizen of a country). In fact, cloud native applications (citizens) are most at home in cloud native infrastructures (countries).

Citizen-Country Analogy

Let's stretch this citizen-country analogy a bit further. There are many countries, and many citizens who, in most cases, belong to only one particular country. Not all countries are the same, though generally they share certain characteristics that make them a country: flag, immigration, government, shared culture/language. Likewise there are probably many ways to do cloud native infrastructure, and while there may be differences in implementation and details, they share the same distinctive set of characteristics and principles.

Secondly, a citizen of a particular country may visit another country and live there for many years. However, even after being in another country for a decade, that citizen would probably still say that he is more at home in his home country, and able to better take advantage of the benefits of citizenship that are bestowed to him at home. Likewise, a particular cloud native application is always written in such a way that the application is more at home and able to take fuller advantage of the infrastructure in a certain native infrastructure than in another infrastructure.

In essence, when we talk about cloud native, we need to address what it means for both infrastructure and applications to be cloud native.

Official definition?

There is actually a foundation called the Cloud Native Computing Foundation (CNCF) that champions cloud native technologies to "enable cloud portability without vendor lock-in" (CNCF FAQ). Its mission is "to make cloud native computing ubiquitous."

Cloud Native Computing Foundation (CNCF)

The CNCF Cloud Native Definition v*0 says (words in bold are mine for emphasis):

Cloud native technologies empower organizations to build and run scalable applications in modern, dynamic environments such as public, private, and hybrid clouds. Containers, service meshes, microservices, immutable infrastructure, and declarative APIs exemplify this approach.

These techniques enable loosely coupled systems that are resilient, manageable, and observable. Combined with robust automation, they allow engineers to make high-impact changes frequently and predictably with minimal toil.

The Cloud Native Computing Foundation seeks to drive adoption of this paradigm by fostering and sustaining an ecosystem of open source, vendor-neutral projects. We democratize state-of-the-art patterns to make these innovations accessible for everyone.

I think the "official definition" is helpful to us to clarify what cloud native is and isn't. Let's take a look at what traits are non-negotiable from this definition:

Non-negotiable: Scalable applications, public/private/hybrid clouds, loosely coupled systems, resilient & manageable & observable, automation, open-source & vendor-neutral
Negotiable: Containers, service meshes, microservices, immutable infrastructure, declaractive APIs (although these are "exemplary")

CNCF Platinum Members (Source: CNCF Website)

Many of the points that follow borrow heavily from many of the points made from Chapter 1 of the book, Cloud Native Infrastructure, by Kris Nova and Justin Garrison, which can be found here.

What Cloud Native Isn't

It is often instructive, when trying to understand a complex subject, to first start off by exploring what the subject isn't.

Cloud native isn't just about running applications in a public cloud. After all, you could simply "lift and shift" VMs from your own datacenter to EC2 or Compute Engine in the cloud (infrastructure-as-a-service), and virtually nothing was gained from it .
Cloud native is not about running applications in containers. For instance, running applications in containers per se (e.g. via docker run) is not really that much of a gain compared to running the application straight in the VM itself.
Cloud native doesn't mean you only run a container orchestrator, e.g. Kubernetes. After all, it is possible to use a container orchestrator in a way that is not intended, locking in applications to a specific set of servers. It is, however, a big step forward in the right direction.
Cloud native is not about microservices. While microservices have benefits such as allowing shorter development cycles on a smaller feature set, monolithic applications can also have the same benefits when done properly, and can also benefit from cloud native infrastructure.
Cloud native is not about infrastructure as code. Infrastructure as code, such as Ansible, Chef, and Puppet, automates infrastructure in a particular domain-specific language (DSL). However, using these tools often merely automate one server at a time, and do not actually manage applications better.

What Cloud Native Is

Since cloud native applications and cloud native infrastructure are separate but related concerns, I'll discuss them separately.

What Cloud Native Infrastructure Is

Cloud native infrastructure is hidden behind useful abstractions. There would not really be a "cloud" if all you get is access to bare metal APIs.
Cloud native infrastructure is controlled by APIs. As above, the abstractions are to be provided for via an API.
Cloud native infrastructure is managed by software. Cloud native infrastructure is not user-managed, it is self-managing by software.
Cloud native infrastructure is optimized for running applications. The chief aim of cloud native infrastructure is to run applications for the user.

In other words, cloud native infrastructure behaves very much like a platform-as-a-service (PaaS) offering.

While the CNCF would like to advocate for "open-source" and "vendor-neutral" solutions as its definition of cloud native (see above), I think that such a definition would preclude what many in industry already consider to be cloud native. Examples of this are AWS Lambda, AWS Elastic Container Service (ECS), AWS Fargate, which are all decidedly proprietary with no open source equivalents, but many still consider them to be cloud native. Hence I think the list is a good guiding principle on what is cloud native in general.

Kubernetes is the poster child of cloud native infrastructure which checks all the boxes above while being open-source and vendor neutral. However, we would be very wrong to conclude that Kubernetes is the only way to having a cloud native infrastructure. In fact, I would even dare to say that trying to manage your own Kubernetes is not in line with the principles of cloud native, because in many ways you are managing it yourself.

Kubernetes

What Cloud Native Applications Are

A cloud native application is designed to run on a cloud native infrastructure platform with the following four key traits:

Cloud native applications are resilient. Resiliency is achieved when failures are treated as the norm rather than something to be avoided. The application takes advantage of the dynamic nature of the platform and should be able to recover from failure.
Cloud native applications are agile. Agility allows the application to be deployed quickly with short iterations. Often this requires applications to be written as microservices rather than monoliths, but having microservices is not a requirement for cloud native applications.
Cloud native applications are operable. Operability concerns itself with the qualities of a system that make it work well over its lifetime, not just at deployment phase. An operable application is not only reliable from the end-user point of view, but also from the vantage of the operations team. Examples of operable software is one which operates without needing application restarts or server reboots, or hacks and workarounds that are required to keep the software running. Often this means that the application itself should expose a health check in order for the infrastructure it is running on to query the state of the application.
Cloud native applications are observable. Observability provides answers to questions about application state. Operators and engineers should not need to make conjectures about what is going on in the application. Application logging and metrics are key to making this happen.

The above list suggests that cloud native applications impact the infrastructure that would be necessary to run such applications. Many responsibilities that have been traditionally handled by infrastructure have moved into the application realm.

Summary

Cloud native is a loaded term which is easily misused by many marketing departments. Everyone claims that their infrastructure solutions are cloud native, but I believe that a guiding rule of thumb (in line with everything that has been mentioned above) is that being cloud native should enable your organization to leverage cloud infrastructure in a way that is cost-effective and resource-effective, that is to say, waste and spend as little (time, effort, and money) as possible while achieving more optimum and faster results, compared to the most optimal state and performance that today's technology allows; it is a continuum rather than a binary state. In my view, that is really what it means to be cloud native.

My GCP Books

If you found this blog post helpful, kindly check out my books on GCP topics!

Run a Postgres instance for cheap in Google Cloud

Jonathan ES Lin — Mon, 25 May 2020 10:42:55 +0000

This post was originally posted on JonCloudGeek.

Scenario
Get started
Create a compute instance running a Postgres container
Add a Firewall rule to connect to this instance
Migrate data to new DB
Summary
Disclaimer

Postgres in a container

In this blog post, I will explore running a Postgres instance in a container within Compute Engine for a fraction of what it costs to run in Cloud SQL.

Scenario

Cloud SQL is kind of expensive:

f1-micro gives you a weak instance with only 0.25 vCPU burstable to 1 vCPU, from $9.37.
g1-small is still 0.5 vCPU burstable to 1 vCPU, but the price jumps to from $27.25.
Let's not even talk about the non-shared vCPU standard instances.

For toy project or production projects that just don't need that power, Cloud SQL is overkill, at least the price is overkill.

This blog post is for smaller projects that need Postgres but without Cloud SQL, and without the maintenance hassle of running commands to manually install Postgres.

Get started

Sign up for Google Cloud. Free trial gives you $300 credits lasting one year.
Create a project to house your related resources.
Navigate to Compute Engine.

Create a compute instance running a Postgres container

In the Compute Engine instances page in the Cloud Console, click on Create.

Click Create
Select the E2 series and the e2-micro machine type. E2 series is a cost-optimized series of compute engine instances. Read more about it in the launch blog post. e2-micro is like f1-micro, but with 2 shared vCPU, which is good enough for almost any small project, but not compromising like the weak f1-micro (which hangs / throttles when you try to do too much CPU work).

The e2-micro starts from $6.11/month.

Select e2-micro
Check Deploy a container image to this VM instance. This will cause Compute Engine to only run the given image (next step) in the compute instance. Each compute instance can only run a single container using this method, and since we have sized our instance to only have just enough resources, this is totally fine.

Check this to deploy a container image to our Compute Engine instance
Choose a Postgres image from the Marketplace.
1. Search for Postgres in Marketplace:
  
  Search for Postgres in Marketplace
2. Select a Postgres version:
  
  Choose your desired Postgres version
3. Click on Show Pull Command to retrieve the image URL:
  
  Click on Show Pull Command
  
  If you click on Get Started with Postgresql 11 it will bring you to a Github page with more (important) information.
  
  Notably you want to take note of the list of Environment Variables understood by the container image.
4. Copy the image URL:
  
  Copy the image url
Paste the image URL into previous Compute Engine step. Set the minimum necessary environment variables. The default user is postgres. POSTGRES_DB is arguably unnecessary, you can already create it manually after instance creation.

Set the image and environment variables
[VERY IMPORTANT] Mount a directory and point it at where the container stores data. IF YOU DO NOT DO THIS, WHEN YOUR INSTANCE REBOOTS OR STOPS FOR WHATEVER REASON, ALL DATA DISAPPEARS.

Mount a volume at the Postgres data directory

It is somewhat container intuitive, usually in the command line we state the host path first, and then the mount path. Here Mount path (the container directory) comes first, and Host path (the OS directory) comes second.

Click Done.
Some optional settings to configure:

Turn on Secure Boot

Uncheck Delete boot disk when instance is deleted
Click Create.

Add a Firewall rule to connect to this instance

By default, post 5432 is blocked in a Google Cloud project. To allow connections from your local machine, do the following:

Go to Firewall rules.

Search for firewall and click on Firewall rules (VPC network)
Select Create Firewall Rule.
Name, allow-postgres (or anything you like)
In Target tags, add allow-postgres.
In Source IP ranges, add 0.0.0.0/0. Or Google "my ip" and paste in the result (safer but cumbersome, IP changes frequently).
In Specific protocols and ports, add 5432 in tcp.
Click Create.
Go back to the DB instance, click Edit.
Add the allow-postgres network tag:

Add the allow-postgres network tag
Click Save. Your instance is now accessible from your local machine.

Migrate data to new DB

Dump your current DB data:

pg_dump -d mydb -h db.example.com -U myuser --format=plain --no-owner --no-acl  \
  | sed -E 's/(DROP|CREATE|COMMENT ON) EXTENSION/-- \1 EXTENSION/g' > mydb-dump.sql

Get the external IP of our new DB:

Copy the external IP of the new instance
Use the external IP to psql to the instance. When prompted, paste the DB password from POSTGRES_PASSWORD earlier. The following command restores the dump back into the new DB instance:
```
psql -h [EXTERNAL_IP] -U postgres mydb < mydb-dump.sql
```
Your DB is now ready. When creating the DB, note the internal hostname for this instance:

Note the instance internal hostname

You can use this internal hostname to talk to this DB from within your VPC (another Compute Engine instance, Cloud Run, GKE, etc.). If that fails, then you can fallback to the Internal IP (see screenshot in Step 2).
[HIGHLY RECOMMENDED] Stop (shut down) your DB instance and start it again. Connect to your instance via psql (note that the External IP will likely change). Check that all your data is intact.
Remove allow-postgres from your instance Network tags (Edit, remove, Save). Your instance is no longer publicly accessible. By default, all internal network ports are open in Firewall rules so your DB instance remains accessible from within your VPC.

Summary

In this blog post, we have successfully created a Postgres instance from a container image in Compute Engine. We configured a firewall rule to connect to that instance from our local machine using a network tag, and we removed that network tag to lock up access to that instance. We also used the instance External IP to connect to it and restore dumped SQL data from our old instance (with the firewall rule in place).

If you are confident about the needs and performance of your application, you can choose to downgrade the instance to f1-micro to save another $2/month. Eventually GCP will come along and tell you that your instance is over-utilized (you can ignore or reject the warning). Note that all the risk is yours if your DB instance hangs because it is CPU-starved. There is an increased risk to cheap in the cloud.

Alternatively, there is a Postgres Google Click to Deploy option in the Marketplace. This will run Postgres in Debian OS, not a container. And you also cannot run it in an E2 instance (only N1 is supported). But it is probably more production ready, I presume.

Also highly recommended is that you take scheduled snapshots of the boot disk of the DB instance. This is important for data recovery and backups. Usually Cloud SQL takes care of this for you, but we need to handle it ourselves since we are DIY-ing here.

Disclaimer

The information provided in this blog post is provided as is, without warranty of any kind, express or implied. By following the steps outlined in this blog post I do not guarantee that your database will be free from any sort of failures or data losses.

My GCP Books

If you found this blog post helpful, kindly check out my books on GCP topics!

Forem: Jonathan ES Lin

Managing background jobs with Cloud Tasks

Table of Contents

Introduction

Overview

Relationship with App Engine

Targets

Create a queue

Configuring a queue

Rate-limit parameters

Retry parameters

Scheduling a task

Security

Cloud Tasks vs Cloud Pub/Sub

Cloud Tasks vs Cloud Scheduler

Summary

My GCP Books and Courses

What is Anthos by Google Cloud?

Table of Contents

Introduction

Anthos Components

Technicals

Pricing

The Good

No new hardware necessary

On-Premises

Development and Operations

Security

The Bad

GKE vs Anthos Lines Blurred

Cloud Run on GKE is no more?

Binary Authorization, not available on GKE without Anthos?

A bad sign for GKE and GCP

Comparison with AWS and Azure offerings

Summary

Related Links

My GCP Books

What Cloud Native Is and Isn't

Table of Contents

Introduction

Citizen-Country Analogy

Official definition?

What Cloud Native Isn't

What Cloud Native Is

What Cloud Native Infrastructure Is

What Cloud Native Applications Are

Summary

Related Links

My GCP Books

Run a Postgres instance for cheap in Google Cloud

Table of Contents

Scenario

Get started

Create a compute instance running a Postgres container

Add a Firewall rule to connect to this instance

Migrate data to new DB

Summary

Disclaimer

My GCP Books