Member Blog Post
Guest post originally published on Carbon Relay’s blog by Brad Ascar Sr. Solutions Architect, Carbon Relay
I make my living in the software business. I started out as a software developer, moved up to systems engineering and product management, and then on to solutions architecture.
It has made for a great career, but I’ll let you in on a little secret. My true passion is cars and racing. That’s right, I’m a race car guy at heart.
Spending time in both worlds, I started thinking about the changing requirements we often get when we’re creating applications or solutions. Having built and modified a few cars of my own, I also considered what a similar approach would be like for teams building race cars. Challenging is the word that comes to mind. Here’s why.
Let’s say our sponsor comes to us with a simple directive. “Build the fastest car you can.” So, you go and build a top-fuel dragster. Designed for short, straight-line races from a standing start, your light, high-powered car has the quickest acceleration in the world, reaching speeds of over 339 mph (546 kph) in less than three seconds.
In the world of containerized apps, that raw power and speed is the equivalent of major scaling capabilities.
It’s good, but the sponsor wants more. They want the car to be able to handle curves in the track, so the aerodynamics, suspension and steering need to be different. And it needs to be able to handle much longer races, so it needs to be fuel efficient. It also needs real-time monitoring of things like its tires, brakes, clutch, transmission, etc.
You’re essentially being asked to turn your dragster into a Formula One race car. In software, it’s the equivalent of handling completely different functions and workloads by adding all new functionality.
You go back to the drawing board in your garage to see if there’s a way to modify your dragster to meet the new requirement. But as any car person will tell you, it’s just not possible to morph a dragster into an F1 kit. So, you start from scratch and build a car that Jackie Stewart would be proud of.
The sponsor is happy for a few minutes, but then comes back with the need for your car to compete in the Pikes Peak International Hill Climb Race (a rain or shine event). So, you need to retool with an engine that can handle among other things the rapidly descending air density on a track with rapidly rising altitudes. Or is electric the way to go? Last year, a new course record was set by an electric car. If your experience so far has been in fuel cars, how will you handle the very different challenges of electric design?
You get the idea; I don’t want to overdo the car-building analogy. But if you and your team are building applications and solutions today, you’re likely having to deal with these types of fundamental, unanticipated requirement changes. Maybe its competitive pressures or advantage, an acquisition, maybe a complete pivot to fundamentally new technology.
In the old days, these sorts of radical changes in direction would utterly disrupt the development process. But today, using cloud-native architectures and dynamically assembled microservices, one can change a dragster app into an F1 solution, and then pivot your design so the resulting vehicle can get to the top of the mountain first.
But here’s the rub. You can’t do any of this type of transformative work without understanding what the new direction will require in terms of performance and architectural changes. What was once a finely-tuned and largely upfront effort, now needs to be tuned again. What are the peaks and valleys of high traffic, throughput, latency, or concurrent users going to do to your application? How do you best optimize for those scenarios? When the pivot comes, how do you yet again validate the proper optimization? Is the new architecture eveIn relevant to the new tasks at hand?
What if your toolkit included a solution that simplifies and automates the process of continuous Kubernetes optimization?