PostNL shared insights and guidance from its transition from outsourced IT project delivery to an in-house product delivery capability. By embracing cloud-native technologies, with an emphasis on serverless services, the company achieved significant gains in productivity and market responsiveness while reducing operational costs.
PostNL is the largest logistics company in the Benelux and has been operating since 1799. In 2012, the company committed to a 100% cloud strategy and subsequently decided to bring all software delivery in-house to build competitive logistical software rather than rely on off-the-shelf products.
To help build a successful internal software delivery capability, the leadership opted to provide clear guidelines and guardrails for standardization and adoption of best practices. At the same time, the company wanted to engage the engineering team to influence standards and guidelines and have freedom of choice in many areas that didn't impact the overall software delivery and cloud strategy.
Luc van Donkersgoed, Principal Engineer at PostNL and AWS Serverless Hero, describes the model for choosing technology and tooling solutions within the enterprise framework adopted by the company:
[...] In PostNL, technologies, products and services are categorized according to a 'fixed, flexible, free' model. In this model, the 'fixed' category contains topics that are standardized across the entire organization. The 'flexible' category contains ranges of products, services, and standards to choose from. Teams have the liberty to adopt any solution within these given ranges. The “free” category contains all other topics. Within this category, teams are free to decide what to use within the boundaries of their own budget, architecture and experience.
PostNL strategically decided to choose AWS as its public cloud provider and only use cloud-native technologies, specifically serverless-only services. To enforce this fixed decision, the company created the AWS platform team, named the Cloud Center of Excellence (CCoE), to assist engineering teams with leveraging the AWS cloud but also to prevent the use of undesirable services, like EC2.
The company decided to go serverless due to the variability of application workloads, including daily and weekly patterns, as well as the high usage holiday period, starting with Black Friday in November and ending with Valentine's Day. PostNL listed elastic pricing, effortless scaling, and utilizing the cloud platform to solve the hardest problems as the main drivers for adopting the serverless stack on AWS for the business's needs.
DynamoDB Autoscaling Capability (Source: PostNL Engineering Blog)
Given the variability of application traffic, PostNL leveraged DynamoDB as its primary database solution and configured autoscaling so that the provisioned capacity scales in response to the load with sufficient headroom to respond to any unexpected traffic surges. The company also benefits from the effortless scaling of AWS Lambda, where the number of invocations fluctuates daily and changes over months. Engineering teams use many language stacks with Lambda, including Typescript, C#, Rust, and Python, although the company also allows Java runtime.
Lambda Function Invocations (Source: PostNL Engineering Blog)
PostNL's serverless architecture utilizes many other serverless services from AWS, including Step Functions, API Gateway, and SQS. In specific cases, teams were allowed to use different services like RDS, Neptune, Timestream, or Fargate when preferred serverless choices could not address their needs.
Shifting from using external partners to internal development teams and adopting a serverless stack resulted in reduced overheads, better productivity, and lower operational costs. However, the transition didn't happen without challenges, like the need to upskill the engineering staff and provide support for junior developers. Additionally, given the learning curve for building serverless solutions, the company opted for a flexible approach, allowing teams to create solutions using managed services like RDS or Fargate rather than always insisting on purely serverless options.
Luc van Donkersgoed concludes the blog post by sharing insights with organizations looking to adopt serverless. The author advises considering serverless if it meets business goals and to start from the guiding principles. He emphasizes the need for automation around infrastructure provisioning, CI/CD, observability, and security. Companies should also embrace cloud platforms rather than just limit themselves to the lift-and-shit approach for cloud adoption and thoroughly analyze the total cost of ownership for their cloud architectures. Lastly, van Donkersgoed stresses the importance of constant learning, particularly considering the fast feature velocity of cloud providers.