In a startup, you need to get to the MVP fast, gather feedback from early adopters, and iterate in a quick cycle. Anything that takes time away from developing and iterating on features delays the launch and that’s a serious problem when time-to-market is crucial. 

Google Cloud offers products that can help you to build and run your backend services on a fully managed serverless platform, saving time and freeing you from the burden of provisioning and managing infrastructure needed to run those services. Less time on infrastructure means more time implementing and iterating on your services. Additionally, most serverless products have a pay-as-you-go pricing model with little upfront cost at the beginning.  Pricing increases in line with the scale of your services and your startup, so you only pay for what you need, when you need it.

Let’s take a look at some of these products and see how they can help you to iterate fast. 

Where to run code?

First, you need to decide where to deploy and run your code. Cloud Functions is the easiest way to run code in Google Cloud. With Cloud Functions, you write a simple function in a supported language, decide how that function should be triggered (via HTTP or events), and let Cloud Functions handle all the details of how to run, trigger, and autoscale that function. 

Cloud Functions is designed primarily for single-purpose use cases and not for entire apps, so it’s important to be aware of its limitations. For example, you can use a limited set of languages and your functions need to respond back within a certain amount of time. 

When you run into a Cloud Functions limitation, you might be able to use Cloud Run for more flexibility. With a Cloud Run service, you run serverless HTTP containers instead of functions. This enables you to define your own runtime, so you can use any language you want and you can implement more sophisticated logic (rather than a simple function), as long as everything can run in a container. 

If all you need is a piece of code that runs to completion (rather than a service that handles requests continuously), you can use Cloud Run jobs, where you can execute long-running containers in parallel on a fully managed serverless environment. 

In both Cloud Functions and Cloud Run, you focus on writing your function or container and Google Cloud takes care of the infrastructure needed to run and scale it. This enables you to iterate fast on the features of your service.

Cloud Code for serverless development

Whether you use Cloud Functions or Cloud Run to run your services, you can rely on Cloud Code to quickly create and deploy your service to Google Cloud from your favorite IDE. 

In Cloud Code, there are templates to quickly create Cloud Functions or Cloud Run applications:

You can then deploy those services and see the list of deployed Cloud Functions and Cloud Run services all from the IDE:

How to coordinate services?

Once you have a service running, you need to decide how to trigger it beyond simple HTTP. You can use Cloud Scheduler for time-based executions. For more control, you can front any HTTP service with a Cloud Tasks queue, which gives you sophisticated features out of the box such as retries, rate limiting, deduplication, and more.

With multiple services, you also need to decide how your services will communicate and coordinate. The options are:

  • Direct service-to-service communication
  • Indirect event-driven communication (also known as choreography)
  • A central orchestrator directing the communication

Direct service-to-service communication is easy to implement. However, it creates tight coupling between services, so it’s a good idea to avoid it.

For event-driven communication, Google Cloud has Pub/Sub and Eventarc. Pub/Sub is low-level service with a high degree of event-delivery customization whereas Eventarc is higher level service with easier semantics to connect services. The important point is that both are fully managed, global services that help you to connect event sources to event consumers without you having to worry about the underlying infrastructure.

For service orchestration, you can use Workflows. You define how services should be called in what order in a service orchestration definition. Workflows takes care of making those calls in the way you defined while capturing the outputs (and handling failures) along the way.

All of these coordination services run in a serverless way without you having to worry about the underlying infrastructure, giving you more time to work on your own services. 

What if you need a server?

Sometimes you need a server due to some limitation of the serverless platform. For example, all serverless platforms have time limits on how long a workload can run and what CPU and memory resources it can have.  Even if you can’t run your code on a serverless service such as Cloud Functions or Cloud Run, you can still use Batch to run and manage batch jobs on virtual machines (VM) in Compute Engine. Similarly, you can use Workflows and its Compute Engine connector to run your code on a VM and manage the VM lifecycle with Workflows. In both cases, the actual workload runs on servers (giving you the full flexibility that comes with that) but the management of those servers is done in a serverless way with services like Batch and Workflows. 

Conclusion

Whenever you need to run some piece of code, ask yourself: Can I run this code on a serverless platform? Even if the answer is no, you might be able to manage its lifecycle on a serverless platform. The more infrastructure management you can delegate to the cloud, the more precious time you’ll have for developing and iterating your own services.