Case Studies

CASE STUDIES

Cloud Landing Zone

A large enterprise experienced scaling problems in the way their cloud infrastructure was provisioned and managed, as their cloud adoption grew. Manually triggering deployment scripts was no longer sufficient - it made it difficult to maintain the growing collection of accounts and environments, there was no insight to the deployment history, and the use of infrastructure-as-code was unenforced and sporadic.

  • AWS - Cloud Landing Zone
  • Migrate from manual/scripted deployments
  • Centrally managed cloud infrastructure
  • Infrastructure-as-code, CloudFormation
  • Deployment history
  • Self-service cloud
  • Centralised security baseline
Summary

The customer needed an approach that would allow them to maintain a central definition of their entire cloud platform as code, and provide a robust, versioned deployment pipeline. Implementing a Landing Zone for their cloud platform would enable their utilisation of the cloud to grow without creating an additional burden of management for each additional account or resource. A solid deployment pipeline would also have to be incorporated to provide assurance of conformity and security for the landing zone's automation.

The Challange

A complete picture of the current deployment practices had to be painted in order to correctly implement a suitable landing zone. The customers particular requirements had to be understood so that a customised landing zone solution could be designed and implemented. The current practices had to be fully documented to ensure that nothing would be missing from the new implementation. Furthermore, the new architecture was designed to encompass all the current features of the customers environment while incorporating a new way-of-working based on the GitOps paradigm - every change to the super-infrastructure or its components should be initiated from the code repo acting as a single-source-of-truth. Using the framework of the AWS Landing Zone solution, an appropriate design for their current and future infrastructure was drawn up.

During the implementation of the landing zone, several issues were encountered that added challenges to the project. Many of the baseline resources utilised in the customers accounts were using cloudformation incompatible AWS API calls, so a way had to be found way around that. In the end, custom resources were heavily utilised to provision the necessary resources and configurations, which required careful design of the resource CREATE, UPDATE and DELETE methods to ensure that proper idempotency was maintained throughout.

Some of the baseline resources required a synchronised procedure of steps with core accounts. In order to maintain the immutability and idempotency of the baseline resources, this was provisioned using cross-account roles, allowing the baseline resources to be self-contained resource definitions.

The existing code repository of the customer did not provide or integrate well with any suitable CI/CD tooling, so the code repo was moved to a self-hosted Gitlab server. This meant that Gitlab's native CI/CD could be leveraged to complete the deployment pipeline, using several custom-made components to complement the customers particular use cases.

The Solution

The final implementation of the Landing Zone allowed the customer to provision new accounts in a simple way using an Account Vending Machine. This collection of lambda backed custom resources allowed the automated creation of AWS organisation accounts which had a baseline of AWS resources. These baseline resources provided for such things as:

  • Managed account access via ADFS single-sign-on
  • A choice of several default network topologies e.g. VPC with 2 private and 2 public subnets
  • Several baseline security measures e.g. AWS Config rules, IAM boundary policies, Guardduty
The Account Vending Machine was provided as an AWS Service Catalog product, which allowed the AVM to be shared with nested Organisation Units (OUs). Thus provisioning of new accounts could be delegated to other business units in a self-service manner, while still enforcing the mandated security baseline for every new account. Furthermore, any updates applied to the AVM's baselines would be automatically inherited.

Automated compute grids

By using automation, researchers are able to run high performance compute workloads with zero effort while also providing cost- and security controls.

  • Microsoft Azure
  • Terraform
  • Gitlab CI
  • Azure Batch
  • Ansible
  • Azure Functions
Summary

A research institute was triggered for Cloud migration because the old compute grid was end of support / service life. This international team of researchers used this compute grid for various kind of scientific use cases. Some of these workloads ran for long periods of time. By running an MVP with Azure Compute and Azure Batch showed the immediate value of using the public cloud platform for these workloads. This made their decision to move these activities to Azure.

The Challange

Create the tools and services for researchers to run their workloads in a consistent way on Azure. Help sizing their workloads and make use of cloud services, like Azure Batch, Azure Functions and more. Cost and security controls should be in place. able to autonomously deploy changes to various environments on this platform.

The Solution

At first we have created the solution design that defines all services, components, networking requirements, naming and tagging conventions. We created their complete landingzone with Terraform, Ansible (+AWX) through automated CI/CD pipelines in GitlabCI. For different research groups we defined blueprints, which could automatically be deployed based upon input parameters. The blueprints contains automatically created dashboards and billing alerts so research project leaders automatically got control on their budget and resource allocation. Secure access to the platform was provided through on-premise Site-to-Site VPN connectivity as well as a Point-to-Site VPN solution for remote workers. By making use of these cloud services we achieved a significant reduction in the durations of these workloads while also saving costs. For example, the runtime of a specific calculation was reduced from 2 months to 46 hours.

Lift & Shift

