Search for a command to run...
I'm currently an Engineering Manager at Skutopia looking after our Shipping Platform product vertical.
I'm working to scale our engineering teams, give our current engineers the skills to be our future leaders, as well as promoting a positive culture where we can all learn, develop, and grow.
No comments yet. Be the first to comment.
The series will explore the tooling we use at Skutopia to improve and simplify engineering
At Skutopia we have recently migrated off our legacy enterprise platform for managing alerts, on-call and incidents. We now have a modern platform thanks to incident.io. The benefits we receive are immense. Incident.io One Platform to Rule Them All ...
The setup During a "Papercut Friday" at SKUTOPIA, I wanted to optimise the startup time of an event sourced service. The setup was as follows: In-memory projections, built every time a NodeJS container starts. A Postgres event store with ~2.5 milli...
It is not just about writing technical documentation.
At Skutopia we provision and manage our cloud infrastructure (GCP) using Pulumi. In the past I have provisioned infrastructure with tools such as CloudFormation (both when it had to be json 😭 and in the more modern yaml structure), Terraform, and no...
At Skutopia, we wanted to get in-front of developer experience as we started to scale. After a vendor selection process we settled on using Swarmia as our platform. Swarmia allows us to have engineering surveys as well as DORA and SPACE metrics all i...
Skutopia has moved to a GitHub Codespaces first environment for developing applications. Codespaces allow us to have a common development environment where problems are solved once and applied for everyone. Onboarding is a breeze as we no longer have to remember that one random setting that fixed an issue six months ago.
The benefit of a common development environment is a reduction in friction, and if something goes drastically wrong it's a case of minutes not days to set yourself up again.
By having a uniform environment
We know that every engineer has a working and aligned environment at any given time.
We know that if we upgrade the runtime, all of our engineers can have this upgrade in minutes.
We know that all of our engineers have access to the plugins and extensions that are relevant.
We avoid issues of "it's working on my machine" as we all have the same machine.
If there were issues, we can quickly decipher if it is someones environment by creating a fresh one on demand.
Historically when an engineer joins a company they install their IDE. They then install a bunch of plugins to make coding easier. Inevitably they will install the latest runtime version. They will clone the repo, it won't work, and eventually they will find that application runtime is a version of two behind.
Now that we have wasted a few days, and a number of engineering hours as everyone in the team tries to crack the problem, we finally have a working environment.
Codespaces changes all that. Due to the uniform environment mentioned above, our engineers on day one create a codespace environment. Everything they need is installed and configured in a bootstrap script. Ten minutes later they have their environment up, running and ready for them to ship code.
The benefits far outweighed the drawbacks for us. To be transparent I will look into some of these
Using Codespaces does have a financial element to it. We are offloading our development environment to a cloud hosted virtual machine, that we pay for. For us the monthly cost is well and truly offset by the improved developer experience.
Being cloud hosted this did mean that we had some delay and lag. There is limited bandwidth and slow downloads. This could be a bit of a pain when you quickly want to install a sizeable package. There is also limited disk space so we did need to be mindful of how much we installed, or how many docker images we had.
We have now moved to fully local Codespace environments. What does this mean? A codespace is effectively a linux container running in the cloud. We now run that container on our local machines. We keep all of the benefits we have found from using Codespaces but reduce the downsides.
We still have a uniform environment that updates in minutes
We no longer pay for virtual machines in the cloud
We no longer have the same performance issues
The only down side of running locally is that we can't dynamically increase resources. We are constrained by our physical machines. In saying that, we haven't had performance issues so far.
We have moved from old convoluted development environments where we needed to install and configure everything on local machines. We now use GitHub codespaces to have a uniform environment where every engineer is running the same versions and configurations. This has made onboarding and new environments a click of a button. We found some drawbacks in cloud hosted Codespaces, and we overcame them by running Codespaces locally without any real downsides.