Hey you, wonderful Earthling!
I hope you are well, and in good health, and spirits.
This story started about 20 months ago, when I started a role as a Platform Engineer 🌱
I was very curious about Platform Engineering, and Engineering Experience specifically, so thanks to the support and encouragement of friends and colleagues, I applied to a Platform Engineering role, a role that I had not formally held before.
It was a new adventure, and in the beginning it felt as if I was navigating an asteroid field … I was not sure how to describe my role: was it DevOps? was it Software Engineering? I had to learn Golang, Bash, Kubernetes, Docker, Microservices Architecture, Helm, Terraform, and TypeScript with some sprinkles of React 😳 While it was not easy, I was fortunate and privileged to have the time and support I needed to learn, and grow 💚
In times of doubt, and self-doubt, I kept going ✨
There is a time for any fledgling artist where one’s taste exceeds one’s abilities. The only way to get through this period is to make things anyway. (Zevin, Gabrielle. Tomorrow, and Tomorrow, and Tomorrow. Chatto & Windus, 2022, p. 68)
… sometimes, trying not to think about the odds …
And so the intention of these humble written words, is that they help you navigate the Platform Engineering field, and hopefully they give you some pointers on how to get started, and provide you some inspiration to create your own journey 🌱
Being a Mandalorian is not just learning about how to fight, you also have to know how to navigate the galaxy, because you never know where you might be headed next. (Din Djarin to Grogu. The Mandalorian. S3.Ep1: Chapter 17: The Apostate.)
Defining the role
The first thing that was very difficult for me was defining the role of Platform Engineer, and honestly after 20 months, I still find it difficult.
I have joined talks, conferences, taken courses, read books and articles(see below 😊) and with that, and having officially held the role for 20 months, today I find that different organizations have their own flavor to what Platform Engineering means.
What it means may depend on: the business, the ecosystem of the organization and its size, the experience and backgrounds of the people in the organization, and more. What organizations may have in common, though, is the Problem domain.
Problem domain
What I consider fundamental is the problem domain of Platform Engineering, which I understand as:
In the context of a software product, the challenges that an organization has to deliver value effectively. Including: Development and Implementation, Testing and Integration, Deployment, and Operation & Maintenance.
Within this problem domain, a Platform Engineering team would use the technology that they consider to best fit the problems within this domain. And so the technology stack can be as broad as the team, and you as a member of the team make it. For me, the technology domain is the broadest I’ve experienced so far: from bash’ing my way around infrastructure code, to styling React components 💐
Learning
Now, let’s talk about some resources that helped me understand better the Platform field. Hopefully, among these, you will find some that serve you in your own path 🌟
Books
- Accelerate: Building and Scaling High Performing Technology Organizations: As mentioned before, something that I consider important to navigate the Platform field is to understand the problem domain, and I believe that this book provides a nice scenic view of the kinds of challenges that are related to software delivery, so connected to some of the problems that a Platform Engineering would find solutions for.
Courses
- Platform as a Product @ Team Topologies Academy: As a Software Engineer with a background in product teams I found this course very interesting, and hope to see an increased integration of product techniques into the ways of working of platform teams.
Communities
- https://platformengineering.org/ - This community helped me feel less alone in the platform field, as I found that I was not the only one facing similar challenges. The articles and talks shared via this community were a source of inspiration for solutions, and ideas.
- https://www.honeycomb.io/hny-events/ - Very interesting demos and live events related to observability and operations.
Talks
If talks are your cup of tea, I would recommend the following two talks:
- Platform Engineering as a (Community) Service • Nicki Watt • GOTO 2021
- From Kubernetes to PaaS to Developer Control Planes - Daniel Bryant, Ambassador Labs
Podcast Episodes
If you are more into podcasts, while making your cup of tea in the morning, or going for a long walk … the Livin’ On the Edge Podcast by Ambassador Labs is great 💜 below are some of the episodes that I’ve heard (so far) and enjoyed:
- Dave Sudia on Kubernetes Local Dev, Building a PaaS, and Platform Personas
- Gene Kim on Developer Productivity, the “Five Ideals”, and Platforms
- Nic Jackson Discusses Cloud Native Platforms and Developer Tooling
Blog Posts
Do you prefer to read blog posts? Below is a list of blog posts I’ve read and that I liked (they are ordered by their time of publication, to provide time context):
-
2012:
-
2017:
-
2018:
-
2020:
-
2021:
-
2022:
- https://blog.getambassador.io/is-platform-engineering-the-new-devops-or-sre-472ed97a1885
- https://loft.sh/blog/platform-engineering-the-definitive-guide/
- https://www.contino.io/insights/platform-engineering
- https://www.honeycomb.io/blog/future-ops-platform-engineering
- https://thenewstack.io/what-we-learned-from-enabling-developer-self-service/
- https://www.honeycomb.io/blog/building-platform-team
- https://thenewstack.io/collaborating-with-internal-dev-experience-and-tool-teams/
- https://thenewstack.io/building-an-internal-developer-platform-isnt-just-about-tools/
-
2023:
Authors
From the Blog Posts and articles I’ve read on the topic, I enjoyed the ones written by the following authors:
Open recurrent questions
A couple of open recurrent questions I found in the Platform Engineering space. I would be very happy to discuss these questions further over a good cup of tea 🫖
Do we go self-service? And what level of self-service?
“A good deal of the job is ultimately about finding the right balances between standardization and autonomy.” (From: Talk write-up: “How to build a PaaS for 1500 engineers”)
On this topic, I found the concept of Transparent Abstractions: “You can use it or you can circumvent it.” - as described by Humanitec in this video (1m40s) - very interesting.
Do we build it ourselves or do we buy it?
Do we build our own solution for problem X or do we buy an existing solution?
In the end it may “all be about the glue”, as described in Talk write-up: “How to build a PaaS for 1500 engineers”.
Closing Notes
I want to close with a note for those interested in giving Platform Engineering a try.
If this is you … my invitation is to take a look into the problem domain for Platform Engineering and to take the time (if this is available to you) to think if this is a domain that you would be interested in, or want to learn more about. The why and the problem domain can become a huge driver to learn the how, that is the technology and ways of working that would be used and needed in the organization you are going to join.
Then, I invite you to take a look into the DevOps Topologies website and read about the different topologies that may drive the team structures in an organization, keep them in mind, when you do your interviews, and ask questions about the team structure in your interviews. This could give you a sense of the culture in the organization and of the ways that you would be interacting with your (internal) customers.
With this, I hope this humble words help you in your journey navigating the Platform Engineering field ☄️
I am thankful to everyone who supported me in this journey, you know who you are 💕
As always, may the Force be with you! ✨