In this conversation, James Schorr, a senior director in the cloud platform area, discusses platform engineering and its impact on developers. Platform engineering is the next evolution of DevOps, aiming to provide a consistent and easy-to-use platform for developers. It simplifies the developer experience by reducing the cognitive load and allowing developers to focus on writing code. The goal is to make the developer's life easier and provide a self-service platform. The platform engineering team aims to meet the needs of developers using different programming languages and frameworks. The skills needed for integrating with platform engineering include understanding CI/CD pipelines and configuration management. In this conversation, James Schorr and Krish discuss various aspects of platform engineering. They cover topics such as understanding Kubernetes and serverless, concerns about learning and vendor lock-in, balancing ease of use and continuous learning, the job market for platform engineering, and the suitability of platform engineering for different organizations.

Takeaways

• Platform engineering is the next evolution of DevOps, providing a consistent and easy-to-use platform for developers.
• The goal of platform engineering is to simplify the developer experience and reduce the cognitive load on developers.
• Platform engineering aims to provide a self-service platform, allowing developers to focus on writing code. Developers should have the freedom to choose their preferred programming languages and frameworks, while the platform engineering team focuses on providing the necessary tools and support.
• Skills needed for integrating with platform engineering include understanding CI/CD pipelines and configuration management. It is important to understand the underlying concepts of Kubernetes and serverless, as the specific tools and implementations may vary between companies.
• Learning and adapting to different platform engineering tools and approaches is necessary, but it can be a concern for consultants or individuals who may need to switch organizations.
• Continuous learning is essential for personal growth and should not be solely dependent on the organization or platform engineering team.
• Platform engineering skills, along with security and integration expertise, are in high demand in the job market.
• Platform engineering is more suitable for medium to large-sized organizations that can dedicate resources to manage and maintain the platform.

Chapters

00:00 Introduction and Overview
00:45 What is Platform Engineering?
03:00 Transition from DevOps to Platform Engineering
06:16 Impact on Developer's Daily Life
08:10 Simplifying Developer Experience
10:35 Supporting Different Programming Languages
13:05 Time Savings for Developers
14:31 Quantifying Time Savings
17:07 Rolling Back Deployments
18:05 Self-Service and Developer Empowerment
21:13 Interacting with the Platform
24:09 Supporting Multiple Programming Languages
25:20 Different Team Configurations
28:39 Skills Needed for Platform Engineering
35:26 Different Developer Personas
39:00 Skills for Integrating with Platform Engineering
45:25 Understanding Kubernetes and Serverless
46:11 Concerns about Learning and Vendor Lock-In
49:56 Balancing Ease of Use and Continuous Learning
53:00 Job Market for Platform Engineering
57:31 Suitability of Platform Engineering for Different Organizations

Transcript

Krish (saas.snowpal.com) (00:01.514)
Hey everyone, welcome to Snowpals software development and architecture podcast. We have a very special guest with us today. We have James Schorr, who's a senior director in the cloud platform area in a telecom company. Hey James, thanks for joining.

James Schorr (00:15.494)
Thank you. It's good to be here.

Krish (saas.snowpal.com) (00:17.442)
Awesome. We are going to be talking about platform engineering today. So folks, for those of you watching, I have not done any work in the space of platform engineering. So I'm going to learn about platform engineering from James as we go during the call. So it is going to be just as conversational as the rest of the podcasts have been. So without further ado, I'm going to start with the most basic question, James, like what is platform engineering?

James Schorr (00:45.238)
CloudForm engineering is basically the next evolution of DevOps. So if you think back quite a ways back when DevOps first came to the forefront, it really came out of the desire from both the developer side and the operations side to have quicker time to market, to have better collaboration, and basically to get things built in such a way quality-wise and security-wise.

that you wouldn't have a lot of rework on either side. So that's kind of where DevOps came to the forefront. But the main motto was, if you build it, you run it. So the desire was to get away from kind of the hot potato approach where a dev team, for instance, would throw something over the wall to operations and the operations side would get it up and running. And then the dev team would only fix bugs in the software. That model was breaking down at the time.

And dev teams were frustrated at operations teams because they saw them as blockers. Operations teams were frustrated at dev teams because things weren't working and they felt like things were being dumped on them. So both sides kind of came together more or less successfully with the approach of let's work together and figure out a better way. And DevOps kind of came out of that. Platform engineering has kind of been the next step because...

DevOps, as you can imagine with any new model, DevOps, when it really started getting up and going, was implemented by various companies in all sorts of different ways, with different structures and so forth. And it was kind of all over the map. So anytime you have something all over the map, you end up with tech debt. So platform engineering was really kind of a desire, maybe about 2019-ish to build something sustainable and easy for developers to use.

provide good developer experience with standardized tools, reducing the cognitive load on developers, making it easier for them to just come in and do their development work. And yet at the same time, easy to support on the backside of it, so to speak.

Krish (saas.snowpal.com) (03:00.21)
You know, that's a great place to start. So let's say if I take myself as a developer prior to the DevOps days and take myself as the same developer in the days of platform engineering, how is my daily life or weekly life, if you will? Let's assume that we're doing daily deployments to production. How would have my life changed going from the pre-DevOps days to the platform engineering days?

James Schorr (03:28.342)
Hmm. Pre-DevOps days, you would have logged a ticket and waited for an infrastructure team to basically set up servers for you, set up configurations, TLS certificates, mounts, all sorts of stuff for your software to use, and get everything ready for you to deploy. And actually, pre-DevOps days, a lot of times the infrastructure side would do the deployments as well, or at least work.

pretty heavily with you as the developer to do the deployments. And they're a little bit more one-off in nature. This is kind of before the days of pipelines, CSC pipelines and that sort of thing. Oftentimes you had a release management team involved as well. Sometimes that was born out of the desire to be SOX compliant and so forth. And so sometimes the deployment would look like I as a developer,

