DevOps and Low-Code/No-Code: Develop, Test and Deploy – DevOps Unbound EP 36

Hi everybody and welcome to another episode of devops Unbound devops Unbound is a conversation amongst the groups of experts practitioners technologists people that are passionate about the topic of devops and related software creation and testing and delivery and all the Technologies processes people issues that kind of go with that. So we're happy to have a great panel here today really interesting topic before I get there. First one to thank our longtime partners and friends from tricentes who are co-creators of the show with us collaborate on topics and guests and things that we love to discuss that we're not talking about their products or other products specifically, but the folks that try scientists have really been very creative and I wonderful collaborators and we look forward to lots of great shows coming that we have in the works for you.

So thanks to linear and team and also to Jodi our executive producer and the folks Extract it also help bring this to you, which there are many folks that that all come together to make us look good. Well, we're on this panel together. So our topic is talking about devops and low code no code and going through the deploy test The Devout test and deploy cycle and we'll get into a little bit with the topic is more.

But first I want to introduce or have our guests introduced themselves. First if if you would someone would you would you introduce yourself, please? Oh Mitch.

Hi everybody. It's a lovely to be here. My name is Simona Domazetoska.

I work in product marketing at tricentus. I've been primarily responsible for our test automation Solutions and that's tricentes Tosca. And now more recently our SAS based test automation solution tricentus test automation.

Looking forward to the discussion and hearing your opinions on this exciting topic. But I think we'll have lots of those lots and including here great. How about let's see near Kush would you would you introduce yourself here?

Thank you stopping me Mitch here a lovely to be here. My name is nirankish Punjabi. Y'all can address me as Kush I work at service.

Now. I run there product management or for the platform where we have lots of tools which are local code Pro code testing tools for all the developers of all kinds to build on the platform. Looking forward to this amazing panel discussion today.

Fantastic and last but not least. We used to have a gentleman on the show. His name was like Clint Sprauve, but he's moved on and we have a new guest.

His name is Clint Sprauve kind of looked like the old man and that's just one right here. They sound long. I can you roll.

You used to be with tricentious. We were great. We're super pleased to have you back in your new role at Delphox.

Tell is welcome Clint. Tell us about yourself and I kind of work that you do. Awesome.

Thank you. My name is Clint Sprauve. I'm director of product marketing at delphics.

I primarily cover our Cloud pillar for a test data management as well as competitive intelligence. So what I do with I focus on being able to implement devops continuous devops to continuous compliance in the cloud, so that's by primary focus and really looking forward to this great discussion with the folks on the panel today Excellent. Fantastic.

I think I've got everybody introduced. So we're off to a good start. So yeah Loco no code.

It's not a new topic and certainly we saw a lot of kind of acceleration and adoption and look at no code especially in business units, but also within it organizations and I think one of the questions people kind of ran into along the way is well, how does loco no code fit with devops or does it or do we have to do some things differently in the end these things all combine whether it's one local node application and another, you know built in a traditional development tool those things all merge together eventually come out as one or multiple applications or databases data sources things at all. Talk to each other. So while we might create an application and specific tool or technology often times, you know, pretty quickly, they'll start to interface and work with other maybe even have to coordinate releases with that.

So we want to really kind of delve into the not just the development part and why local Different but as we start to enter the Aston and deploy cycle, what are the things we do? However, we adapted it or adapted devops to kind of include it in that sort of people process technology wheel if you will anybody want to take a first kind of stab it, you know, here's here's how you think local code. No code fits into the devops Infinity the if that's a good way to start.

So Jump Right In whoever's first gets the kids gets the first prize not to tell you after showing right I can jump in but I want you to that price. Okay good so much. You're right like local no code is not a new thing.

It has been there in the industry for many years. The thing which I love about local code is it's brings the culture of innovation where you're empowering all kind of builders. build applications, which can Delight the end users but when they are building these applications having the right guardrails in place are very very important and testing tools the devops tools Source control are all the right guardrails which are put in so that that Innovation that creativity which that Builder is building can be taken from an idea to production seamlessly.

I think this is great just to start. Yeah, sorry great start. And if I may add I really Echo the point of Nish was a Nish.

Sorry because yeah, so it really goes back to how do you define devops to begin with right? So it's quite a loaded term and it has frequently been relegated to the Realms of development and are indeed. But if you if we if we look at devops as a concept that improves the speed efficiency and quality of software delivery.

