WELCOME TO SATELLITE-X
Satellite-X is a private company that offers consumers personal satellites. The purchase of a personal, private satellite includes launching it into a stable low-earth orbit, and a 5 year guarantee for it to remain in orbit and functional. Satellite-X is popular with the super rich who never want to be without the internet, and who like to scan the planet for places to build their next mansion.
Personal Satellites?!?
Okay, so in case you haven't guessed it already, Satellite-X is a fictional company. I happen to work for a very non-fictional company though called CodeZero, and we make a developer platform for Kubernetes, which includes a CLI tool and an installable desktop application. In our experience our platform can lead to a 10x increase in developer productivity. One of our challenges has been, however, explaining to people - technical and non-technical alike - just how this boost in productivity is achieved.
I had the idea of using a mock company to illustrate how using CodeZero during a typical product development life cycle can greatly shorten the developer feedback loop and lead to a significant increase in velocity. Let me know if this invented company and use cases works for you as a way to communicate some pretty technical concepts. I'd love to get your feedback.
Use Cases
I came up with two use cases to explore the workflow for both a front-end and a back-end developer. One developer will solve their problem using CodeZero’s teleport tool, which allows you to test local code that relies on calling services running in a Kubernetes cluster. The other developer will solve their problem using CodeZero’s intercept tool, which allows you to route remote in-cluster traffic to a service running locally.
Let's meet the developers:
Samantha, or Sam, is a front-end developer at Satellite-X. She works on the company’s web application, called SatelliteVision, that consumers use to control and manage their satellites. With the app, users can tell a satellite camera to point at specific coordinates and take pictures, turn on and off their internet broadcast, and send messages into space for any listening aliens.
Roger is a back-end developer at Satellite-X. He works on the company’s proprietary satellite navigation system that is responsible for keeping satellites in orbit, at least until the end of their warranty period, and making sure all the personal satellites don’t crash into each other (or other company satellites, or space trash).
ARCHITECTURE
Satellite-X recognizes that security is paramount to its clientele, and so every satellite includes its own on-board infrastructure consisting of a high availability Kubernetes cluster. Satellite-X also has a robust microservice architecture running in the cloud (on earth) that coordinates with all of the satellites and runs the SatelliteVision app.
The details of the infrastructure are as follows:
TerraFirma Application: The earth-bound software application consists of the SatelliteVision web app and a number of back-end microservices, including:
- An API service to handle requests from the SatelliteVision app.
- A service to interface with the satellites in orbit.
- A security service. The security software came bundled with the motherboards used in each satellite. The software’s documentation is in Russian, but it works flawlessly so it continues to be used, although no developer wants to touch it.
Satellite Application: Every satellite runs its own microservice architecture. Notable services include:
- A sensor service.
- A navigation service that makes decisions on the trajectory of the satellite.
- A thruster engine service that controls the satellite’s speed and direction.
- A service to talk to the TerraFirma application and receive software updates.
- A security service. The satellite part of the Russian-made software.
FRONT-END USE CASE
The Problem
A new version of the SatelliteVision app was released recently, and it was quickly discovered that it shipped with a severe bug: When a customer using SatelliteVision instructed one of their satellites to take a picture, the app was instead sending a request to the API to delete the last picture it took. Customer complaints were piling in.
The Setup
Sam is assigned the task of fixing the bug as soon as possible. She checks out the main production branch from Git for the SatelliteVision application, and gets ready to fix the code. Running the web app’s front-end code locally in a browser is straightforward, it’s just HTML, CSS, and JavaScript, but it needs to talk to a fully functional back-end to work. Before CodeZero, Sam had to run mock services locally for all the required back-end services, and tell her locally running front-end code to talk to them. All the services are in Docker containers, so it wasn’t the end of the world, but there was always some back-end service that failed to start for some reason, and the security service was infamous for being especially finicky.
Today, though, Sam has the CodeZero Desktop application installed on her machine. And she has a development profile ready to go for teleporting into the Kubernetes namespace that is running the production TerraFirma application.
The Solution
The CodeZero Desktop app is already running on her machine (she rarely closes it), so she clicks on the tray icon to open the dropdown menu. She hovers over the Configuration menu option to make sure she is pointing to the correct cluster, but she notices that she is in the wrong workspace. Using the tray menu she quickly switches to the SatelliteVision workspace, and then selects the “front-end-dev-teleport” option from the available development profiles.
Sam opens up the Desktop dashboard UI and sees her teleport session starting up. Once the UI updates to show the teleport session running as expected, she opens up her terminal application and runs the yarn command to start up the web app’s front-end.
Debugging locally in her browser, she discovers that someone mistakenly changed the “take picture” button’s action to send a DELETE request to the API instead of a POST. She fixes the behavior and then tests it. Since she is teleported into the production cluster, any actions she takes in the locally running web interface will apply to live systems, but this is what she wants — Sam wants to ensure her changes will work once deployed. She wants to know this fix will work on real satellites. She double checks that she is logged into Satellite-X’s test account, selects a satellite, and directs it to take a picture of the Himalayas.
Nothing happens.
At least the last picture taken with this satellite wasn’t deleted, but a new picture wasn’t taken. Sam goes back to the JavaScript that runs when the button is clicked and finds the error: a missing await on an asynchronous call. This bug might not have resulted in an error if she was running the back-end code locally, but with the latency inherent in communicating with an orbiting satellite, it certainly manifested in Sam’s test. She fixes the code and tests again.
Success! On her screen she sees a high-res satellite image of the Everest base camp.
As a final step, Sam commits her code and creates a pull request to the main branch. Once merged it will trigger their CI/CD pipeline to automatically deploy. All in, Sam’s turnaround to identify the bug, fix it, test it, and deploy the fix to production: 15 minutes. This would have taken significantly longer without CodeZero.
BACK-END USE CASE
The Problem
When the satellite navigation system software was originally written, its collision detection algorithm was set to monitor for objects of a certain size. Objects under the specified size were not considered a threat to damaging the satellite, and objects meeting or exceeding the specified size would trigger evasive maneuvers. Recently, some bit of space debris from an old exploded satellite collided with one of Satellite-X’s satellites and damaged one of its solar panels, and it is believed that the object was smaller than the current threshold.
The Setup
Roger is assigned the task of updating the navigation system microservice to look for and avoid smaller objects. The code change is trivial — it’s just some simple math — but it needs to be tested in an environment that is as close to production as possible. Roger learned early on in his time at Satellite-X that code running successfully in a satellite simulator on earth is not the same as code running on a real satellite in space.
Before CodeZero, Roger had limited options for replicating a satellite’s deployment environment. So a typical development cycle would consist of develop & test in simulator -> deploy to satellite -> test -> repeat if unsuccessful. A deployment to a live satellite takes about 40 minutes, so if the feedback loop had to be repeated a number of times, it could easily take Roger all day to get out a small change.
Now Roger has the CodeZero CLI installed on his workstation. With this tool he can reduce the feedback loop significantly.
The Solution
The collision detection system is fairly straightforward. Sensors on the satellite continuously scan the surrounding space for objects within 500km or closer. When an object is detected the sensor service passes on the telemetry data to the navigation service, which calculates the object’s trajectory, size, and speed. Objects of a certain size on a collision trajectory cause the navigation service to tell the thruster engine service to initiate an evasive maneuver.
The first thing Roger does is log into the company’s intranet and download the kubeconfig file for a cluster running on one of their test satellites. He then launches his terminal application and sets his Kubernetes context to this cluster. Next Roger grabs the latest code for the navigation microservice and gets it running locally.
Roger wants to direct all communications coming from the sensor service on the satellite to the navigation service he’s running locally. He runs a CodeZero CLI command to intercept all traffic destined for the navigation service. He sees the telemetry data from the in-cluster sensor service begin streaming to his service running locally, and this local service in turn communicating back up to the thruster engine service running in-cluster on the satellite.
Roger switches to his IDE, makes some small changes to the navigation service’s collision detection algorithm to look for smaller objects, and moves on to testing. He could wait for objects to inadvertently get in the way of his satellite, but luckily the satellite is equipped with a program for rendering debris in front of the cameras to accommodate what Roger needs to test. He launches the program and objects of various sizes start appearing in front of the satellite’s cameras.
The sensor service on the satellite does its job, scanning the objects that appear, but because of Roger’s intercept, it sends its data to his locally running navigation service instead of the service running in-cluster. An object appears in line with the satellite that used to be under the size threshold.
The satellite doesn’t change course. And according to the data it should have triggered an evasive maneuver. Test failed.
Over the course of the next 30 minutes Roger tweaks the collision detection algorithm repeatedly, testing after each change, until he finally nails it. What he thought was simple math turned out to be not that simple when running in a real-world scenario.
Satisfied with the new code, Roger closes the intercept session, commits his code, and creates a pull request. Once merged a new deployment will be triggered to this satellite’s cluster including the updated navigation microservice. Eventually this update will get pushed out to all the company’s satellites.
All in, Roger’s time to develop, test, and finally deploy the change to the satellite: 1.5 hours. If he had had to deploy the code changes to the satellite’s cluster each time before testing (each time being a 40 minute operation), this exercise would have taken Roger all day.
CONCLUSION
What do you think? My hope is that the front-end and back-end developer use cases demonstrate some scenarios under which CodeZero can really save developers a lot of time and frustration. Even though I described fictional scenarios, my hope is that you can identify some comparable workflows in your own development feedback loop, and now have some clear insight into just how powerful CodeZero’s tools can be. By removing the deploy step from each iteration, the productivity gains can be tremendous. Especially if you are deploying your code into outer space. ;-)
Top comments (0)