I need my software to be out there in production, well, in test environments and then production, right? So I would log tickets with the infrastructure that would take however long to get the servers up and running. Then I would log separate tickets with release management team and they would help me coordinate a time to release my software a lot of times hopefully into test environments and later on into production, providing all the testing went well. So all of that, as you can see, has a lot of bottlenecks.

has a lot of areas where things can go wrong, a lot of frustrations, a lot of one-off type of approaches, a lot of human error. So when DevOps came along, the thought was, let's also start using automation a whole lot more than we are. Let's start using code a lot more than we are. Infrastructure as code approaches, and let's make this as self-service as possible so that the developer can just get their code into production as quickly as possible.

Krish (saas.snowpal.com) (04:57.591)
Great.

James Schorr (05:26.462)
but it also required a developer to understand the infrastructure that they're deploying onto, the targets that they're deploying their software onto. So that was kind of where it set at that point. Platform engineering is kind of, like I said, the next evolution of that, where instead of having many different ways to do DevOps and many different tools involved, and this team likes this tool and that team likes that tool, having more of a consistent platform that's treated as a product and...

There's one way or maybe two or three ways, but not very many ways to get your software out the door successfully into production. And that includes all the goodies. You know, it already has TLS certs, it's already scalable, there's load balancing, there's monitoring, there's flirting, et cetera.

Krish (saas.snowpal.com) (06:16.258)
You know, okay, that's great. So which means prior to, just to recap what you said, just in my own words, prior to DevOps, I had to follow a very manual process, if you will. You had mentioned creating tickets, following up with different teams, working with the release management to getting your solution out the door. And in some cases, like when I worked for larger product companies, it was almost oblivious to me, right? I wouldn't even know as a developer.

We would be done with what we are doing. And then that's it, you know, it's off of our plates. We get back, we continue working on the next features, we go with the roadmap, what else is in the mix? I mean, what do we need to get done in the next quarter? So we almost had no idea who was involved, right? In some cases, perhaps, you know, in application teams, most of my work was in product teams. I did not necessarily even know who was involved in this. I just knew that my job was done or my team's job was done.

And I can now give it to somebody else, and they'll take care of it. It's pretty much, I threw the ball in their court, and we were done. And now you mentioned there were issues with that. We didn't have transparency, and it was not super efficient, to say the least. So we went into the world of DevOps. It was cool for a while from what you're seeing there.

But then the developer needed to understand a lot more about what was involved in the process in the process of deployment. I had to understand, can I say even things like the developer needed to know how to create Docker files or Docker compose or, or more recently, how do you set up, you know, the Kubernetes, the cage environments, interact with that things of that nature. Are we saying that if when it comes to platform engineering,

I would have to know less about those things, or would I still have to know those things, but just slightly differently?

James Schorr (08:10.93)
Yeah, you know, really the goal long term is for the development side things to focus on their code and focus on what they love to do. So I think about it in this way. At my company, I would love for a Java developer to come in and write Java. That's what they love to do. Or a Ruby developer, Rust, GoLine, whatever the case may be. They come in and they focus on meeting the business needs through quality software.

and getting that software out the door, you know, well tested and all of that. I don't want them to have to come in and know everything there is to know about TLS certificates in Linux and Windows and mount points and volumes. And I mean, the list goes on and on, permissions and so on and so forth. I think that really detracts from the providing business values side of things. So long-term, the goal for me at least,

is how do we make the developer's life a whole lot easier? And I see that as kind of a public API contract. So for instance, if we on our side, in the operations side, in the infrastructure side, provide a platform that is good enough that meets most of the needs of developer, why would they not want to plug into our platform? Why would they want to go their own route? Why would they want to choose their own path if the path is laid out?

pretty easily to plug into. So the goal, or a goal of mine at least, is reduce the cognitive load on developers. Meaning they don't have to know about all this stuff. But at the same time, we don't wanna be, we don't want, we also wanna be transparent about everything that's under the hood. So for instance, you may have some developers that they want to know about the stuff, they're curious. And that's not a bad thing, that's a good thing. There are some developers that,

They want to be involved in every little bit of it. That's a good thing. We want to encourage that and partner with that from the infrastructure side of things. And then you have other developers that they perhaps grown up in a world where all that was done for them, or they've used Heroku, or they've used some sort of a PaaS service somewhere, and they are used to just putting their code out there and it just works, so to speak. It just works, and they don't care about how it works.

Krish (saas.snowpal.com) (10:35.702)
All right.

James Schorr (10:38.534)
I really see that Platform Engineering can lead both sides of that. And we can produce a quality platform that's easy to use, easy to operate, and easy for us to update over time, as long as that public API is kept with the development side of the house. Meaning, why do you as a developer care what behind-the-scenes changes as long as that public API, so to speak, contract is kept?

How do I plug into your system? That should stay fairly static. That the same ease of use should be there now versus two years from now. Two years from now should be easier, frankly, to deploy your code than it is today. All of that is easy for me to say in a meeting. It's easy for me to put out as vision or mission statement or whatever. It's not that easy to implement in real life. So just like anything with thought from engineering, you'll see various...

Krish (saas.snowpal.com) (11:20.95)
All right.

James Schorr (11:36.474)
levels of maturity in that and as companies adopt it, they have to realize it's not going to be perfect right out of the gate. We're going to have problems. We're going to have things we need to tweak. So I think the biggest thing we can do is keep our eye on a couple things. Prioritize and pursue self-service. Are we making our platform as self-service and delightful to use as possible? Is it easy to maintain and update?

it's easy to switch out someday, maybe for whatever reason. Some other new technology comes along. We want to completely replace the guts of our platform. Are the technical choices we're making today, are we boxing ourselves into a corner or are we doing things in a modular way, in a flexible way so that we can easily swap things out in the future and not harm the development teams? Because remember, the development teams, they're constantly.

