Let’s Talk Tech with Chris Hajjar & Sean Wright
Welcome to another episode of Digital Dexterity. I'm Wes McChristian our Kentico practice director here at American Eagle dot com. Today I'm joined by two wonderful guests in what we're hoping to be. Let's talk Tech Session.
So, Chris, I'd love for you to pass it your way first. Would you mind doing a quick introduction first? My name's Chris Hajjar. I've actually been implementing Kentico since about 2010, so seeing quite a lot of things, seen a lot of evolution not only in this product but also the space in general.
So I'm really excited to be here. Great. And Sean, would you mind giving our listeners a quick introduction as well? Sure. My name's Sean Wright. I'm a lead product evangelist at Kentico.
I worked for about ten years on the partner agency side, building dot net applications, working with client side JavaScript architecture and slowly moved into being kind of a solutions architect, then jumped over to the Kentico side to move more into marketing, which has been an exciting adventure for me. Maybe that'll be another episode for us. Sure.
So, so great guys. You know, I'd love to have a conversation about Kentico and just your philosophy behind technology. We've seen the industry shift and change and flex and bend as a result of a lot of things that Microsoft is doing. And as a dot net driven content management system or digital experience platform, maybe, Sean, maybe you start, you know, kind of explain the background and philosophy behind Kentico as it as a dot net platform. Can we maybe start there? Sure. Yeah. Fantastic. So Kentico as a company has been around for about 20 years now, and it was dot net based from the beginning.
Building on ASP.NET Web forms, which some people might be familiar with. If your beard is a little more gray and longer or just called out right away. For people who can't see Kris sitting next to me has some great.
Some is an understatement for Thank you. You just got lined up. Yeah. So built on ASP.NET web forms and has tracked with Microsoft's technology offerings over time, including adoption of the cloud with Azure.
About seven or eight years ago. Right. And now has adopted Microsoft's latest technology.
A dot net. Five, six, seven, eight. Now ASP.NET Core.
So really, as a as a company, we have tracked along with the technology offerings from Microsoft, also incorporated some other cutting edge technologies. And talk about those a little later, too. Yeah.
And, you know, I would say too, like as a partner that implements, you know, I think you guys have done a really good job of progressively adopting the standards that Microsoft is putting forth inside of the dot net ecosystem. You know, even so far as to. Right. Really set the stage for what we now have on the horizon. Well, I guess it's was it last week or the week before dot net eight? Right. Like in your your
wonderful experience by Kentico product. Right. And you have you have successfully laid the groundwork in order to adopt that the dot net eight changes that that are being driven by Microsoft, which I think is just like really cool because there are other platforms in the market that have not they have not put in the elbow grease. Right. You guys have right for that adoption, which which I think is just so, so cool. Yeah.
I think they've always stayed up on one of the you know, again, my career has been built on building count to go implementations for people. And one of my, you know, favorite things is that the software did a great job, like you said, of kind of following in dot net footsteps without getting in your way, without blocking possible functionality or solutions that you're looking to build it. It just complemented them rather than, you know, a hurdle or anything like that. Yeah, Yeah.
Like at the recent Connections event in Nashville. Like one of the standout moments for me was actually Brian McKeever put a slide up on one of his presentations with like all of the Microsoft iterations as far back as I think it was. I don't know if it was 20 years, but maybe ten. It was really interesting to see it framed up that way, which which I think is cool. But
but let's maybe dive into the product itself. And Chris, I love your perspective on just kind of where we stand today, like kind of components and build philosophy. You know, given your history with the product that net aside. Yeah. You know, tell us what you're excited about in experience by Kentico. I mean the biggest for me, especially from, you know, being a technologist for so long, is again, they started this rebuild a few years ago and getting rid of all the legacy code, including older versions of Dot net and really building towards the future.
And you know, with our new architecture, you know, namely around this this content hub and things that that myself and Sean will speak to, it really has enabled quicker paths of production. It's enabled, you know, being able to headless capabilities, all that kind of stuff that was maybe unheard of or just not even an option for people years ago are now easy for even non-technical people to, you know, use on their day to day basis and stuff like that. Yeah.
Sean, tell us what you're most excited about in the current state of technology with experience by Kentico. Yeah. So the first time that I started working with Experienced by Kentico, I was still on the agency side, using it as a potentially a product that my agency would be using for our clients. Yeah, And I went through the documentation and I was up and running in 5 minutes and compared to both previous versions of our products and other products in the marketplace and ecosystem, to me it was just amazingly fast, amazingly easy to get started using the product. And so that barrier which is it something that affects developers and developers feel is a huge pain point when they can't get started quickly.
Yeah, when either the the tutorial, the documentation requires 500 steps and this bespoke customization and setup, when you can remove that barrier, you help developers feel productive and enabled and they want to work with the product and they get excited coming back to it. And for me, that was the the biggest takeaway for where this product is today is that speed to feeling enabled and productive as a developer with the product. And you know, I'm just technical enough to be dangerous, right? If if, if I'm coding your website, you're having a bad day. Right. But like, I mean, give us some give give some of our listeners a sense of what barriers are you are you specifically describing here that that would have been a blocker to not just the morale and motivation that you're describing, but also like like time to code, time to market? So there are key philosophies in the product, in the product strategy. One is to meet developers where they are.
So what are they using today in terms of toolchain or technologies or languages? So we're using the latest version of dot net. C-sharp We are compatible with Docker for database. We can be stood up and a matter of minutes using dot net CLI Project templates, and we sit on top of ASP.NET Core instead of replacing it. So if a developer is familiar with this very popular, common, highly performant, always updating technology stack, then becoming familiar with experience by Kentico as a product is not going to be a stretch for them. We are unlearn, you just know.
Add on to the knowledge and. Yeah, if there are if they already have that knowledge, then getting to a place where they feel like they understand us. Yeah, is not a stretch. It's it's just a few steps to get up and running. And when they look at their code, yeah, it's going to look like an ASP.NET Core application.
It's not going to look like some bespoke vendor's product that you don't quite understand it. It's ASP.NET Core at the foundation and everything they can do with that technology stack they can do with our product. There are no limitations there. That's great.
I'm surprised they actually didn't bring up one of the barriers. What was the first computer you actually installed this on? yes. So this is a nice softball coming from Chris. Yeah. So in the past, you know, years ago, Microsoft's technologies were built for Windows because that was the operating system that they delivered everything through. Sure.
In about 2014, 2015, Microsoft realized they need to be cloud first and allow any developer to work with their technology solutions. And so that was the development that began the development of ASP.NET Core and modern DOT net, which is cross-platform. So you can run net on Mac Linux or Windows you can develop it on any of those operating systems, you can even run it on a Raspberry Pi if you want to. It it works everywhere.
And because of that experience by Kentico as a product can be developed on Mac OS, whether that's Intel chips or M1. M1. M2 and three chips doesn't matter. I have a MacBook Air, I can do experience. I can't go development there and I can transition Raspberry Pi. I mean, it's probably you can make a.
Door, you can do it there too. Yeah. And then transition. Transition over to windows. Sure. And have people all in the same team collaborating together and not have to care what operating system, laptop technology, hardware, technology they're using to develop a solution. It's seamless for anyone on that team. So old Mac users know the pains of parallels or VMware and all that kind of stuff.
So I mean, that kind of dovetails into just how portable, you know, experience I had to go was quite a small deployment too. So I mean, like you mentioned, you can deploy it anywhere, kiosks, things like that, you know, digital signage inside of buildings. So it really kind of again, this wouldn't have been possible on older versions or older technologies. So, you know, that that limitation or that barrier is is, you know, pretty much nonexistent at this point.
Yeah. I mean, it's I really love that commentary because, you know, there's a couple of different angles to it. And I think one of the most important ones is is talent acquisition, right? Not just for us as partners, other partners inside of the ecosystem or the community, but this story of barriers being broken down is also a story of how do we onboard new team members and make it successful for them to be able to drive value inside of our projects or inside of our applications. And like this is the kind of stuff that's being taught to fresh talent, to RIM. And then likewise, I think it's really important for you guys have a rich history. You have 20 years of client.
Building this stuff. Too. So there's still a lot of people on some legacy tech that these barriers are very important for them to break down so that they can transition into the experience by going to go ecosystem regardless of whether they're on 13 or 12 or we have some clients that are even older than that, right now, which is fine. It's the way that it is.
But this this idea that, like we're adopting these new standards, we're building it into the product philosophy, and that's helping us accelerate into just our day to day. And I love the way she says new development teams where they are. Like. Right, we don't want to upend. And that's the same way we look at our potential customers, is we don't want to upend what you might do on a day to day basis with, you know, third parties or integrations.
We want to complement it. We want to work with that because, you know, large corporations have teams. You know, there could be five different teams that have five different stakes in this. You know, this area of either content management or whatever it might be. And that is, you know, another thing where you don't want to come in and say, well, you can't use this third party thing anymore. You have to use our stuff you can as opposed to, you know, integrating with it and things like that. Yeah, I'm not sure.
I think it was your cursor. Well, I don't know who said it now, but you sort of made the joke I it, it's lightweight, it can be installed in kiosk signage and it does lead me to actually sort of a parallel path where like I think there's a really exciting roadmap feature that you guys are releasing here just in a little bit in the form of the Headless API. Yeah, right. This idea that Headless is just a feature I think is a really refreshing, pragmatic technology angle on, you know, what we see inside of the market at large.
Would you guys mind just tell us a little bit about the Headless API. What's driven that? Where do we expect the value to be driven from this as a feature? Yeah, so this feature comes from I mentioned some of those like underlying product strategies or philosophies. This comes from that same place. So the idea that we are delivering capabilities without delivering complexity to both the, the marketer as the end user of the product and the developer, the one that's really driving the solution delivery, we want that to be applicable to all aspects of the product. And so if a developer is used to building a website with a headless CMS, it can be a great experience for them.
It can also be a complex one. Sure. And we want to enable building a site heedlessly without requiring the complexity that comes with that. So it's if there is additional complexity there, the developer gets to opt into it that the team that's building the solution, they get to decide strategically, does this make sense for us and opt into that at the pace and the level of complexity that they want? And so a developer could stand up an experience by Kentico solution with just content management and allow marketers to start creating content. Day one You don't have a website yet, you don't have emails designed, you don't have a website that's consuming this this information over Headless API. You have none of that yet. You just creating content, modeling that content and really learning the product and learning what the needs are.
And then the team gets to decide, All right, do we want to deliver this over a traditional ASP.NET Core website? Sure. Product enables that has a great story for that. It's a great experience for developers and marketers.
Do they want to deliver that content heedlessly to a next Joss application or any other technology? It really doesn't matter. It's adjacent API, it's a GraphQL API, deliver that content to what other, whatever external consumer they want, but they get to opt into it. It's not a requirement.
So that that headless channel is a feature for us. We're seeing that as a real big advantage for migrations too, from existing things where, you know, maybe that needs a new look and feel, but you're you're happy with the content. Well, that's great because now kind of the way with experience I can't go is you can, like you said, stand that up. You can, you know, model your content. You can even start putting that all in there. You can even query it through the channel or whatever it might be.
Or like you said, the most common one would be to build out a web channel and then start referencing that content. But what this can actually enable is a cloud of running in, you know, things in parallel. Instead of waiting for content, waiting for design, having to bring all that stuff together at one time, you could, you know, do a whole bunch of content if the content strategy has been figured out, but the design hasn't and then bring them together later or again, it's could be creating email channels, it could be creating, you know, next as apps, etc.. And you can guess what you get all of these capabilities without the complexity, you are not required to stand up a Kubernetes cluster to get this application running. You don't have to have some bespoke incantation that your I.T operations has to recite in order to get this thing up and running.
You can have it up and running quickly and you can have headless API and websites all within the same product, one ASP.NET Core application, one SQL Server database, and that's all you need. If you want those in Docker containers, fine.
If you don't, fine. We don't care. It'll work. Okay, so this is maybe a good transition for for our last couple of minutes here. Speaking of sorcery, let's can we talk about the SAS version? The SAS? Sure. Right. Because. Because I mean, I think you're naturally sort of talking about what you guys have elected to do to create these deployment options.
Right? There's still this on-premise self-hosted model, which is in large part what you're talking about, but there's also clients that prospects that say maybe we don't want to have to deal with that at all, and you now have a solution for that with our last couple of minutes. Can can we talk about that as well? I mean, give us a rundown on the on the SAS player of the product. In the same way that we're meeting the developers where they are, We also want to meet the IT operations staff, where they are or maybe where there is no idea. But yeah, sure. Yeah. So that's actually one of the bigger ones is that they don't, they don't want to hire the investment in an IT staff is overkill to manage your website or you know just much more expensive.
Yeah and our product is sometimes implemented directly by customers. They have their own development teams, their own I.T teams and an application would be deployed within a private data center or it could be deployed to the server sitting under someone's desk if they really wanted to. I don't advise it, but hey, it's possible. So we've always been able to do things on that side of the spectrum.
But what we haven't had in the past is a managed deployment environment for customers that either customers can use or our partners can use to host and run that application. And so what it does is it takes away some of the responsibility of getting that application out to test production environments, managing the infrastructure or scaffolding out that infrastructure, and also writing what that deployment process looks like because some teams have lots of knowledge and skills today about DevOps practices. Yeah, but there are some that just want to focus on the software application development and they don't have the skill sets nor want to invest the time to learn those things. Well, you don't have to with experience backing to go. You can build the application handed off to us and then we roll out that deployment for you.
Yeah, I think one of our unique things is too that the product behaves ideally in both scenarios, whether, you know, it could be in a very complex DevOps scenario with a giant I.T team, or it could be just publishing into the beginning of a SAS or even, you know, an app service or something like that, that the software, you know, the development lifecycle, all that kind of stuff is identical. It only comes down to again deployment options and meeting people where they are as opposed to saying you have to do it like this. Yeah, we have some customers that are really mature in terms of their technical infrastructure, knowledge of hosting and running a web application and for them setting up a pipeline, deploying out an application and also knowing how much to allocate for infrastructure and manage your infrastructure. It's no problem for them.
Maybe they don't need SAS environment coming from a vendor like us, but for the ones that don't have that knowledge and skill set, we can take care of that for them so that it's not a limitation on them getting value out of our product. So we have blue green deployments in production, we have surface resource usage logs and graphs and events and air logs in the dashboard in the portal where customers can deploy their application as. Backup or store retention. Yep.
Like those are all the things we thought of. That's part of the base package instead of, like you said, if you deploy something in your own Azure environment, it's not going to automatically back up. It's not going to kind of take some of those things that industry professionals would take. AS Yeah, what a baseline deployment would look like. Yeah, and that's the stuff that we, you know, are looking to take off people's plates or off their mind if they don't have that kind of expertise.
Yeah, developers might hear this and be a little concerned. I'm giving you control over something. What happens if it doesn't work out or I'm stuck now with, you know, the product is the same product, whether it's being deployed in your infrastructure, your public or private cloud or our SAS environment, and you can transition between the two with just configuration changes. So if you start out in a private data center and you want to come to SAS, no problem or an application that's been running for a year, no problem, we can get you from point A to point B if you start out in SAS, but have some compliance requirement that's unique to you that you found out about. don't worry, we can get you out of SAS and into public cloud or private data center if you need to.
Yeah, yeah. I mean, I think these are all great philosophies. They don't, they don't eliminate risk, but they help mitigate it substantially when it comes to managing sizing infrastructure and deployment practices, which I think.
Is just right into the title of dexterity to me, like that's the agility or thanks. Yeah. See what I mean? That's that's kind of what I was saying about before, about kind of never getting in my way when I was always and there's more than one way to solve a problem usually and that that again following in what the billions of dollars and hundreds thousands of hours Microsoft has come up with this framework. We're not looking to upend any of that.
We're going to build on top of that strong foundation and, you know, utilize it. That's great. That's great.
Well, guys, this has been a wonderful conversation. I really appreciate you taking some time to to chat with me about Quantico Modern technology practices really surfacing this content for two listeners. I think it's it's all valuable and understanding the Quantico trajectory, understanding the technology that ours that I think is just is it's just so important to being successful.
So I really appreciate you guys taking the time to be here to join the episode itself. Thanks for having us. To all our listeners, thanks so much. And we'll catch you on the next one.
2024-02-20 08:52
