Here we go another episode of Adventures in DevOps. Jillian, thank you for joining me as co host today. Hello, Warren is off on vacation getting some much needed rest and relaxation and also joining us today, Vernon Keenan from Salesforce DevOps.
Welcome, Vernon, Thank you, thank you.
It's great being here. I hope, like, I'm sure some insights.
Dude, I'm pretty sure you can.
Because I'm particularly excited about this because it's not very often that I get to hang out and talk with people who have been doing this longer than I have.
So I'm not trying to like throw out your age or anything, but I feel like.
You know, yeah, I take it as a badge of honor that I've been doing it this long, and so when i meet someone who's been doing it similarly, I'm excited.
Well, thank you, yah. I've been doing it for forty five years now, that's a while. Started my career at the Northwestern University working in the medical school, and then had a great chance to work at Genentech in the early.
Days, and that was what were we doing there.
I was doing clinical research, so I was actually one of the first people to see the results of the clinical trials because I was doing data analysis and we used a product called SASS, and of course, because we were genetic and we thought we could do anything, we decided to write our own clinical research product. How hard. Yeah, that was. That was a lesson in humility, right because because we we we learned that Oracle did a much much better job at that particular product.
Than we ever cracked down some hubrist So I'm sure it was all fine.
Yeah, yeah, I mean it still happens all the time, you know. I talk to enterprises all the time, and people still waste their time doing custom projects they could buy out there.
I think it's one of those It's one of those lessons that you can't teach anyone.
They just have to learn it themselves.
Yeah. Yeah, I mean, because you're so conceived, you know, you know that you think your requirements are so unique, You think your requirements are special, You think that your
talents and your abilities are special. Well, it turns out they're not, generally, because usually what happens is a software company is going to find somebody who is much better at those qualities than you are, because they're going to produce it for ten times as many people and they're going to make ten times as much profit, so they have as much, you know, ten times as much motivation to find to find the right people. So but that's yeah, I got started there, and then I had a fascinating
early career. I was that I was at Oracle and actually Mark Benioff himself hired me there and I was working for him, and I had the unique experience of going into the corporate visits center all the time and I was basically just lying my butt off all the time, drawing boxes on the board, putting putting arrows, talking to the CEO of various global companies, saying, yeah, we can do this, we can do that. We look at this application server. It puts everything together, and it was all
It wasn't true. It wasn't true. That's that's what I call the first act of enterprise software. We basically said everything was gonna it was going to work. And then and then it didn't.
Like first act like a Shakespearean tragedy where you know what acts too, and there you're going to be like.
Well, yeah, I mean act too. I think was the data Lake data warehouse era. We tried to put everything into like a secondary storage area, and we still didn't get transformation and we still didn't get you know, new capabilities out of that. And hopefully we're in the third act now where maybe things will come.
It is just going to do it for us, That's what I think. Well, my data anymore? Who who needs even Mango dB when I've got AI.
We could delve into that a little later, I guess, but but yes, So my friendship with Mark Benioff is kind of interesting because I recently renewed it. It was fascinating because I wrote a blog post that got his attention that said why Salesforce trailblazers don't care about AI? And my phone started blowing up and I and I was have renewed my friendship with Mark. So so that is that that's interesting as well.
So what's your take on that? Why don't they care?
Well, the reason was because they didn't actually put it, make it available in the product. So the thing about Salesforce that I liked as a you know, like I got my first Salesforce account actually way back in nineteen ninety nine, and I've been using it, you know, on and off, and I actually built my own business on it about starting in twenty twelve created a whole enterprise
product for telecom that I used in my business. And the reason why I thought that the Trailblazer community was so active and so forthcoming with chips and tricks and like techniques and sharing and things like that was because the SaaS pricing model basically gave you all you could eat for a fixed price. So any Trailblazer would be able to like go to the set up menu and search for a new feature, for example, and then they could just like start trying it out. So those capabilities
were always in there. But because AI seems to be different, mainly in terms of the cost that the companies have to burden to provide it, they didn't do that. They made you order a product. So while they were all carping and you know, saying AI this and AI that, like ninety five percent of the Trailblazers out there couldn't get access to it. So that that was my point.
And the thing that was a fascinating story actually is that what happened was Mark read that they sent me the keynote and I actually was able to like edit the keynote and tell them what they should fix. Oh wow, And this is like three days before Dreamforce, and and
they I sent it back to them. They put all the changes in, They changed product timelines, accelerated timelines, and just you know, made a bunch of people, you know, you know what happens with the CEO says do things to a bunch of people they weren't expecting to do things like over the weekend and.
Weekend that at all.
That's right, it's gone. You know. It's like plus, you got all the stress of you know, Dreamforce coming up, all the prep and now they got to change all the products. So they changed it. They actually included a free version of their new Agent Force thing in a new go to market version of their product they call Foundations, which is kind of like you can just buy it with a credit card as opposed to dealing with one of their account executives. They so they actually changed the product.
Not sure how effective that was, but kind of just like in any situation, when it did, it just peeled the onion a little bit and revealed another problem underneath, which is how are they going to charge for it? So they haven't really figured it out yet is the answer. So there's a lot of confusion out there. In the Salesforce world as to how they're gonna pay for it. The all this magical AI stuff. Sure it keeps talking about for sure, But so get back to the saastevops thing.
I just tell my story a little bit more so, Like I said, I was in Telecom, I had this. I had built an actual tax engine on the Salesforce platform for Telecom, which is you can imagine, it's pretty complex. And I had an opportunity to kind of like leverage that tax engine outside of Telecom. And so I realized that Salesforce was kind of a bad platform for that
because of its performance characteristics. You know, like if you're gonna have an API service, you don't want to rent it off as salesforceas it was just too much overhead, too many constraints. So I personally got into more of I think your world of DevOps kind of like the go Kubernetes world, and I implemented all of my stuff, you know, my new API, my new database everything with Go Kubernetes. It was beautiful scalables, you like, one hundred
times faster than Salesforce. And so I had that, but you know, business wise, that project didn't go anywhere so I had all this wonderful new DevOps knowledge plus being the Salesforce expert, so I turned my attention back to Salesforce, and then I realized that they were in deep, deep,
deep trouble when it came to release management. Basically what happened was Salesforce had an initiative in the late twenty tens was called the sfd initiatives where they essentially created a command line interface to their metadata API, and this enabled developers to pull configurations out of a Salesforce org
and put them into a get repository. So now this is starting to sound a little bit more like a regular DevOps workflow, right where you have repository, you have a somewhat kind of a source of truth, and then you're able to deploy it again in some fashion, maybe to another org, or you're changing the deployment and you're redeploying it to add a capability, fix an error or something like that. So it turns out that the SFDX effort was noble and was good and actually was kind
of sufficient to begin the DevOps movement within Salesforce. And so what happened was all these end users basically started to try to figure out how to use this SFDX tool to manipulate Salesforce. And then at the same time, a group of companies I'll name a few of them. The leaders are Capato and back then Flowsome, and another one that's come out is gear Set and all of
these companies. What they did is they kind of operationalized that API or that CLI interface the Salesforce that provided end users and put a low code CLICKI interface on top of that capability, so that Salesforce admins and other folks who were accustomed to a low code interface could start to do release management in a more rigorous way using tools like get or vs code or things like that to you know, have a more kind of rigorous development effort. But at the same time, it was still
constrained a lot by the way that Salesforce works. So like, here's here's a crazy thing. I mentioned this metadata API, right, and you think that this metadata API would love let you to actually pull all the information out of a Salesforce org so that you could reproduce it, like maybe
copy it to another org or something like that. Turns out that there is neglect within Salesforce the company to implementing the metadata API, so they have they have definitely a priority to get the low code interfaces out there first, so they actually recognize that they've gone to the point now where it's a real problem. And some of these
DevOps companies. Another one I'll mention is Elements Cloud, and they're interesting because they have all kinds of proprietary ways to go into the Salesforce Org and get out that
metadata that's not available through the API. So this kind of gets into a central theme that I have all the time when I'm talking about SaaS stevops and Salesforce DevOps, which is that the way these things work is that you kind of have to treat the subject's system, you know, like the Salesforce Org that you're updating or the org that you're reading or copying. You have to kind of treat that thing like a living system where there's there's no source of truth really other than the state of
the thing that it's running in now. And that's really quite problematic because you have to, like in order to understand if you can produce a deployment that's going to work, you know it's not it's going to go through and not have any errors. Essentially have to like the only way to do that is the is to submitted to the org and see if any errors come out. So you can imagine how slow that would be on an
iterative basis and how frustrating. And this actually gets back to a complaint that Salesforce developers in the community have about working with Salesforce, which is that it's very slow. It can and like as somebody who went from goot Go to apex, you know, Apex is the is the development language, this jab alike language they have for Salesforce.
So like with Go, I could just you known't compile things, you know, hit you know, recompile or whatever, go and I'd have like ten seconds between a coding change and being able to see if it worked. With Salesforce, that can go out to maybe two or three minutes sometimes, right, So when you submit a package to either your Scratch org or even you know, a Sandbox org for testing, it's still going to take you know, like ninety seconds
two minutes that for that submission to go in. So I think Salesforce developers are always complaining about this this flow of work thing, and the way that you can fix that as a vendor is to do kind of what Elements is doing, which is to create what I call a very complete digital twin of your subjects SaaS
system within the DevOps product that you're working with. So Elements has a separate like AWS thing running where they essentially ingest all of the metadata from an org and convert it into like a graph database or some other kind of representation that they can then manipulate. And then they can use that to do something which is very
essential in Salesforce, which is called impact analysis. So like if the boss says, oh, we got to have another you know, shipping type in the shipping module or whatever, then that thing needs to be defined in what they call a picklist in Salesforce. And when you change the picklist though, you could actually impact a whole bunch of different things, you know, different screens all over the place, apex code, user interface mechanisms, and other things like that.
So by having a digital twin, you're able to easily pick do what I call impact analysis or change intelligence is another word they use for that. My favorite term is blast radius for sure. You know, like like when you when you make a change, what's the blast radius potential of that particular change? And so that's a that's a critical and that's just one thing, one example that you can't get out of salesforce and that you do.
You need a DevOps service provider to help you delve into that and to help you organize that stuff.
So let me pause you real quick right there and like reach out the problem here for our listeners. So with these large enterprise style SASS, I think you're describing two problems here. One is you never know what the true state is. So someone with the appropriate permissions could go in make a change to the environment and you don't have any way of tracking that change to see what was actually impacted, aside from asking that person, hey, would you do and getting their typical response nothing.
And then the.
Other one, the other aspect of this is if you want to introduce new features or capabilities to your system, you don't have any way to create like a staging area and test your changes before you apply to production.
Correct. Correct. So those are those are both capabilities that DevOps products, salesforce and SaaS stevops products that you do. And the most popular salesforce s deevops product is from a company called gear Set. They're in England and the simulated deployment is the most popular feature of that product. So that's and it's also affordable, so like for two hundred and fifty bucks a year or whatever to get a seat for that thing. Yes, yeah, it's pretty cheap,
and it'll save you a ton of time. Basically, it's that iteration.
Yeah, at that price, it doesn't even need to save you more than a few minutes per year.
Yeah, yeah. No. And and gear sets easy to buy too. That's another reason why they're popular. They kind of have a you know, a PLG product led growth concept where they just try to make it easy to use, easy to buy, you don't have to talk to a sales rep, where with most of the other products, is more like an enterprise sales Yeah, sales loop where you got to kind of delve into dealing with somebody and then coming up with a license agreement.
Jillian, you were about to say something, Yeah, I.
Was just wondering who is kind of the target audience for this, because on the one hand, we have salesforce, which is you know, like a sales tool, right, and then on the other hand, we're talking about DevOps and from the you know places that I've been at the sales and marketing team is not necessarily going to know where I want to have anything to do with any
type of DevOps project. Right if they could be running things off of their laptop and accel or whatever, they probably would and would have nothing to do with somebody like me. So I'm just wondering, what are kind of the target audiences of these different tools.
Well, that's changed over the years, so I think that's important to realize. So the Salesforce has evolved over the last let's say eight or nine years into an enterprise platform, so it's more like an application delivery platform than a
pure CRM than it was in the past. And also, if there are several customers out there, salesforce customers out there who are spending in excess of one hundred million dollars a year on Salesforce and kind of the minimum for a fortune five hundred type company, the minimum expenditure is in the tens of millions. So because of that, a lot of the responsibility for maintaining Salesforce has moved off of the departments and into the office of the CIA.
So I think that that's part of the explanation for why people care about DevOps is in Salesforce now, and it's been it may have been taken out of the hands of some of the departmental because that they want to increase efficiency. But I think, Jillian, you're right that everybody, you know, there are lots of people out there who could care less about DevOps and really want to use Salesforce kind of like what they've been telling you. How they've been telling you.
For marketing tool, I thought it was like a more robust like HubSpot or something.
Yeah, yeah, yeah, it's.
A contractor thing and I have like Harvest and HubSpot for emails. I thought that it was a fancier version of that. And now I'm finding out that I was so wrong.
Is well, you're not, of course, are not wrong, but I mean, there's just the they it's more like they want it to be bigger. And the other thing to appreciate about salesforces is that when they're in a big company selling, their number one goal is to have multiple clouds, as they call it. So they have their sales cloud, their marketing cloud out, their commerce cloud. Now, they have data cloud, now, they have you know, all these other things that are kind of all designed to work well.
Actually they're not well designed to work together, dirty little secret out there, but and they're trying to make them all work together. They're actually rewriting.
Somebody doing their best.
They are, you know, I'm a critic of them, and I always like to, you know, have a little empathy in my criticism. But they're, yeah, they're they're trying. They're trying to do that. But I think they definitely want the attention on their product to be at the CIO level. And a lot of vendors now are in the salesforce ecosystem are kind of like turning their sales pitches in
that direction. Where before the sales pitches need to be used to be more in a land and expand kind of philosophy, so that they would be pitching to the trailblazers, would be pitching to the sales managers, would be pitching to, you know, the people who are actually using these products more. But the pitch has definitely turned more to the CEO CIO level pitch and like. And also let's look for a minute at where DevOps is most prominent in salesforce,
and it's it's almost always in a critical application. So there's a salesforce partner out there called Encino and Capital ci n O and they are a multi billion dollar valuation public company that that runs on top of Salesforce and what they do is banking, so there will do
financial transactions and banking service. So you can imagine that the people who are running and Sino installations definitely want DevOps right because they they definitely want to be able to have a record of all the changes they made to their system. They have validation protocols, they have q A protocols and they and they have to sustain them. And there's actually a DevOps company that's pretty much devoted to that one sector and it's called auto Rabbit. It's
a cute name, huh yeah. The their annual conference is called dev hops.
Yeah, good job.
Yeah. I like auto Rabbit. They have some Greek people there and and they they're very rigorous in terms of the security aspects. It often gets folded into salesforce DevOps too, like static security analysis and and other things like that. So yeah, I think the reason why there's been a transition from Salesforce being kind of this this SaaS platform that you just use to being something that has to have like a change management process associated with it is
mainly the introduction of critical applications into it. There was another product used to be on Salesforce called Viva. Made a heard of them. They're a big, another giant software company who services pharmaceutical industry. So you know, like I used to work at Genetic, and it totally reminds me
of what we're doing. Is kind of like the software QA and validation that we had to do for the FDA, you know, like a Genetic we had to like have a protocol for for how we like did all the rat lab way, you know, so that we could produce that protocol to the FDA and say this is how we weight all the rats, and and the similar thing happens with software too, right, So they that that's where this kind of culture came from, I think, and it's it's now been extended more into Salesforce.
So what are the.
Like In my experience, very few people who really need DevOps.
Know that DevOps is the thing they need.
So what does a conversation look like for you when you're talking to people that clues you in to say, oh, here's what you're missing, here's here's what this problem is describing to me.
I think it's release management problems. That's that's the other essentially equivalent description for what the field is in Salesforce because like I mentioned before, the there is so many speed bumps and roadblocks to developers to to get the is going. So if you're what a lot of these products do is they offer you cic D pipeline automation as well, so they kind of give you a clicking
interface to let you do pipelines. And again it's it's more compatible with the Salesforce trailblazer kind of profile to have that. So I think it's it's a common pain point in almost every Salesforce shop that does customization is is this. And they also know that the vendor ecosystem is out there to service them because if you're part of the whole Salesforce, you know Dreamforce World Tour thing, you know all all of their outbound communication and their
partnership programs and everything. There are companies like Capato and gear Set and flows some and all these companies are upfront, you know in terms of their partnership, and Salesforce actually has investment relationships with some of these like Capato, and they does the Sales Force frequently recommends them to solve
problems for big people. So I think people realize that the release management in Salesforce is still broken, still a lot of problems with it, and you probably need some vendor help to help you get through it.
Yeah, I'm sure.
Just thinking about it from a Salesforce perspective, you know how they started and where they got to. Now you're dealing with thirty years of legacy code and now you're like, oh, hey, let's do this new thing. I would imagine that that's not an easy implementation.
No, it's not. It's uh. I think you get a lot of some of these tools are bought and not used. Yeah. Uh, that shelfware is a big problem in Salesforce ecosystem. The I think they people are are always looking for solutions to this kind of thing. And especially if you have that external pressure of like uh, you know, a QA officer or somebody like that in your organization, who's going to you know, be looking down your shoulder, or if you have external regulatory concerns or things like that. I
think that that really is the dividing line. I think I think of all these companies, like I would say, there's about it's something like about a billion dollar market I think for all the software and services for stev ops, So that might be a little bigger than the people have thought. I think about a quarter of that is software and about three quarters of that would be services
from people like you know Accenture or whoever. You know global system integrators who are consultant houses that frequently come in and and and do this kind of thing. So I think the other thing that I think we want to talk about today, and we can kind of switch subjects a little bit here is is like three years ago I wrote this blog post where I said predicted
that SaaS deevops was going to be a thing. And I recently was talking to one of my old customers, Op Sarah, and and they have they're out there really trying to make this saastevops thing work. And here's the thing that they've noticed talking to customers now, is that at the CIO level, or maybe at the Center of excellence level, you do have a lot of people now thinking about how to manage every business platform in their company.
So you have what is I've heard some crazy numbers like if you're a fortune five hundred, you have maybe up to one thousand different applications running in your organization, and maybe if you're a department, you might have fifty different online apps or SaaS apps that you could be using for this kind of thing. So I think the same kind of momentum that we saw in Salesforce, where they become it becomes more critical, it becomes more widespread, it becomes harder to manage, so that it kind of
rolls up to the CIO level for concern. This is happening with other products as well. Obvious ones like s A P four Hanna or or you know, like oracle ERP or something like that is one of them, but even things like Jira or things like HubSpot or things like Zendesk is a big one. So people, there's an expression there's a thing out there now that I think kind of goes hand in hand with the platform engineering movement actually that CIOs want some sort of universal business
platform system that they can use to do that. And I've seen various salesforce DevOps companies, just a handful of them have been successful. Two of them I want to salto.
Another one is up Sarah to kind of do this, to have like a code user interface to do SaaS DevOps on different application products, But I kind of have a feeling that it managers are looking for the solution right now that they want to have a universal application to be a digital twin manager for all of their different SaaS products.
Yeah.
For sure, there's a big risk factor there as well, because we pretty rapidly ran to the SaaS world and now in hindsight, you can look back and say, oh, wait, all of our business critical data is not ours. It's sitting in a SaaS somewhere, and so how do number one, how do I manage the control and permissions in that? And also what's the blast radius when that SaaS provider gets hacked?
Oh right, Yeah, I mean it's all as of security and safety considerations and data governance and and retention problems there. I think I think the a lot of people are kind of over the idea of the SaaS data being stored in somebody else's computer being not your data, you know. I think that most people have an export capability, and I think that the success as SaaS is kind of like an indicator that people are are are getting over that.
But I think the they definitely want to have some way to consolidate DevOps sprawl in their organizations, because this is I think something you're seeing that goes along with these separate business systems. So if you're going to have a salesforce DevOps team, you're going to have an SAP DevOps team, You're going to have maybe a Jura DevOps team.
So I think that if you're a CIO and you're trying to consolidate tool usage and trying to get people to work together better, I think that the looking at how you now have release management processes and critical infrastructure processes associated with these SaaS products, that that there's a SAS DevOps discipline that could be developed around this that that would consolidate and systematize your ability to manage all these things.
Yeah, it almost strikes me as very similar to back in the nineties when you were doing desktop configuring, Like when you were building, like if you had a salesforce of two hundred people, you know, you only made it through the first two or three computers before you were looking for some way to automate it, and then that took you into the world of like modifying the Windows registry and and all of that kind of stuff.
It feels very similar to that.
Oh yeah, like in other words, taking a bunch of crazy configurations to trying to manage them under one roof Yeah. Yeah, yeah, that's.
Were there biolinics.
Well, I think that's where we all ended up. But now here we are facing the same problem again.
No, I just I just remember, like you know, a certain team trying so hard to get all the bioformatics applications bundled with one distro of Linux, and I don't know they really tried. Okay, you guys they tried was Biolinus and that was that was my job to manage that for like a.
Year, BioLinux.
BioLinux. Yeah, it was. It was like a I think a distribution of Hubantu that just had a lot of bioformatic software pre installed. So it had like R and Blast and all like the mixed off all the top general mix software at the.
Time you could, I don't know, sounds like a project.
Very small gene. Oh my gosh, I don't.
Know that that was. That was a while ago.
I think that was that was a while ago.
Yeah, yeah, yeah.
You're talking about desktop management. That was my job for a little bit was to install BioLinux on all the new Scientist computers.
So do you think companies like Salesforce have a roadmap of taking this problem in house and bundling it as part of Salesforce or you think they're going to rely on the external vendors and support them and solving it.
I think the solid answer is the external vendors are the ones to to to rely on. I think because of generative AI. I think that there will be disruption though in DevOps right now. And I think maybe a year ago there was a rumor going around or it might have been just a hope from the Copato people that Salesforce might buy Capato, and after they bought own back up recently that for over a billion dollars that
so that possibility came up again. But if I was you know, look, if I was an advisor for Salesforce on this, I would say maybe try to hold off on that because the uh just dovops is going to be highly disrupted by AI. I think, like like like, For example, I was telling you the story about the digital twin for example, So that's so if what that required to create was to ingest all of the metadata from a salesforce Org and then create a structure around it so that you could then use it traverse it
in some way like a graph database for example. And you can actually achieve that same functionality now by simply ingesting all of the XML metadata and just putting it in a giant blob or rag or into an organized semantic database is the better way to do it. And then you can use an LLM to get the same results. So you can use an LLM to find a blast radius for a chain proposed change without creating a graph database.
So that means a new entrant in Salesforce DevOps can possibly have the same kind of capability that that you know, elements Cloud and Penia and few of these others have to find the blast radius with almost.
No coding all right on.
Okay, So so this is just one example of the revolutionary capabilities of of a I when it when it comes to two DevOps. So I have a like there was a company in y combinators current batch called s r dot a I. There's an intriguing r L and they're doing Salesforce DevOps with the natural language. So you would be able to uh give it a command like take uh a deployment from sandbox A and deploy it to user testing sandbox B just with a command like that,
just with natural language. And I think that this crowd is the listeners here kind of understand how potent that would be because that that that would invoke a whole pipe line process. And also what this company claims they can do is do repair errors that occur in the pipeline, so you know, self healing kind of capabilities with that, which is the thing that AI seems to be really great at in terms of root cause analysis for errors.
So I think to answer your question, I think that they may have been thinking about acquiring Capato or one of the other ones maybe a year ago, because it is an obvious thing and they're kind of moving out of this no acquisitions phase that they were in. But I think right now the field is up for grabs.
Yeah, for sure, now I see that because.
In the model you just described, like the the capabilities of using an LLLM to do that would just dwarf the capabilities of any team trying to do it by forcing people to follow procedures and policies.
Yeah. Yeah, And I think also it's just the code generation aspect of of AI as well that I think that's considered to be part of Salesforce DevOps. Now, Salesforce has an agent let's or I should call it a copilot works kind of like it a co pilot. Even though market's copilots, they still got some they uh yeah, they still have the capability to generate code and and that kind of thing. But and that's part of DevOps. But I don't think that that they're going to be
supporting it very much, honestly. And I try to get into that because like this the publisher of Salesforce DevOps dot net, it's kind of like my job to figure out for the community, you know, where the solutions are going to come from. And you know, like they have a product called Salesforce DevOps Center, and it's kind of terrible. It just it hasn't been updated. There's the they have a very sluggish pipeline of features that they're that they're
putting in. If you're aware of how Salesforce operates internally politically, you kind of realize that this is a kind of like a group that's that's sitting in a non revenue position within Salesforce, so that they have no product that you could put a revenue number on. So if you don't have that in Salesforce, you're at a disadvantage.
To making money.
Yeah. Yeah, And I think that this like one thing I like to compare Salesforce and Microsoft in the in this respect. I think Microsoft for me as a developer, as as somebody who uses tools and was looking for things to put together all the time, Microsoft does it right, you know what They basically they're going to create an API, create an interface, and they're going to service the developers first.
They're going to make sure that developers have all the tools in order to create these applications, and Salesforce does it kind of backwards. They're going to make sure that the trailblazers have all the tools to do the CLICKI thing first, but then then the the DevOps capabilities or the apex coders or even a flow coder capability is added later. You know, they got to get this functionality
out the door that people can buy. And it's it's that mentality that you know, it's just kind of like a gigantic difference in the founders between Bill Gates and Mark Benioff. You know that you have, you know somebody who wants to create a tools that developers can use, and that's not the mentality at Salesforce. So the DevOps industry is basically compensating for that.
Yeah, for sure. And that's been the.
Pattern I've seen a lot in my career in startups. You you know, you have two types of startups from that perspective. You have the ones who are just like ship it, or the ones who think about the long term, you know, how do we support this, how do we configure out, how do we maintain it? And are they're
a little more deliberate in there the delivery. But I tend to lean towards the former with just ship it, because odds are from a startup perspective, odds are your product's going to fail, So you want to fail as quickly as possible. And in the off chance that it doesn't fail, well, now you've got money, and with money you can pretty much solve all the bad decisions you made early on.
Well, yeah, that's I tend to agree. I mean, I think my inclination as a developer is to kind of go down the wrong road here, which is to make it, make it perfect. Yeah, you know, I think I kind of have that O C D A D d uh uh thing that a lot of developers have, which is, you know, oh but if I just do that, get this one thing, get the speed going, you know, cut out this one thing, it'll it'll be perfect and everybody will buy it. And then the problem is you always
find some other thing to fix, for sure. Yeah, after that you get into an now, yeah, always new problems. And I think you're right. Is you got to ship the thing. You got to You gotta get customers, You got to have your m VP out there. You gotta uh, you know, talk to people. And yeah, you can fix bad design design decisions.
Later, for sure. So what is the what is the this changing landscape look for you? Where if we use the.
Wayne Gretzky analogy of go, where the puck's gonna be? Where are you lining up for this?
Oh well, I'm uh, I'm interested in cognitive DevOps. Now that's kind of the thing.
I hadn't heard that term before that.
Yeah, that's my term, cognitive DevOps.
I like it.
Uh, I like to I call it. That's what sr e dot Ai is doing, is cognitive DevOps. I think that we're gonna the other thing that's happening for sure, and I talked to all these companies. I talked to Salesforce is this agent concept is. I think it's a little more real than any other part of the generative AI revolution that we're now in the third year of. I guess the reason why is because there's some serious programming and development behind these things. It's not just the lllms.
It's you've got multi stage lms. You've got a you know, an LM that does the planning, then you've got other lms that do the actions for example, and then you've got other ways to kind of conceive of this. And I think the most interesting way to conceive of this is what I call the virtual employee paradigm, and that I think that this is where it's going to go.
I think that you're going to have the agents and this is going to happen in DevOps too, so so you're going to have be able to hire a virtual employee that functions like your Salesforce ADMIN. That you're going to be able to communicate with the VE like a business person, you know, like you are able to express
your business needs to this your Salesforce admin VE. And then that Salesforce admin ve will actually use RPA or whatever it needs to do to actually operate the software to implement those changes and to manage manage it for you. So I believe that most of the DevOps companies have a project working on this right now.
Yeah.
I can see that being very realistic because when you think about the common hands on tasks that happen in develops, it's you know, create a Kubernetes pod with these images and configure a database and add that database connection stream to this parameter, which are all things that are very much within the capabilities of an agent like that, right.
Yeah, it's it's exactly, it's essentially. I think the the way these ves are going to go is they're going to replace entry level employees first. So that's just the kind of thing you would give to your DevOps trainee, right right, and that uh so, so they're going to be a joy and a boon to senior people like us, you know that to know how to use all these know what needs to be done, and can just give out the instructions like you're like you're talking to a
junior person on your team. And that, by the way, gets into the public policy aspect of of this AI businesses, you know, what's going to happen to all the entry level chops for sure, what's gonna happen to all all
that kind of stuff. So, you know, I don't want to be just blight lead talking about virtual employees without mentioning that you know, there's obviously a public policy and human impact to this, and I think it's if you're a young DevOps person right now, it's you know, I have no other have nothing to say other than I'm kind of worried about that because I think that you look at this ve thing and something that you can
associate with that is what I call VEE economics. And essentially, if you can hire let's say you needed twenty of these DevOps junior people in your giant company, well you're going to start experiencing some economies of scale that you won't experience with people. Right So on the twentieth one of this, you're going to get a big discount from
whatever service provider that you're getting this from. So there's kind of like new economic laws that are that are that are happening here, and one of them is you know the law of infinite scale. The basically, you know you take away the profit margin, and you know, you get a service provider like Salesforce and they'll be happy to provide you all of these agents or virtual employees at a at a discount. So now you've got the prospect of being able to grow your head count without
a linear increase in expenses. So this basic property of vee economics, I think is what's going to drive uh this forward, is that this is something that CEOs get immediately right and that you like, they're there. What is what does the CEO do? They manage their workforces, they manage resources, they they they take inputs and outputs, They think in terms of profit and laws. The they are
extremely interested in this. Like I've talked to the Agent Force rollout from Salesforce in September was definitely changed the landscape in terms of their sales. Right now that I've been talking to system integrators and consultants and they're getting calls from their CIOs basically because their CEOs are saying, hey, you know, I saw what Mark's talking about. I get this ve economics thing. Get me some of these virtual
employees as quick as possible. And so it's we're seeing a different shape of demand right now, And I was talking to another one of these cognitive DevOps companies and they're actually going in there making the sale based on what their customer is paying a salesforce admin. So this to me is kind of revolutionary because it implements what
people are calling the service as a software model. And what that means for the software industry is that not only are you able to, let's say, get budget out of an existing IT budget, but now you're able to get budget out of an existing human resources budget.
Yeah, for sure, that's crazy, and that just yeah, that gives you you know, you refer to it and sales a lot it. You know, it gives you stickiness because now you can bring multiple decision makers in and create compelling arguments for each of those.
Yeah. Yeah, it's it is wild, I think. So, you know, where am I looking for things to go? I think I'm sticking with the DevOps thing. The cognitive DevOps, I think is going to be a huge disruptor. I think that they're going to slowly get into this area, and I think that we're going to have pretty soon you're going to have virtual employees. Let's say within two years.
I'd say, who would be able to manage or release management process all completely on their own, so that that would be tremendous in terms of automation and time savings for the salesforce admins that are left to do that.
Yeah, that is crazy disruptive when you think about kind of all the industries that could be applied for, Like it wasn't too long ago that we had you know, secon ferries and things to help with scheduling, and now
we have virtual calendars that can do all that. And I think AI is on just a completely different scale than even these kind of revolutionary technologies that we've already seen, like virtual calendars and a word processor, you know, like being a word processor used to be people's jobs as well. For sure, I don't know, it's got to be scared to be a young person in like who's coming into the industry now or you know, or thinking about coming in.
Sure it's scary for everybody else too, but I would be especially scared as the young people because of what you said about the entry level jobs like just being obliterated by AI.
Yeah, I'm really concerned about that. You know, as a policy prognosticator, I definitely see a problem there. I also like, I see this ve economics is like a giant sucking sound, you know out there that CEOs are locked in. I think it only took him a few months to get locked in on this, on this thing. And like here in Silicon Valley, I couldn't think of a single young entrepreneur who isn't thinking about dream who was in dreaming about building their company this way as well. So and
I think that they're getting tremendous encouragement from the venture capitalists. Also, this vee economics story, if you bring it to the table, if as a startup entrepreneur and you're and you are able to latch onto that, I think that that is a story that just instantly sells with investors as well. So I think we're about basically. Another thing I like to say is we have not reached the peak of
expectations of generative AI. You know, there was a talk that maybe we had hit that trough of disillusionment for some referring to the Gartner HiPE cycle graph here and the people thought we'd hit the trophic disillusionment with the enterprise AI this past summer. And would I never felt that way because of the conviction that I have on the subject, which like, here's a simple reason why I have conviction. And I'm sure you've heard this example before.
But let's say you've got a pile of ten legal briefs and you need a lawyer to kind of examine those in the context of a case you're working on. That would have taken you know, the cheapest lawyer you could have hired and the Philippines or whatever for like, you know, seventy five bucks an hour to do something like that. That would have cost you, you know, three or four hundred dollars, And now that costs you three
or four cents to do the same thing. And that's actually a reliable application that I'm referring to here, and where the hallucinations are not that much of a problem and you can do things to manage it. So when you've got anything, it's like a three or for order of magnitude change in economics. To me, that's like an inevitable force. It's similar to like the distribution of paper catalogs.
What happened to that in the nineties because it was literally a thousand times cheaper to send that stuff around the world as a PDF. Then you know, over the internet, then you actually print and distribute it. So I think this is why I have conviction on AI is that
kind of basic cognitive change. And that's actually one of the second economic laws I've kind of been working on, which is, you know, this the ability to have cognitive scale that you can do things with AI that was previously not possible or was so expensive you couldn't do it all the time, that you can now do it
with AI. So that's those that's where I think it's going, and it's I think it's it's generally good because I mean, like the abundance side of this equation of this of this idea is that if we make it easier to make to build software, more software will get built. Right two. So that's another thing. I mean, there's there's the market
Andresen quote where he says software will eat the world. Well, according to Gartner, they're only about thirty or forty percent done really, so like if you look at the cloud migration, the we've still got more than half of corporate data is still on prem So I think it's you know,
there's a long way to go with the stuff. And I'm pretty sure that cognitive DevOps is probably going to be one of those things that kind of like seeps into the background and we take for granted three or four years from there for sure.
And I do want to, like, for all the young listeners listening to the show who are still early in their career, I want to give them some hope and not send them away from the episode going, well.
Dan, that was a buzzkill.
So, you know, we've seen this in the past, not exactly like this, but we have seen you know, like Jillian was mentioned, there used to be a career called word process or like you were mentioning Vernon, you know, you used to have people who ran the printing presses for printing paper catalogs.
And we saw the outsourcing movements.
I was a kid, yeah, and we had the outsourcing movement of the nineties and early two thousands of outsourcing the tech jobs in the US to other countries. So there's there's patterns. There's historical patterns you can look at if you're still early in your career and see what happened.
Where did those.
People who were displaced, where did they go? And then see if there's some parallels here in this type of movement. And you know, back to the Wayne Gretzky quote, start steering your career in that direction.
Yeah, I think you got to look at the you got to move up the application stack. Essentially, you have to. I think the thing that folks like us are gifted at is to be able to understand capabilities and marry
them to problems. Right, So you need to be I think we're going to have fewer people in it is definitely a thing, but I think that we're going to be doing more good work, and we're going to be doing more work that's actually tied to whatever the enterprise that you're working for does, because it's a I mean, we're all familiar with the Phoenix project, right. It's amazing
how many dysfunctional IT organizations there are out there. You know, we have people who have no idea why they're doing something. You know, they have no idea that you know, like working on this weird salesforce problem is somehow going to help the company like they can't translate that into that. And I think what's got to happen in our profession
is we have to become more aligned with business. For sure, it was and so I think that if we're able to use tools like AI and cognitive DevOps to remove us from some of the daily grind of this and
some of the drudgery that goes along with it. Then I think we're making progress and we have the ability to expand out talent so that talent, young talent can can use their imagination and there are new ways of thinking and other gifts of youth to you know, participate in the economy more in terms of constructing solutions and working more where the rubber meets the road in a particular organization. I think we're just like, you know, don't
have elevator operators, don't have buggy whip makers. You know, we might not have more DevOps engineers in the future. We might have few of those because of automation. But I think the people if you're looking to marry your love of technology, your ability to see solutions, your imagination to pull things together, I think that there's a lot of business people who would love to hear from you.
For sure, there's always going to be problems that don't have solutions, and one way to look at this is you can shift your daily grind from solving the problem of why doesn't this doc or container build to a higher level problem of something that the customers of the company you're working for are going to value.
Yeah, I always try to give that advice to, you know, whenever I'm working with students, are talking to young people, the very wary of putting yourself in a position where
you don't know why you're doing what you're doing. Always try to, you know, kind of move up the ladder to the decision makers, talk to the people who are actually using the product you're creating, if that's what you're doing, or that kind of you know, the equivalent and sort of whatever job it is, do you have because if you can, if you can keep identifying problems, you can keep having a job. For the most part, is at
least what I've found. And obviously you know that's not always a perfect strategy, but I think it's much better than kind of sitting in your corner and saying I'm going to be the best Python or Go developer of all time, right, Like that's that's maybe not the best goal. It should be instead, want to solve this problem, and then there are always new problems, you guys. Always they never end, like they just they never they never stop.
So no uplifting advice. There's always new problems, always, right.
And I think also it took a lot of resources and a lot of capabilities to solve some of these problems with it in the in the past, and now you could do it with less. So I agree. I think that there are more problems to be solved always, and I think that we're going to have a different kind of flatter world when it comes to doing this.
I think there's going to be suer middle managers, fewer people trying to function as gatekeepers because we're going to have, you know, assistance to help us with some of the stuff, for sure. So that's where I think it's going. If you want to aim your puck in the right direction, I think it's it's for that.
Awesome What do you think should we move on to picks.
Us?
So I'm going to go with the shameless self promotion this week. I am opening up I don't know, maybe five to ten spots for and actually an AI product that I have now that we've you know, had this nice end of the show on how AI is going to take all the jobs and things. Let me take some jobs away from your company. No, I'm just kidding. It's cool. Stuff to empower your scientists to do different tasks.
The most frequent, one frequent one that I see is to be able to do literature text mining and throw you know, thousands of papers at it and then to be able to get some type of information. I work in drug discovery, so it's it's mainly drug discovery. I
do have an article on that. It's called using LLMS to query PubMed knowledge bases for Biomedical research and kind of like what it says, you can query a PubMed you can throw all of your papers at THEAI, and then you can tell the AI you don't please summarize this for me. So it's a product that I have that gives you a chat GPT like interface that your
scientists can use. But it's all self hosted on AWS, so none of your data gets out if you have proprietary data, if you have you know, pre clinical data, all that kind of stuff, or other data science companies that I don't know what you all are doing, but it might be useful for you too, I don't know. So anyways, it's got the chat GPT like interface, and then it's also got a programmatic interface that you can use wherever you have a terminal stage maker HPC wherever
all the things are. That'll be on my website dabblodepops dot com, slash ai if anybody is interested in that and would.
Like to try it out right on awesome vernon. What'd you bring for a pick?
Well, I got my website so dot net and invite everybody to come by there. Like I said, I'm I'm also on LinkedIn vernon keenan all together is my is my thing on LinkedIn, and I would just my pick is I want people who are complaining about Salesforce ops or have complaining about the pricing models and things like that to contact me because I'm trying to gather.
Input right on.
It's not like a support group that could be, that could be.
It is it is, you.
Know, It's just we're gonna get all these people and we're all going to have like snacks and fuzzy blankeys and.
Just it is. That's what I'm trying to create, is just a comfort group where we can all complain and and give each other let us know that Salesforce is not paying attention to us and this thing. So here's but it'll start out with a fine counseling session with me to get all your complaints. Yes, yes, yes, yes, yes, So trying to you know, be the trailblazer whisperer here. So the more trailblazers who contact me to tell me about their problems with data cloud and agent Force, the better. Right on?
Awesome?
All right, my pick this might be one of the wildest things I've ever picked. But with the holiday season coming up, if you're looking for a gift for someone.
And they are a male, I'm going to suggest Shine sty underwear, which.
All right, it's hard to get excited about underwear, and I was pretty skeptical at first, but I used these. I ended up with some and used them extensively a year or so ago when I was training to run a one hundred k Ultra marathon.
So the ones I had, I was to say, that is crazy.
Okay, anyways, carry on, carry on.
So I'm just gonna say my shine Steeds are battle tested and they have performed well. So yeah, that's my pick, and that's probably the one that's gonna get me kicked off of this podcast. But you'll have a pair of Shinty to take it.
Shinesty's uh boxers or briefs.
I like the I like the long leg briefs.
Just the the support factor. Mm hmm.
Okay, we're going into the chafing aspect of Yeah, of the podcast. Absolutely, he will and Jillian, this is fantastic.
I really appreciate have you on the show. This was great.
Thank you so much for for joining us. And uh, feel free to to come back and chat with us again at any time.
We can.
We can do this later and see how our predictions went.
Yes, yes, yes, we'll see how my little mission to h fixed agent force pricing goes.
Right on.
That's my current missioncause nobody knows how much.
It costs right on, looking forward to good that's a big problem.
Okay, great yep. To the listeners, thank you guys all for listening.
Appreciate having you support the show, and we'll see you all next week.