By Leon Stepan, VP Ground Product and Brunston Poon, Satellite Ground Software Engineer
Even though we have satellites flying in space today, Loft does not have a satellite operations team. Instead, we have a culture that we call “SatDevOps”. If you recognize the DevOps part of that word, you’re onto something! Our approach to scaling our space infrastructure is influenced by how the software industry has scaled through the proliferation of cloud computing. For us, the scaling journey comes down to a single thing - culture.
Why SatDevOps?
The space industry has evolved both processes and best practices to accommodate large, expensive one-off missions. Companies have to build, produce and operate their own satellites, which take years or even decades to execute. Each satellite is designed around a specific concept of operations (CONOPS), which is difficult to scale.
We see the future differently. As the number of applications for capturing data about our planet increases, every company has the opportunity to become a space company. To make this future a reality, we need to redefine what a “mission” is and the operational paradigms around it.
First, let's start with our notion of a “mission”. We blend terminology from aerospace and software to describe the successful execution of a customer flow.
The focal point of the mission are the objectives executed by the payload. The payload can be anything from a camera to a software application running an algorithm in space.
Missions can be long, over the course of years, or short, over the course of months (or days!). When we decouple them from the platform (satellite) we’re flying, we can have many missions running on a single satellite, as well as single missions running on many satellites. We often compare our service to the software applications running on a cloud computing cluster.
You get the idea - we’re building a platform and, in our case, missions are deployed and executed on the platform.
So, what is SatDevOps?
We define SatDevOps as a set of practices, philosophies and tools aimed at shortening the systems development life cycle and providing continuous delivery with high-quality software within our space infrastructure ecosystem.
To create the fastest ride to space, we must be creative about removing any friction associated with getting there. We borrowed a few concepts from the world of DevOps, as we saw similarities in the frustrations from which it was born - namely, inefficiency between software developers and the guardians of production software environments (operators).
The DevOps model has been tried, tested and refined, and in the book Accelerate the authors provide an excellent appraisal and recommendation for technology companies looking to create high performing teams. We’ve embraced the fundamental tenets to build our SatDevOps culture, such as collaboration, automation, observability and metrics, and continuous integration and deployment. However, there are differences between satellites in space and terrestrial servers in a rack. We address those differences with detailed training to bridge any knowledge gaps.
Building a SatDevOps Culture
Be careful of the walls you build. We have never had a satellite operations team. Instead, we foster collaboration and accountability through cross-functional participation and training. Everyone, from our executive team to our developers, is bought in on this cultural decision.
Be deliberate in what you incentivize. We intentionally started building automation into every process to ensure we were ready to scale from the beginning. While this took more time up front, it was better than trying to apply it retroactively.
Be willing to try new things. Without night shifts or long hours in front of a console, our team was able to think bigger than the next pass over a ground station. We got comfortable with the fact that this was different from the “normal” way to do satellite operations, because it would allow us to scale.
SatDevOps in Action
We’ve flown over 10 missions (and counting!) and our SatDevOps culture enables us to focus on the mission, while still reliably operating satellites. Whether we were flying an imaging payload for NASA to increase technology readiness level, an unnamed IoT customer that wanted to conduct a RF spectrum survey across the globe, or Ball Aerospace evaluating software using Loft satellites and our Cockpit interface, we’ve scaled our ability to support each of these missions from the same satellite (YAM-5).
In future blogs we’ll dive deeper into our software-centric approach to satellite operations, including infrastructure-as-code, CI/CD tooling, test automation, and the work we’re doing to support “virtual missions”. It’s time we treat our satellites as cattle, and not as pets 😉.
More to come!