Build vs. SaaS with Calvin Hyndryx-Parker

Machine-generated from the episode audio and not hand-corrected, so names and technical terms may be imperfect. The audio is authoritative.

All right, you're watching another episode of the CTO Advisor podcast. I guess that's my official intro. Another episode of the CTO Advisor podcast. I'm joined with a good friend from the tech field day community and fellow CTO, Calvin Hendricks Parker, CTO of six feet up. Calvin, before we get started with the topic, which is build versus buy, give us a quick intro of six feet up. What do you what do you folks do there? Sure. Then, Keith, it's been awesome to get to know you and finally now being on the podcast.

I love this. Excited to be here. So six feet up is a software cloud Python consulting company where we help impactful leaders accelerate their digital transformations. We have got very senior development resources who love working on app dev, AI, big data, cloud orchestration projects. And our customers are in interesting fields, really working on a lot of things that are kind of climate tech. Good for humankind type impactful projects is actually our most recent initiatives. So in the background, if people are watching this on YouTube or in video, you have a a a game.

Oh, yeah. Well, we'll get to that at the end. So tease people that if they stay at the end, we get to talk about the game cabinet that you have in the background. Definitely. So the reason why we're having a podcast together is because both of us have similar interests around events. You put on an annual show, Python. What is this? PyConf? No, it's the Python web conference. Yeah. And so you have this business challenge that you want to bring together your community virtually, actually even before the the now times.

Tell us about kind of the origin of the conference and in the goal. Yeah. So the Python conference came about because the larger Python community has kind of moved in different directions. Python has become a very popular language, like number one programming language in the world. And a lot of folks have picked it up and use it for data orchestration. And it's just not kind of a one trick pony. And I felt like the the current conference situation, like the in-person conferences for Python around like PyCon or regional Python conferences, weren't catering really well to some of the topics I loved, which is like maybe more advanced web based topics.

And that was actually the original impetus for Python web conference. The secondary reason we started doing this was for folks who couldn't travel or it was implausible or financially impractical for them to make it to a conference. Maybe you were in Central Asia or in Africa or some someplace where maybe you can get a visa to come to one of these regional conferences or there's not a regional conference near you. We still wanted to bring that Python community to those folks. And this was pre pandemic.

Twenty nineteen was our first one. Yeah. Yeah. We started off with three tracks over two days and did a basically the Python conference I thought was missing from the community. So I've been supporting virtual conferences, actually, even before the pandemic, the VMware user group. I consulted for the VMware user group for a number of years. Actually, they were one of my first customers as the CTO advisor. And one of the things that I did was then was content curation and picking out topics and call for papers and helping them kind of curate and put on their virtual event conference, which they've been doing, I think, since twenty seventeen, twenty eighteen.

So I have I had some good familiarity with virtual conferences and virtual conference platforms even before the pandemic. So you're going into this in twenty nineteen. There's platforms around. You folks decided to build your own platform versus using one of the existing platforms. Let's get to the why of that first. Yeah. You know, kind of why. I mean, no one builds things anymore. It's all about sass. I wish I could have found a platform. I think they would have fit for this very first year we did the conference.

We basically kind of, you know, bailing wire and bubble gum and duct taped it together with a couple of Zoom channels and some slack. So basically the slack channels were there. There was a conference schedule posted online. And if you had purchased a ticket, you could come in and basically you would have to switch your Zoom client from like one Zoom channel to the next Zoom channel to the next Zoom channel to actually watch any of the three tracks. And now we realize that obviously is a suboptimal experience for the attendees.

We really want the attendees to be engaged. We wanted to have integrated experience. And I wanted to do it in a way that really focused on their experience. I think a lot of the virtual event platforms are focused on maybe the sponsor experience or the Legion experience or this kind of virtual expo hall experience. And I didn't think they did that, especially in 2019 and 2020. I don't believe any of them did a really good, you know, super job of that.

In 2020, obviously, things changed. The world kind of flipped around. And a lot of people went into this virtual event software space. And I still don't think they're doing a good job. Otherwise, I think we would have switched. But the original emphasis behind the build was none of the platforms that were available really fit or suited that integrated experience where I was trying to really cater to our attendees as much as possible. I really wanted them to connect with one another, connect with the speakers.

