Disclaimer

My articles are targeting organizations that are far bigger than one development team. While the concepts are still valuable, if you’re in an organization that is small - there are probably far better and simpler solutions to your problem.

If you want to know what are they - reach out, let’s chat.

Intro

Charity Majors, apart from other great speakers spoke at the PlatformCon 2023 in June this year and she said a lot of things that were funny (in a good way), here’s one of them:

But even more so things that made me think and review how I thought about things. name of this article comes from realizing that things people that want to make organizations productive fight for are the way the first programmers used to work.

Developers Should run Their Code

Developers used to write their code and, as you may have guessed, deploy it. However, the complexity back then, including abstractions and business criticality, was not even close to what we face in our day and age. Everyone used to have a server or two, and there were no regulations preventing you from editing the code on the production server to fix a bug (only to unintentionally introduce three more). This occasionally resulted in the production system going down.

We have come a long way, but the core concept remains the same: the programming "grandpas" used to take ownership of their code, and modern development organizations should do the same.

In the utopian world that I, for one, advocate for everywhere I go, anyone within the R&D department should understand how different services operate and communicate, and they should be able to contribute to the code if necessary.

If you are not at the beginning of your IT journey, you should strive to become a T-shaped engineer—one who is a Subject Matter Expert in certain subjects but possesses a good enough understanding of how other parts of the industry work.

Platform Team is here to enable you

As I mentioned in the previous section, the complexity of owning one's code has increased with technological advancements. This is where Platform Engineering steps in to ease the load.

The Platform team acts as an enabler, relieving developers of cognitive load and offering simplified interfaces for tasks that developers typically disregard. A case in point is observability. Regardless of the standards, middleware, or a very knotty solution of cloud functions, bash scripts, and microservice spaghetti, that allstar engineer who left implemented 2 years ago, you employ to deliver logs to a logging backend. What developers need at the end of the day is a layer that allows them to deliver logs in order to provide visibility of the operation of their software and troubleshoot when issues arise.

Taking into account that Many companies undergo at least one major transition from solution x to solution y every one to two years for various reasons, such as pricing or licensing. I'd even suggest eliminating the practice of using product-specific endpoints in favor of more generic solution-oriented URLs. Rather than grafana.yourcompany.com, consider observe.yourcompany.com as the URL for your chosen dashboarding product. Instead of jaeger.yourcompany.com, use trace.yourcompany.com, and so on. The same principle applies to the cloud services your company employs. Most developers, except the exceptionally curious ones, are less interested in the intricate infrastructure running on GCP, Azure, or Alibaba Cloud. Their primary concern is writing code and implementing business logic. And your primary goal is to make their work as seamless, fast and secure as possible.

Create interfaces for your intricate infrastructure that are intuitive from the outset. Provide documentation on what the interface uses behind the scenes for those curious developers or times when additional functionality is required.

With great simplicity though, comes great cost management. Developers should be conscious of the costs of the resources they deploy. This brings us to FinOps - the practice of financial operations in cloud computing that aims to bring financial accountability to the variable spend model of cloud. Every team should take responsibility for the resources they utilize under the FinOps model.

When developers own the code they write, they gain a better understanding of how the system operates. Similarly, when they are financially responsible for what they run, they learn how to optimise application performance and costs. With the help from Subject Matter Experts, of course. This dual ownership can lead to more efficient utilization of resources and improved bottom lines. Overall, it encourages a culture of cost awareness and accountability among developers and other teams.

Don't Enforce, Enable

After creating the interfaces I mentioned in the previous section, you shouldn't enforce them merely for the sake of enforcement. Instead, treat your colleagues as internal customers. For them to use your product, it has to be good. Offer a product that will make their lives easier, instead of requiring them to use something you created just because your team lead or CTO read an article on Platform Engineering.

Consider implementing different levels of abstraction for the product you offer to your developer teams. They can choose a ready solution, adopt part of your solution as a baseline and adjust it according to their needs, or in exceptional cases—and by exceptional, I mean rare circumstances, not that one special team that always has unique needs—ask you to create a tailored solution just for them.

Let's illustrate this with some examples based on a Kubernetes use case:

Ready solution: A generic chart for a backend application that includes a set of the most common optional features such as a database, event processing software used within your company, a log backend, and others. You apply best practices, abstract away the communication details between the services, and expose a subset of useful parameters for developers to utilize. This path should entail the least resistance.

Part of the solution: A generic manifest for something you use internally, like a Kubernetes deployment, a configured ingress where developers only need to provide a domain, or a database chart with sensible defaults. These components should not be integrated with each other; they should be blocks that anyone can build upon to achieve their specific needs.

Tailored solution: Built from scratch. This should rarely occur; it's preferable to dedicate time to refactor the workloads of this team to comply with one of the previous categories.

As an enabler, you should always be open to suggestions from your clients and stakeholders within the company. Collaborate with your developer organization to make everyone's life easier and reduce the time teams spend on re-writing the same code for problems that can be globally solved. Avoid boxing them into your solutions, as these might become obsolete over time. As I heard in a talk somewhere, provide golden paths, not golden cages.

If You've Made It Here, Take Away These Things

Avoid over-engineering; simplicity is key. Create molds for the most common use cases. Develop portals for workloads handled not only by technical people—featuring bright buttons to make everything work again. Create CLIs with a simple command syntax, enabling developers to deploy what they need, when they need it. Remember, you're all in this together, not against each other.

DevOps is everything you do to overcome the friction between silos. All the rest is plain engineering. Patrick Debois