In this final part, the Scout team continues our talk with Freedom Dumalo, former CTO at Flexcar and current CTO at Vestmark. We discuss some essential questions about architecture, touch on Rails, Turbo, and Stimulus, and the key considerations for those starting off before they lock in an architecture or tech decision.
By the way, before we jump in, Scout Error Monitoring is coming! We’ve been putting a lot of our effort towards getting this feature lately, so for those who are eager to join in, click here to join the waitlist now!
FREEDOM: I think there's a big missing space in the dialogue that we're having with each other today on the internet about how to manage software, on how companies like ours should be managing software. There's no book on what to do besides Kubernetes. It just isn't out there.
Kubernetes is sort of like jumping right into that Manhattan high-rise when really what we need is just some way of reasonably keeping systems running as we operate them. And we're starting to see, though, obviously there are some outspoken individuals that are starting to say some things similar to what I'm saying here, and I think that's good.
LANCE: Having seen the complexity that Kubernetes brings, it makes me want to avoid it when possible, actively. And I think listening to people like Kelsey Hightower, who came up seemingly through Kubernetes, and is still the first person to say, please, there's a good chance you don't need this.
Start simple. Don't automate processes until you can checklist them all the way through 100%. When you find yourself at the other end of the spectrum with your service discovery and you need to do all of these other extremely complex things that have a complexity cost, like okay, now you're in that territory, but there's a lot of space between A and B there.
FREEDOM: I think you're right, and that's what I'm saying. Obviously, you can always spin up an EC2 instance or in whatever cloud you use some flavor of virtual machine and just FTP your files right up to it like we used to 20 years ago. I don't recommend anyone do that, but there's definitely been days where I wish I could do that, that's for sure.
But then you look at services who are definitely making lives for developers easier, like Heroku and Vercel and fly.io. The problem with those services tends to be that you pay such a huge premium. They show you what's possible, but the only way to get access to it is through paying for those services.
We were actually investigating a technology called Dokku, which I think purports to give you a Heroku-like experience on your cloud provider. But again, even that, it just feels like there's some overhead. We're going to have to manage this thing. So, am I just trading Kubernetes for Dokku if I'm doing that? And Kubernetes, at least I can buy a library of books for it, and I don't know that I can do this with Dokku.
We really need a golden path somewhere. Somebody just to carve this out and say, here's what you do: here's how you deploy at your size and here's how you manage the infrastructure at your size.
LANCE: One thing I'm curious about, you mentioned reaching for React or a Vue or single page. Have you explored Hotwire, Stimulus, and Turbo and how those play together?
FREEDOM: We have to be responsible here and we've made big investments in React already. So, we'll probably maintain a lot of the existing React stuff while we make this transformation. But we've already done some experimentation with Turbo and Stimulus.
Stimulus is brilliant. I wish it existed in the earliest days of Rails because I think it would have changed how every other JavaScript framework ever was built. It's just such an elegant way to wire up JavaScript to HTML. And Turbo, especially with Turbo Morph, with this new version of Turbo that's coming out, it really does look like I could do all the things I loved about Phoenix live views, but from Rails.
When we were doing the initial Rails experimentation, so the second Rails app that we built, that was sort of a mini version of Flexcar, I went to Bangalore and I grabbed a handful of engineers off the production line and said, “hey, we're going to sit in this room this week and build this thing”.
One of the guys who was on the team, as backend as backend can be, had never built anything that you could consider frontend, outside of what he did in school, but he knew HTML well enough. I remember when we got towards the end of the week and he was demoing a screen for me that he had built. It was rough, there was no design there, but he was clicking a button and then the list of vehicles that he was showing was changing as he clicked the button. I was like, oh, that's really cool, and he says, “I used Turbo.” He was so excited that he could build this sort of morphing page view and could get that reactive experience himself. This didn't take any time, and it was all within a week.
On Monday, he had no idea that we were even thinking about Ruby on Rails, and by Thursday, he's actually showing a demo of how a reactive frontend application can be built. And was really excited by it, and actually enjoying the process.
So, those kinds of experiences told me like, yeah, there's something here that if we invest a little bit more in, and I think Turbo Morph is definitely the killer part of that stack once it's done.
SARAH: Yeah, it's really cool, andI love the idea of that kind of excitement. I guess before we wrap up, I'd love for both of you just to kind of think about if you were a brand new company making decisions or kind of early-stage and trying to decide what's the path you're going to take–what are some of the key things that you would recommend people consider before they make a fairly binding decision from the architecture or technology standpoint?
FREEDOM: I think you need to figure out what your values are, like what's important to you right away. Usually, for a new company getting started or a smaller company, those values are almost always something about growing, which means acquiring new customers or getting profitable, like, this is always going to be in that mix somewhere. But figure out what they are and figure out what your tolerance is.
Once you have an understanding of what your values are, which hopefully doesn't take you very long, then the next thing to do is look at what tech exists in the world that can help you to align with those values. So if your value is growth, you want to get products that excite customers and get customers to sign up.
You know, there's a lot of great frameworks, and we made our decision based on our needs. But I think there are other options out there that are similar. I think a lot of organizations are choosing Python-based frameworks these days as well, like Django, just because they want to have that easy access path to adding in TensorFlow or PyTorch or something like that. All very reasonable choices to make. But think about it.
Like Lance and I were both sort of mentioning earlier, are you going to be able to find people to work on it? Can you find talent? Are there interested parties that will come and work with you on the tech that you're choosing?
LANCE:Think about the work that your application is going to do, and think about how that gets broken down. Consider if there are areas that are going to need to scale if you hit some targets, and think about which parts won’t. For the parts that don't need to scale, take the simplest pick, the most boring, most familiar tools that you can for those.
Then, turn around and look at the ones that are going to have to scale and pick the most boring, familiar tools for those, because they are going to get all the weight put on them and they're going to fail in ways that you would like to predict.
But anyway, that's me and just wanting familiarity and boring foundations to build on. Think hard about where you're going to put the new stuff that you're not very familiar with when you're starting out. Because you will have many challenges and you don't want to add to them unnecessarily.
SARAH: Yeah, I think choosing a reliable technology is definitely the right path. Lance, I love to choose boring tech because, you know, it's been tested and you're not going to hit some unforeseen roadblocks.
That's awesome. Well, thank you both so much.
FREEDOM: Yeah, and likewise. Thank you very much.
Another good architecture move? Sign up for your free trial with Scout now!
