Using AWS Serverless Technology as an Enabler for Cloud Adoption

By Andy Frodsham, Head of AWS Technology at BJSS

When a national UK retailer undertook the challenge of replacing their e-commerce platform, the challenge was not inconsiderable.

A heavily-customized WebSphere implementation had been the backbone of the organization for many years and was integrated throughout the business. When the project was first initialized, extended support for WebSphere 6.1 was still in place. But with the platform nearing end-of-life, the need to modernize was imperative.

In this post, we describe how BJSS leveraged the AWS Serverless Platform and an innovative delivery approach to deliver success for the customer.

BJSS is an AWS Partner Network (APN) Advanced Consulting Partner with AWS Competencies in both DevOps and Government. BJSS is also a member of the AWS Well-Architected Partner Program.

If you want to be successful in today’s complex IT environment, and remain that way tomorrow and into the future, teaming up with an AWS Competency Partner like BJSS is The Next Smart.

Selecting an Approach

Having worked closely with the customer on numerous challenging IT projects, BJSS was asked to investigate several approaches that addressed the following issues:

• Changes to the WebSphere e-commerce platform were difficult and carried inherent risk due to the monolithic nature of the solution.
• It took a long time to deploy changes or new features due to the traditional waterfall delivery approach employed, such as quarterly releases.
• The on-premises hosting model was costly both in terms of capital expenditure and operational effort required to maintain the system. Test/DR environments required investment in infrastructure that would typically stand idle for much of the time and were difficult to instantiate due to the manual deployment processes.
• Licensing costs were not insignificant, with the caching component alone cost in excess of £400,000 per annum.

The key success factors for the business were clear:

• Improve end user experience. A major issue with the existing e-commerce system was the lengthy response times for large shopping baskets. Once the shopping basket reached 60-65 items, it could take up to eight seconds to add further items.
• Deliver new features rapidly. The site needs to handle upward of 3,000 offers per month and must dynamically apply savings at checkout. Again, the existing system would creak under high load, taking tens of seconds to complete.
• Keep the platform fresh and appealing for online shoppers.
• Realize the benefits of utility-based cloud computing.
• Achieve all of this while minimizing change risk.

Rather than upgrading WebSphere or selecting another packaged solution, BJSS helped the customer make the bold decision to migrate the platform to the Amazon Web Services (AWS) Cloud. We also helped them build using open source frameworks, and incrementally replace their e-commerce platform with a cloud-native solution enabling the delivery of change far more effectively.

Architectural Approach Drives Technology Selection

BJSS developed a modular target architecture specifically designed to decommission aspects of the existing functionality and add new functionality at the same time, replacing the full system over a gradual period.

The order of modules built and functionality decommissioned was not fixed. Much like we have come to expect with agile backlog management, it was reassessed and refined as the project developed.

To ensure that change was delivered incrementally, demonstrated the promised benefits, and didn’t put new developments and features on hold, we selected the Strangler Pattern as the delivery approach.

Figure 1 – Strangler Pattern applied to replace functionality from the monolith.

As Figure 1 depicts, the Strangler Pattern allows for the incremental migration of a legacy system by gradually replacing specific pieces of functionality with new applications and services. As features from the legacy system are replaced, the new system eventually replaces all of the old system’s features, strangling the old system and enabling it to be incrementally decommissioned.

Of course, like any approach, this does come with its own complexities. Facades must be developed to enable interaction with both new and old functionality, and data must be synchronized from replacement to legacy and back while aspects of the data model are decommissioned over time.

Benefits of AWS Serverless

AWS Serverless proved to be ideally suited for this approach, providing the services that enabled the application development teams to focus on incrementally building functionality without the headache of designing, deploying and operating a fleet of servers.

Amazon API Gateway was a simple and fast way to deploy the strangler facade, with support for HTTP proxying, the pass through of binary data, and the catch-all ANY verb for the HTTP method providing all of the flexibility we required.

With AWS, though, there is more than one way to build a solution. The dynamic origin functionality provided by Lambda@Edge does exactly what it says on the tin by examining any part of the request and dynamically switching the origin where the request is routed to between “the monolith” and our replacement functionality.

During the gradual replacement, there are aspects of both new and legacy solutions that interact with each other, take the process of synchronizing the order basket between AWS (stored in Amazon DynamoDB) and WebSphere where the customer’s basket information must be available to both systems.

We use an event-driven method for synchronization, hooking into existing events to trigger a synchronizing service call upon update of the basket in either system, as illustrated in Figure 2.

Figure 2 – Legacy synchronization.

This approach was vital to the success of the project in several ways:

• Development teams could focus on small pieces of functionality, which enabled delivery of value very early in the project.
• This gave the business confidence that as we moved more functionality onto AWS, service levels for customers would not be impacted. In addition, successfully validating this new approach ensured buy-in from all stakeholders.
• A pattern for the delivery of incremental change was established during the initial Proof of Concept (POC), including tooling, coding standards, and release processes, that would scale to support multiple delivery cells and enable rapid change. The POC was further accelerated through the use of AWS CodePipeline for CI/CD, which aligned to our serverless paradigm.
• The pattern could be applied to the deployment of new service features, as well as “strangling” the monolith.