Migrating from a, private, on-premise cloud to the public cloud. Embracing all new benefits and being able to make use of big data platforms. We started with the designs and ended up shutting down the on-premise cloud.

  • Lift and Shift
  • Private Cloud
  • Public Cloud
  • Amazon Web Services
  • Infrastructure as Code
  • Scalable
  • Flexible
  • Cost Savings
Summary

Customer decided to make the move to the public cloud to be more flexible, scalable and have more control over costs. Customer wanted to be able to make use big data platforms, machine learning and AI.

The Challange

Due to very strict timelines we had to work quickly in order to reach the deadlines of migrating to Amazon Web Services. Every delay would bring extra costs by extending their current contracts, also the duration of the lift and shift operation would mean extra costs by running their infrastructure in parallel. Large parts of their application landscape was not 'cloud ready' yet and we needed to find ways to properly deal with that without making compromises to availabilty and performance.

The Solution

By writing out their infrastructure as code that was kept in source control we made it possible to work simultaneously and even made their development team able to collaborate. Writing infra-as-code made enabled us to re-use large parts within the different stages of DTAP. Next to the inra-as-code we used configuration management tooling and software to automate the creation of 'golden machine images'. By using this combination we got the ability to make the infrastructure push button deployable which saved a lot of time and made deploying > 100 ec2 instances a breeze. The architecture was monitored with DataDog and logscraping was done with an ELK stack. From this point we were able to transform legacy applications into cloud native solutions. Lowering cost and increasing the cycle team of their development teams.

DevOps automation

A large company running legacy IT systems were on the verge of renewal. Mainly due to expiring support on multiple components, like the old virtual infrastucture, software and more. That was a call for action. The internal cloud platform needed to be renewed, using latest automation standards.

  • Re-platforming
  • Automation
  • Private Cloud
  • Infrastructure as Code
  • Scalable
  • Configuration Management
Summary

A large scattered environment running various applications on private cloud. Most of the applications were manually managed without any modern tooling. The IT organisation was traditional, where very team was working in silo's. A paradigm shift was needed to renew both the internal processes as the IT platforms used. Therefor a private cloud solution was created with a complete automation suite. On top of that configuration management and remote execution tools made sure that their new application landscape converged to latest standards.

The Challange

This migration faced multiple challenges. Organisational ones as well as technical challenges. A new cloud platform, with automation features was set-up, ready to be used. More than 200 applications needed to be migrated. For this a lot of building blocks were missing or incomplete. Next to these technical challenges we faced their organizational struggles. A lot of teams, working in their own silo, needed to work together.

The Solution

We introduced the DevOps way of working. We started to use Agile Scrum and helped setting these processes up. We coached their internal people and advised on their organizational challenges. Their new private cloud infrastructure had all components to be fully automated. The only things missing where building blocks for the various types of applications. Configuration management and remote execution software were introduced. Together with their newly formed DevOps teams we created the building blocks and consulted on various topics. Slowly we were able to create more velocity during the project. Mainly due to the re-usability of these building blocks.

Service Catalog on AWS

Customer wanted to enable its users the freedom to create, manage, and take ownership of infrastructure as part of the Service Catalog in the AWS Cloud. The goal was to remove the manual overhead and setup a fully automated deployment of portfolios and products via CI/CD Pipeline.

  • Service Catalog
  • Automated CI/CD Pipeline
  • Self Service
  • Amazon Web Services
Summary

Our team had limited time to implement the project. We had to strictly follow the schedule and think every step of the way twice prior to implementing. Our client had number of AWS accounts which had to be taken into consideration, making sure that all resources are correctly provisioned, monitored, and secured. Creating, importing, and sharing all products and portfolios with multiple AWS accounts had to take part of the fully automated CI/CD pipeline and version control system that our client had in place.

The Challange

We gathered all necessary information from the customer. Big chunk of the AWS Service Catalog depends on AWS Cloudformation stacks and our team has started creating all portfolio and product templates from scratch. Being successful with this task, we’ve started working on the CI/CD and created a stable automated pipeline that allowed the management of the catalog easily. Applying constraints and specific group of users working with the catalog was a priority. We’ve minimized the time and cost of AWS resources provisioned by the Service Catalog drastically. We’ve given the users the ability to manage their own resources and take responsibility. Notifications are being sent for all infrastructure running reminding users about that. Each resource can be monitored individually, thus providing security and separation.

The Solution

We introduced the DevOps way of working. We started to use Agile Scrum and helped setting these processes up. We coached their internal people and advised on their organizational challenges. Their new private cloud infrastructure had all components to be fully automated. The only things missing where building blocks for the various types of applications. Configuration management and remote execution software were introduced. Together with their newly formed DevOps teams we created the building blocks and consulted on various topics. Slowly we were able to create more velocity during the project. Mainly due to the re-usability of these building blocks.

goToTop