putting things out the door to meet the needs of the business. And that never stops. That train never ever stops. And so we've got to be very intelligent and future looking, so to speak, as we build our platform and as we make technical decisions. And we need to be including the developers to constantly having feedback and tight collaboration between the teams. Make sure we're building a platform not just that we enjoy operating.

that the development teams love to use.

Krish (saas.snowpal.com) (13:05.942)
You know, I love what I'm hearing. So it sounds like if I go back many years, if let me take an example, in an average work week, which is 40 hours, to be honest, a lot longer than that from a lot of us, but let's say if it's 40 hours. As a developer,

When I started my career, I spent 40 hours writing code, building features, you know, writing enhancements, fixing bugs. As things progressed and changed, as you started doing a little bit more of, you know, as DevOps came into the mix, that number dropped, right? You did not have 40 hours to actually do development. You had maybe 30, 35 hours or 30 hours or whatever the ratio is. It just depends on the type of deployment, the size of the team.

and perhaps that specific change you're making, give or take. Let's say those numbers change nevertheless. Now given this world we're talking about with platform engineering, James, what would that number be? It's certainly not gonna be 40 hours because I still have to know a little bit more about what I'm plugging into. I need to understand the contracts, how those contracts might evolve, but it's certainly not.

It sounds to me like it's not going to be as much time as I would have had to spend learning the DevOps side of things. Am I right in saying that? What do you think is the average time I would need to spend as a developer if I were involved in platform engineering?

James Schorr (14:31.986)
You know, if everything was perfect and I had my way and had an endless budget and all the staff I need and all that stuff. Yeah, you would view the goal would be you as a developer, it's been 40 hours developing your code and only your code. And that's a little bit perfectionistic. That's a little bit pie in the sky. It'll probably never get quite to that hundred percent 40 hour mark, so to speak. So maybe, maybe a more realistic goal would be okay.

you'll spend two hours a week on things that are not development or something like that. That might even be reaching a bit. But I think it's, it's really based upon the maturity as a platform matures, as we get better about building platforms, that it's easier and easier for the developers and it could ease, it should get easier for the operations side as well, because we're sticking to our standards of having standardization, simplifying and

choosing tools that are easy to use and extend, we're using practices and workflows that make sense and are adaptable and modular, et cetera. We're hopefully avoiding tech debt, a little bit easy to say and hard to do. But as we mature, just like any practice, as you mature, things should get easier and better. They shouldn't go the other way.

I don't know that we'll ever hit perfection though, Krish. That might be a bit of a stretch.

Krish (saas.snowpal.com) (16:00.742)
No, no, no. And we don't aim for that. I love the phrase that says, don't let perfect come in the way of the good, for instance. So let's say, James, can we then say, these are not empirical data, but ballpark numbers. Can I say, as a developer, I can expect to see me get back 10%, 15% of my time, so I have that time available to doing something else. Would that be a reasonable target to aim for?

James Schorr (16:07.944)
Absolutely.

James Schorr (16:28.122)
I would say so, you know, as long as that platform is mature and you've got good support staff in place and so forth. And a little bit depends on how far you wanna take it. So it's like any technology, right? You've got people processing technology and it's like anything you implement, it depends on how much you wanna put into it. How do you know when it's good enough to where now you can just iterate on it?

And you don't need to continually pour more and more money into it and time into it as a platform. It probably depends, Krish. I'm hedging my bets a little bit because it's totally all over the map. It depends on how the maturity is.

Krish (saas.snowpal.com) (17:07.782)
No, no, absolutely not, that's fine. No, yeah, no.

Yeah, now I'm just trying to quantify these perfectly, right? It's not easy to quantify. The only reason I try to force myself to quantify this is just so you as a person understanding this, someone watching it, tries to get some perspective.

James Schorr (17:18.823)
Yeah.

Krish (saas.snowpal.com) (17:26.642)
But clearly, it sounds to me like I would have to do less of what I'm doing today integrating perhaps with DevOps team if I actually ended up interacting or integrating with a platform engineering team, for instance. But let me ask some random questions to get to digest this. If a deployment, let's say there is a bad deployment. In the case of platform engineering,

Is the developer involved in rolling back the bad deployment? Or is it, you mentioned self-serve. So I'm trying to understand if I did a deployment, it is not so good. I want to roll it back. Would I have to interact with anybody in the platform engineering team or I just do it myself?

James Schorr (18:05.726)
You should be able to do it yourself. I mean, that's a goal of self-service CICD pipelines, right? And even, I was gonna say GitOps approach, but I think that can play into it as well. But you as a developer should always have the freedom and the tools at your disposal to both get your code out the door, to update your code and to roll it back or change your code. You should never have a dependency on another team or another group.

to help you with that. Now, that being said, that's again, like the perfection type of thing. We always stand by an infrastructure side to be helpful and to help with any issues that pop up. Because remember, as you're deploying things, as systems get more and more complex over time and just the nature of IT, the nature of technology, we always have to kind of fight against that complexity by simplifying. But that being said, things do get complex over time. And so you do have...

servers involved and there's all sorts of stuff behind the scenes at network. So if a developer has deployed something and something's not working right, a lot of times they may need that the infrastructure side or the platform engineering side to step in and help them troubleshoot that is maybe something that is not a code issue or perhaps it doesn't look like a code issue.

So we always stand by to help with any sort of outages, ROSs and things like that. I think there's a very strong operational side to platform engineering that can't be forgotten about. And I think that's a good thing. So, yeah, basically as a developer runs into an issue, we want them to be in a position and equipped where they can self-service to fix as much as they can. But if they hit a wall or if they hit an issue where they think, you know, this may not be my code, maybe something else is going on here.

And I'm not real clear as to what's going on. I need some infrastructure help. Well, that right there, of course, Uproom Engineering side would step in and help out. And what's nice about that as well is if it turns out to be an issue with the platform or an issue with the pipelines or whatever the case may be, is the platform engineering side can take that as a lesson learned and they can bake that back into their product.

