Transcript
Renato Losio: Today we’re going to talk about the architecture of the developer experience, where product, platform, and operations meet. We are going to talk about platform architecture. Platform architecture doesn’t exist in a vacuum. They must support collaboration across product, operation, and the teams that build them. As practitioners, how can system, platform, and processes be designed to reduce cognitive load, enable automation, and accelerate delivery across distributed systems?
My name is Renato Losio. I’m a cloud architect. I’m an editor at InfoQ. Today I’m going to be joined by four experts coming from very different backgrounds, different companies, different continents. They will discuss approaches for designing according to best practices. Very first chance for each one of them to introduce themselves. Maybe you want to give a few words about yourself and what you bring to the table?
Martin Reynolds: I’m Martin Reynolds. I’m currently field CTO at Harness. I come from a background of more than 30 years as a hands-on engineer, engineering leader, and platform engineering, working across multiple industries, sectors, languages, clouds. Bringing a fairly broad breadth of experience.
Ran Isenberg: My name is Ran Isenberg. I’m a principal software architect at CyberArk at the platform engineering division. I’m an AWS Serverless Hero. I’m a serverless and platform engineering consultant. I started to practice platform engineering here at CyberArk about 6 years ago. We started with 15 people. Now we’re over 100 people, and we cater to the needs of over 1,000 developers, and we build a serverless platform.
Stephane Di Cesare: My name is Stephane Di Cesare. I work for the DKB who are a German online bank. I worked there as a platform engineer in the experience team for our digital platform. I’m focusing on being the interface between the platform and different kinds of users or developers and others. I have a background in the past at companies like Accenture and VMware.
Garima Bajpai: I’m Garima Bajpai based out of Ottawa, Canada. I’m the founder for the DevOps community of practice here, which has several chapters. A recent hall of fame shows that we have done several hackathons, DevOps for GenAI hackathon is the recent one. Talking about myself, I’m also the chair for the Ambassador Community at the Continuous Delivery Foundation. I’ve written several books, “CI/CD Design Patterns”, “Strategizing Continuous Delivery in the Cloud”. My call to action is communities and leadership practices. I bring on the table 22 years of R&D experience. I have a section which primarily works with research and development in telecommunication. We can talk a little bit more on diverse platforms and niche platforms in that space.
Developer Experience – What Does it Mean?
Renato Losio: Let’s set, first of all, a bit of background information and kind of, where do we start? When you hear developer experience, what does that really mean to you in practice?
Ran Isenberg: When you think about developer experience from my perspective, it’s thinking about my customers and that’s my internal developers, the developers that I work with. Basically, it means that when I develop a new service or a library or an SDK or an animation, I need to involve them as much as possible in the process to get their feedback from the design stages, then in the implementation stages, and then basically think about how they’re going to use this product from their perspective. I’m thinking about usability. Then I’m thinking about documentation, how easy it is to understand what’s going on there. Going forward with maintainability, release notes, and things like that. These are the things that come to my mind when I think about developer experience.
Martin Reynolds: I would echo a lot of that. For me, I would say that developer experience really just means making it effortless for engineers to build, test, ship, and remove as much friction as possible. I would always do that. I think this echoes what Ran was saying, and I’m going to use one of our internal values, which is, do that, but remember the human. Remember the person that’s actually consuming those things at the other end. You can’t do one in isolation without the other.
Garima Bajpai: It’s needless to say where we started this concept from. History reminds us that once the complexity of your development ecosystem increases, it’s essential to streamline the workflows, streamline documentation, bring standardization and governance. This is part of how this movement got started. For me, I think it’s extremely important to be people centric. As Ran mentioned that your customers are your developers. Don’t forget where you started from, and what is the problem you’re solving for them?
Stephane Di Cesare: I basically agree with what everybody else said, but I have one comment. The first thing that comes to my mind when I hear developer experience is, don’t forget the others. Because I see in the platform, one kind of user is the developer, but we are also working with the finance team, with security, with auditors, because we’re a bank. I think it’s important to have in mind as well where the platform can bring value for these users, because it’s sometimes completely different to what developers need. It’s important for us that they are happy as well.
Friction Points Between Product, Platform, and Operations Teams
Renato Losio: Where do you see the most significant friction point between product, platform, and operation teams. Now I start to think that maybe the number of teams is even wider, but let’s start with the core one, let’s start with product, platform, and operation. Do you see any friction point, and where do you see most friction points?
Martin Reynolds: We do. We see it and I’ve seen it as well. You tend to get a lot of friction when teams are using different tools or the tools are very siloed by the teams that they’re working with. I think also anything that has too many manual approval stages in, also causes friction because it’s like, I can’t get it out. Product teams very much often just want to get those features out the door as fast as possible. Developers are then trying to get it through the process. It just slows down those release cycles. I think the larger your scale the bigger those inconsistencies tend to get. If you have inconsistent delivery mechanisms, inconsistent deployment architectures. I know there’s no perfect world where an organization says, we only deploy one way and that’s how we do it.
If you’re thinking of those golden paths to production or secure landing zones, or whatever you want to call them, there’s no one way, but generally there is a subset that works for most people. I know we have some questions later about how flexible that should be too. I think that friction really comes from wanting to get something out, and then the processes that you need to do to actually get something in front of the business’s customer. Often, there’s a desire for that to be quick and there’s lots of things that get in the way.
Ran Isenberg: I totally agree. I think that even if you have a golden path, which we do, it’s really easy to stray from the golden path. The bigger you are, it’s easier to get, so people stray from the golden path, or from the beginning, you have different teams, you have different tech stacks because the platform didn’t arrive in a vacuum in many cases. You have other tech stacks, some Kubernetes, some serverless, some Java, some C++. Then everybody wants something from the platform. We become a bottleneck because we have a product manager. We manage our platform as a product. We have our priorities, and we need to make everybody’s happy. At some point, many people will not be so happy because we can’t really get to what they want. This is a very large friction as well.
Renato Losio: Thinking about the golden path, actually, Martin made me think as well, one company doesn’t usually have just one way. Actually, one thing that I tend to forget when I go to conferences, like QCon or other conferences, that you hear practitioners on stage explaining how they do things. I tend to immediately associate that that’s the way they do it. Often, it’s just how one team, that’s what they presented, and often the best part of what they’re presenting. The attrition points are usually coming from the part that is coming from the other team, other processes, and all the rest that is still there. That’s a very good point. Do you see the same challenge in your scenario, in your more regulated industry?
Stephane Di Cesare: I think that the friction very often has to do with information and communication. Very often it boils down to, the agreement between the user and the platform wasn’t very clear about what the platform is actually supposed to do, or the communication channels were not clear. I think it’s really important, especially when you’re a platform team that starts from an engineering background to not only have something that works, but also be able to explain well in which conditions does it work? Which capabilities do we actually deliver in which way? Where do you need to use it? Because I think very often the friction points are related to that.
Garima Bajpai: I echo all the points which have been mentioned by Martin, Stephane, and Ran. I think the biggest friction point or pain point is, don’t lose sight of user needs. Don’t think about building a world-class innovative platform without understanding where the inefficiencies are, what kinds of workflows you can automate for developer productivity.
Then also think about a cross-functional ecosystem and things like security, compliance, and those kinds of emerging technology integration gaps. I think these are things which we would be expecting from the platform. It depends on business unit to business unit, team to team. I drive a large ecosystem of developers through communities. What we see is that ownership and accountability also becomes a challenge in this domain. Whether you should streamline your workflows in a centralized way, or you have autonomy to decentralize some of the functions and some responsibilities, those are the kind of things. Every organization has to look at their own culture, workflows, needs, as well as adaptation, and then decide in their own way how they want to go about this kind of challenge.
Factors That Influence Team Velocity
Renato Losio: Actually, Ran, I think you mentioned before of how much your team grew in the last few years or whatever. I was wondering, on a growing team, what’s the thing that slows down your team the most? Is it more a technical thing or something else, or just the fact that it’s growing, or anything to share?
Ran Isenberg: I think growing the team has had its challenges, even inside the team where you have best practices for how you write documentation, we use GitHub Pages, for example, or how you do release notes. Or, how do you even make a design, how do you get feedback, how do you communicate whatever you build, they need to scale that and you need to share all the knowledge that we have. For example, we’re using a serverless tech stack with Python. Every new member that you onboard needs to know all the best practices and how to design things. That really slows down. This is part of the regular onboarding.
I think the thing that really slows us down is the fact that there are many golden paths. There are many variations of requirements. Again, serverless and Python is what we started. The more we started to integrate with other teams and add more teams to the platform, we realized that we need to make some adjustments. We need to support other things that we didn’t think of, because when you start and learn something like serverless and Python, it’s really hard to think about everything. Like, how do I support Kubernetes? How do I support people with Java? How do I support other needs of services that I’m not really communicating with every day, because the adoption takes time, even for the platform. Start with one service, two services, and you grow and grow. Then you get more needs, you grow your team. It’s a whole cycle.
How to Balance Core Operations vs. New Innovation
Renato Losio: For a platform operation team, how should they balance between core operation, like release versus new innovation in platform engineering? As in every team, any technology we use, there’s always a balance to find.
Martin Reynolds: I have multiple views on that. It’s a nuanced answer, just because I think a lot of those core operations, those are the kinds of things that I would expect to be as fully automated as possible. It shouldn’t take people to do releases. It should be a process that’s automated and can just happen. I know that can’t happen a hundred percent all the time, but as much as you can do that, that really simplifies and frees up that flow. I think that on the other side of that, that platform engineering side, I think and I know it’s already mentioned, you treat developer experience and you treat platform as a product.
You should absolutely have a roadmap that you’re sharing with your customers and you should be validating that roadmap and understand the priorities of what needs to come in that roadmap so that you’re actually planning your resources based on, ok, this is what I need to support my golden pipelines, my test automation, my security scanning. This is the effort that I require to do that. This is how much extra I have, and this is what I can deliver in that innovation space in that time, just like you would with any other product. I’m talking about this now exactly the same way I talked about when I was delivering education products or when I was delivering finance products, it’s the same thing. There is always a core level of support that you have to reserve resource for, and then based on the rest of your capacity, plan out what you can deliver based on what’s going to best serve the community and the business.
Garima Bajpai: This is value versus velocity. You have to understand where you are in your journey with platform engineering and what your users need. For example, I’ll quote this report from Harness, which states about the AI paradox. What happens is that in today’s times we have like a lot of AI generated code and documentation. Now where the platforms could help us. The platforms could help us in removing the bottleneck for testing, deployment, security, and that is where most of the delays and risks are associated. We will have to understand what kind of innovation could help us with the developer journey, which is taking place side by side.
Metrics to Measure the Success of a Platform Engineering Process
Renato Losio: If you had to pick just one metric to measure success, which one would you pick? I would like to know the first few metrics. Do you have any metrics that you would recommend to measure success of a platform engineering process?
Stephane Di Cesare: My first reaction would be, it should be first clear to you what are the outcomes you want to reach. Where do you think that the platform should benefit? I think that’s part of the product management part to understand, where do you think we will have the best value, and to focus on that in the metric. I think in general for platforms, the customer satisfaction is a good way to have an overall view of, is it going well or not. Then I think it’s important to look at what are the more specific outcomes you’re looking for, especially in the shorter term, and try to see, how can I measure this specific outcome?
Renato Losio: Do you have any metric that you actually use or you recommend?
Ran Isenberg: I think it’s a very specific, maybe an advanced metric. One of the projects that we’re very proud of is that we’re able to basically automate the time to create a new service, a hello world enterprise-grade, production-grade serverless service that is already out of the box connected to our SaaS control plane and has all the best practices and SDKs that we advocate here in the platform. For me, a success metric would be how much time would it take for a developer to use successfully our self-service automation from the developer portal. It would be the time and success rate because we estimated this by running this automation, which takes about 3 hours, we’re able to reduce the effort from 25 weeks for creating everything, basically what we have, into 3 hours. If they’re able to reproduce this automation and create services, which is something that teams do many of the times, new services. If the success rate and the time is very good, then for us, that’s a success because that basically means we save money to the company.
Renato Losio: Do you have any favorite metric you’re using?
Martin Reynolds: I’m going to give two answers. If I was boiling it down to the simplest thing, and I think this is what Ran was really saying as well, which was really that lead time for change, if you’re just picking one metric, because that encapsulates the velocity and the improvement in speed of delivery. I would probably pair that with developer satisfaction just to give you a more full insight. However, I would also say, if you want investments in developer experience from your leadership, from your management, you have to speak in a language that aligns with what their goals are. You might want to pick a metric that aligns with what they’re trying to do, and what’s a priority to them.
Sometimes that isn’t necessarily the same as well. It might not be lead time to change for them. It might actually be reduction in cost. Being able to map those two things together saying, actually, by making things faster and more efficient, we’re actually getting better value out of our engineers, because they’re able to spend more time doing the thing you pay them for. The ones I mentioned at the start, they’re like my go-to, but equally, if you’re talking to management, you need to talk the language that they understand. That’s what gets you the investment to keep delivering and keep improving.
Stephane Di Cesare: When I hear about cost reduction, one way to express it that can be more useful for platform teams is cost avoidance. Which cost do you manage to avoid? Because I think for an operation team, it’s often a good way to show value as well, is that we’ve done that and it avoided that people will run into that problem, which would be very expensive.
Self-Service Functionality for Devs – Dependency Reduction
Renato Losio: What are your thoughts on making self-service functionality for devs or training them to be more platform aware and reduce dependency on the platform team?
Garima Bajpai: I’ll answer it from a broader perspective. I think from platform engineering, the platform engineering existence is because we have a lack of quality of processes. When we started with a lot of developer tools and capabilities, the tool stack was fragmented and there was a lot of cognitive load on the practitioners to bring these tools in the ecosystem in a good way. There was lack of standardization or governance. When you talk about self-service, what it offers to the developers is a centralized interface where the developers can access tools. There is a software catalog. You can also associate the environment and infrastructure and the services around it. It practically enhances the developer experience.
Even the tools which you have in the platform space, they can also be integrated into a secure logging system, performance monitoring, and alerting. It also creates a lot of visibility for their developers and troubleshooting capabilities. It is definitely an asset for the developer ecosystem, at least from where I sit. I sit with thousands of developers developing research and development capabilities for telecom ecosystem, for example. I’ve seen that these self-service portals do affect the productivity of the developers and reduce the cognitive load on the practitioners.
You can also think about, if you are working with many product teams and if you have specialized needs for these product teams, how self-service portals could help you. Templating, configuration, and also streamlining your workflows. On the click of a button, if you can access those tools and applications, that’s great. The developer wants to develop applications and do not care a lot about what goes in the background. The platform engineering team is helping them build that kind of perspective.
Internal Developer Portal as a Self-Service, in The Platform Eng Journey
Renato Losio: Garima mentioned as well, internal developer portal. At what point in the platform engineering journey should an internal developer portal as a self-service be thought of?
Martin Reynolds: There’s two things with that. It’s providing a front-facing way for engineers to access their information and access self-service especially. I’ve seen organizations have amazing success with self-service in terms of reducing the load on platform and DevOps teams because those self-service things just take away that load. Generally, the gateway to that is an IDP. At which point though, when it’s really going to start adding value. I don’t think there’s a golden bullet answer to that. Like, is it a day one thing? Probably not. There’s probably other things you need to do before you get to that.
Often, I think, especially like 18 months, 2 years ago, I think there was this view, it was going to be like a magic bullet and you’d put this internal developer portal in front of all of your tools and then everything would be magically better for developers. That isn’t what happens. Internal developer portals actually take effort to really build out, to populate, to maintain. You have to factor that in to your platform team, and when you can actually deliver that and be able to deliver it reliably to get that value. Don’t get me wrong, I love IDPs. I think they are a great tool. Is it where I would necessarily start though? I’m not sure. I think sometimes fixing some of the other processes has a much bigger impact. Maybe fixing the deployment process or the automated testing or embedding governance or things that have bigger friction points might be where you want to start and then move on to that kind of developer portal. It’s part of the maturity journey. There’s places to start, and as you’re maturing, developer portal becomes the right thing to have.
Garima Bajpai: When you talk about self-service, and essentially, when you talk about platform engineering, 2, 3 years back, people did see this as a big organization bet, the investment big organizations with thousands of developers were making. Lately, what I’ve seen is that there is a shift. There is a shift that small companies, startups, and even solopreneurs are adopting platform engineering capabilities, platform engineering in a box.
If you talk about Microsoft, for example, they are launching this platform in a box. Why it is happening and why it is keeping traction with the developers is that increasing complexity, AI integration, and also, I think streamlining the mundane task or the toil from the development ecosystem. Because as you mentioned, Martin, all those hygiene factors, coding practices, the best practices you can bring for applications and developers, it is needless to say that you should be having that. Platform engineering is not the first thing you do in the ecosystem. Once you have crossed that journey and you have matured to an organization where you can scale or you can see that these processes, if you automate, won’t reduce cognitive load on the developers, that is great. Even solopreneurs and small companies are using this platform engineering as a box kind of concept, which is great to see because this is not only a big company or big organization investment anymore.
Ran Isenberg: I completely agree with everything Martin and Garima said. I can share that from our experience, we didn’t have a developer portal for a very long time. You start with building libraries for observability, data installations, all the things that you need in the system. Eventually, you start to build blueprints or templates and then you want to reuse them. For us, it was Jenkins self-service pipeline that people would use and it was fine for many years.
Then we got feedback that people wanted to build entire services. We have backend, you have frontend, you have other repositories, and everything needs to be in line together. You have all these complexities. You need to orchestrate the creation when you create a new service. Then that was the time where we actually added the developer portal where it basically acts as an orchestrator for the self-service. It’s no longer just a single repository that could live in the Jenkins pipeline. It’s something that orchestrates the creation of multiple pipelines in GitHub and does other things in the background. It’s feedback and complexity. You can do without a developer portal for many years if the need doesn’t come.
Stephane Di Cesare: I also agree with what everybody else said. The two main points for me are, you have to have streamlined processes or golden path, depending on how you call them, to be able to have a portal, else it won’t bring that much. I think as everything else you’re doing in the team, you have to think about the lifecycle and the maintenance and not underestimate that this will need maintenance as well.
The Appropriate Scale to Tailor Platform Eng to Business Units
Renato Losio: I was reading earlier this year an article from Google about how they do platform engineering their size. One thing that struck me was the measures that they say, tailor platform engineering for each business unit and application to achieve the best outcomes. When I read it, I felt, sure, Google can do that because they have 100,000 people still working for them, but does it actually work only at a company the size of Google or do you use the same approach at any scale? Do you try to tailor things for different business units? Stephane mentioned that there are different business units involved usually in platform engineering. How do you deal with that?
Stephane Di Cesare: I think platform engineering, the main point is to try to find where can you provide value, to try to find what are common points between business units, which you can address centrally to make it more effective. I think when I read that sentence from Google, it sounds like it’s a bit the opposite. I don’t know if I understand it correctly.
Garima Bajpai: I think what you were referring to, Renato, is that Google has actually distributed autonomy of their platform. They have distributed the autonomy of the platform with specific business unit capabilities. To the question you had, as Stephane was mentioning that you could do that in any scale. Scale does not matter. Maturity of the organization would matter. Because if you have not standardized the process, you do not have the basic hygiene of the development ecosystem itself, you don’t have the mature pipelines. Like the CI/CD pipelines are flaky, then probably it would not work. You have to have a certain level of maturity in the ecosystem before you take that decision. The scale does not matter.
If you ask me personally, as an R&D leader, I would say, you distribute the autonomy as close as possible to the users, because that is the way you could actually gain a lot of efficiencies, as well as work on a specific need of the organization. I’ll just cite one more example and finish this point, that what we are seeing with AI, for example, integration of AI into coding and documentation. Every developer has taken things in his or her own hands. Is this good for platform engineering? If you think about this, it is a lot of shadow AI in making, and that’s the AI paradox we were referring to in the beginning. We probably have to reach a state of awareness, state of consensus, state of standardization and governance, and then we can distribute the autonomy. Scale does not matter, if it is Google or a startup. I wouldn’t say that it’s only for big organizations.
Martin Reynolds: I think what Google is talking about is really a maturity thing, because if you have good standardization and good hygiene, well-governed pipelines, those can then mature into maybe multi-dimensional pipelines or flexible templates where you can add things in that are specific to a business unit while keeping the overall governed pipeline in place. You can certainly adapt that. If you have the right governance over those pipelines, as in, these things are allowed and these things are not allowed, and you have a way to enforce that, ultimately, you just want to make it easy for the engineers to do the right thing and hard for them to do the wrong thing. Because if you do that, they will generally do the right thing and that plays into the shadow AI type thing too. You make it easy for them to do the right thing and hard for them to do the wrong thing.
How to Safely Deviate from the Golden Path
Renato Losio: How can platform teams enable developers to safely deviate from golden paths? Ran, for example, as you mentioned golden paths before, how can you deviate from it in a safe way?
Ran Isenberg: First of all, they should have a very good excuse or justification and business requirements to move from the golden path, and it happens. It might be performance. It might be other requirements. For example, we use Python. Sometimes we use Golang instead, or even C++. Again, it’s about having the justification and about having the proper security and governance mechanisms, so we can help them understand, ok, we can’t support you at this time, but these are the things that you should do, one, two, three. You should consult with these security architects and these people, so you make sure that you follow the same guidelines or follow the Python implementation, for example, and do the same for your own technology, if you’re using, for example, containers and we’re using serverless, just to guide them as much as possible and make sure that we can have the same governance mechanisms.
Martin Reynolds: I think answering specifically to that question as well, one of the things I would say is teams need a way to approach platform teams to be able to say, this is what I want to do, help me do it, so I’m still sticking to all of those guidelines. I think it’s less about blocking them and more about providing them a way to actually engage and do that. I think some of that kind of stuff you can do with what I was talking about just before by having flexible templates that allow places where teams can insert or change things specifically in specific areas in a governed way. Sometimes it is just, I want to submit this new architecture or this change in architecture, or, I want to be able to have streaming inside my service or whatever it is that might not be in those golden paths right now.
Then actually working with the platform team to deliver that as a, this is what we want to do, here’s the reasons why, like Ran was talking about. This is the value that we’re going to get from doing this. Then it becomes a conversation on, ok, let’s work together to get that in place, because 9 times out of 10 you find that the golden path that you already have already does 99% of what they need, and essentially, you’re then creating a version of that path. It might just then even be an input parameter to that existing golden pipeline, or it might be a new golden pipeline. It actually contains 90% of the same templates, smaller templates that build that up, thinking of it like Lego bricks, you build out those, and the platform engineering teams have those Lego bricks to build out those pipelines.
Garima Bajpai: If you see the last question we had about autonomy and democratization, and how do we build some guardrails which also provide some flexibility to our teams and developers? It’s like a balance. The maturity of Google has come into play here, why they are doing it, why they are democratizing it, because they want people to be accountable for their own decisions to a certain extent, making an oversight of the governance and the guardrails.
In the longer run, I think we’ll have to be very cautious, because all these kinds of flexible exceptions build technical debt. There has to be a balance of how much we can build leverage and let the amplification happen when it comes to non-standardization and exceptions, or going in a different direction in the namesake of innovation. There is a balance. I’m not saying that we don’t allow the deviation from the golden path, but I think once you understand where the autonomy lies, and how you distribute or democratize that, I think people will be responsible and accountable to a certain extent.
Renato Losio: I was wondering if it’s still the same in the space of regulated industries, I was thinking the banking sector, whatever, if you can still deviate from the golden path in an easy way, or how do you deal in those areas, Stephane?
Stephane Di Cesare: Very often when this occurs, I find that when a team wants to do something differently, in many instances they have a reason and they have also some skill. Then what you can do is, you can actually take ownership about that way to do things, and you can contribute yourself. Then as the platform you can follow it up, so that you know that this kind of issue, it’s not in the scope of the platform, but there is that team that knows how to do it, so that you can also follow up.
If you can see that the use case comes back several times, then you can start thinking about the contribution model that, we see your use case, it’s actually used very often, so we can now look at integrating it back in the platform. I think what’s important is to follow up these kinds of cases, to know that when you have this specific use case, there is actually this team, they know it well. I think with AI it happens quite a lot at the moment, that we have some teams who are really skilled in AI. We know that they have specific use cases, and they’re actually good at that. I think in the long term, what shows the maturity of a platform is when these use cases become more commonplace, that you can then bring everything back in the platform in the long term.
Ran Isenberg: I completely agree with Stephane. I think that also golden paths, they need to evolve over time, otherwise they don’t become so much golden path anymore, they become very legacy-like. The contribution model is also very important. I think that it also helps to relieve the pressure from the platform team, so we advocate for an open-source model, where we can say, we can’t build this for you right now, but we’d love to have this option in our templates, or in our blueprints, or whatever. Why don’t you build it, and you contribute it, and once you contribute it, we’ll basically manage it and maintain it. That’s also an option where there’s a handover at some point.
Incrementally Increasing Developer Velocity
Renato Losio: Martin, as you mentioned before, making life easier for developers, I was wondering if there’s one thing you see really helps developers to move faster, without, of course, adding risk and chaos to the development team.
Martin Reynolds: One thing that helps them move faster? I see it as an incremental thing. There are a hundred things that help them move faster. If I’m looking at it, and I was coming into a new organization, and I wanted to be impactful, I’d be looking at the thing that causes them the most friction. Take whatever causes them the most friction, and remove it. When I say remove it, that might be automated, or make it self-service somehow, if it’s something that’s like a manual approval, or requires a ticket. Just make that one hard thing easier for them, and then the next day they will feel better, and their lives will be a little bit easier, and they’ll have a little bit less stress.
Then find the next one, and then find the next one, and then find the next one. I don’t think there’s an easy answer that says, you can do this in every organization, and it will just make it better for the engineers. You have to at least spend the time to understand what are the biggest friction points for those engineers, and then take that away. Take that away from them so that that reduces their stress, reduces their cognitive load, makes their life a little bit easier.
Even if it just frees up 25, 30 minutes of their day, by taking that away, that cascades, and those small changes, that Kaizen approach of small incremental changes make a big impact. That is truly what delivering great developer experience looks like, ultimately. You can have big buck projects, but if you’re making those small incremental changes that are making life a little bit better every single day, that’s what will have the biggest impact. That’s what will make your engineers want to stay working where they work. It’ll make them more innovative, and probably more invested in the work that they’re doing, because they can see the change.
The Role of Platform Architects in Designing DevOps Practices
Renato Losio: What is the role of platform architects in designing DevOps practices?
Garima Bajpai: I will start with one statement, which is a follow-through of what Martin has said, be it platform engineering, be it DevOps, technology itself doesn’t solve any problem by itself. It’s the people, 70, 20, and 10 rule. Seventy percent of all the problems we see around us is how we interact, and how people interactions work in an organization. What is the culture of the organization? If you think about a platform architect and DevOps practices, I think if you foster that collaboration between these two groups or two segments, I think that would be the first starting point.
Then, 20% of technology, so try to find out the technology gap. It’s the S-curve of technology. Some of the technologies which are maturing as we speak, like we have spoken about AI-native software, for example, we also have spoken about multi-cloud environments and all those things. There’s a lot of change happening in how we build platforms, and what kind of tooling is required there? This S-curve of technology, which is basically some of the technology components are not at scale used by DevOps practitioners. How do platform engineering architects have the discussions and the communications to say, this is a technology which is mature enough to be put into the platform, and we scale it, and this is a good opportunity to automate the workflow and integrate the workflow.
These are the decisions which you can take as a platform architect with your DevOps practitioners or DevOps practices which you have. Another example is CI/CD, for example. What you see in the platform has a lot of data. You have observability. You have a lot of insights into how practitioners are using this platform. You can actually give that feedback to the DevOps practitioners. It’s more insightful from a platform perspective to bring those feedback loops into the DevOps practices.
Resource Recommendations
Renato Losio: If you can share one example of a paper, a book, a presentation about, of course, today’s topic that you think every developer should not miss, should take a look at.
Ran Isenberg: At AWS re:Invent, I’m actually giving a talk about scaling serverless with platform engineering and how we used blueprints at CyberArk. Basically, I tell our platform engineering journey, what we built, how we build it, and how faster our developers can deliver value. The session number is CNS361. I speak with Anton Aleksandrov from AWS.
Stephane Di Cesare: There are many things I’m thinking about, but I have in mind, I recently listened to a very interesting presentation in FastFlowConf, which was by Toli Apostolidis, which was a really good introduction to platform engineering and also mentions what are the important points to pay attention to when you develop a platform.
Martin Reynolds: It is a specific platform engineering. One of my favorite books and it’s helped me multiple times in my career is “Team Topologies” by Matthew Skelton and Manuel Pais. It is just a great book for understanding cognitive load and how to manage that, and how to pull that together. Then, if I’m being very specific around what we’re doing here, it’s not a book, but I would definitely read the DORA State of DevOps Report. It really helps you understand where the market is, what the trends are, maybe what good looks like. That would be very high on my list. Just because I’m from Harness, we actually have a book on how to improve your developer experience that you can download for free.
Garima Bajpai: From platform engineering perspective, there is a very interesting book by Gautham Pallapa and Mark. It’s from Packt Publisher, so I would highly recommend this. I would definitely recommend that book for platform practitioners.
Best Practices to Foster Better Team Collaboration
Renato Losio: Name a few best practices to foster better collaboration between development team, platform DevOps, and operation teams across teams.
Martin Reynolds: I don’t think it’s any different for those teams than just fostering better collaboration across any teams. The reality is that they need to talk to each other. I would add a whole bunch of other teams into there. I saw a talk years ago at O’Reilly Velocity Conference, which was a very early DevOps conference, and somebody put this slide up that basically had like dev, sec, prod, blah, blah, blah, ops. Because the whole point was that you need collaboration across all those teams. You need to be talking to each other. You need to break down those silos.
The only way to do that is just by directly engaging and almost by making virtual teams for cross-cutting projects, so those people actually get to know each other, talk to each other, solve problems together. That goes from everything from the finance team to the security team, to the operations team, to the infrastructure, to the product teams. It needs to be an ongoing conversation, not a, I’m making this decision for you.
Renato Losio: Any recommendation on the FinOps perspective? I think Stephane mentioned of course before when he mentioned how to address the topic of cost reduction. I don’t know if you have any advice.
Stephane Di Cesare: What’s important is to make the purpose, the value, and the challenges of your team as visible as possible so that the others can understand it. This could be through metrics, but also what your vision is, what do you want to achieve, things like that. What are you struggling with? The more the others know about that, the better they are going to be able to collaborate with you. About the metrics, about TCO, ROI, so unfortunately, we don’t have the silver bullet yet. We’re going in that direction. You have to focus on some specific outcomes you want to reach, and how you can find the best metrics to measure them.
Ran Isenberg: For us, it’s about understanding first where you’re bleeding money, like where do you want to shift your focus. To basically investigate where you can reduce the cost. Then you tackle that in a platform way. Maybe it’s a login configuration. Maybe I’m overspending on some scaling that I’m doing too much, so I can build a blueprint for this unit so it doesn’t scale too much, or it knows how to scale down when needed. Maybe it’s login configurations. Maybe it’s firewall rules. It can be all sorts of things, but you need to first investigate where you’re wasting a lot of money, and then try to investigate and see how you can uniform that, and make the best practice, and share it through the platform engineering utilities, libraries, blueprints, templates, whatever.
See more presentations with transcripts
