Introduction to Cuckoo's Cloud Strategy

Cuckoo was founded in early 2020 with the aim of becoming Britains best Internet Service Provider (ISP). To help us achieve this goal we adopt both a Cloud First and Serverless First approach to technology. In this article I’ll cover what exactly that means and how we go about it. 

In years gone by companies would purchase, run and manage the servers their software ran on. This would be done on-premise in a mini datacenter setup just for themselves. They would have to consider upfront how much compute power and storage they’d need. Often this would lead to overspending on hardware in an attempt to future proof their capacity. Not only that, they would need in-house expertise to manage such things as networking, storage backups, redundant power, operating system (OS) upgrades etc etc.

Amazon were all too aware of this from their own experiences. So they set out to offer IT infrastructure services to businesses, now commonly known as cloud computing, and hence Amazon Web Services (AWS) was born. Companies no longer needed to make upfront costly infrastructure decisions, rather they could pay for what they use and services could scale inline with the demands of the business. Fast forward to today and AWS is comprised of over 200 such services.

Cloud First at Cuckoo means cloud services are preferred and considered before any other options. AWS is key to this strategy and is the backbone of our technology platform. Additionally we favour Serverless technologies wherever possible as it allows us to run our applications without thinking about the servers they run on. Some other benefits of Serverless include a “pay for what you use” pricing model and horizontal scaling based on workload.

We find that Serverless naturally helps us model our software better, by encouraging the breakup of workloads up into smaller logical chunks that can be parallelised. Some of the key AWS services we use in this space are:

• Lambda
• SQS
• AppSync
• EventBridge
• Step Functions
• plus many more…

In order to manage and provision these systems we practice infrastructure as code (IaC). This means we maintain a set of machine readable files describing exactly what services to provision, how they’re configured and what security permissions apply etc. This approach ensures we have reproducible environments at the click of a button practically, and protects us against unintended changes (either accidental or malicious). We store these files in version control alongside our regular source code, meaning we inherently maintain a version history of what has changed and who made those changes.

Our choice of tool for IaC is the AWS Cloud Development Kit (CDK). The main advantage of the CDK for us is that we’re able to use a familiar programming language. In our case this is TypeScript but it also supports other languages like Python, Java, .NET, and Go. With all the features of the programming language you chose at your disposal, you’re able to easily setup what would otherwise be complex infrastructure. The documentation is also excellent. It’s a great product and I highly recommend you give it a chance. One drawback of the CDK is that it only deals with AWS, unlike Terraform for example, but for our use case this isn’t an issue.

All the pieces outlined above play an integral part in our bespoke technology platform and wider cloud strategy. They helps us deliver (at pace) a highly secure, available and resilient platform. 

If you’d like to help us redefine what people can expect from their broadband provider, we’re hiring for a number of positions at the moment. Go check them out!

https://www.cuckoo.co/careers