James Schorr (20:28.466)
and strengthen their product over time so that hopefully the developers don't hit that issue again or it becomes more rare, or at least it's easy to recover from, it's easy to address. So I really love the idea of when there's an issue, us getting various teams involved to fix the issue as quickly as we can. I also love the concept of after the dust settles and the bleeding stopped.

Let's go back and let's figure out what went wrong, what we can do better. How do we improve our platform? How do we tighten up things so that we don't encounter this again?

Krish (saas.snowpal.com) (21:08.371)
Okay, so more random questions to digest this. Let's say I wanna bump the replicas from.

five to seven, for instance. Today, I would go into a Kubernetes config file. I would make that change myself. In this world of platform engineering, should I say that I would actually go to a user interface, perhaps, a layer of abstraction that's created by the platform engineering team, so I'm actually not interacting with the Kubernetes config file directly, but I'm actually interacting with something in between, which will ultimately make the changes to Kubernetes behind the scenes.

James Schorr (21:39.43)
I think that's a design choice, whatever platform someone wants to build. So what you're getting at there is an internal developer platform. So, so basically an internal developer platform is a tool that provides paths of least resistance that provides golden paths is what they're called. And it tries to make it as easy as possible for you to deploy your code, update your code, scale your code, and do all the things, all that have all the goodies that your code needs to run successfully.

When you talk about updating replica, the number of replicas to expand out the resiliency, basically, I would see that I'm a code person. I would always love to see that as code. Let's let you just do the code. However, I've got to remember that some people aren't. Some people, they really enjoy GUIs for whatever reason. I don't get it, but some people do. So I see any successful platform as let's provide.

those golden paths, let's provide those ways of doing things in both as much as possible. We should have APIs, we should have ways to do it through code, we should also have GUIs where we can. Now, the challenge then becomes, what all do you invest the time and money into to make it available in GUIs and code and APIs, et cetera? Is it everything?

Maybe if you have the time and money to do that. If it's not, then you have to decide what are the most important things a developer needs. Well, you hit on one, scaling their code, right? You want to have more replicas. You want to have more resiliency. Maybe that's something we want to put in a GUI. Maybe that's something we want to make as easy as possible. Hit the button and it scales up. Hit the button and it scales down. Or maybe even set up a schedule to wear during a holiday season and it's...

It's an e-commerce software, maybe it needs auto-scale and you don't even choose anything. It just does it and keeps up with it based on load. Those are all design choices that are very specific to business, very specific to a need. So I don't think there's a one answer that could fit all, but I do think that all of it comes back to, is it easy to use? Is it a pleasure to use? Is it easy to operate? Is it easy to...

Krish (saas.snowpal.com) (23:39.268)
Right.

James Schorr (24:03.91)
update it, change it out, etc.

Krish (saas.snowpal.com) (24:09.742)
Okay, so let's say today, you know, at Snowball, we use a variety of different languages. One of the most recent ones we've started using is Golang. I fall in love with Golang as a language. So it's lovely. And then, you know, for a variety of reasons, and perhaps you could have a separate conversation about the language in itself, because it's just so close to my heart right now. But the reason I bring up a random language, if you will, is there are...

James Schorr (24:21.928)
Oh yeah, it's a great language.

Krish (saas.snowpal.com) (24:37.314)
There are teams that work on a single language, a single set of frameworks, like Java teams do Java work all day long, all year long. And there are companies that have a different mindset, like ours, for instance, where we are very polyglot. We have like six or seven different languages in the mix to throw some flutter.

TypeScript, Ruby and multiple frameworks in Ruby, Golang, and you name it, there is something out there because somebody wanted to solve that problem. It could have been solved slightly better using that language. So we don't necessarily see a good reason to streamline that. I'm taking that almost random example to sort of come to platform engineering. Now, let's say there are two such teams. Let's take two ends of the spectrum.

One team that uses one language, say Spring, Hibernate, and Java, a singular suite of frameworks. And there's another one that uses a variety of different languages. What is their experience going to be from this platform engineering create that level of abstraction so the experience is identical for both these teams? Or are there going to be differences? If so, what kind of difference?

James Schorr (25:45.654)
That's a good question. I think in general we try to be as language agnostic as we can. So generally with any IAC type of approaches we lean more toward Terraform, Ansible, these type of things, that there's Packer and so forth, instead of the traditional development languages. That being said, there might be some things in Python, etc. If you're coming from the development side,

we wouldn't want you to care at all about which develop, we would want you to be free to use whatever development language and framework you have, as long as you're able to deploy. Now, how you deploy, what you deploy, that is very language specific, and, or at least the what you deploy part is language specific. The how you deploy both sides of the house, so to speak, kind of have to be very much in agreement with, here's how.

our pipelines are going to look. I try to see that as separate from the platform itself. So here you've got this platform and then you've got the on-ramp into the platform or the road into the platform. How you get your stuff from point A to point B, point B being the platform. I don't think that can be done in isolation. I don't think a platform engineer team can just decide we're doing it this way or that way.

I don't think a development team could just decide we do it this way. That way, you have to use kind of a collaborative effort. That being said, there are some, there are some, uh, some factors involved. We don't want to be choosing technologies that are going away. For instance, uh, technologies that have a high price tag, it's technologies that are brittle or difficult to use, or there's five people in the whole world that know, you know, some obscure, uh, IAC language, you know.

We have to think through all those things. You know, what are the technologies that we can support for the foreseeable future? And then we also have to have in the back of our minds that this stuff is all going away at some point. Everything we're talking about today, it's all going away at some point. So how hard is it for that stuff to be decommed? How hard is it for us to get away from that and move our stuff to the next new awesome thing? Someday Kubernetes is going away. Someday cloud is going away.

James Schorr (28:07.606)
What will the next things be? We don't even know, but we can make intelligent choices and try to make sure stuff is well understood. It's easy to reason about. It's easy for us to shift gears, so to speak. So I don't know if that answered your question, Chris. That's a hard one. Long story short, you should be able to use whatever language you want to use as a little bit of development team. And you should be able to bundle it and send it somewhere.

