GCP Business Logic Layer Design

In simple terms business logic refers to the rules that decides what happens to the data, how it’s created, stored and changed.

From the perspective of designing a solution for the cloud, it’s important to determine and design what cloud service the business logic code needs when it is called.

This blog post is a deeper look at the business logic layer design that we referred to in our blog post an-8-step-process-to-architect-solutions-on-the-google-cloud-platform-gcp

Let’s take the example of ordering delivery food from a restaurant, you can order food via their website, through their app, call them or from a 3rd party food delivery service. All of these approaches are using different front end or interfaces, but the core transaction itself, ordering food remains the same no matter what interface is used. This is business logic.

Image result for different ways to order delivery food from a restaurant
copyright – uber eats

One of the more popular approaches to designing the business logic layer efficiently is by using a microservice architecture. The main reason for a service, is to handle requests from its clients. Requests are handled by an adapter or a messaging gateway, which invokes the business logic. Essentially microservice architecture deploys independent, small and modular services. Here the business logic is spread over multiple services and contributes towards a business goal. Each service is run as a unique process and it it communicates through a lightweight messaging system like Google’s Cloud Pub/Sub. The advantages of a microservice architecture is that it is easy to develop and maintain, you can isolate faults and debug quicker, supports A/B testing and has redundancy and resiliency. It is also easier to unit test, but integration testing becomes more complex with a microservice architecture. Microservices make sense only when there are many consumers of an atomic unit of functionality, i.e., a lot of people doing the same thing over and over again.

One way that Google handles a microservice architecture is by the service Cloud Functions. It’s a managed service that allows developers to create single-purpose stand-alone functions that respond to cloud events and pass along the business logic without the need to manage a server or runtime environment. The only trade-off is lower latency and lack of flexibility in price/performance due to Cloud Functions being serverless. Here’s an example where an image is uploaded and the text in the image is translated. The events are the trigger and Cloud Functions use Cloud Pub/Sub for the messaging.

Microservices using Google Cloud Functions
copyright Google Cloud Platform

You can also design business logic layer using microservices with the Google App Engine. Here you need to store state externally, but Google handles the infrastructure for you, leaving you to just think about the code.

copyright – google cloud platform

Google supports 12-factor design (https://12factor.net/) which is the modern way of building software-as-as-service and designing the business logic layer. Let’s look at the services that Google offers that support 12-factor design:

a) Cloud Shell is a microservice or micro-vm for building and deploying code with version control and many deployments. It has all the API privileges to call any of the services with the Google infrastructure.

Google Cloud Shell
copyright – google cloud platform

b) Cloud Source Repositories to store your source code with Github support. It’s like your private Github.

Cloud Source Repositories
copyright – google cloud platform

c) Separate build and run stages by isolating different version of code – you can building your applications in Google Cloud Shell or your desktop/laptop and upload to the Google app Engine.

d) Keep development, staging and production as similar as possible by automation via templates using the Google Deployment Manager.

Image result for Google Deployment manager
Google Deployment Manager

e) Explicitly declare and isolate dependencies by creating your own custom image for compute.

f) Store config in the environment, this gets tough with microservices as you have external dependencies and you don’t want to store sensitive information on Github. so you store it in Google’s Metadata Server or Google Cloud Storage.

g) Fast startup, autoscaling and graceful shutdown with Instance templates in the deployment manager, and Managed Instance Groups.

Next, let’s look at Compute. Business logic uses CPU, you can run CPU on a Virtual Machine, a Container or the App Engine. The App Engine should suffice for most needs (billion dollar companies run on app engine). With the Google App Engine, google handles all the infrastructure leaving you to worry about just the code. You can A/B test, do canary deployment to test out new versions of releases and it handles autoscaling for you. You can now even run containers on App Engine Flex – it’s a beautiful thing! 🙂

Google enables complete Platform Independence with Google Kubernetes, you can pick up containers and run it any other cloud provider. It has no OS dependencies and if you already using Kubernetes on site, you can scale elegantly with Google.

source – CNCF

If App Engine and Google Kubernetes Engine does not meet your need and you want complete control, you can go with Google Compute Engine. It has high processing efficiency and you can choose your specific OS if need be. It is also useful, if you want to migrate to the cloud without re-writing your application. You can also get access to local storage.

Google Compute Engine

Have any Question or Comment?

Leave a Reply

Your email address will not be published. Required fields are marked *