And a lot of the platforms just don't facilitate that in a really fluid form. So you have a very developer focused organization. Yeah. You folks literally the value of engaging with you is to create code, not necessarily operations. I don't think so. Why take on the burden of operations? Because you've since kind of created offered this as a product in addition to an in-house offering. Yeah. And so two questions. One, let's talk about let's talk about the journey to offering this as an offering.

And then to kind of this, what happens when you now have customers on the platform? Yeah. So year one, 2020, with the platform, after we did Python conference, I had 10 leads that next week from people who had been at the conference and said, we want to use your platform for our conferences this year. We had six feet up. We've had a couple of false starts on maybe some building product. And we really kind of settled on the fact that we are a service company.

We do consulting. We are like very senior folks who enjoy solving tricky problems for other people, not necessarily always solving our own problems for our own platforms. But this time we had real customers online like they're people who were very interested, very eager to participate and use the platform. So we had to rearrange some of our internal human resources to support operating a new product, which is very different because now we're basically becoming event producers, having support staff to support the help desk and the back end operations of a virtual event platform, which was challenging.

I think we've kind of changed our minds about how we feel about that a little bit and kind of backed away from selling the platform as much as we had in that first year. But we've not backed away from building the platform. We actually really still believe in this platform for ourselves because it provides the exact experience we wanted to convey for our attendees to our events. Another upside, I'll kind of talk a little bit of kind of expanding in a secondary here is another upside we found with building our own platform in-house, being that we are a consulting company who does consult other organizations and we do deliver code.

That is our true value is having this platform enabled our developers to do some greenfield work and work on some leading edge technologies in the cloud that we had not had a chance to really touch with some of the customers who are working with, who may have been maybe a little further behind that adoption scale. So being able to actually onboard new developers into our team, giving them a product that we own and is only ours that they can cut their teeth on, we can basically teach them the six feet up way of developing and delivering on our value in-house without having to kind of risk them going out into maybe a customer's site and not really portraying like what the true value of six feet up might be.

Yeah, I've heard this theme repeatedly over the past couple of weeks. I don't know if you notice in the tech field, the channel for the edge building, which is just ending the week that we're recording this, that Brian Chambers, who's the director of enterprise architecture for Chick-fil-A and the person responsible for the Kubernetes at the edge on Intel Nooks. We discovered this in the past couple of weeks that his team, the enterprise architecture team, was responsible for that platform, which is crazy. If you think about it, enterprise architecture group within a large enterprise delivering a platform.

I mean, he talked a lot about many of the same lessons that you learned and that the team was able to learn that running a product inside of a organization and being responsible for customer and delivery and etc. Has its advantages. Oh, yeah. It also has its pitfalls. I mean, there's a lot of work. Let's talk about some of the pitfalls. Yeah, don't get me wrong. It's a lot of work. Once you get on the software development product, once you're building a product and maintaining a product, you're on that treadmill and you can't get off because you've got to support it now like this.

I think my CEO asked me how much we're going to spend next year on Loudswarm development. Loudswarm is the name of the virtual event platform, and I kind of threw out a big number and they were a little shocked. I said, well, you understand there's continual movement in all the libraries. So under the covers, Loudswarm is actually based on the Django Python application framework. Well, there's multiple releases per year, security and major releases. We've got a React front end. Those have multiple security and major releases each year as well.

We're also dealing with databases and Redis and all the other things that kind of go. All the things that are around this whole ecosystem have to be maintained or else they bit rot. I mean, there's just no there's no case anymore where you can launch a piece of software and have it just continually run without needing any maintenance. You could do it. It's risky because of, obviously, security vulnerabilities and attack surface vectors and all those kinds of things that happen. Performance issues as you scale.

There's going to be new features that always need to be added. I mean, how many times you've gotten frustrated going to some governmental site you tell has not been updated since 1998. And the usability of those systems are just terrible. And I don't want to frustrate our users. So we have committed to maintaining this product, which means it's ours that we spend internally on the product. But we have to get our return out of that value. And part of our return has been that training of our developers, giving them those those experiences, those experiences with specific cloud technologies that maybe they've not touched before and the great experience during our virtual events.

And we still do sell the platform to various communities that have a good fit with the type of a virtual event platform we built. So let's talk a little bit about that operating model. You know, you have basically this natural journey that AWS likes to talk about that. Yeah. The IT vendors that like to talk about kind of this DevOps movement where you have developers that had an idea. Specifically, you had an idea. You built the idea. And now you have to do steady state operations.