Krish (saas.snowpal.com) (28:25.684)
No, no.

James Schorr (28:36.382)
And that somewhere is that platform.

Krish (saas.snowpal.com) (28:39.498)
No, perfect. And also my intent is also not to necessarily get to a very, a lot of these things as we both know, James, there's no simple straightforward answer. The only reason I'm asking this is at least it gets the creative juices flowing, if you will. And at least folks who are watching this, can tell, okay, these are.

James Schorr (28:48.556)
Yeah, that's true.

Krish (saas.snowpal.com) (28:58.742)
pros, these are cons. Where do I spend more time doing some research and understanding? So you're on the money there. Let me continue. You had mentioned self-service. That's awesome. All of us, who doesn't like self-service? And especially in the B2B world, as I talk to more people, the whole experience needs to be self-service, not just within a company, even when you're integrating tools from outside companies and organizations, how self-service something is, it goes a long way in you making the decision to using that for instance.

And we, even giving specific examples, our APIs, we try to make it as self-service as possible so people can actually start consuming and checking those out. But let's take that self-service. And I also mentioned multiple languages. Now, to understand this further, if you're a platform engineering team, you have built plenty of tools and I'm able to consume those tools. I was using different languages. Now I, suddenly as a developer or as an engineering team, decided Golang is the way to go.

Uh, is it typically self-serve to the point that I do not even have to socialize that we are building applications in a new language with James and James's team, or you publish a set of languages that you support. And when we have something new that we need, you're going to have to make some changes and you have to add some features and add support for it before I can, we can start integrating.

with the platform engineering team for deploying the Golang solution.

James Schorr (30:29.222)
Yeah, we would definitely prefer and lean toward. We shouldn't even have to know how you wrote that application. We shouldn't have to know the innards of that application. You would have to know as a development team from your side, how do I, as a development team, plug into what you're doing? How do I onboard my stuff into your platform? How do I hopefully tie that in to GitOps approaches and so forth to get it nicely put in so maybe I just do a Git push and.

or I merge something and then a trigger sets off the whole pipeline and all that stuff starts happening. So really, it's a lot more about that connection point. I don't think our platform engineering team should be in the business of telling development team, you must use this language or this framework, et cetera. Now, that being said, if there's some special feature that someone wants, that it must have a connector written in such and such language, that would be a different matter.

I think platform engineering in general stays away from that as much as possible. And they try to make that more on the development side things. So to speak, I've not, I've not really seen a lot of, um, connection points that are language specific that you must use this language or must use that language. I think that's kind of an anti-pattern. We try to, try to stay away from.

Krish (saas.snowpal.com) (31:51.71)
Okay, the reason I ask is, let's say if you took, you mentioned Heroku earlier, but if we took Heroku as an example, while it supports a variety of different languages, you need to create these build packs that are specific to those languages, right? When you're deploying an application, you're selecting those build packs. I mean, it's straightforward enough, but you are selecting those, and it's only because Heroku does have support for those build packs that you can actually even deploy those applications, which means they did something to have that work. So I know I exactly know what you mean, but I was just curious to know,

Is it wishful thinking or in reality that's how it works? In other words, I'm able to do it.

James Schorr (32:27.698)
Yeah, I gotcha. I don't think it's visual thinking. I think that we see the CI part, especially, and the CI CD part of things as a bit separate from what I'm talking about. It can be very integrated, like GitLab or something is super integrated and so forth. I don't favor that approach. I like to separate that out a bit.

So I think, again, Chris, it comes down to you can do it many different ways. If you ask the question of, is this a delight to the developer? Is this easy for development team to use? I think you would have to honestly answer no if you're forcing the development team that you must use this language or that language to use our stuff. That being said, you'll always have some things you have to standardize on, right? So a lot of things are YAML driven.

sometimes JSON or whatever, where sometimes you can't get away from that, you know? But it's not necessarily, at least what I think of as a traditional development language, we don't want to get in business again of forcing a development team to choose. You want them to be able to choose the tools that meet the business need and write the software in such a way that it meets that business need. Without worrying about how is my stuff gonna work? How's my stuff?

Krish (saas.snowpal.com) (33:25.997)
Right.

James Schorr (33:52.778)
or I shouldn't say that. How is my stuff gonna be deployed? How's it gonna be implemented? As much as we can separate those implementation details, the more we can do that, the better. So yeah, I don't think it's pie in the sky or wishful thinking. I do think it's again, part of the maturity model of a platform. I would see a platform that requires way too much from development teams as being fairly immature.

I would see a platform that as it matures, development teams, I see that going down where they don't, less is required of them freeing up their time to focus on doing what they can for the business. While art world platform teams are focused on maturing the product and maintaining, managing the product really well over time. Just like any product, you have a life cycle, right? So it starts out, it's bumpy, you know.

And then at some point it kind of matures to point. And then at some point the product goes away through the sunset period. And we have to think about that with the product, every product, not just platforms.

Krish (saas.snowpal.com) (35:04.79)
Perfect, right? So let's say I'm gonna make a couple of comments, see if you agree or not, and then I'm gonna play the devil's advocate for a couple of minutes, right? So let's say there, I've worked with developers who love building software, like writing new features, enhancements, new languages, yada, yada. DevOps, they don't mind doing it.

James Schorr (35:10.898)
Yeah, sure. Sounds fun.

Krish (saas.snowpal.com) (35:26.306)
But that's sort of a niggle, if you will. They're like, yeah, I have to do this because I need to get all my beautiful changes out there. So I will do it, not a problem, but that's not something how, if you woke me up in the middle of the night and asked me to do something, maybe DevOps is not what I'm doing, building features is what I'm doing. I've also worked with folks who are at the other end of that spectrum who absolutely love DevOps. Like they would, they had been waiting for something like that all these years and it came along, it was brilliant. So yeah, they are part of the dev team.

