This message was deleted.

check number 3 here for a relevant diagram https://www.getport.io/blog/guide-to-internal-developer-portals

I'd argue that "dumb" is an over simplification. They should understand the platform at a bird's eye view, otherwise you get too much of the "works on my machine" syndrome. Software works very differently at scale, but you are right developers shouldn't be developing the app or vice versa and don't need to know the minutia. However principles/architects on both sides should have a deeper understanding of the boundaries to ensure issues in production can be handled appropriately

I pretty much agree with John, for a larger org, your devs need to focus on building world class apps, as others have said, being dumb to the infrastructure isn't ideal, even though your platform is self service, your devs still need an understanding of what your IDP is doing. You dont want your devs picking cloud services "a la carte" as it costs too much, thats why your IDP has the golden paths built in. Your IDP will obviously be delivering services in a way that makes sense but your devs need to know whats going on. Making an IDP "blackbox" is a bad idea.

I had someone on Twitter accuse me of not understanding DevOps, when I said, devs working on infra should only work on infra and devs working on applications, should only work on applications. And DevOps entails both of these types of devs. Dev = application devs Ops= infra devs The Ops team's role encompasses the dev team's role. And, theoretically, we could argue about semantics, but that is how I see the roles with this image:

@Kyle Campbell "Dumb" may be a bit of a strong word, and I'm not against a developer having some understanding of platform functionality, but I am against the needing to understand it to do their job. My goal when helping a company develop or tune a platform is to reduce developer overhead and improve business value. It is possible that a company is at a platform development stage where operational things like, for example, VM type are indeed in the control of the developers, but ultimately, this is just a symptom of a platform that has not been refined to the point where VM size selection has been automated. Devs should focus on building the customer facing functionality of the application and ideally not need to think about " will it run, scale, be resilient?" For operations, the customer is the developer (and yes also the software user by extension). There should be a constant dialogue between developers and operations to understand requirements, but being able to then automate processes to meet those requirements will ultimately provide maximum business value.

I slightly disagree...I think? DevOps is the whole process of application development and delivery. It is always there. There are two clear roles within the process. The application dev and the infra/ automation dev/ admin. When the team is small, a single dev might work both roles and he'd be called a DevOps engineer. When the team gets bigger, the split between the roles should be more and more predominant and you'd only have Ops engineers (whereas one could argue their name is DevOps here too, since their work envelops the other's) and application engineers. I think in the end, we would agree on that overall? 😁

Having worked at both the very large org scale and very small org scale, I guess I still disagree somewhat with this statement. “Devs should focus on building the customer facing functionality of the application and ideally not need to think about ” will it run, scale, be resilient?” This falls back into the old IT model of devs build software and throw it over the wall at IT folk. I feel it’s not possible to build good software without understanding the concepts of run/scale/resiliency. They don’t need to know the details, but devs do need to know the concepts, otherwise they will unintentionally introduce very inefficient things that may require really expensive ops solutions, when a change in code may have saved that. Likewise, software shouldn’t be a total black box to ops, they should have some idea of what it’s doing under the covers

Ironically enough, when the DevOps roles are definitely split between different teams, and "the devs" are given a consistent workflow to develop apps and/or services with, the Ops devs, the ones responsible for that workflow, could be called "Platform Engineers". 😛 😄

@Kyle Campbell I generally agree with you at least when dealing with more traditional development models. Applications running on bare metal or VMs, where dependencies were not canonically defined could cause problems when developers threw their apps over the proverbial dev to ops wall. Containerization has changed that. A container that works on a developers laptop should work in production. If it does not there is a fundamental flaw in the development platform. A properly implemented cloud platform should provide appropriate resources for developers to run their apps and have equivalent behavior in dev/test/prod. This is not to say there might be limitations that a developer discovers and needs the platform team to implement, but it should not be the developer's problem to fix it.

Oh no, I didn't mean the developer should fix it. It is the platform team's responsibility, they own that code, but devs do have accountability in understanding what happens when things go into production And, I'd generally agree with true microservices generally the same container runs the same in dev/test/prod. The challenges I hit daily and colour my opinion are A) developers not adding proper telemetry or logging into their code, either too little or too noisy. These don't bother a developer on their machine but cause me huge headaches B) Understanding where bottlenecks/root cause of failures can be hard to figure out with a complex mesh of microservices all talking to each other. This one in particular requires both ops and dev to solve usually, and can be hard for ops to understand new issues as the relations between services can change frequently C) I've never been lucky enough to have a truly clean perfectly architected microservice environment. There's always legacy monoliths running on VMs somewhere intertwined into the newer stuff or "megaservices", which are containerized mini monoliths that do too much. Megaservices usually started out as microservices but kind of grew and became ungainly over time

In certain organization size, R&D groups have the requirement to hold Operational knowledge. SRE representatives that handle ops work and have it related to group daily work. Most of the developers can be the ones focusing on code ("dumb") while other group members are responsible to performance, resiliency, architecture and generic operational work. When it comes to large scale organizations, Platform teams are responsible not to the actual infrastructure, but to enable infrastructure usage and provisioning. Looking at the Day 0-1-2 operational requirements - R&D are responsible for Day 0 and Day 1 operations while Platform are responsible to Day 2 operations (hopefully with automation). The way that I envision Platform in large scale organizations is Platform write the tools (e.g. a tool like Terraform with DSL) while the R&D is doing the dev-ops part by declaring their infrastructure requirements. It's an evolution of tooling and required knowledge. In the early days, EC2 was considered developer friendly, while today the entire stack is abstracted up to Fargate. Who knows what will be next? 🤓