Beyond Platform Engineering
co-written with Renata Rocha
The Elephant in the Room
First off, thank to for not running away screaming after seeing the title of this blog post, because let’s face it: our industry loves buzzwords. We have many colleagues who, after surviving so-called “DevOps transformations”, cringed when “SRE” and “Platform Engineering” became popular terms. Especially when many organizations took that as a prompt to rebrand existing ops teams as SRE teams or Platform Engineering teams. And let’s not forget the companies out there who jump on these buzzword bandwagons and try to shove DevOps, SRE, and Platform Engineering products in our faces. Like we don’t have enough tools to worry about, amirite?
And aren’t these just all different ways of saying the same thing anyway?
We’re here to tell you that there is a difference, and that there is a method to our madness. To illustrate our point, we’ll take you on a little journey through time. So sit back, relax, and enjoy the show.
In The Before Times
In the beginning, managing a bunch of computers before the Cloud was no walk in the park, because:
- We used to telnet to computers. Do y’all remember that? We sure do! That was SO.NOT.SAFE.
- Computers were huge. About 20 or 30 years back, computers used to be quite large. Maybe not as large as the original computers that used to take up a whole room, but still large.
- Computers were L33T. The Matrix and Hackers did a great job of making sysadmins look suuuper cool!
- Processing power took time and $$$. We really take for granted that compute power is much less expensive than it was a couple of decades back. Consider this: our smartphones have more processing power than the computers that sent humans to the moon in 1969.
- Skilled professionals had a hard time managing so many computers at a time. We definitely didn’t have the nice management consoles that we have nowadays.
- We literally had servers at our feet. Yup, the servers we managed sat right under our desks.
- We had a direct connection between human and machine. Okay, maybe not direct like Neo plugging into the Matrix, but sysadmins were definitely fine-tuned to a server’s moods.
But, as we said, managing a fleet of servers was not something that a single human or even a small group of humans could easily do at that time.
Add to that the fact that technology doesn’t seem to like to stand still. The internet became a thing. And as the internet became more popular, we ended up with online stores, social media, and online games. Which meant that we needed more computing power. This meant that the way in which we architected our systems also changed. We ditched our monoliths in favour of micro-services. Which meant…more complexity!
What was a sysadmin to do?!
Lucky for us, the Cloud came to our rescue!
All of a sudden:
- We found ourselves with tons of computing power at our fingertips!
- Everyone could have tons of servers!
- We were able spin up servers in minutes!
With the advent of more complex technology and infrastructure, we needed a way to manage it all. And so, we were blessed with the lovely gifts of DevOps, SRE, and Platform Engineering to help us out.
In the Now-ish Times
While there are many different interpretations and definitions of of DevOps, Site Reliability Engineering (SRE), and Platform Engineering, we see these as an evolution in how we think about and deliver software, with everything rooted in DevOps. And with that in mind, let’s do a bit of level-setting and define these terms.
DevOps gives us the fundamental principles of collaboration, Codify All The Things™, Automate All The Things™, and rapid feedback loops.
Site Reliability Engineering (SRE) applies DevOps principles, with a focus on customer impact and reliability.
Platform Engineering is an extension of SRE. While SRE focuses on external customers, platform engineering takes things a step further and also focuses on internal customers — that is, developers.
It’s only natural then, that if Platform Engineering is the next step in the evolution of DevOps, we would expect something to come after Platform Engineering.
But what would that “next thing” be?
The Future Times
Looking to the past for inspiration
In order to answer that question, we can turn to the past for some inspiration!
First off, we can turn to DevOps itself, for inspiration. After all, we know that whatever follows Platform Engineering should be anchored in the principles of DevOps, since it’s derived from SRE, which itself is the root of Platform Engineering. This includes all the DevOps-y goodies like fast feedback loops, collaboration, automation, and codifying all the things.
In addition, we can turn to some vendors for inspiration. For example, HashiCorp has a product called The Infrastructure Cloud. According to HashiCorp:
“The Infrastructure Cloud isn’t a new product. Instead, it’s a new way for the HashiCorp products to deliver value more quickly via the HashiCorp Cloud Platform (HCP), a unified SaaS platform for infrastructure and security lifecycle management.”
So basically it’s essentially a repackaging of existing components to provide a unified SaaS experience for infrastructure management and security.
We can also look at on-premise (data centers) virtualization. Being on-premise gives us that added security from managing our own infrastructure. It also gives us back that human-machine connection from The Good Old Days™, while leveraging the power of virtual servers. It’s where it all began, and it’s not going away quite so easily.
Looking to the future for inspiration
We can turn to the future for inspiration. While we don’t know what the future holds, we have a pretty good idea of where things are headed.
First off, we don’t have to be bound by just cloud or just on-premise. (What? Didn’t we just talk about this? 😜) In the past, we were forced to be on-premise, then we felt that the Cloud was our only option. Now we have reached a point where we have choices, and we can choose the options that best suit our needs, with combinations on-premise and Cloud to make a solution that best suits our organization’s needs.
Secondly, we know that Observability will be a big part of this as-yet-unnamed Platform Engineering Successor. Technology is only getting more and more complex, and having insight into your pipelines, infrastructure, and software results in better reliability overall.
And finally, there’s our good old friend, AI. Ah…AI…that thing we love to hate and hate to love. We simply can’t ignore the fact that AI will have some sort of influence on things. And while we don’t see AI as taking over our Platform Engineering Successor, we do see AI having a huge role in being an assistive technology. AI is great at parsing through tons of data and identifying trends, so why not use it nudge human operators in the right direction? Ultimately, however, it’s still up to the human operator to decide what to do with that information.
What’ll it be?
With all that in mind, then, our new Platform Engineering successor should basically be: more of the same, but with a little extra!
That is we want to continue seeing more of…
- Basic DevOps principles: Codifying All The Things, continuous collaboration, continuous testing
- Security, especially around policy-as-code. That way, we can ensure that we keep the security folks happy, while not having to deal with annoying security-related bottlenecks
- Continued fast feedback loops by baking Observability into our pipelines and our SDLC
- Better integration. Sure, things typically play nice with each other, to a certain extent, but we have to stitch things together. Wouldn’t it be nice if we could use pre-packaged “cookbooks” to deal with common patterns/use cases/automations?
- AI as a companion or co-pilot.
But don’t just take our word for it. Check out the following shorts featuring Kelsey Hightower and Charity Majors on Geeking Out Podcast:
What shall we name our creation?
So now that we know what we want our new Platform Engineering Successor to look like, it needs a name.
Some of the options we came up with were a combination of really cringe suggestions from ChatGPT, our own ideas, and ideas from the community:
- DeltaOps: In the spirit of embracing change, delta seems pretty fitting.
- NextOps: The next thing to come after Platform Engineering, so why not literally the next thing?
- Synergeneering: Thanks, ChatGPT
- FuturEngineering: Thanks again, ChatGPT
- Cloud Gardener: This was a community suggestion from a poll that Adriana ran on LinkedIn, and definitely a personal favourite of ours
Synergeneering and FuturEngineering definitely sound like something a consulting company would want to sell to its clients. Just you wait. Give it a year. We both used to work in consulting, so this would not be outside the realm of possible. 😜
When we ran the poll at our DevOps Days Montreal talk on May 28th, 2024, the people voted for…
Yup, Cloud Gardener! So maybe we’ll see you at Cloud Garderner Con in 2025?
Wrap-up Times
Before we wrap things up, we want to make one thing super clear. Our goal is not to force a new term on anyone. Instead, we want to acknowledge the fact that technology is changing, and that this Platform Engineering Successor is happening whether we like it or not.
All we’re doing is collecting and sharing information from what is already happening. From what you are already doing. Technology is fast, dynamic, and we are constantly iterating on it, and we need to embrace the change in order to keep up.
And as we learned from Battlestar Galactica: This has all happened before. This will all happen again.
Until next time, peace, love, and code. ✌️💜👩💻
Originally published at https://geekingoutpodcast.substack.com.