James Schorr (35:42.11)
Mm-hmm.

Krish (saas.snowpal.com) (35:55.65)
They also like to build features, but they would naturally lean to the right side of the spectrum. And I'm talking smaller teams where you have to do a lot of both. Now, if I took these two engineers, am I right, James, in saying that the first kind of engineer who enjoyed building the features and not everything else would be a better fit to integrate?

with the platform engineering team. I'm kind of stating the obvious based on our conversation, but would that be fair to say that it's more a fit for the first type of engineer than the second type of engineer?

James Schorr (36:29.034)
No, I think it's a fit for both. But again, I think it's how, now we're getting into the how you build a platform. So it so much depends on your focus, right? So with any product, when you're building a product, you think of your audience. And in this case, I think you're mentioning two very different use cases, two very different user types, two very different personas, and they're both equally valid. And...

There's probably a big spectrum. There's probably in real life, you know, a spectrum of 20 different types or whatever it may be. I see that as we need to meet all of these needs. None of those are invalid. We want to be able to make... That's why I talked about transparency earlier. For some, they want the platform to be opaque. They don't want to know what's going on. They don't care about what's going on. I just want...

I want to come into my code and go home. Awesome. We can help you meet that need. Others, they want to be intricately involved. They want to know exactly how the platform's working. They want to look under the hood with you. They want to argue about it. They want to debate about it. Awesome. We love that curiosity. We want to reward that curiosity. Those are equally valid. And so I see, as you build any platform or any product, let's keep our audience in mind.

Remember that those are all valid use cases. Now, all of that, we wanna make it easier for all of those users, right? So let's make things as transparent as possible, as easy to use as possible. Well, let's not make using the platforms difficult for either side. It's a hard balance. It's a hard thing to walk out in real life, but I think it's doable. If we keep our eye on the ball, we keep our eye on.

Are we building something sustainable? We're building something that's easy to use, easy to update, easy for us to get rid of. Is it well understood? Can I reason about it? Meaning, Krish, can I talk to anybody about here's how you use our platform and is it fairly easy to understand? It should be easy to understand. Anyhow, I'm starting to pontificate. You have to stop.

Krish (saas.snowpal.com) (38:49.42)
Right.

Krish (saas.snowpal.com) (38:53.106)
Yeah, no worries. Yeah, no, so I'm gonna play the devil's advocate. I'm gonna get to it, but let me ask a question before that. The skills I needed.

to become part of this, you know, as DevOps came into the mix, there were other skills that a developer needed to have that they did not necessarily need to have. It was just not enough to just know Rails or Golang or TypeScript. You had to know a little bit more about other things. Some other things were, how do I create a Docker file? How do I create Docker Compose files or YAML files? How do I, you know, create the Kubernetes configuration, for instance? Maybe a little bit about you mentioned Terraform, you mentioned infrastructure as code. Now, how much of each of these things

to know, it really depends on the company, the team, the size, and a number of other factors. But it should suffice to say that a lot of us had to have some understanding, some level of understanding of some of these items, and perhaps a lot more about some of those. Like, you know, like say I would be closer to Docker files and Kubernetes configs and some secrets maybe, but not so much with Terraform, for instance, because that's into a different space altogether. Compared to that,

What are the skills, let's say you're hiring somebody into your dev team, maybe a Ruby shop, maybe a Golang shop, maybe a Node shop. What skills do I need to have? People are gonna be curious, what skills do I need to have to sort of integrate with the platform engineering team compared to just doing DevOps myself as part of development?

James Schorr (40:22.394)
Yeah, I think that's going to be very different for every company, for every platform, depending on how mature it is. I would say that table stakes, if you want to be able to deal with just about any platform out there, just about any target, so to speak, to deploy upon, you should understand YAML, you should understand maybe it's emancipal, maybe that's helpful as well.

It can't hurt to at least understand configuration management. And when I say configuration management, I mean a more like configuration of power. How do apps have configurations? How do they have secrets management to some degree? I see all of those as fairly critical. You should understand CI-CD pipelines. That's probably one of the biggest things for developers to understand, at least enough to troubleshoot, at least enough to.

be able to change things. Maybe they don't, maybe they're not, maybe they're more of a junior engineer and they don't quite understand how to set up a CI-CD pipeline from scratch and that sort of thing. But the more someone knows about the CI-CD tooling, the better, you know, I think that's gonna stick out on a resume or an application. If someone wants to become a senior engineer, they, even with platform engineering, they're gonna need to know

kind of a little bit or a good bit about a lot of different things. But they need, at some point, some of those things may start to drop off, meaning that maybe they don't need to understand certificates that much anymore because that's all happening for them. By the platform, that's a lot of media that's all handled for them. So maybe over time, as time goes on, job requirements start changing a little bit. You don't need to know some of these skills that...

people 20 years ago, 10 years ago, five years ago, had to really understand as a senior engineer to help their teams get their stuff out the door. Those folks become more and more rare over time as they get a little bit more and more spoiled, so to speak, by the nicer platforms, the public clouds, these things that are doing a lot of things for you.

Krish (saas.snowpal.com) (42:26.314)
Right, so.

Krish (saas.snowpal.com) (42:31.298)
Hmph.

Krish (saas.snowpal.com) (42:40.426)
So James, when I listed a list of these things, I mentioned Docker, I mentioned Kubernetes, Terraform, et cetera, your response, at least correct me if I'm wrong, as I'm understanding it is, that you need somebody to understand the fundamentals. It's almost like a computer science fundamentals, right? You're saying, here, understand the DevOps fundamentals. If you did understand the DevOps fundamentals, you'll be in good shape working with a platform engineering team.

James Schorr (42:44.893)
Mm, dark.

Krish (saas.snowpal.com) (43:03.702)
But you did not mention in your response that you would have expected for them to know a particular technology. You did not mention Docker. You did not mention that you would need to know Kubernetes, for instance. Does that mean that you want to create that layer of abstraction so Krish doesn't need to know how the internals of these deployments necessarily work? Because you didn't mention I need no EKS, for instance, just as an example, or Azure equivalent of that service.