That's when I think we need to go beyond development and expand to as you say Mitch different line of business units and enable them to contribute to the software delivery process and that's where precisely see no code and low-code platforms playing a huge role by enabling wider accessibility different personas to contribute to the speed of the software development delivery process. So that's just my perspective. Yeah, I would never totally agree with that.

I think also that one of the things that people tend to forget or organizations that Bring in or Implement low-code no code Solutions is that we look at it from a devops perspective. The challenge has it gone away. It's just sort of evolved.

Right just because it's low code no code doesn't mean you're not going to have the same quality challenges the same release challenges that you have right? So I think a lot of organizations one of the things they need to embrace is the fact that only is everyone doing devops differently. Now we have to figure out okay, how can we ensure just because we can do things with kind of a broader skill set of folks, but making sure that we can Implement our solution and release our product.

It just don't assume that just because it's low code and no code that there we don't have any the same challenges that's most organizations that have A hundred percent. I I will plus one to what kind just saying. In fact in some cases the challenges may increase because now you have Pro developers building Pro applications, you have citizen developers building applications and you have no code Builders building applications.

So the amount of applications which are being built in an organization have increased because you have essentially democratized the way anyone can build in our organization. So having that devops cycle to take each and every application to the final Journey becomes very very important and because this democratization has happened there are various aspect which you called out your work in security like having the right security patterns test cases guardrails in place becomes Paramount for that Enterprise now because like they want more and more AppSec more and more digitization, but at the same time they want to make sure that the security footprint is still at the same bar, which was before so plus one to what Clint was saying that it becomes more and more important. Here you mentioned citizen Developers.

I think one period of time I think we thought them a little code. No code really just a citizen developer tool, right? That's what people non-technical people and the business units outside of it.

Let them kind of play in their sandbox and go create their their applications. So by the way, the first Loco no code app was physical in my opinion. But anyway, that's that's going way back, you know, because that's really weird things done this account anyway, but it really is much more than that.

I mean, yes, it's empowered and enabled a lot of people as you're talking about Kush in the business units to create their own applications and do data management and put in logic and Screen flow and or whatever my mobile AppSec, whatever it might be without having to have super amount of depth. And then also we're collaboratively with the it organization when they need other things like security and data and integration AppSec or it's also a tool which I use a lot of times those AppSec. Consumed or adopted or even now built within the it organization themselves true agree with that.

I would say to like I I often see local no good and procode having a seamless bridge between them. Like because I see local and local tools as a progression of an API. An API is used by a pro developer to build an application.

But as you keep making that API easier and easier to use all the way to drag and drop you're essentially democratizing anyone to use that API. So the tool chain should be exactly the same. The challenges are exactly the same.

The surface attack area is exactly the same. That's why I like devops needs to be taught through not as only for certain set of applications but as a whole Yeah, I I definitely definitely agree question. I think that if we look at you know, if we're speaking about personas we should also talk about what are you testing?

What is the application that you're testing? Is it a consumer facing app? Is it sap is it an Enterprise Erp system, right the speed at which different types of applications get built across different Industries vary significantly and that also has implications on who are the personas that are responsible for testing those applications as well.

So, you know, I hate to bring up the agile testing pyramid, but it's a good thing to talk about right because let's talk about consumer facing AppSec. I guess that's where speed of releases increases significantly and you need to have a solid group of unit tests test that individual code integrate into Bill. Sorry commits the code into your CI/CD pipeline and run those tests the problems that arise is what about those larger tests?

What about your system test your integration tests, you're into n test who's responsible for those and let's just hypothetically say you have an sap business analyst that is looking after, you know sap applications how to how does that team collaborate with the development team and what type of testing do they do? So as you can see it all gets really complex and I think that if we're going to answer the question of the personas we should be really We should clarify first. What are we testing?

What is the scope of the testing? And what is the testing strategy? Because you can't do it all at once need to go bit by a bit and understand right like, you know where you're going to start and I think that's that's really crucial component.

Yeah, that's a great point because there's also there's so many different aspects to testing right A lot of times when we look at we think low code no code or Pro code. We think of it either as development or ridiculate think of it as just functional but as you know, as you mentioned back that you have, you know performance testing you have unit testing, you've got all these other components that have really come into play that require a certain level of expertise. And then if you throw in test data on top of that do I have the right amount of test data do I have that test data properly masks?

All these key components or at least components are still key in terms of how you develop that that's software and how it's going to relate to each of those personas as you build that application. It's interesting. I think sort of the fallacy was well, we could create it because we've sort of abstracted out the complexity of the technology by using a low code no code.