Yeah. You're not going to spin up an entire infrastructure team because it's not that type of product in that revenue structure. So talk to me a little bit about this natural DevOps movement. Where have you found, you know, kind of this story to be when I say DevOps story? I mean, developers doing their own operations. Where have you found to be kind of real and advantageous and advantageous? And where do you kind of wish and I wish I had an infrastructure team to kind of throw these things over to?

So over the course of developing the product, we needed to be able to do releases or have preview environments or QA environments or dev environments so we could test. And we don't have a big operations team anymore. We really have honed in on being a senior team of developers. But the whole movement around CICD and DevOps and the whole movement around serverless in the cloud has reduced our need to worry about patching servers or things failing. You know, the whole aspect of like auto self-healing and auto scaling, whether it's in Kubernetes, the last one platform itself currently runs on Fargate using Amazon's ECS, which has been nice because we can define those tasks as Terraform code or some kind of infrastructure as code, which is a lot more comfortable for those developers to kind of wrap their heads around.

Again, another set of new technologies that they got to understand, you know. Try out on their own without having to have the big worry of like maybe having a customer site customer project fail because of maybe they're inexperienced with that. And then as maybe the more senior folks on team can now mentor the other developers on the team around certain aspects of the infrastructure, like how how the release process works, how the code we have multiple code pipelines going on now. There's just not only just the CI pipeline for running the tests and all the integration tests and all the unit tests, but the whole delivery of the platform is all done via code pipelines as well.

So we have a code pipeline in Amazon that does the release process. We'll bundle up, excuse me, we'll bundle up the images and put them into the repositories and then launch them into the Fargate containers. Post the conference this year, we'll be launching these now on Kubernetes. We're going to be moving over to EKS or some kind of Kubernetes, basically to start to remove some of our dependence on specific cloud native pieces that are proprietary to Amazon and maybe using Kubernetes as a platform.

It's more, you know, less lock in. We can move it to, you know, digital ocean, running on digital oceans, Kubernetes, you know, infrastructure be less reliant on right now. We're very reliant on those pieces that were part of AWS, like ElastiCache and RDS and CloudFront and ALBs because we didn't want to deal with those things. Now we've got a little more runway in front of us. We probably can in Kubernetes become a lot more mature since we first started doing this project.

It's a lot easier to then deploy this with MinIO inside of Kubernetes with a PDO database operator for Postgres. And so some of those pieces have matured to a point where we can actually pull them back out of AWS and just run them purely in Kubernetes. Yeah. So this is the maturity of a product that I've talked to folks about. They, you know, they think through, oh, public cloud is the place to run application. Why would you like why would you ever not do this?

And I think you're showing gradually why there's value in pulling away from native cloud services. And eventually, you know, I could see this running on under a, you know, on a laptop on your desk. I'm exaggerating on a laptop on your desk. That's an exaggeration. That's actually part of our developer experience journey. From the developer standpoint, we started off with Docker and Docker Compose locally on a laptop. We're now moving to running, you know, Minikube or MicroK8s on either a deskside machine or on your laptop or in some cheaper cloud.

And the developers now use tools like Scaffold to synchronize their files. So they still get to use their own IDE, their own tools. But the deployment experience and the development experience are actually becoming much more aligned. And so that the Kubernetes manifests or tools like Crossplane allow us to basically spin up the exact same looking thing locally as we would in the production environment. It's just a matter of scale or a matter of saying that when you're in the production environment, you may be using RDS or you may be using a different database cluster that scales slightly different than what you'd use locally.

And then from a developer logic perspective, that logic isn't changing. They're just, again, adding features, et cetera. And then you're allowing your platform group. And this is where I call the platform group within a large enterprise make these decisions. Am I using RDS versus some other managed database service? I've extracted even the the database calls in a way from the there's the there's the application platform that uses RDS or uses Microsoft SQL or Oracle. That's really not relevant to the development logic and the decision that the platform group can use.

So if I want to wholesale move this application from the public cloud, I'm no longer tied to elastic search or RDS. I can now move this to a colo facility. If I know the if I know the shape and size of the of the demand for the app. Yeah. Now, in our case, for our app, having the close proximity or availability of a CDN tool is absolutely necessary. You probably could run less than a colo, but we would still need a CDN just due to the fact we're delivering video.

