Development and operation of a serverless e-commerce solution for the packaging industry in the Google Cloud

In this post, I describe the experience I gained while developing the e-commerce solution for “aXpel one for all”. It is an application for the packaging industry. Technologically, a cloud native solution was developed, which also includes integration into an external ERP system. The post is intended to help decision-makers form an opinion as to whether the development of a serverless solution in the Google Cloud is also an option for them.

Author: Roberto De Simone
Date: 04/01/2024
Updated: 03/11/2024

What does serverless computing mean

The term “serverless” initially suggests that no servers are used. However, serverless solutions naturally also require servers. In the case of an extensive application, even a large number of virtual servers are used. But you don’t have to maintain them and they can be scaled as required. If you want to use a database, for example, you use the Cloud SQL service and define the required system resources depending on the workload. As a user, you can then concentrate on the database functionalities and do not need to worry about the underlying servers or maintaining the database engine such as PostgreSQL, MySQL or SQL Server.

In addition to Cloud SQL, there are a variety of other services that can be used in a cloud solution; and behind each service are servers. I will talk about some of these services in the course of this post.

The benefits of serverless computing

In my experience, the benefits of serverless computing are manifold:

The system resources can be scaled as required, as already written. You only pay for the resources and licences that you really need. Whether this is really more favourable compared to an on-premise (on-site hosting) solution must be considered in the overall context.
Only limited system administrator knowledge is required for operation (with more complex solutions, especially if virtual networks are used, however, such expertise is essential). No maintenance effort is required to keep the system components up to date.
A wide range of services are available, which can be conveniently added to the solution as required. For example, if you need a content delivery network to cache data, the Cloud CDN service can be added, or if you want to translate data automatically, the well-known Google Translate service can be integrated into the solution. Google makes it really easy for customers to integrate a service - everything comes from a single source - but it also comes at a price. More on this at the end.
Security should be higher compared to a self-managed solution, as best practices are already applied by the managed services and there are therefore fewer vectors for attacks. In addition, the Google Cloud already protects against a range of attacks from scratch. With the Cloud Armor service, a further service is available with which traffic can be filtered in detail. However, none of this prevents the actual software solution itself from having to be implemented with best practices.

The motivation to use the Google Cloud

Cloud Run, the service for serverless cloud solutions

The Cloud Run service was the decisive factor for me to develop a serverless solution in the Google Cloud. With Cloud Run, application containers can be executed in a managed manner. Such a container is, for example, an API that was developed with Java Spring Boot or .NET Core. The user interface, which was developed with Angular, React or another web framework, is also executed in a container. A solution therefore consists of various application containers. The containers can communicate with each other or they can access other services such as the aforementioned Cloud SQL Service. These containers can be scaled as required depending on the workload. If the traffic increases, another container is automatically started up. Before Cloud Run existed, you had to maintain container solutions yourself with an orchestration tool such as Kubernetes. This was and is associated with a great deal of expertise. However, Kubernetes is probably still the first choice for really large applications.

Microsoft Azure and Amazon AWS now also have a similar service to that offered by Google Cloud with Cloud Run.

Google Cloud Services for operating the e-commerce solution

Cloud Run alone is sufficient for simple solutions. This website is also hosted in the Google Cloud with Cloud Run. The site developed with Astro is executed in a container.

Cloud Run also takes over the management of the SSL certificate. It is sufficient that the DNS entries of the domain used point to the Google Cloud. You can also choose which data centre should be used. In short: once familiarised with Cloud Run, it opens up extremely flexible hosting options in the simplest possible way. Cloud Run alone is not enough for more complex solutions. You will soon realise that a load balancer is required. This enables the use of the aforementioned Cloud CDN (Content Delivery Network). Especially for e-commerce solutions (shops), where a very fast page load is important, you can’t get past it. A load balancer also enables optimum performance if customers in several regions or even worldwide are to be reached. The load balancer is also required if the aforementioned Cloud Armor service is to be used, which allows traffic to be filtered. Cloud Armor also has the “Adaptive Protection” option, which analyses traffic with the help of machine learning (ML) and makes automatic suggestions for filtering suspicious requests. However, the costs for this are unfortunately considerable, meaning that the use of this service is only an option for really large applications.

The aforementioned Cloud SQL service is used for the database. I will not go into this any further, as its use is actually self-explanatory.

When it comes to exchanging data with external systems, further services are required to ensure reliable data exchange. The Cloud Task service, for example, enables the synchronisation of orders from the shop with the ERP system. When a new order arrives in the shop, a task is created that synchronises the shop order with the ERP system. The task calls commands (endpoints) in a cloud run container, which in turn call the interface of the ERP system to record the data in the ERP system. This task is placed in a queue that is processed. Only when the data has been successfully recorded in the ERP system, the task is considered complete and removed from the queue. If the ERP system cannot be reached due to a network error, for example, the task is executed again at user-defined intervals. Cloud Pub/Sub can also be used as an alternative to Cloud Task.

If an external service requires a fixed IP address for security reasons, a VPC Network is required. A Cloud Run Container does not have a fixed outgoing IP address by default. If all queries are routed via a VPC network, they can be assigned a fixed IP address.

Cloud Scheduler is a service with which tasks can be executed at specific times, for example the synchronisation of articles between the ERP system and the shop. A cron job would be created for this on a Linux server.

Other useful services are the Google Translate Service and Cloud Storage. The former automatically localises missing localisations in the ERP system articles for the shop. All article images are stored in the cloud storage, which are cached in the cloud CDN with the help of the load balancer to ensure fast access to them.

Of course, the Google Cloud also has a variety of other services that can be used depending on the application.

However, there are also things missing: surprisingly, there is no email service for sending transactional emails (order confirmations). For comparison: Amazon AWS has the Amazon SES service for this. In our case, we use SendGrid from Twillo.

Summary

It is fascinating to see the possibilities offered by the numerous cloud services for the development of a cloud-native application. In contrast, the use of similar products in a self-hosted solution is associated with a high level of maintenance and development expertise.

There are also more and more services, especially in the machine learning sector, that can only be offered by the large cloud providers.

Increasingly sophisticated hacker attacks pose major challenges for on-premise solutions. The cloud already offers more protection from the ground up thanks to its best practices.

However, a cloud solution also has its price: if you look at a monthly invoice for the Google Cloud, the largest invoice item is “Compute Engine”, which corresponds to the costs of the various managed virtual servers. As already mentioned at the beginning: behind the services there are also servers that consume computing power.

The bottom line is that the costs of the individual services add up.

A similar on-premise solution with self-managed virtual servers and open source products would be significantly cheaper. Nevertheless, in my opinion, the benefits of the Google Cloud solution described at the beginning still clearly outweigh the disadvantages.

Whether this will remain the case also depends on whether Google or the other cloud providers do not start to utilise their position more. The first customers are already saying goodbye to the cloud. If the costs become too high, a new market for local solutions could emerge. History would then repeat itself, as demonstrated by the switch from mainframe to local servers in the 1990s.