As we enter the holiday season, retailers are working behind the scenes to ensure they can provide the best experiences for customers, in store and online. Challenges in retail do not begin or end during the holiday season as sudden shifts in customer preferences, supply chain nuances, and overall demand ebbs and flows take place year round and retailers must be prepared to adapt swiftly.

Google Cloud’s retail customers globally, in total, saw more online traffic in the first six months of 2022 than all of 2019. This year, retailers can expect an early launch to holiday shopping activities, as 50% of consumers plan to start purchasing goods before the traditional Black Friday kick-off.

The very same improvements made to automate and improve retail infrastructure can prepare it for holiday surges and support year-round innovation. Let’s take a look at how Ulta Beauty, the largest beauty retailer in the U.S., is partnering with Google Cloud, MongoDB Atlas, commercetools, and HCLTech to cover these two areas and more.

Architecting for innovation

Creating personalized shopping experiences in stores and online is key to Ulta Beauty’s success. This commitment is best demonstrated through Ulta Beauty’s Virtual Beauty Advisor. Built on Google Cloud, this tool enhances shoppers’ experiences with personalized recommendations in addition to the ability to try on makeup virtually with GLAMLab.

As innovators in support of the best possible guest experience, Ulta Beauty needed to re-architect its infrastructure for greater agility and stability.

To start, Ulta Beauty chose to use Google Kubernetes Engine (GKE) as the backbone and orchestrator to build and deploy cloud-native applications. The Google Cloud deployments coincided with an organizational move from end-to-end application development to one that focuses on individual features, specific modules, and micro-applications.

This strategic change allowed Ulta Beauty to fix bugs, experiment with new offerings, and drive customer experiences faster and more efficiently. Thanks to the transformation and GKE, Ulta Beauty’s developer team now accelerates time to market for new products and services, and delivers new ways to engage with customers more quickly. These efforts all ladder to create ‘WOW’ experiences for the retailers’ guests who have emotional and personal connections to beauty and wellness. They can now discover and experience products that are served to them based on individual preferences.

Adapting to the new environment comes with its own set of challenges. “Microservices are not a silver bullet,” says Sethu Madhav Vure, IT Architect, Ulta Beauty. “For Ulta Beauty, the biggest challenge was how to break up a monolithic environment into multiple applications. We had to evolve our core systems—without impacting today’s services—and address what was needed for the future.”

Google Cloud partner HCLTech provided expert guidance throughout the re-architecting process, defining the solution blueprint and cloud-native deployment architecture through cross-functional workshops. HCLTech then assisted with the actual migration and platform setup, paving the way for fully automated, continuous integration and continuous delivery (CI/CD) pipelines to support faster rollouts and deployment architecture to drive higher availability and scalability.

Ulta Beauty took a domain-driven design approach to identify operations that could be grouped together to reduce complexity and improve scalability. Now, the applications are based on multiple domains, such as Commerce, Promotions, Catalog, Order, Customer, and Inventory. The new architecture prompted a fresh look at storage requirements to scale dynamically alongside its modernized applications.

For Ulta Beauty, MongoDB Atlas proved to be the best database solution for dynamic scaling, ease-of-use, and integrations with Google Cloud. The company also leveraged an entry-level plan to prove the value of MongoDB Atlas before investing in the technology.

“MongoDB Atlas offers a free tier that gave us an opportunity to quickly demonstrate tangible benefits of a proof of concept,” says Vure. “Once we proved the value of MongoDB Atlas, we benefited from the straightforward resource allocation supported by Google Cloud and MongoDB.”

Integrations between MongoDB Atlas and Google Cloud allow Ulta Beauty to take an iterative approach to new projects. The company creates new clusters in an existing project, then piggybacks them onto an existing Private Service Connect setup between a MongoDB project and Google Cloud project.

By removing complexities within infrastructure management, Ulta Beauty can manage its incredible amount of data, such as member preferences and purchases, that fuels its event-driven architecture. The much more agile infrastructure enables Ulta Beauty to deploy and scale offerings faster than ever.