We're delivering an application and not a Web site really through the browser to the end users. So it's nice to have those public cloud components available to us. And I have run a colo years past when we first started the company where we've been in business now, 23 years. So cloud didn't exist when we first started. We had a cage of equipment in a colo someplace. I don't know if I yearn for those days back. I don't think many people other than me yearn for those days back.

I have a cage now and it's coming up for renewal. And I really wish I had a business model where I didn't need a cage in the data. Yeah. Yeah. So two things. One, we we're we're still going to get to the video game cabinet in the background. But when is the next conference? It's coming right up. So it'll be March 13th to the 17th. If you go to Python Webcom dot com, it'll redirect you over to the full schedule.

All the speakers are up. We've got five days of conference. They're going to be half days across Eastern time zone, which means you don't take a whole day off work to come check out the scene. All the all the sessions can be recorded and put up within about 10 minutes of them being given. So you can actually sign up and watch after hours as well. We've got some great talks coming. We've got some people from the climate tech industry who are going to be there.

We've got a speaker who's working at a lab or a major laboratory right now on some work in the fusion area. And Python's role in actually developing and analyzing all the test data that comes off of the current experiments around fusion, which we've been following the news. You know, we've just finally gotten more energy out of a fusion process than we put into it. So that's kind of a big deal for them. There's going to be a culture track, a pie data track, an app dev track and a cloud track.

So if you have interest in any of those areas, Python plays a role in those places. We would love to have you come join us for part of the conference. And I'm going to put in a plug for an alternative experience. If you're a hybrid cloud. Yeah, chances are you are because you listen to this podcast. If you haven't heard by now, the CTO advisor virtual event specifically around hybrid cloud has returned. You can sign up for that conference.

CTO, a VC dot com. So a good opportunity to contrast and compare platforms. I use a SAS platform. Yeah. Calvin and his team are using a platform they built. I would love to hear about the difference in experiences. Now, let's get to the important part of the podcast. What's going on with the game cabinet? So I got this back in twenty eighteen. We so six feet up has sponsored PyCon, which is the in-person Python community conference in years past.

And we were looking for a good gimmick for our booth at PyCon that we had twenty eighteen up in Cleveland. I said, well, why don't we do a high school high score competition on my favorite video game of all time, which is Galaga? So that's actually a Galaga themed Raspberry Pi RetroPie playing Galaga in there. The cabinet looks like Galaga, but it actually has like six feet up branding really embedded into the whole cabinet. And it really makes a nice little piece back there to talk about.

But it's my favorite game ever. It'll play a bunch of other games, but it's got Galaga running full time. Might as well rip off the knob for choosing games because it's only going to play one. It is way cheaper than bringing an Airstream. Yeah, I've seen some of your gimmicks at conferences there. They're much bigger than mine. I love the I love the Galaga. One, I'm a big fan of Galaga. I'm not. I've never been good at it, but it is also one of my all time favorite games because it takes me back to my childhood.

Going to the arcade, the corner store arcade and just watching my friends who were very good at it. Find the I don't know, it was an Easter egg or a bug that allowed you to get to the point where the aliens don't shoot back. That is like it's a cheat. But, you know, it was a bug. It was absolutely a bug. I know exactly what you're talking about. I have gotten into like I love all the old retro video gaming stuff.

I love the art of it. I'm not a gamer myself. I don't like you. I'm not very good at Galaga, but man, the artwork on it. And you can probably see over here, that's my Atari 2600. That's my Nintendo NES and there's my N64 right there and my Wii. So I've got a collection of classic retro arcade stuff going on up here. And it's just really funny. I've gotten the kids into it, too. Yeah, I have a Nintendo.

I don't know the name. All I know is that I bought it to play Super Mario Brothers. So, you know, it's like I have like modern game for the Witcher and a bunch of other stuff that I never play. Always grab it. And I'm playing Super Mario. Yeah, same. I'm I'm a man of a certain age. All right. If you want to find out more about the CTO advisor, you can follow us on the web. The CTO advisor dot com.

You have questions for me or even things that you want to relate to. Calvin, the his Twitter handle and all of that is in a show notes. But you can shortcut at me at CTO advisor on Twitter. DMS are open. Calvin, thanks a lot. I appreciate you joining on. Yeah, thanks, Keith. I really enjoyed it.