Customer Challenge

As a web solutions provider with a long history – and one addressing the substantial needs of clients with complex online requirements – Silverstripe found itself with clients on multiple legacy platforms, with websites and associated infrastructures at varying degrees of maturity and modernity. As a strategic priority, the company sought standardisation on a single platform and identified AWS as the preferred target.

“We have many clients looking for onshore cloud with infrastructure and platform as a service,” says Silverstripe CEO Tobias Oschwald. “With multiple platforms, we require multiple skills sets; even across two providers, there is added complexity in maintenance, and it rapidly results in considerable technical debt in terms of keeping up with the latest versions. And it stifles innovation; if we have a single platform offering a full set of features, we can innovate across our entire customer base, rather than for individual clients.”

However, Silverstripe faced a potentially monumental amount of complexity in migrating its customers, given that each ‘lift and shift’ might be a substantial project. It sought assistance in the creation of an automated framework accelerating the migration from legacy hosts into AWS.

Partner Solution

With considerable complexity involved in designing and delivering an appropriate framework which would guide every future migration from legacy private cloud hosts into the AWS environment, Silverstripe asked AWS itself for a recommendation of a suitable local technology partner. Lancom Technology was nominated and soon proved an appropriate fit for Silverstripe from a technical and cultural perspective.

Silverstripe Technical Director Jackson Darlow says the work predominantly involved solutions and cloud architecture underpinning the framework design, then creating the sandboxed result ready for platform architecture and engineering. “Lancom brought a lot of capability from high level management of technically complex work to iterative programme management in an agile format where we were the product owners,” he explains.

In a project executed over 6 months, Lancom’s AWS team combined systems engineering with its technical capabilities in working with AWS services and microservices, systems administration and architectural skills covering server management, computational management, database management, network engineering, and Continuous Integration/Continuous Development skills. Darlow adds that Lancom’s expertise was clear in working closely with AWS-driven cloud pipelines providing workflow automation and integration automation. “A large component at the core is Infrastructure as Code. For our requirements, this is a fundamental skillset delivering cloud provisioning and infrastructure management assets into a single codebase library.”

Primary AWS services used include:

• AWS Control Tower: Deployed as a landing zone with the ability to deploy policies across all AWS accounts and simplify onboarding of new AWS accounts as required in the future

• AWS Organisations: Resource tagging policies implemented so all resources meet defined tagging rules, with alerting/reporting for any resources not matching the defined tagging policies

• AWS IAM Identity Center with external Identity Provider: SSO configured with an external Identity Provider, allowing Silverstripe team members to access AWS accounts/roles based on group membership. The existing Identity Provider allowed the Silverstripe team to use corporate accounts to access AWS, while enforcing existing security policies (password expiry, MFA etc).

• AWS IAM: Various IAM policies deployed across AWS accounts, both roles which staff access via AWS Orgs and roles used by services for RBAC (i.e. containers ability to mount EFS shares, CodeBuild ability to consume and upload S3 objects etc).

• AWS VPC: Provided both the centralised egress/Transit Gateway VPC, as well as one VPC per AWS account/cluster to host the various services such as ECS, RDS etc.

• AWS NAT Gateway: Deployed into a centralised egress VPC and paired with Transit Gateway to provide a centralised network egress/exit point for all AWS accounts.

• AWS Transit Gateway with RAM Share: Deployed and shared between AWS accounts in the AWS Organisation to enable VPCs to be able to use the NAT Gateway/egress network for internet access.

• AWS ElastiCache for Redis: Used as a shared session storage location for PHP sessions.

• AWS Aurora: Deployed using Aurora Serverless v2 as the database tier hosting platform. Serverless was configured to allow for seamless automatic scaling of reader nodes

• AWS ALB: Deployed to provide TLS termination between the external CDN and AWS. ALB rules configured to route traffic to the relevant backend containers based on a host header appended to all inbound requests from the CDN to the ALB.

• AWS Certificate Manager: Generates certificates for the ALB to provide TLS termination/secure traffic between the external CDN and AWS.

• AWS EFS: Storage tier for persistent media assets uploaded and served by the application. EFS allows multiple containers to mount and utilise the share.

• AWS ECR: Used for container image storage both for generic base images as well as customer specific container images.

• AWS ECS Fargate: Used as the main compute platform, with container images running Apache/PHP for the web tier. Auto scaling configured to ensure the number of containers running for a given customer scales automatically based on load.

• AWS Secrets Manager: Used to store passwords such as database credentials, consumed by the containers to ensure no credentials were stored in an insecure manner.

• AWS S3: Used as a storage tier for various services, but primarily used for application code package input and output artifacts (CodeBuild).

• AWS CodeBuild: Provides a controlled build environment for container images as well as application packages.

• AWS CodePipeline: Configured to provide triggers and manual approval steps for deployment to production (configured alongside CodeBuild).

• AWS SNS: Configured to send notifications for various services/approval steps.

• AWS Backup: Configured to take backups of persistent data points, such as AWS Aurora and AWS EFS.

• AWS CloudWatch Metrics/Logs: Metrics collected by various services to provide performance insights as well as allow for automatic scaling. CloudWatch logs configured as a log storage location for various services such as Fargate, Aurora and CodeBuild.

The results

Oschwald describes the creation of the migration framework as ‘technically sophisticated’. “Lancom worked iteratively through multiple workloads, implementing architectural structures and services supporting the eventual fully functional migration of Silverstripe assets to AWS.”

He adds that with the initial scope anticipating delivery over 8 to 9 months, completion was ahead of expectations. “With such a complex challenge, a flexible approach was invaluable. Assumptions at beginning might not work in practice, so an open relationship helped steer in the right direction and ultimately to a successful conclusion.”

With Lancom Technology’s support, Silverstripe has completed the first essential steps in the longer-term strategic initiative of platform standardisation. “In effect, the preparatory work is done and now we are campaigning with clients to move towards AWS, and enjoy the advantages available on that platform,” says Oschwald. “Attempting this journey on our own would have required a massive internal effort; Lancom has created automation and a well-architected framework which brings forward our plans and will accelerate our move into the AWS cloud.”

Darlow says both cost and risk would have exceeded Silverstripe’s appetite for tackling the migration without expert assistance. “We needed a highly capable service partner working closely with us for an effective outcome. The sheer complexity and scope of the challenge means we probably couldn’t create these automations and a well-architected framework without Lancom. We have a degree of confidence and satisfaction in the work done to date, with the scope delivered which we can now use as a foundation towards complete maturity for our migration services which will start moving customers to a modernised platform.” 

While Darlow says there is ‘always an active workload’ when it comes to migration off legacy platforms, he says the framework delivered with Lancom Technology’s support will kick into higher gear a the beginning of Financial Year 2025.