Am I right in then saying that I need to know the fundamentals? I need to understand how a CI CD works, but I don't need to understand how Jenkins works because you're going to give me a different tool. Maybe you create a layer on top of Jenkins so it doesn't look like Jenkins. Maybe it uses, maybe it doesn't use it. So I just need to get acclimated with James's team's versions of these platforms and tools, but I do not need to know the ones that are generically out there. That's my takeaway. Am I right or am I wrong?

James Schorr (43:59.498)
Hmm. I think that's partially right. That would be, that would be a goal, at least for me, would be that someone does not need to know the intricate details of all that stuff. That being said, I think understanding really well, at least one or two tools in each space is super helpful for any engineer in their career. So I'm somebody that, you know, I love to do things.

all sorts of things. I love to learn new things. For a while there, I was learning a new coding language every year. And I love learning new things. So it's hard for me to imagine someone not wanting to learn new things. It's hard to relate to that. But I do think as a platform engineering group, we don't want that to become a requirement where our customers need to know all these things because I'm sure you see it in the CNCF.

that they have a big image where there's just tons of different tools and all these, there may be hundreds of tools. We can't expect that of anybody. Knowing one or two tools from each space, I think that's super helpful for any engineer. I think it helps them learn how to think differently and at least understand the concepts behind the various things like, what is storage? What is CICD?

What is Kubernetes? What is serverless? It's really healthy, I think, to understand at least enough to understand the concepts. The specific tools, the specific implementations, that's going to vary from company to company. I'm sure you've seen that in the consulting space where you go from this company to that company, you know, you see all sorts of tools. But yet there's often common themes, there are common approaches.

or let's say to doing things. And if you can really understand those, that's what's key. You can, if you can understand the underlying assumptions, approaches, then you can understand anything.

Krish (saas.snowpal.com) (46:11.334)
Well said, right? But let me take my example. There's no, you know, just like as you grow older, I realized like most things in life, there's no real simple right or wrong answer. You just figure how right or how wrong it is to you and then you go with that. So let me just take my example.

As somebody who loves to hear that with platform engineering, that I wouldn't have to spend as much time in the deployment of things, and I can spend more of my time in the building of those same things. It gives me a lot of encouragement. That's my first reaction. But just before I can enjoy the fullness of that reaction, I immediately have a concern, which is even though with DevOps, I had to spend some time understanding

For instance, if you're doing one of these deployment using EKS on AWS, it's different from how you might do it on Azure. So there is a bit of learning curve. Tools work differently. Even though the fundamentals are exactly very similar, if not identical, they're presented very differently. That's how vendors differentiate themselves. But

James Schorr (47:15.318)
Mm-mm.

Krish (saas.snowpal.com) (47:17.334)
But even though they were different, I was building those skills as an engineer. I kind of want, I mean, some of it is open source, some of it became open source. Other things are not so open source, but they are still shared between three big companies, Microsoft, you know, Google and AWS. So it's kind of a vendor lock-in, but it's vendor lock-in to these large organizations. So I was directly building a skill.

Whether I liked it or not, I needed to know those things to deploy my features out there to production to keep them stable, scalable, performant and all those nice things. My first question slash concern, putting myself in that space is, now if I'm integrating with platform engineering tools, it comes across to me, maybe I'm wrong, but it comes across to me as though

every company that does is going to create their own layers of abstraction. They might provide their own DSL. Now I'm going to have to learn something. Learning is not the problem, but the usefulness of that learning outside this organization comes across as a concern to me. And let me say why. If I'm a full-time engineer who's going to be working in this organization for years to come, it's less of a concern. But if I'm a consultant, it's more of a concern.

Or if I'm the kind of person who's not exactly sure where you're not signing your life to a company, you stay there as long as you learn, you benefit, and the organization benefits from you as well. So you're keeping your mind open, right? Hey, I wanna be here as long as I enjoy it, but there comes a point where my learning becomes stagnant, I might have to find a different place to go to. And I might not be able to carry over these learnings. And I say this, James, with specific examples that I won't give you names, but...

I've worked with engineers who helped us along the way at SnowPAL, who've done something for a long period of time, and then they come on board to helping us with something. And I've been quite shocked to knowing that they're good at doing some things, but their awareness in other peripheral areas and aspects of engineering has been appalling, to say the least, right? Because it's not their fault.

Krish (saas.snowpal.com) (49:25.722)
It is almost a fault of the organizations that they were in because they protected them beyond a point that you want to actually protect them. It's like a child. You want to let the child go out there, explore the world. You give the child everything it wants. It's going to be in this comfort zone. And then when the child leaves the house, it's super, I say it because it's a boy or a girl or whoever they essentially, they're going to be super shocked. I mean does that?

Concern resonate with you first of all, if so what do you have to say to somebody who has that concern.

James Schorr (49:53.118)
Thank you.

James Schorr (49:56.974)
I think it's an awesome concern to have, I think it's very, very valid. It strikes me that as we, in anything, as we make things easier, you know, there is a strong risk that people become more and more used to that ease and they try, they don't stretch themselves as much, they don't learn as much because they don't have to. A good example would be

I remember back years ago in school, you know, you were not allowed to use your calculator, at least for a period of time. You could not use a calculator. That was considered cheating. You know, well, then that kind of morphed into you must bring your calculator to class, you know, especially with the higher maths and stuff, and you must use it, you know. And you can look today, many people don't spend a lot of time doing deep learning and really getting into subjects because they can just Google it. They can find out in two minutes, you know.

the gist of what it is and why should I spend time researching and diving deep? So I think that's a very valid risk. I think that that's a really well put question. I don't think platform engineering makes that better. Perhaps it does make that worse in some ways. And, but it all comes down to does the business get more value? You know, is the business able to get value more quickly?