Implementation Challenges

Throughout development, we found that certain adaptive architecture patterns are vital to ensuring a good service when utilizing the AWS Serverless Platform to interact synchronously with end-users and legacy systems.

An example of this is the implementation of the Circuit Breaker pattern to “protect” AWS Lambda function calls. When connecting back to legacy systems not designed to provide the same levels of responsiveness we have come to know and love from our utility-based compute, it’s an inevitability that Lambda functions are going to be impacted by external latency.

Figure 3 – Circuit Breaker trips on call timeout to microservice.

To mitigate this, the Lambda function would keep track of the number of failed API calls in a DynamoDB table, adding increasing pauses between retries. Once the number of failed calls reached a certain threshold, the circuit would “trip” and redirect to a fallback service (or respond with an error if a failback service was not available) until the remote legacy system was available once more.

By configuring Lambda functions with the DeadLetterConfig parameter, Dead Letter Queues were used to direct unprocessed events to an Amazon Simple Queue Service (SQS) queue for failure analysis.

The Initial POC

Another benefit of our AWS Serverless approach was how it enabled the migration to be phased. Not only were we able to test a small piece of functionality, we also routed just a small subset of users to the new component. This approach ensured any issues with the new component would have a minimal blast radius and would be simple to roll-back.

The customer set an initial POC target of 3,000 users with a defined set of functionality that mirrored their current usage. By adopting the principles, patterns, and approaches outlined in this post, this was achieved within two months.

Performance improvements were realized immediately; customers could add unlimited items to the basket without hitting a performance penalty, the process time reduced from eight seconds to a consistent 400 milliseconds. Cost savings have been significant and enabled the customer to reinvest .

A Driver for Organizational Change

It’s fair to say the work undertaken by BJSS in collaboration with the customer has proven to be an outstanding success and serves as a great example of the benefits the AWS Serverless Platform and cloud-native delivery. In addition to a great technical delivery story, the project has also brought about less tangible benefits.

The operating model surrounding the legacy e-commerce platform, and the wider IT organization, made change difficult. Additional features were submitted as change requests to an offshore vendor team, and this would inevitably lead to long lead times and large, risky deployments.

Release processes were onerous and bound to ITIL processes that couldn’t support the business requirement for agility. Rather than trying to impose a new operating model across the IT organization in one big bang, the serverless/strangler delivery approach allowed us to incrementally embed new agile processes.

As new technology and processes were rolled out, roles within the organization were created or adapted. The requirement for training engineers on AWS is a straightforward process given the excellent training materials generally available, but those engineers also had to adapt their skills in other ways.

Rather than a team of subject matter experts looking after specific technologies such as wintel, networking, middleware, or storage, they had to understand the full stack. Fixing an operational issue would now be resolved by changes to automation code rather than manual corrections. Disciplines traditionally restricted to development teams, such as code quality, are now the domain of the Platform Engineer.

Of course, engineering was the most visible change, but the impact was equally felt in finance where new processes were required to realize the benefits of utility-based compute; in project management where kanban boards and sprint planning replaced gantt charts; and in business analysis where user stories replaced long drawn out requirements gathering.

Conclusions

It’s critical to have a clear strategy. We were fortunate to work with a customer that had a clear sense of the target business outcomes. This allowed us to quickly provide confidence that the technology and delivery approaches we proposed would align with these goals.

Serverless technology is often perceived as the domain of the greenfield solution developer, or the end-game in the continuum from virtualization to containerization to function as a service. In this particular case we “jumped over” containers all together and demonstrated that serverless can be used to solve different kinds of problems.

Delivering value early was essential. When attempting to deliver changes that have a wide ranging impact, there will inevitably be stakeholders who are less enthused than others. Overcoming this would have undoubtedly been more difficult without the AWS utility-based cost model.

As we progressed through the engagement, the monolith was gradually strangled and a continuum of improvements have been delivered. Perhaps the most beneficial aspect of the delivery has been the change in mindset and approach, and serverless patterns have been a core driver of this change.

Additional Resources

• Martin Fowler’s articles on serverless provide a great introduction to serverless concepts and patterns.
• BJSS whitepaper examining AWS Serverless performance profile in the context of systems requiring synchronous interaction, AWS Lambda chaining, or low latency response.
• BJSS Cloud Readiness eBook details our approach to enterprise cloud adoption.
• An eBook detailing the award-winning BJSS approach to Enterprise Agility.

The content and opinions in this blog are those of the third party author and AWS is not responsible for the content or accuracy of this post.

.

BJSS – APN Partner Spotlight

BJSS is an AWS Competency Partner. A strategic delivery partner for customers in public and private sectors, BJSS delivers a range of technology and cloud services across solution delivery and service management.

Contact BJSS | Practice Overview

*Already worked with BJSS? Rate this Partner

*To review an APN Partner, you must be an AWS customer that has worked with them directly on a project.