“We recently had an unplanned traffic surge that impacted our domain services. It took less than an hour for MongoDB Atlas to scale up to the next level of the cluster and manage that traffic,” says Vure. “The on-demand, dynamic scaling, plus GKE, has saved the day more than once.”

Preparing for a happy holiday season

This holiday season, Ulta Beauty has a stronger technical foundation to manage demand surges and provide customers seamless shopping experiences. Previously, the company used 50 pods in a cluster, each with 6 GB of RAM without domain stores, to handle about 100 transactions each second. With domain stores, the same 6 GB of RAM with just 20 GKE pods was able to scale up to 2,400 transactions per second.

With Google Cloud as its technology foundation, Ulta Beauty partnered with Google Cloud partner commercetools to evolve its application APIs as products and properly separate interfaces and capabilities.

Ulta Beauty uses event-based integrations within commercetools to identify how best to leverage Cloud Pub/Sub middleware on top of MongoDB Atlas integrations. Patterns established here were extended into MongoDB change streams and in turn improved business processes.

“Working with the right technology partners has helped us to avoid analysis paralysis that can happen when developer teams spend a lot of time trying to understand and manage every detail,” says Vure. “Instead, we convert a proof of concept into a working solution, and quickly bring it to market. It’s been a major shift in our IT culture as we try out new things weekly and see incredible support from leadership.”

The improvements enable Ulta Beauty to maintain a high level of innovation, performance, and customer service year-round. Now, when the holiday shopping season begins, Ulta Beauty is prepared to handle surges in traffic through auto-scaling with Google Cloud and MongoDB Atlas. Customers get what they want, when they want, free from the frustrations of outages.

“With these changes, we are ready for a holiday season that everyone–even those of us in IT—gets to enjoy. We’re positioned to continuously focus on new, better ways to serve our guests,” says Vure.

Check out MongoDB and commercetools on Google Cloud Marketplace to learn more about what these partners can do for your business.

New locations in Eventarc

Back in August, we announced more Eventarc locations (17 new regions, as well as 6 new dual-region and multi-region locations to be precise). This takes the total number of locations in Eventarc to more than 30. You can see the full list in the Eventarc locations page or by running gcloud eventarc locations list . 

What does location mean in Eventarc?

An Eventarc location usually refers to the single region that the Eventarc trigger gets created in. However, depending on the trigger type, the location can be more than a single region:

• Pub/Sub triggers only support single-region locations.
• Cloud Storage triggers support single-region, dual-region, and multi-region locations.
• Cloud Audit Logs triggers support single-region locations and the special global region.

Before looking into trigger location in more detail, let’s look at other locations relevant in Eventarc.

What other locations are relevant in Eventarc?

Triggers connect event sources to event targets:

Each event source, event target, and trigger has its own location. Sometimes, these locations have to match and sometimes they can be different.  

Here’s an example of a trigger connecting Cloud Storage events from a bucket in the europe-west1 region to a Cloud Run service in the us-central1 region with a trigger located in the europe-west1 region:

  gcloud eventarc triggers create trigger-storage \
  --destination-run-service=hello \
  --destination-run-region=us-central1 \
  --location=europe-west1 \
  --event-filters="type=google.cloud.storage.object.v1.finalized" \
  --event-filters="bucket=my-bucket-in-europe-west1-region" \
  --service-account=$PROJECT_NUMBER-compute@developer.gserviceaccount.com

In many cases, you don’t have control over the location of the event source. In the example above, the Cloud Storage bucket is in the europe-west1 region. That’s the location that you need to work with and it has implications for the trigger location (which I’ll get to later). 

The location of the event target is the region of the service where you want the events to go. You get to choose this from one of the supported regions when you deploy your Cloud Run service. You typically want this to be in the same region as your event source for latency and data locality reasons (but this is not strictly a requirement). In the example above, the event source (bucket) is in europe-west1 but the event target (Cloud Run service) is in  us-central1 as specified by the --destination-run-region flag. 