But you know not even good software developers are always good at signing testing strategies. Yes, they're created lots of things in that everybody's created everything and it does take their situations and things it's benefit from a different mindset, right? You know one of my kids was very good at breaking things and sometimes not intentionally, but you know what someone who's just like, let me use this in a way.

It's not intended. Let me design something for how we think it is supposed to be used in all those kind of things and I'm curious to what you're experiences working with customers or yourselves. How do you introduce the topic of testing beyond the citizen developer?

Let's say testing it themselves. Is it sort of the this is breaking too much. We need to get more help or can you roll this in as part of a larger discussion?

Okay before we roll this out that's got it. It's got a calculated interest, right? So let's make sure that's you know, we've got this wall covered.

Yeah, I think it depends on the organization and which group you're talking to right? Because there are because we mentioned there's so many different personas. There's so many different aspects of quality in terms of how you build that into the application.

You know, if you're talking to a developer that may be working on Enterprise package application like a service now like an sap like a Salesforce the conversation is going to be different than if I'm working with someone that's more focused on kind of the end user sign. So typically when if I take it from just from a test data management perspective, you know, when we engage with a particular customer we want to understand and typically our customer will be probably a little bit more technical on the data side because they're working with working with death testers. So they need to understand.

Okay when you're building this and we have to talk to different groups throughout the organization. So I need to understand. Okay, how can I get a replication of production?

Data, what are the legal ramifications that I need to go to? How do I get that? How do I mask it?

How do I make sure it's secure how do we make sure that we don't have multiple copies floating out there, right? So what's the best way to do that? So, you know, they start getting into you know, if femoral environments and things of that nature, so I think it really depends in terms of that.

Typical Persona in terms of how you engage with them and their understanding of quality and where they need to do it because it has to really span across the entire developed lifecycle. So there has to be different conversations for those different groups. Hey.

good, so Oh, sorry. Sorry Chris. Yeah, I just wanted to say as well.

I agree with what Clinton saying at tricentus. We have a continuous testing framework. So, you know different types of customers have different levels of maturity when it comes to their testing and devops practices.

So we have a cruel wall Quran fly approach and the first step usually involves. Let's switch to test automation because a lot of companies out there are still doing manual testing and once you establish a good set of automated tests, then you need to look at things aspects such as well. What about performance testing?

What about usability testing then you need to expand your different types of testing that you're doing but then again complexities the rise, how do you integrate those tips the tests into your CI/CD pipeline and that's really quite complicated. So we have to really look at the the company and the industry in which they're in because there's different. Levels of maturity.

So for instance if you look at banking or Challenger Banks, I mean they're having to test across a really wide variety of applications. Not only those consumer facing AppSec which by the way if there's one tiny glitch or if the application loads too slowly the customer will just get frustrated and customers today are ruthless and they will just go to the competitor. So not only do you have to ensure your consumer-facing AppSec and customer-facing AppSec are flawless.

But also that it works well from an end to end perspective. So from banking, you know, you have to make sure that integrates well with your back end systems with your third party applications as well. If you're doing SMS verification and that whole process needs to be tested, but the question is how frequently do you need to test that you know, do you tested, you know, every 40 seconds or every 11 seconds like Amazon does with its current applications.

Well, I would argue. You that's where you need to define the test strategy you run your unit tests on a much more frequent basis, but when it comes to those larger entrant tests, you know, we see companies having different approaches some random on a nightly basis on a weekly basis. It really depends on how much coverage you're aiming to get and what what is it?

They actually testing I do I think like Richard depends like as a seminar and Clinton called out customer to customer but the core principle Remains the Same we cannot think about development at testing as two different things. It's the entire software development cycle you design you build you test one of the things which service now has done is like it has talked through local code in every category. Like we cannot make development super easy and testing still very hard.

So service now has invested in create low-code no code testing tools where we automatically generate test cases for your business rules. We automatically generate performance test cases give you performance heat map on like okay, if you have XYZ users running concurrently on the system, how much will be the load so all of these things help the customer on Into the testing strategy and as Simona was calling up. Like each Enterprise needs to make their own decisions, right?

Like how many times they are running their unit test cases how many times they are running their end to end cases? Like if multiple developers even local no-code are working together what kind of hygiene practices the Enterprise wants them to go through so that the conflicts are not causing any regressions for the end user. So if everything everything is thought through as like hey, I'm building a product and not building a product and testing a product then the right practices are big 10 and it seems that you know different platforms different different Technologies provide test capabilities.

