 Hey friends, welcome back to theCUBE's live coverage of AWS re-invent 2022 in Sin City. We are so excited to be here with tens of thousands of people. This is our third day of coverage, really the second full day of the show, but we started Monday night. You're going to get wall-to-wall coverage on theCUBE. You probably know that because you've been watching. I'm Lisa Martin and I'm here with Paul Galen. Paul, this is great. We have had such great conversations. We've been talking a lot about data. Every company is a data company. It has to be a data company. We've been talking about developers, the developer experience and how that's so influential in business decisions for businesses in every industry. And it's a key element of what's going on here on the floor at re-invent is developers, the theme of developers just permeates the show. Lots and lots of boots here devoted to DevOps and Agile approaches. And certainly that is one of the things that the cloud enables is your team to rethink the way they develop software. And that's what we're going to talk about next. We have two guests from Split. Split.io is the URL if you want to check it out. Chris DeMars joins us, developer advocate. Chris, great to have you. And Pierre Mass, VP of engineering. Guys, thank you so much for joining us on the program. Thanks for having us. Thanks for having us. Talk to us, Pierre. We'll start with you. What, for the audience that might not know Split, what does the company do? What's the value in it for customers? What are you all about? Sure. So in very simple terms, for those who are familiar, we do feature flags, feature management. And experimentation. And essentially that two essential features of the Agile transformation, as you were mentioning, and elements that really helps getting as much as we can from the team in terms of productivity and in terms of impact. And we basically help with those elements. So that's a very short story. Excellent. Very nice. Chris, you were saying before we went live, you do a lot of speaking at conferences. You're often in front of large audiences. And in front of large audiences as the developer advocate, what are some of the key requirements you're hearing from the developer community that organizations need to be encompassing? I think community is key. Like community is at the forefront of developer advocacy and developer relations. Like you want to go where the developers are and developers want to hear those stories in those personalized pieces of the puzzle. And when you're able to talk about modern web and software technology and loop in product with that and still keep talking about those things and bring that to them, like that is on top of the list when it comes to developer advocacy and being embedded within the developer community. Tell us about feature flags because I would assume that for our viewers who are not developers, who are not familiar with Agile technology, the Agile approaches, that might be a new term. What are feature flags? How do you use them? Sure. I can start with that. So feature flag is a tool that you embed in your code that allows you to control the activation of your code, essentially. And that allows you to really validate things in a much better and sort way and also attach measurement to it. So when you're writing your new feature, you just put essentially a new statement around it. If my feature flag is on, then I actually do all those things with softs and I don't do any of those things. And then within our platform, then you can control the activation. Do you want to turn it on for yourself just to try it out? Do you want your QA team to start validating it? Do you want 5% of your users 10% and start seeing how they're interacting with the product? That's what feature flag is. It's an amazing piece of any part of the stack, right? Because I'm a web accessibility and UI specialist and being able to control the UI with a feature flag and being able to turn on and off those features based on percentage, locale, all of those things, it's very, very powerful. What are some of the scenarios which you would use feature flags? You have a testing? Yeah, yeah, we actually, you can imagine, we use it for pretty much everything. So as Chris was saying, in the front end, everything you want to change, you basically can validate and attach measurement so you can do AB testing so you can see the impact, you can see if there is a change in performance. We use it also for a lot of backend services and changes and a lot of even infrastructure changes where we can control the traffic and where it goes so we can validate that things are operating the way that they should before we fully turn them on forever. It can be as small as having a checkout button here and then writing an AB test and running an experiment and moving that checkout button somewhere else because then you can get conversion rates and see which one performed better to a certain amount of people. And whatever performed better, that's the feature you would go with. Chris, talk about the value, the impact in feature flags for the developer from a developer experience perspective, a productivity perspective. So I think that having that feature and being able to write that UI, let's say that you have a checkout button and there's specific content, there's verbiage on that checkout button and then let's say that another team within the organization wants to change that because the conversion is different. You can make those changes, still have it in production and then have it tested so you don't have to cut specific branches like test URLs to give to QA. You can do all of that behind that flag and then once everything is good to go, push it out there and then based on those metrics and that data, see which one performs better and then that's the one that you would go with. One of the things with feature flag and it goes to like our main theme of what a relief is that it gives autonomy to the teams and to the developers, enables them to move independently from others so their deployment can go but their code is not activated until they decide to and so they are not impeding anybody else. It makes releases a lot safer, a lot simpler and it gives a lot more speed to everybody because when you do releases with five teams, 10 teams pushing the code all at the same time, you have such a high risk of breaking something that it's a huge effort and it requires a lot of attention from a lot of people. If anything happens, all those teams need to investigate. When you decouple all those things, the deployments are essentially not doing anything per se until every individual team activates those things independently so if anything goes wrong, only them are affected and they don't have to depend on anybody else to get their thing out so it really helps them making their life a lot safer and gives them a lot more speed because they have autonomy. So why come to reinvent? What do you get with this audience that you don't get elsewhere? Why? To reinvent, I think like reinvent in the cloud and the WS is a lot about getting speed to companies to build better product and faster and essentially like the tool we provide and the technology and the platform we provide is really at the heart of that team in itself and so that's why we feel we have really great conversation with all the people on the floor. The people here have the right mindset to adopt who you are. It's very much, for me, it's very much community and networking. I love developer community and just community in general is my lifeblood. That's why I travel so much and I talk about these things and I'm with people and if it's not about the product, it's the story and the story is what gets people and that's why I love being here and being with my team and it's amazing. And what is that story? If you had an elevator pitch to give, what would you tell me? Oh, if you were in a late release or deploy at night, I've been there. I'm sure you've been there. It doesn't matter what you're doing. We don't want to be up till two, three in the morning doing those things, right? Our product helps alleviate those stresses and I'm talking about accessibility. What I do, a big piece of that are hidden impairments like anxiety. Well, stress and anxiety go hand in hand and you want to alleviate that all across the board for everybody involved. As you see organizations shift agile technologies and to parallel development and continuous release cycles, what are some of the biggest barriers they encounter in changing that mindset? Oh, what do you think? It depends on where they are in the organization. The agile transformation is a journey and it's also a change of mindset. It's a change of process. So depending on where they are, and they might have some areas where they need a little bit more effort in those directions, what we see is that feature flag just the control of the layout. It's usually something that's fairly easily adopted. Thinking about measurement and attaching measurement to it is often something that requires a little bit more thinking. Like engineers are not really used to thinking about A.B. testing. It feels like more of a product management thing, but A.B. testing is important also for performance information. Like errors and all those things. There is a lot of risk management to be done. We do that through monitoring with APMs, but with feature flag and with split, you can do that at a feature level and it really gives a great insight. And that's usually something that takes a little bit more digestion from the developers to really get their mind around it and get to it, but there's a lot of value to it. I'm looking at the split.io website and I like the tagline. Shorten time from code to customer. As customers in any industry, as consumers, we have this expectation that we can get whatever we want anytime 24 by seven and it's going to be a relevant experience. So it sounds to me like from a speed perspective, there's a lot of business impact that split can help organizations make from getting releases faster, getting cut faster time to market, delivering what customers expect because we all expect real time these days. Nobody wants to wait. That's right. Yeah. I think that has to do with going back to the decoupling of things, not having to go through so many teams to have it tested and getting away from all the meetings about meetings to review the metrics, right? We all love meetings about meetings. No. Right, exactly, exactly. So having, being able to take that away and being able to push all of that stuff into production, getting it tested while it's in production and then being able to turn those features on, it's already there without having to do another deployment. And I think that's really powerful, to me at least. Does your solution have value at the security level as well? Yes, so that's one of the particularities on the way we do things is like the way you control the feature flag, you have kind of two ways of doing it. Either the piece of code, the SDKs that we provide the library, we provide you that you put in your code, could come back to your platform and check. The way we do it is we send the rules back to the SDK. So the whole evaluation is local, the evaluation is extremely fast and it's very secure because it's all happening within your environment. You never have to share any information, no PIA whatsoever, contrary to some of the other tools that you might find on the market. So the theme of the booth is what a release, what a relief. What are some of the things that you're hearing as you're engaging folks on the show floor this week? What is aura photography and can I take a picture? I think just a lot of stresses of the release cycle and having to go through so many teams, like I feel like that's a common theme that I've heard of. Yeah, we see a number of teams, organizations that still have really big deployments with a lot of teams basically coming together, pushing their code together and there's a lot of pain in it. It's a huge effort by huge teams. You get 10, 20 people that have to have watched over it at always weird hours and I think there is a lot of pain to that and that resonates a lot with people. Then when we talk about monitoring at a feature level, that also helps a lot. I was part of organizations before where we had a dedicated staff engineer to just monitor and fix performance on a daily basis because it's such a huge problem and it affects so much the performance of the company and so essentially you have this person that has to look at the performance being degraded today with the deployment up yesterday and what went out yesterday and you have so many things that went out, it's so hard to control. With what we provide, we tell you exactly which feature flag is responsible for degradation and so you don't need that person to focus on that anymore and you can focus on delivering value a lot better. I think it also might take away the need for extensive release notebooks and playbooks. When you do bring all those teams together, it's certain people that are in that meeting and there's a PDF saying, all right, we check this off the list, we check this off the list. I think that might alleviate some of that overhead as well. Streamlining processes, process efficiencies, workforce productivity improvements, big impact. And that gets code quicker to the user. You talk about decoupling deploy from release. What do you mean by that? What's the value? So the deployment in my definition is essentially getting the code out to production. The release is activating the code in production. And often people do both of those things at the same time. But there's a huge risk when you do that because if anything goes wrong, now you need to revert everything which is not a short operation often and takes a lot of effort. So now if you can basically push your code to production but separate the activation of it, the release of it, then it goes a lot faster. You have a lot of autonomy and decoupling and if anything goes wrong, it's the click of a button at the top. So like there's a lot of safety that comes with it. And we know that any outages has a high cost for all the companies. So it's like if you can reduce the outage to like five seconds, right? It's a lot better than basically several hours. Can you talk about the value out of split versus DIY and where are most of your customers in this process? Do they have a bunch of tools, a bunch of processes, a bunch of teams and you're really helping them consolidate Streamline? The one thing I hear a lot is we rolled our own A-B testing and feature flagging system. But some of the issues I've seen and I've heard of that, they don't have all those metrics or they have to work with a specific data team to get those metrics. And then you go back to having those meetings about meetings where you have a data team that's putting together a report that is then presented to you and then that's got to be presented to a stakeholder. And then that stakeholder makes a decision whether to turn on feature A or feature B, right? Our product, from my understanding, is we have those metrics already built in and you can have that at your disposal. The other thing I would add to that is like, we see a number of people, they start on the feature flag journey just because they have a high risk thing that they need to put out. So they do the minimal thing to basically control it somehow, but it works only in one part of the stack. They can't basically leverage it anywhere else. And it's very limited in capability so that it just serves the purpose that was needed at that time. They don't have a dedicated team to manage it. So it's just there that is very constrained and it's not supported effectively. The other thing is like for those companies is like they have a question to us themselves. It's like, do they want to invest resources in managing that kind of tool? Or is it not so close to their business that they want essentially to have vendor deal with it at a much lower price and they would have to invest resources for them to support it? It sounds like feature flags are kind of a team building. And we have a team building dimension to them. Yeah. It takes a team for sure. Yeah, and then once you add like AB testing and the feature flag, it's the collaboration between product management and engineering. It can go even further like to executives like to basically this, you know, view the impact, understand the impact. So it goes from the control to the risk management to the product and to the impact and measuring the flow of delivery and the communication around it. Here we are at re-invent. So many thousands of people, as I mentioned, we're on the second full day of the event. What have you heard from AWS that really excites you about being in their ecosystem? Any news in particular that jumps out at you that really speaks to improving that developer experience? Because we've heard a lot of focus on the developer. Yeah. I haven't heard much. Have you? So I arrived yesterday. I haven't followed yet all the announcement. I'm just like running on the news. Yeah, yeah. So I'm thinking on the booth at the same time. I stopped counting at 15 during the keynote this morning. Yeah. I can't keep up. There's so much happening at one time. So much. This event is a canon of content. A canon of news. Exactly. Re-invented is hard. But yesterday they've spent so much time talking about data and how, and I always think every company today has to be a data company. It'd be a software company. We were just fucking with Capital One and they think of themselves as a technology company that does banking. And sometimes I'll talk with retailers that think of themselves as technology companies that do retail. And I love that. But that's what companies have to enable these days is companies to become technology companies, deliver code faster to customer because the customer's demanding it. We're not going to want less stuff slower. Yeah. I mean, it's so essential I think for me. Like I joined Split because of that premise. It's like every company now is a software company. And every company has really to compete in innovation. You know, all those banks, Capital One, like we see it a lot in the financial industry where our message resonate extremely strongly is really in a high competitive environment and they have to be innovative. And innovation comes when people have speed and autonomy. And if you basically provide that to teams and the tools to basically get some signals and some quick feedback loop, that's how you get innovation. Like you go and decide what to build, but you can basically provide the tools to enable them to think about. You can experiment more flexibly, faster. And developers have to be empowered, right? I think that's probably one of the number one messages I've heard at all the shows we've done this year. How influential the developer is in the direction of the business. Autonomy and empowerment are two main factors. Because I'm a front end developer at heart and I want to work on cool stuff. And we're doing cool stuff. Like we are doing cool stuff. Now we can't talk about all of it, right? But I think we're doing a lot of cool things at Split. And I'm really stoked to be a part of the team and grow developer relations, grow developer advocacy and be along for the journey. Yeah, I love that. Last question for both of you. Same question. If you had a bumper sticker, you were going to put it on a fancy shiny new car, car of your choice. About Split, what would it say? P.A., start with you, then Chris. Bumper sticker. On the spot question. On the spot question. I mean, the easy answer is probably written on my T-shirt, like, you know, what a release, what a relief. I think that the first step for teams is like, you can have a message that's very, like even further, you know, the actual transformation is a journey. And I basically tell people, you know, you need to first crawl, walk and run. And I think that what a release, what a relief is a good step to like getting to the walking. And I think like that would be the first bumper sticker before I get to the further one about AB testing and, you know, innovative. Love it. Chris, what would your bumper sticker say? It would say split software, feature flags for the masses. Heart stop. Mic drop. Done. Awesome. Thank you so much for joining Pallami on the program. It's been outstanding. Introducing split to our audience, what you do, how you're impacting the developer experience and ultimately the business and the end customer on the back end who just wants things to work. We appreciate your insights. We appreciate your time. Thank you so much for having us. Our pleasure. For our guests on Paul Gillan. I'm Lisa Martin. You're watching the queue, which you know is a the leader in live enterprise and emerging tech coverage.