Google Services as Recipes and Hosting Environment— Part 1

Google Recipes are program snippets that make the Google services available via an application server. They are simple to write and use in other snippets. They run inside a pre-built application server environment. Thus, a hosting environment is a prerequisite for them.

How are they different from cloud functions wrapping Google Cloud Services.

A recipe is a simple yet powerful concept different from the cloud function. Although, both are serverless.

Recipes run inside a distributed application server environment that provide several application level services. Therefore they are a higher level abstractions and simple to write and use.

Think of recipe as a script or function running inside Salesforce Platform as opposed to the Cloud Function running in the Google Cloud. Salesforce Platform provides higher-level abstraction and several application-level services.

So what is an equivalent of Salesforce platform on the Google Cloud?

There is a gap between Google Cloud Platform and a platform like Salesforce. On the Google Cloud, Trillo Workbench bridges this gap.

Trillo Workbench provides an application server environment on the Google Cloud which is equivalent of Salesforce Platform.

In a series of blogs, we will take a deep dive into the concept of Google Services as Recipes and an environment (Trillo Workbench) to host them. This article is the first blog of the series.

We will make the best attempt to keep it simple.

Google, AWS, and Azure clouds are lower abstractions than the application server. Therefore, an application server is a requirement for the end-user software system. Companies spend thousands to millions of dollars building application servers. Typically, an application server consists of several distributed microservices.

Whereas the Salesforce Cloud, the platform itself is the application server. It also provides an environment to customize itself.

The Salesforce Cloud is an application-level platform.

An Application Server Environment is a running server where you can plug in pieces of customization so it can acquire the personality of your application server.

It means that you no longer have to build an application server. Instead, you customize an existing application server using its environment.

An application server environment provides “X%” of services needed in the application, where ‘X’ tends to be 100. It can never be 100 since you can think of a use-case which it can’t handle. But for an application, it should provide 70–95% services. The application server environment is also a programming environemnt to add business logic i.e. add missing piezes of the puzzle.

Salesforce Platform is one such environment. Trillo Workbench provides an environment similar to Salesforce on the Google Cloud.

Before the cloud, building an application server environment was an arduous task. The gap between the infrastructure and the application was vast. Salesforce was the first successful company to deliver such a customizable environment. It probably succeeded due to its CRM focus.

The three big cloud platforms (AWS, Azure, Google) have reduced the gap between the infrastructure and the application server. Therefore it is possible to build an application server that can support customization with less effort. With the latest changes in its Power Apps platform, Azure is getting closer to providing an application server environment.

A cloud platform is the foundation of a customizable application server environment. The Trillo Team picked Google Cloud, due to beauty of its consistent design and a partnership opprtunity. In our expereince, the Google Cloud platfrom follows the principles of software engineering.

The benefit is evident if you don’t have to build 70–90% of the application server and customize it to meet the business requirements. You will save lots of money and time.

Such environments are also known as Low-code Platforms.

1. It provides a fully operational application server out of the box.
2. It provides several application-level services.
3. New services can be added easily (as recipes, more below).
4. The provider of Application Server Platform must be willing to add new services that require platform code changes.
5. The platform should transparently handle non-functional requirements such as security, scalability, elasticity, governance, compliance, etc.

Recipes are program snippets that make some services securely available via an application server. A task, function, or another recipe can use them through a programming language toolkit. Or, a remote client can invoke them as restful APIs using an OAuth2 token.

Say we have a requirement to add a new API to translate a given text paragraph. In the following code, we add a recipe using Google Translation Service. This recipe automatically becomes available as a secure API invoked by a remote client.

Trillo Workbench publishes each recipe (and several other services) as API. Trillo Workbench issues the client-id and client-secret to invoke APIs.

An external client can securely invoke API via Trillo Workbench to the recipe to Google Translation Service.

In Part 2 of the blog series, we will examine how to translate many files. It will cover the following steps:

1. A user will upload 100s, 1000s, or more files into the Google Cloud Storage bucket using Trillo Workbench (UI or in-built SFTP server).
2. Add a database table dynamically to store the result of translation.
3. Write a Task that repeats — load an unprocessed file from the Google Cloud Storage Bucket, read text from, call Google Translate recipe for text, write the result into the database.
4. Trillo Workbench will automatically kick off the tasks when files become available in the bucket. It will run multiple instances concurrently (on different nodes).
5. Using Trillo Workbench, we will be able to monitor the status of each task, any failure.
6. An external client will retrieve the translation of a given file using a restful API call.