Themselves. There's also other kinds of testings that may not maybe not be provided by that platform. But also Cross application cross deployment activity pipelines that we need testing because when I was I was running it a period where everybody was worried about Shadow it Shadow it Shadow items like, you know folks are doing this for a reason there's value they're trying to gain, you know, one of the roles it can be here for is to provide security access to data but across deployment and Courtney pipeline coordination of delivery of software because a lot of times there's integration between our own app and third party AppSec and that that's gets pretty complex.

That's not something a business person necessarily what is going to want to spend a time to figure all that stuff out and know the back end of what's happening in the systems and it and that seems to be another place where the professional tester or a test or QA organization and you can step in and say yes. Okay great. When you deliver this new functionality for the product that you're releasing.

Here's the coordinated test plan that we'll do with the billing application and the provisioning in the product or the product catalog while you're delivering the whatever part of it that don't customer orders and something like that. Yeah, it's it's interesting. Um, you know, when I when I joined delphics that I initially thought I had a, you know, a really keen understanding of just test data management and some of the you know, the use cases and some of the challenges and one of the things that I learned and just understanding, you know from customer case studies and talking with customers and different events and so forth is the fact that When you think about what you what you just talked about and we all experienced this your choice sentence and service.

Now when you're working with these integrated complex end-to-end systems where you have, you know, commercial applications homegrown applications, you know your package applications where you have Salesforce service now, all these components linked and I thought about it from a data perspective. This is where you know, you have a new vehicle into that. So now I've got all the you know, just trying to test all these systems how they work together.

Now, I have to make sure that all the test data is it's sync across all these different applications and trying to maintain that so I think there's so many different levels in terms of how we need to look at quality just across the board and then we haven't even talked about platform engineering or performance testing or observability and some of these other key capabilities that come in so it's Take a lot of times as organizations, you know, it's just kind of step back and look at okay, what do we really need to be successful so that we don't hit these roadblocks. Right? So we always say that, you know, the whole cliches, you know, QA is always the bottleneck.

Well, no, it's not necessarily QA is because of how we are lack of planning. That's kind of causing that so I always try to look at it from the standpoint of okay, what are the things? We really need to make sure that we're focused focusing on so that they can properly address these issues across the board.

Yeah, and I think it's it's true that You know QA is always enough to talk after thought and it's not just QA it's a security testing as well. And I think this data point is always iterated and almost every single state of devops report that you read. The number one barrier to adopting devops is I mean, I think this was in a recent dinotrace report that you know, if 55% of organizations admit that they are forced to make a trade-off between security and quality and user experience in order to meet that rapid transformation and test data as you point out Clinton is a huge problem as well.

It's not just test data. It's many different facets of testing but you know going back to what Mitch said regarding, you know Shadow it and you know, how can we solve that problem? Because I think security is a huge critical component.

I mean, we all know deaf sick ops is a very important Trend we need to be integrating security much earlier into the developmental cycle. So what do we do? When all these business users are building all these, you know, no code platforms that do deliver value, but they're also can cause a lot of security threats to you know, the organization if they are not tested the applications are not tested for security and then you will end up in a really messy situation where your customers lose trust.

So I think that These local platforms really need to embed those security functionalities within them whether it's you know access control or you know threats the system is assessments because that's really a situation that you don't you don't want to be getting into and we have numerous examples in our industries of you know, companies facing huge challenges. Like I think it was targeted back in 2013. They had a suffered a data breach that compromise the personal information of all their customers, right?

Why because the security the payment system processing system was not tested thoroughly and in advance, so I think we do need to be thinking more carefully about how can we embed security testing with those personas that are Developing Beyond building applications Beyond it. It's interesting to that. Yeah, I once describe to someone testing is like think about buying a car if it was coming off the manufacturing line for the first time but it never been tested.

What are all the things you'd want to know, you know, really do all the buttons and blinkers and all those things. Hold up will this hold up at a certain speed or higher speed lower speeds longevity, you know long trip for since they're short-haul what happens under, you know, safety crash condition. They're all different scenarios right that we need to think about security locks.

Keep keep people from stealing your car. There's all that there's a lot of nice analogies that kind of can make sense to someone who's not a professional QA person or security a dead set gaps security person to understand why those things can fit into a deployment cycle. How do you have that conversation with a let's say a citizen developer team to help bring add those things into the mix of what they're doing because you know citizen developers can be just like any other developer.

