In the dynamic world of digital development, our customer Siemens AG, one of Germany's largest technology companies, was looking for a simplified solution to manage HTTP redirects across their web domains. Our collaboration exceeded expectations and introduced a seamless redirection solution that was just the tip of the iceberg. Not knowing that this would lead to further innovations, we slowly introduced the potential of serverless cloud operations and found new possibilities for efficiency and innovation.

The tool in use at the time was built as a traditional monolithic Spring Boot application. While it was functioning adequately, it required more elaborate operations processes than desired and was fairly expensive to operate. Any replacement for the existing application was supposed to improve the situation by reducing the operations burden and cost. Additionally, streamlining the redirect management procedure was a key goal. At the same time, Siemens was also keen to experiment with the “serverless” application development model as a possible replacement for more traditional technology stacks.

This was the perfect opportunity for both our customer and us at Groundfog to create value, drive internal IT forwards, and gain knowledge at the same time.

Using serverless services offered by AWS, the next iteration of the Redirect Tool was the ideal proof-of-concept to verify serverless development practices. If successful, the Redirect Tool and the learnings made along the way could be used as a blueprint for other internal applications.

Exploring New Technologies

Trying out new technologies is always the most fun part of a project, but we also wanted to create real-world value beyond that. Besides the obvious requirements like cost efficiency, scalability, resiliency, great performance, and usability, we gathered a list of additional requirements together with the customer:

• Tenancy should be supported to allow other legal entities to have their own Redirect Tool with their own branding.
• All 300,000+ employees can log in and create redirects.
• More automation of processes like expiring redirects, redirect health checks, and informing owners when one of their redirects is broken to call them to action.
• An API that can be used by third parties to create redirects (e.g. marketing tools that have to create redirects/vanity URLs for marketing campaigns).

With the idea born, it was time to formulate a plan for how the customer and Groundfog could successfully launch the first version of the new Redirect Tool within a few months.

Development Strategy

Now that we had identified our desired outcome, we needed a plan to achieve it. Our approach was to assemble a compact team consisting of a single architect, backend, and frontend engineer and let them iterate fast.

Work was divided into sprints of two weeks, and with every iteration, the customer and the team “corrected” the course when necessary.

Due to the fact that we were venturing into the proverbial “uncharted territory,” we used the first phase of the project for smaller proof-of-concepts. This allowed us to quickly validate the feasibility of our solution concepts upfront, preventing the need for expensive and time-consuming refactoring down the line. After this initial phase, the focus shifted to rapidly developing a minimal viable product, presenting it, and then iterating based on stakeholder feedback.

The first version of the new Redirect Tool went live about six months after the first workshops.

Building the Redirect Tool

Similar to many modern applications, the Redirect Tool is not a single monolithic application. It consists of various components working together to redirect end-users to the correct pages.

The three most important parts of the Redirect Tool are:

• The UI used by employees to manage redirects
• A REST API to allow third-party systems to manage redirects and used by our UI
• Our “redirect engine” that actually redirects incoming requests

Other components, such as functions dedicated to database maintenance, exist, but these three play the most crucial roles. The UI is a Single Page Application built with VueJS using the REST API to access the data. To build the API, we used API Gateway and Lambda, which communicate with our storage layer consisting of DynamoDB and OpenSearch.

Our “redirect engine” handles the redirects, where low latency is paramount to avoid delaying requests, especially those made by actual users. To keep latency low, we use AWS DynamoDB because it offers single-digit latency. The Lambda@Edge that processes the incoming request queries DynamoDB directly instead of using our API. To further lower latency, the Lambda@Edge has two caches to reduce the number of queries to DynamoDB. The first cache consists of JSON files that are pre-generated every five minutes and downloaded by the Lambda@Edge. Redirects not yet in those files are read from DynamoDB and then cached.

In addition to the previously mentioned services, we also use CloudWatch, IAM, Cognito, CloudFront, Route53, EventBridge, SES, SQS, SSM Parameter Store, and Step Functions.

Challenges and Learnings

Looking back at the project, it's easy to see the many challenges we faced. We were diving into a new development paradigm. We at Groundfog had extensive knowledge when it comes to software development. The team had close to 30 years of combined experience developing web applications.

Nevertheless, we were moving from building monoliths hosted on “machines” (bare-metal, virtual, etc.) to deploying our application into a PaaS. Additionally, we needed to get used to event-driven architecture, instead of running an application 24/7 and processing incoming requests.

Building a serverless application also required us to change our development habits. Gone are locally running instances of our application. Now, we needed to deploy our application to AWS to perform functional tests. This meant building fast and reliable deployments locally and in our continuous integration (Gitlab). In the past, we used to deploy ZIP artifacts every few weeks. However, as we aimed for faster progress, we shifted to deploying whenever a new feature was developed.

None of this is groundbreaking in our industry. Established practices, such as using Terraform for AWS infrastructure and employing GitLab for CI/CD pipelines, are well-known. However, the ongoing challenge lies in seamlessly integrating everything to ensure an optimal developer experience.

Apart from the technical aspects, it can also be a challenge for stakeholders when development speed is faster than it used to be. Previously, stakeholders were used to intervals of months between new release reviews. However, incorporating daily assessments of requested features and changes presents its own set of challenges.

Wrapping Up

The Redirect Tool proved that Groundfog and Siemens are able to leverage serverless AWS services to build a cost-effective internal tool that delivers value to employees. Currently, the monthly operating cost is about one sixth of the cost of the previous solution.

Although cost and efficiency are important metrics for project owners and us at Groundfog, user experience is also equally significant. That is why we are happy that the feedback from employees has been overwhelmingly positive, while end users of Siemens webpages experience fast and smooth redirects.

As we reflect on the evolution of the Redirect Tool, it's worth noting that since its inception, new and enhanced AWS services have emerged. The landscape is dynamic, and so are we. We are committed to further refining internal tools like the Redirect Tool and look forward to the next iteration with excitement.

Join us on this journey of continuous improvement and innovation. Stay tuned for what lies ahead, and let's shape the future of your digital experience together.