The location of the trigger is dictated by the event source location, but the trigger type also comes into play. It is specified by the –location flag. Let’s take a look at the trigger location for each trigger type in more detail.

Location in Pub/Sub triggers

In a Pub/Sub trigger, you connect a Pub/Sub topic to an event target. Pub/Sub topics are global and not tied to a single region. However, when you create a Pub/Sub trigger, you need to specify a region for it (because Eventarc triggers need to live in a region) with the --location flag as follows:

  gcloud eventarc triggers create trigger-pubsub \
  --destination-run-service=hello \
  --destination-run-region=us-central1 \
  --location=us-central1 \
  --event-filters="type=google.cloud.pubsub.topic.v1.messagePublished" \
  --transport-topic=projects/your-projectid/topics/your-topic

By specifying a location, Eventarc automatically configures the geofencing feature in Pub/Sub such that events only persist in the specified location. As I noted above, you typically want to (but are not required to) choose the same region for the trigger and the Cloud Run service for lower latency and data locality. You can also use regional Pub/Sub service endpoints to publish to the topic to ensure that all of the data stays in a single region. 

Location in Cloud Storage triggers

In a Cloud Storage trigger, you connect a Cloud Storage bucket to an event target. A Cloud Storage bucket can be in a single-region (e.g. europe-west1), dual-region (e.g. eur4), or multi-region (e.g. eu) location. The location of the bucket dictates the location of the trigger and they have to match. The earlier trigger example was for a bucket in the  europe-west1 single-region location. Here’s another trigger connecting Cloud Storage events from a bucket in the eu multi-region location. Notice how the location flag matches the bucket region:

  gcloud eventarc triggers create trigger-storage \
  --destination-run-service=hello \
  --destination-run-region=us-central1 \
  --location=eu \
  --event-filters="type=google.cloud.storage.object.v1.finalized" \
  --event-filters="bucket=my-bucket-in-eu-multi-region" \
  --service-account=$PROJECT_NUMBER-compute@developer.gserviceaccount.com

If the bucket region and the trigger region do not match, you’ll see an error:

  ERROR: (gcloud.eventarc.triggers.create) INVALID_ARGUMENT: The request was invalid: Bucket "my-bucket-in-eu-multi-region" location "eu" does not match trigger location "europe-west1". Try again by creating the trigger in "eu".

Location in Cloud Audit Logs triggers

In a Cloud Audit Logs trigger, you connect any event source that emits Audit Logs to an event target. The location of the event source will dictate the trigger location. This is typically a single region but there is a special global region that’s necessary in some cases. 

For example, if you want to read Cloud Storage events from a bucket in the europe-west1 region with an Audit Logs trigger, you will create the trigger with the same location. Note that this will match all buckets in the europe-west1 region as there’s no filter by bucket in Audit Logs:

  gcloud eventarc triggers create trigger-auditlog \
  --destination-run-service=hello \
  --destination-run-region=us-central1 \
  --location=europe-west1 \
  --event-filters="type=google.cloud.audit.log.v1.written" \
  --event-filters="serviceName=storage.googleapis.com" \
  --event-filters="methodName=storage.objects.create" \
  --service-account=$PROJECT_NUMBER-compute@developer.gserviceaccount.com

On the other hand, if you want to match a dual-region or a multi-region bucket such as eu, you will create the trigger with the global location as Audit Logs triggers only support a single or global region. Note that this will match all buckets in all regions globally:

  gcloud eventarc triggers create trigger-storage \
  --destination-run-service=hello \
  --destination-run-region=us-central1 \
  --location=global \
  --event-filters="type=google.cloud.storage.object.v1.finalized" \
  --event-filters="bucket=my-bucket-in-europe-west1-region" \
  --service-account=$PROJECT_NUMBER-compute@developer.gserviceaccount.com

As you can see from this example, if you want to read Cloud Storage events, the native Cloud Storage trigger is a much better option, but this example illustrates a typical case in which a global Audit Log trigger is necessary. 

That wraps up this closer look at locations in Eventarc. Feel free to reach out to me on Twitter @meteatamel for any questions or feedback.