from the software that's being developed or integrated or even purchased and implemented, et cetera. That's our goal here is business value. When it comes down to individuals and learning, I think that an individual really needs to look at that totally separately. Am I as an individual continuing to learn and really diving deep into things and really understanding things and preparing myself for what's coming.

and preparing myself for the future. Don't put yourself at the mercy of an organization or a way of doing things or a platform or a platform engineering team. Treat that as a separate matter. That's something that you did is nice to have. It's a really good thing to have. It helps us business value and all of that. But that shouldn't stifle you as an individual from stretching and learning and growing. I'm a strong advocate that someone needs to be learning and growing throughout their entire life.

James Schorr (52:16.21)
And it doesn't need to be only an IT subjects or development subjects. It should be in everything. You know, let's just keep growing and learning. So I see those as separate, but that's an awesome concern. I really enjoy, enjoy that spread top remote.

Krish (saas.snowpal.com) (52:31.262)
Thank you. And we have like about seven minutes before we hit the top of the hours. I want to use this time to ask you some questions that folks typically also have. And they've asked me, you know, we can predict anything in life, most things at least. And then I'm going to have to convince James to come back to more of these conversations because I have a lot more questions, I have plenty of more questions. Sadly didn't expect to get to them with him in the very first session. But let's say someone watching this, one of the questions,

had as.

Hey, this looks like an interesting area. I want to kind of explore this, get into it. And one part of it is learning. And you mentioned, we are very alike in many ways. You want to learn these new languages. You want to learn something different. You want to push yourself outside the comfort zone. But some other folks like the comfort zone. You know, they do push themselves out only when it's needed, right? You're not seeking to be outside that comfort zone. But let's say, regardless of who you are, you want to learn,

I want to learn a bit more about platform engineering. Before you did that, you made the commitment to time. You're asking yourself this question, what is the job market looking like in the future? As we enter 2024, we are like a few days away from the new year. Is this something that you see as useful? It is useful for sure, but from a job market standpoint, James, as people are wanting to learn,

If that is my only thing, not learning, let me make it difficult for you. If learning is not necessarily my interest at all, it's only I'm learning this to actually find work that's gonna pay me well in the year, in the next year, in the years coming forward. Would you recommend that we explore platform engineering? And if so, why?

James Schorr (54:19.294)
That's a really good question. I would say platform engineering is one of those skills that's definitely pretty hot in the market. Anything around security that's also not just very needed in the market, but it's very rare. So security's another really big one. I do think traditional development and custom development is over the next decade or two, we're gonna see less and less of that.

So that could mean a couple of things. That could mean the jobs become more rare in that space. That could also mean that because it's more rare in the space, that it becomes a lot more lucrative to be in that space. So just like anything. Another big one really has to do with folks that are, I don't even know what to call it, but to really understand how to integrate and...

mainly around integrations, especially with AI and what does AI and GenAI and so forth mean for the upcoming applications? I think we're going to see a complete shift. It's already started with how applications are done. They're going to be a whole lot more interactive than they are today. People that understand how to take today's stuff, so to speak, and morph it or not upskill, I'm trying to think of the word, but

bring it up to where that interactivity, that expected interactivity, that's another area that's going to be really, really hot. So I know that's a big hype thing right now with Gen. AI. I do think there's some substance behind that hype. And I do think that that's something that's going to affect us a lot more than we think it will. So that's another one.

Krish (saas.snowpal.com) (56:04.65)
You know, I didn't mention intentionally in this first call because I have a bunch of questions I wanna ask around that, but I've typically saved that as we get deeper into the conversation. So that is a good teaser for folks wanting to come back and me having a James back on the podcast because I wanna talk a lot about what it means. You know, we talked DevOps versus platform engineering.

I want to take platform engineering with and without or before the advent of AI and all the conversations that are happening this year and going into 2024, how the same platform engineer might have to do things a little bit differently or quite a bit differently to become more productive in this world of generative AI, for instance. But I'm just going to save that for a separate conversation altogether. So James, we are coming up at the top of the hour here. This is great.

In my mind, at least we've scratched the surface for somebody like when I called you, I didn't know the space of platform engineering. As somebody who's done DevOps work as part of development work that I do and DevOps to get our solutions out there.

Just one quick question and closing comments. The question is, is platform engineering only for larger organizations or is it good for small? In other words, how big should your team be? Are there some numbers before which we start looking into platform engineering?

James Schorr (57:31.402)
Yeah, that's a good question. I do see it as more of a need for a medium to large size business. I think smaller groups, startups and that sort of thing, it can help. I do think it's a lot of work. So I would probably say you need to have a dedicated staff to manage the platform for one thing. If you're not at the level where you have a dedicated staff to do that, it's probably not right for you at this point.

because it is a lot of work. That being said, there's a lot of tools out there in the marketplace where you can kind of get, buy a platform or a program and then use a platform. That might be enough with one or two people that are dedicated to maintaining that or something. I'm not sure that you'll see as much value as you would for a medium to larger site organization. The concept behind platform engineering, it's a product concept.

concept. So I would say that applies to every group. So even a small group, even a startup, treat your stuff as a product, meaning it's not just a project, it's not just something that you throw out the door, get it up and running. It's something you've got to care, love, and maintain, so to speak. And at some point, you've got to get rid of it, and the next thing comes along. So thinking about that product life cycle and

All that's really important for every group under the slides.

Krish (saas.snowpal.com) (59:05.71)
With that, James, I think this is a great point to end and pick up from here as we talk through this. I want to, again, folks, this is James Schur. Thank you, James, so much for taking time to chat about platform engineering. I've learned quite a bit in the last, like, an hour or so. If there's anything else, or is this a point we could say I could just stop record on this one?

James Schorr (59:19.03)
Sure thing.

James Schorr (59:32.19)
Nope, this is great. I appreciate you all and hope you had a good time listening. Thanks for all that you do, Krish.

Krish (saas.snowpal.com) (59:39.81)
Thank you.
_