Don't slow me down. Don't stop you. Don't make my job harder, right?

Nobody wants that. So how do we introduce these Concepts different kinds of testing to them Simona you want to start out? yeah, I mean it's it is a challenge and I read this really interesting article in The Economist about a business test or I believe it was an Australian telecommunications company that what this gentleman did is he built an application that unified several different messaging systems for reporting phone line problems.

And he did this using a no-code platform and the app in interface looked a bit clunky. I had some buttons here and there but actually got adopted across the organization and I think more than 1,300 employees and technicians were actually using it and that saved the company 12 million dollars. So yes, it does have value to have these platforms.

But when you do when when an employee feels empowered and wants to bring Innovation to the company because they are after all the front line with the customers with the employees and they know exactly what needs to be built then enable them let them build it let them experiment but they need to be some procedures in place and I think that That's precisely where security testing teams and it teams can come in. They need to collaborate. So this is where you know devops is not just it's not all about tools.

It's about how do we if you want to launch such as such an application you need to then therefore bringing the it teams to precisely to test those platforms in terms of data privacy and make sure that all those aspects are in place. So look, I don't have a super bullet answer but I think that collaboration is is crucial and I know there are several tools in the market that do enable security testing to to come in early into the piece. Yeah.

Yeah, and I was going to do that. I think that what you're starting to see now is a majority of the student the devops or devs that got platforms are starting to ensure that their tools have security mechanisms built in to make sure that it can be done at that Dev test level. So they're really starting to incorporate that across the board.

I think the other thing is that There needs to be a more proactive input in terms of because security again is not a nice to have anymore. It's it's a must and it has to be it used to be you know, yes the developer to you know, make sure his code is secure he'd have to go to the security team and bring them in so they could kind of come out. So now it's kind of you know, you're getting the there's you're starting to get the best of both worlds.

So it's a matter of how can we ensure that? So another example, there was a large telecommunications company that within the last few months and a huge breach the cost and millions and millions of dollars. Well, where did that breach come?

Well, they got in through the systems that they use protesting and the you know, the information that these protecting allows to preach those systems. So it comes down to as someone was talking about making sure you have that in place but making sure that if you have groups where security is not there. Are bread and butter or they don't have the wear with all really kind of grasp that you can put those things in place to ensure that as they're doing the development as they're doing their testing.

They're going to be taking care of there's something that they shouldn't have to Actively think about at that level but you know again it should be on everyone's mind but they shouldn't have to proactively be looking to this be something that should be embedded in all of these systems as we go for. I I agree with that. I think one of the big things which are these local tools should solve for us like embedding these best practices as guardrails into the system itself.

And that will take out lot of noise out of the system. So that's the first part. The second part is like introducing these Concepts to that developer whether it's a local developer or professional developer.

to to test these things at the right time like there's there is there is a fundamental thing in the industry where the car like shift left shift left. Like you don't want to test when you're entire app or entire thing is build because then you're putting a lot of owners on finding the issues at the tail and of your development cycle you want to find the issues when you're developing So introducing those best practices early in the development cycle whether you're a procodeveloper or a local developer is going to help a lot. The third thing is the bridge which I talked earlier if there is an amazing bridge between a local developer and a broker developer the then they can work together in this journey where like a local developer could build an application send out to code review or to testing to the pro code buddy and they can work together figuring out the right testing strategy and then putting it in production.

One thing which we haven't touched yet is like the importance of beta users right? Once you're building an application you want to have that application used by a small set of users who can give you feedback on user experience. You can give you feedback on the important issues or important use cases you you want to cater to and that kind of feedback listening to your customer listening to your end user and incorporating that feedback into that application at the right time becomes very very important.

A hundred percent agree cushion. I just want to add. When you bring in that feedback, you know, that's when you can fix the problem right there.

And then you don't need to feel you know build the full solution. And then launch it to the market you need to bring in that much needed feedback early so that you can prevent such, you know issues coming to the fore and speaking of security one thing. I think that's also very interesting is AI.

and what that means for privacy and security and so if you look at you know Functionalities or Solutions such as process mining right? This is where you look at. How does the product application work in production?

And how can we derive test cases from that by unanalyzing how users are using the platform? I find that very fascinating. But I also find it quite concerning when it comes to you know, privacy and security because process Mining and Discovery what it does is it utilizes event logs and looks at screenshots and where do you store those screenshots?

