 Hi there. Welcome back to the Workforce Identity Developer podcast. This week, I'm joined by Jeff Taylor, who's a Senior Product Manager on the SAS platform team here at Okta. It's a heck of a job title, Jeff. What does it mean? We deal a lot with just the overall developer concerns. So a lot of my responsibilities, first and foremost, are centered on what a team we call the Developer Community Products. And this is just building tools like our management SDKs to make our developers successful in building with Okta. Another part of my role is actually working with the Okta integration network. And this is dealing with another class of developers that are integrators, looking to build solutions that can be used by all of our Okta customers. So as you can see, I spent a lot of my time in the technical arena, but also thinking about things like product and moving us forward. So success metrics and everything are driven based on how well our developers can build on Okta as a platform. Yeah, absolutely. And a lot of that building that folks are doing is automation in some way. And I really like the way that you articulate the automation journey or almost loop. How do you describe that? Yeah, I really liked the term journey. When I was coming up, the first clue I got into architecture was on the application continuum. I like classic movies. So this was how I learned how to live with a monolith. So I do like this concept of being able to transition in phases and to not look at your in-state as the ultimate barrel toes of finish line goal. To be okay in the states that you're in and to recognize the signals and the catalyst with which to mature. And the application continuum would move from monolith all the way to fully distributed microservices. And I've been applying this to other areas. And one of the great ways that we can apply this here to automation is knowing when you are doing things manually in ad hoc and when's the right time to actually go into full blown full scale automation. It's a journey. You take different stages. There's different tools that you can use to help you on that path. And it's okay to be in one state versus another. It's just going to be a determination of what's right with your people and your corporation and all of the things that go into discover like when you are ready to take that next step. But to understand to first of all be okay with where you are and know when is the right time to invest to move forward. So what are the steps that you'll often see an organization pass through on that journey? There's a couple of interesting forks in the road, but it really just starts out with like just the manual stuff, right? In octet terms, like this is using our admin UI. So making changes to your policies, changing users and working through any number of things that you could configure. When we start to put some regularity to those changes, we start to notice that there's opportunities for mistakes to happen or unintended consequences, right? Like we might do something and then realize that we've changed something unexpectedly in another area. It's probably a good signal that we may want to standardize. That's another big term here, standardize on how these changes are made. And what we're trying to do is we're trying to basically not, not replace the human but put the human in a different position to gain some more oversight. Use them in a better way and not necessarily just like rip and replace like that's far too abrupt. But sometimes our painful moments are times that which we can, we can mature and change or other times are just when the frequency gets too large and we need to scale quickly, right? We noticed that we're having a lot of change requests coming in for a particular area and it might be easier for one operator to do things if they have a button to push as opposed to a number of steps to complete. And so those are like two scenarios that you can use as real gauges as to when you should be looking to employ a more automated solution. Another thing that I've personally seen is when you start having the long checklist, that's a cue that you know what you're doing to a level of clarity where you can explain it to a machine in a way that it will do what you expected. Yeah, I think there's a key item in there is the repeatable tasks, right? Once the repeatable tasks are very well known, good opportunity to start automating. What does the end game there often look like for the organizations that you see that are automating identity stuff? Not to bring too much prescription in here, but like we do see this with our advanced Terraform users where and I think Terraform is a really good technology to really describe like the strength of automation because you can do pretty much anything with your infrastructure. So while you know I work for Octa, I think identity is super important in the whole corporate infrastructure. It is a small piece of a much larger ecosystem where you have machines, you have operating systems, you have networking, you have all sorts of peripherals and additional applications that are going into your ecosystem to help run your business and increase and stay and have productivity stay on a much higher level. So it's important to understand that like in these advanced organizations that are employing large-scale automation, they're running all of these aspects in concert and usually there's a single thread of technology through that and that's what Terraform provides. It's a way that I can orchestrate and automate just pretty much anything in my infrastructure including the identity to make sure that it's all done smoothly without manual intervention so environments can be stood up and torn down very quickly. If I like a couple of really great examples are if I need to add another environment say I have a dev and a prod and I need want to introduce a UAT to involve my customers to test pre-production material. Terraform is a great way to actually build that. The other thing is when I say we need to expand into another region we're talking about globalization. It's really hard to do that and also make sure that you have the right controls in place for actually crossing those thresholds into other sovereign nations. You want to make sure all of that is instrumented and written down most importantly. That's what Terraform gives you. You can check all that in You can read through the setup as you would like any type of manual or any output of diagnostics before you create and then also check and make sure that's synchronized after creation. There's a number of scenarios that you see as companies going. I like to give these examples because you may or may not be in one of these situations where it might be good to start looking at something like this just to standardize and make sure everything stays sane as you look to increase your reach and improve your business. That auditability can be another huge clue or cue that you want a bit more automation. You want the automation to not only be doing the task but also logging appropriately that it happened rather than trusting a human to remember another step. That's a really good point to go into and that's one where you see this in the processes, translating the verbal description of what's changing with the actual machine instructions of the change. Being able to match those things together is a very important concept especially for auditability. It's not just like I don't want people to assume that this is about who made the critical change that took the infrastructure down. This is really just about the visibility into how your environment is changing. You can look at these modalities and what's been changing over time if you are recording this. It also gives you these added protections as well. You can make sure that the right people have access to run these things. I think these are also good tangential benefits to building automation into your daily workflow and processes to help non-business users understand what's actually going or non-technical business users understand what's going on with the technology and the infrastructure that's being built. That need for accessibility of knowledge about what's happening to an increasingly diverse group of backgrounds and group of knowledge bases as an organization grows ties into something that we sometimes talk about among ourselves. We sometimes call it corporate maturity where I think most listeners will have the intuition that the best tool when you're a tiny little startup is probably going to be different than the best tool for the same job when for a huge enterprise or for a government just because they're under such different constraints and have such different risk profiles. How do you think about that maturity model? Yeah I think there's a understanding kind of where you are, what industry you're sitting in, what are your guardrails and for regulation and whatnot. Those are really important to understand what your next steps would be. If you're a traditional like you're just a startup you're starting out and you're trying to like figure stuff out remember like that's why I love the application continue and we want to be able to respond quickly like it also means that you might not have as congealed processes because you want to get changes out very quickly. So it's a little bit loosey-goosey when you're when you're making these changes but either the moment you have important customers like you've landed your first enterprise customer or your first really large customer and that site goes down and really it's like well we've got to tighten things up because we can't really afford to have this happen so that we you know have these have these Mars on our on our reputation so you want to level up you know and I think it really just it depends it's a good way to pay attention to what's going on around you. I think another good thing is when you start to understand that data that you might be bringing in or housing might be more sensitive so you want to make sure that changes are a little bit more rigorous or you're going for like you're going into different areas where like you want to get into government and so you want to get fed ramp security there's a lot of controls that you might have to implement some of that precipitates down into the technical world with things like infrastructure's code and so you want to be more responsive to your customers in those areas and be able to adjust quickly without years and years of toil to kind of get on on that speed so I think like there's a lot that goes into that maturity it has to deal with you know your size so how many people I didn't even talk about this how many people are touching the code once you get to a critical master those like I can't like I can't just like look over and say you know hey hey hey Emily like what are you doing here with with this piece of code like can we can we take a look at this together you've got thousands of engineers you've got hundreds of engineers across the globe you need tighter controls over like who's checking in so you need to use things like source control all this stuff happens so you've got your corporate complexity like how your size and your makeup and your distribution you've also got your business areas so the industries that you're applying to you've got the data that you're looking to create or protect or assets that you're creating for your users and also you've got your own scale like what does your footprint look like for your infrastructure sometimes that may outpace your you know building AI solutions that we have now you need more compute power right you got to be able to scale very quickly so that would change the complexity of your automated deployment so there's all these things that you're paying attention to and I think the most concrete advice I could give is every once in a while just take a step back take a deep breath like look at some of these axes right how many developers do I have accessing my infrastructure in my code how many industries am I in what kind of data am I providing and protecting for my users and then what is what is my needs for compute on the back end those four axes can give you a good clear idea of when the right time to mature is I even think it's like that complexion one is roped into your processes your people all of these things so I think you I think with that you've got a good base to cover and when you can when you can start thinking more seriously about automation and with automation as with just development in general you're thinking about looking for that sweet spot between speed and safety where if you're just prototyping a brand new product the worst thing that could happen might be that you take two years too long and someone else beats you to market and now you're not a company whereas if you're really established like the worst thing that might happen might be a down time or a breach at a really crucial moment so the threat models if you look at it from the pessimistic angle change so much across the different scales and one thing that I would throw in as well is that you kind of want to be mindful of the scale and the threat model not only of your own business but also of your customers if you're selling software in any way because that will inform what they're looking for and looking to buy absolutely it's only 100 agree but automation though is going to let us sort of build this institutional memory of things that have happened in the past and get that blend of speed and safety I really like that term of institutional memory because all of this being codified is there you know for posterity right like we look at like our github logs right like aside if you're doing like you know a forced push in your racing history all like the crazy things that we've been through but in general right yes like you you've got the full lineage right I think that's one of the that's one of the holy grails that that security actually looks to give us like do we have a full chain of custody like from the time that a you know the code is actually written into the moment that it reaches production do we have like clear insight into that whole journey and like that's a that's a great way to build you know the muscle for improvement just as much as like you're building the muscle for like releasing right so you know exactly what you've done in the past so you're not doomed to repeat right like that's always what we what we hope is that we're continually improving not repeating the mistakes of the past yeah and every new test that you add in your automation every new consideration that you add is usually either because someone had the thing happen to them and says I don't want that to happen again or because someone foresaw the thing happening I said well I don't want that to happen at all or I do want this to always happen or that worked really well so let's have this happen again in a way it's sort of this encapsulation of what all of your colleagues have known including your past self yes exactly that anthropomorphization that we can do is fun is helpful do you think that that ties into how we change our automation as we go on how we think about adding removing tests and reasoning about what belongs in it the testing is a really interesting one so I'm a big believer in in test driving your development I think it provides a lot of clarity between product and engineering to create changes in code which leads to safer you know better more resilient code in the long term I've actually like in my past I try to explain explore like putting this into practice with infrastructure as code modules like can we do the same thing building testing in with this that same same kind of outcome and I do believe that it's possible I know Terraform has this plan that we can run and we can always introspect into the plan and see what is what is actually going on before it's actually being applied and built and this becomes really important because when we're going and we're making like we're making production infrastructure and sometimes we're making production infrastructure in places where price matters right like maybe ec2 or the cloud compute like yeah google cloud like depending on when in history we are price will matter much more or much less yeah and like nobody wants to wake up in the morning with a huge bill for compute because they've over allocated right like that's a it's a real problem so you know doing this like running these tests and making sure that things are set up correctly or having ways that you can even extend your infrastructure as code to test and make sure that the compute numbers and everything it's all very essential and making sure that your environment is exactly the way that you intended right like I think that's always good and you have more flexibility like this is one area where you would seem like if I'm just a person at a terminal trying to like create an instance and like ec2 I can immediately get that feedback but you can't do that at scale right like and that's that's the thing is like you might get that in a very very small mirror box but like having to horizontally scale that workflow it's just not going to work so your next best thing is to work with testing in the automation frameworks and I think this is a great way to prove out the concepts especially like if you want to add another environment and especially getting something closer to prod you you know you're taking on more expense but you always want to figure out if it's if it's worth what it's going to cost to get there and I think these tools are what's you know these testing tools are the ways that we can actually evaluate that on an even playing field without having to expend so much cost when you talk about scaling like that moving it shifting from I want a machine to I want the machines is sort of the backbone of automation it turns your single action from a smaller scope thing to a larger scope to action that takes you a similar amount of thought to decide to take to decide it's the right time a similar amount of work to execute and yet it has so much more impact yeah absolutely I think this is like one of the things where we turn our like individual statements into superlative statements not like like you just you said like I want one machine to do but like no I want all the machines to be a certain way right like that's that and that was something like in the early 2000s and 2010s like we were always looking for it's like machines have to be like for like and before this was at the cost of cloud computing like there wasn't really a great way to do this with like infrastructure on the ground and there were not really great ways at that time with the segments of EC2 instances which is the only thing that was available like you could say well I want a large like I want somewhere between a large and an extra large but I don't really have a choice so I'm going to have to pick one or the other now with all of the things being like you know more precise like we're able to to make these decisions at a much more heightened level so I think it's just great to see that we can do like we can make these statements like I can assure that every machine is working identically in a large ecosystem I can assure like from octave perspective I can assure that every organization I have has the same policies set up in the same grouping set up so everyone's experience is standardized across wherever wherever you are whatever tenant you're in so I do believe like that's a that's a really key thing that we can do to you know assure that we're able to continue scaling the business but we're not worried about slowing down the infrastructure to get there. So let's say that an auto admin is currently just doing everything by hand so the concrete case of this general automation journey that we've been talking about today and how are they going to know that it's time to start thinking about automating some of what they're doing. Well I do like the agile like listen to your emotions obviously this is coming from products so product we're obviously very much into user empathy but I do think that the the spark for innovation comes like it's born out of emotion and sometimes it's negative emotion like why am I doing the same thing over and over again. I really want to do this other shiny new thing that's really great that will help the company but I'm stuck doing the same repetitive task over and over again. I think this is like this is the infomercial saying there's got to be a better way well you know. It goes from get to to have to. Yeah exactly so and I think that those using those existential moments where people are like I got to find something else because I want to do this other thing great signals to explore and when you start to explore there's a couple of opportunities you have like one is using the API it's the most tangible thing that's right in front of you. I know like in the customer identity cloud we've got a full blown CLI that allows you to explore all the objects and everything that's a really great way to navigate your way do both things I think CLIs do a great job of this navigate and a headless experience through all of the objects and contained in an application or platform and to allow you to start putting those pieces together in like a scripting type form again you can do this with the API it's a little bit more complicated because you have to deal with authorization and all that great stuff but still possible the point is you know the steps you start instrumenting the steps in a more deliberate and programmatic way through CLI or API and then you just package those things together either with bash and you know the added instructions that you have from CLI and maybe a bash script that uses a bunch of girl commands that can do a lot of these things right together but you start putting those together now you've got like these scripts and you start putting these scripts to uses like maybe building them into your you know an internal self-service tool or something like that and then you get to the larger and you're dealing with like user requests like I need to move to a group and like okay well I can figure this out with approvals and whatnot but when you start saying like well I got to like move a policy between development and production what's going to happen there they need something that's a little bit better right like you want to be able to get that into source control at that point because you're talking about a change request you want to be able to adhere to your change control process and move that along the with all the rigorous testing and whatnot and so now that's a good signal for you to start building something with like Terraform or not so you I think now now you've started to get like I think in this question we're building concretely how I move from like I'm doing the same repetitive task over and over in the admin UI I'm exploring and learning and cobbling together the pieces through an API or an admin or sorry an admin CLI and then now I've like I'm in a full blown like doing everything with scripts but now I need to actually start moving over the infrastructure like the bare bones things that we need more oversight on that's a good signal to use Terraform. Yeah and I think you're also touching here on an important way that the learning curve is split between the different parts of itself so the first time when you're like figuring out what API calls even need to be run what even is happening under the hood in octa there's part of it is you're learning your CLI or your SDK whatever you're using but another big part of that learning curve is you're just figuring out the language of what's happening in the identity provider you're learning to describe what you want it to do and so when you imagine how hard is it going to be to shift from let's say the API to the CLI switch or shift from the CLI to Terraform something like that or even potentially to shift from something that's lower code like a workflow to something that's a bit higher code to give you a bit more customizability or integrate more tightly with something else then it's not going to be quite as hard as you'd expect because you're not going to have to relearn that internal vocabulary you'll go oh here's here's the outcome I wanted here's how I can check through the console that it happened the way I thought it would yeah and I think that's a great way to to sort of summarize all of it it's like in the one hand you spend you spend most of your time learning octa right like in that admin UI you're learning octas like names and objects and object models and relationships you're then applying octa in real world scenarios in this next step with our SDKs API and CLIs all of that then next step is you're then you're saying I'm ready for the next thing which I think is a real key differentiator because learning Terraform Terraform is backed by the configuration language the hash of configuration language or HGO so you're learning something a little different it's based on go so if you don't even know go you're gonna start to learn go and then start to learn this HGO but there's a there's a there's a definite carrot at the end of that which is like this full blown automation and now I'm applying my learning of how to navigate octa and its object model in conjunction with all of my other ecosystem as well so like now I'm putting that into place in the grandest scheme so it's you know it's learn octa then learn octas object model with the intent to apply and make changes and then make those changes at scale with with any platform but each level of that builds and I would say like energy for the next layer of investment as you start to see benefits from it again why I think the journey is so important embrace the stages that you're at because you're learning all of this there's no there's no rush again you're just paying attention to the signals that are coming in so you know when you're ready to jump and you're not leaping before you're you're ready yeah and more than just energy you're building skills you're building skills that will apply to other use cases so you build the terraform skill and then you want to automate something else that also has a terraform provider it's going to be so much less hard than you thought it would be if you're comparing it to when you also had to learn the basics of terraform you want to build something else that uses an SDK in your language that you've been picking up it's going to be that much easier because you're that much more familiar with the language so I think making sure not to discount the reusability of the skills that you build through the automation journey is really important yeah I think it's like a similar analogy is like it's much easier to multiply if you understand addition than it is to learn multiplication just right off the gate so I think like building on the skills allows you to take these natural extensions and really like level up and I think the great thing that you put in there is yes you're learning skills like everything that you acquire skills and knowledge and just as I mentioned that multiplication analogy shifting between terraform providers is extending what you already know based on a very core common concept so it's just then translating the knowledge of terraform with someone else's object model and resources that are modeled in their provider yeah and one thing that I personally really love about open source tools like terraform open standards like OIDC is that skill is transferable any IDP that uses OIDC is my OIDC knowledge is going to apply any organization that uses terraform the terraform knowledge is going to apply and so it's an investment in that you get to keep as well as something that your team gets to keep and benefit from indefinitely for as long as the problems that you automated keep being addressed by your automation yeah and I think it's like you know a little historical note here like we terraform terraform has been around for a while it wasn't necessarily like the it's been a very popular tool for a long time but it wasn't necessarily the only tool I think the statement that you're making here just sort of lends testament to like where it's come over time and how it is more of a standard before it was an option and now it feels more like a standard for development we hear this again from our customers a lot that they really love it but it is important to call out that like even when you're still talking about infrastructure as code and managing infrastructure that like it's really really important to understand these skills do translate even to these other tool sets because a lot of the a lot of there's a lot of similarities there so again you're translating it's the same way if I'm moving from maybe like moving across like back in languages right like there's a lot of syntactical knowledge but like understanding how to build server side applications is still going to transfer to some extent so you're just you're learning how to apply that in these different arenas but I think like again doubling down on what you said like building those skill sets making those skills transferable if you come into like a company that uses something different or like you need to move into low code so these principles will still apply and you can still apply them with a lot of success in these different areas it's like how math is still going to be math no matter what human language you've described a given concept in and the final thing that I'd ask you about our example of someone who's automating tasks they're doing day to day in octa is that as the adoption of their automation grows what challenges are they going to run into in terms of people being surprised by it or having all these demands of it and how would you suggest that they handle this yeah we're actually hearing about this in a little bit from customers that are looking to incorporate more automation like this is part of the journey we taught we talked a lot over the course of this podcast about like you know how to get started when you know the signals but you didn't really touch on as like where the rubber meets the road right like okay and I'm going to take a group and I'm going to have them automate all of their changes and I still have some I still have some users that are doing manual changes like what am I going to do here so one of the things that we start to do is like you can definitely experiment with automation but I think the most important thing to do is to incorporate automation in with your normal change process again if you think about it you've got two processes that might be competing for attention well like you just need some piece over top that can help normalize both right so like if you have something like a change advisory board or some change control system committee that meets regularly like bring your automation changes to it along with those manual changes and work on that translation between the code to business or business to code bringing all of these diverse backgrounds in in conjunction with those manual changes and that is a way that you can start like leveling the playing field so you can start to move more of your manual changes to automation the other things you can do is like look at areas where you have maybe some frequency of change that's comfortable to you and lower risk of of issues and start there as well right like if you're changing maybe maybe like you'd say it's you know prepod prepod policies let's say like you would you you know that there's going to be some impact but it's localized to internal but you want to make sure that all those are going through automation this is where you can work out a lot of those growing pains right so making that first selection is a is a really great way to step through this process and then also incorporating it in with your larger change management processes are some really tangible things to do to get started along this journey we could do a whole other episode on the considerations around config drift and what to do about it which sounds like it'd be a lot of fun to do sometime I do think so yes for now I hope that gives you a taste of what you're looking at in the automation world let's you think yeah actually that boring thing that annoying thing that darn checklist that I don't want to mess up I should be making some system do that for me so hop on into the comments and share your stories of automation tell us where you're at and what questions you have and I'll hope to get those answered on future podcasts so thank you for joining us thank you for having me this was great