Is it in the customer Zone service or is it? Potentially sensitive data being exposed to external servers and I think that's always like a huge showstopper for organizations. And that's those are the challenges that we also need to address when we're embedding different Technologies to you know, speed up testing but you know, bring those privacy concerns earlier to avoid catastrophes, right?

Yeah, I totally agree with that because I think if you look at ephemeral environments and I think that really helps reduce the amount of data sprawl in terms of where things are our captain and how things need to be kept. So that's that's a huge. I think that's a that's a big issue as well.

Yeah, I was thinking no fur producers. Another great topic we could have is how do you test AI generated code as they're special consideration today that right? That's it.

Yeah. Yeah. We just go to chat GPT and ask them.

How do we test just go down the road the rabbit hole? Yeah, let's wrap up on this and well, I'm sorry. I opened the portal to that rabbit hole.

We won't go full down it, you know something else we haven't talked about yet. We talked about devsecots kind of s*** left idea with security, right and also that applies very much to to testing as well. There's also a shift right both security, but all so for testing right testing in production, which used to be a big no, no, right?

We would never do that. But now it's it's a very legitimate strategy. in approach cushed maybe if you want to kind of kick up thoughts on what might look code no code and developers think about of things that are beneficial to test in production that aren't going to be destructive that are going to be valuable to to learn and improve from the first thing which comes to mind which Clint also called out was observability.

Right in production. You can essentially gauge like, how is your CPU Lord? How is your memory pressure?

How many users are concurrently using your application? Can you scale up your application? How many users are coming from different countries?

What are the experiences for them? If you don't have a CDN all these things you will get to know when you're in production. And when you are like deploying your applications, like from small number of users to ultimately like the full set of users you have and that kind of testing becomes very very important.

One of the things which has become very very apparent in an Enterprise industry is like everyone wants to have consumer grade applications because if I'm used to going to a consumer grade application in my personal life, I want to have the exact same experience when I'm in office. I want to Consumer grade application with which feels Snappy which has amazing user interface and which can do for me rather than me working on that application. And like all of these things become very very important.

Even your thinking about that shift, right? yeah, totally agree with that and I think that one of the Issues that we fail to I think when you think about the biggest myth I think when it comes to low code no code is that it's especially you put in the context devops and that you think of these tools or Solutions as being very limited in terms of what they can do either where these ship left or s***, right, you know, in terms of the level of integration of what you can do when you think of Loco no code you automatically think okay. I'm limited.

I can't do all the things that a traditional developer can do but you still can you can follow those same best practices and the thing that are needed to implement devops correctly and that's set up, you know in terms of doing observability doing monitoring doing performance monitoring and all these things, you know understanding what does it look like on the production side being able to use that particular data to be able to ensure that we're going to really we're going to build the right application. So I think it really comes down to if we are. To when we talk about shifting right and some automation this earlier how a lot of times we focus we think of devops we focus on the shift left side.

We think about they develop a perspective but never and operations perspective. So now we have to look at observability, you know in the larger contexts as well as you know monitoring things that Simona in debates, if your name gets called out then you get to you get to jump here. Yeah, I can't disagree which means I agree.

Yeah double negative but no I think shift right is definitely very critical because they're just certain issues that can't always be found in the early stages of testing and that's when you really need to bring in both functional non-functional testing such as performance security, you know, you need to see how that works from an end-user perspective. A lot of critical issues can actually be called then so we need to be thinking about that definitely. Wonderful.

Well, thank you. Thank you to all of you. I'm going to mention to to our audience.

We now deliver about some bound as podcasts so you can get it on your favorite podcast platform. com and start there or go to Spotify or apple or whatever podcast delivery system that you enjoy using Simona. Thank you so much for being here with us.

And thank you to all everyone to try sentence for sponsoring a kind of industry collegial conversation here today Chris great to have you from the service now perspective. Of course, I'm very widely used low code no code platform and lots of wealth of experience and knowledge bringing. From that perspective and of course Clinton your prior and new roles and now kind of thinking about the data side.

It's been good to have you from Delphox as well. So thank you to all three thank you tricentious and and most importantly thanks for our audience for spending this time with us together in exploring the topic. We hope you will come back for our next topic.

We we have a new episode about every two weeks and some live round tables. com and also Textron time tech TV, it's Textron dot TV, excuse me for a new and as well as past episodes. We'll see you all soon on the road to devops and local code.