This is the written version of my youtube video ✍️ 🙂
Introduction
In this blog article we're going to talk about a relatively new hot topic in DevOps and Cloud space, which is “Platform Engineering”.
There is a lot of discussion going on, where some people are asking whether platform engineering replaces DevOps. Many people say it goes hand in hand and is rather an addition to DevOps, but in reality it's a bit more complicated than that. Platform engineering actually changes a lot of established rules we knew about DevOps, SRE and Cloud engineering, it changes the game and introduces some new rules. 💡
So let's clearly define, what platform engineering exactly is, more interestingly, why was there even a need for this new role and how it evolved and of course how it compares to DevOps and cloud engineering and does it really replace any of these roles? 🤔
✔ Topics of this blog article
Why Platform Engineering? Issue in traditional and DevOps teams
Standardize usage of tools
Non-functional requirements
What Platform Engineering is responsible for?
How Platform Engineering works? Internal Developer Platform (IDP)
How it looks in real-world?
Flexibility with Infrastructure as Code
How to implement an IDP successfully
Platform Engineering vs DevOps
Platform vs Cloud Engineer
Why Platform Engineering?
Whenever a new role or concept appears, the first question should always be: Why was there a need for it? Because there must be a problem behind, that couldn't be solved with existing solutions and naturally caused the evolution of this role. So let's talk about these problems that led to emerging platform engineering as a solution.
Issue in traditional Development and Operations teams 🐌
Initially we had developers and operations working in separate teams and developers were responsible for programming the application. And when ready, they would throw the packaged application over to operations, who was responsible for deploying and running that application.
So while you had a dedicated operations team with expertise to properly manage the infrastructure or operate company-wide CI/CD platform for example or other platforms for the application teams, this was an inflexible and slow process:
❌ Developers waiting on operations, when they needed any change in infrastructure or needed any infrastructure resources like additional servers or Jenkins pipeline for their applications
❌ Or on the other side operations team waiting on developers to fix something in the application that affected the deployment or application runtime etc.
So when DevOps was introduced it united those teams removing the inflexible and limiting process.
Issue in DevOps teams 🤯
DevOps removed the communication challenges and knowledge silos between these two parts, developing application and running and operating the application. So this was a huge improvement to the traditional way of working. ✅
This led to one DevOps team that now owns the application as well as the underlying runtime and infrastructure. So basically the application itself and everything the application needs to run:
This is way more flexible, fast and just a cool way of working for the engineers. 😎
But with lots of options and ownership comes a lot of responsibility and cognitive load. Now you’re having one DevOps team, everyone developing the application and running the entire stack under the application.
So you have one team where either developers or a dedicated DevOps engineer is setting up:
a CI/CD platform and creating the pipelines
writing Terraform scripts for infrastructures code
spinning up Kubernetes clusters
configuring the cluster with best practices
configuring logging and monitoring
adding security scans
maintaining Helm charts
also maintaining all these infrastructures code scripts as the tools evolve and new versions come out, right?
Managing Docker repositories
And all these in addition to the actual application development 🙉 This is why we are even doing all these other things.
And this increases the flexibility and speed of work and efficiency, but naturally it also adds tremendous cognitive load on the team, because too many things that just few roles need to be responsible for.
10 other DevOps teams having the same challenges
But it goes even beyond that. Now imagine you have another application team developing a completely different application and they have the same challenges and tasks. So to increase their efficiency a DevOps engineer designs the same CI/CD workflow for the project, sets up cluster, maybe this time a managed EKS service instead of self-managed one, configures all integrations with AWS cloud, configures the storage, adds security scanning steps, monitoring the whole secret management and so on. Maybe they use a different Docker repository like ECR for an easy integration with the EKS cluster.
So they have the same challenges and same needs for their application to run somewhere, so they do all this stuff in their own ways with their own tech stack, right?
And maybe you have 10 more such teams in your organization, now all of them need to figure out all these things for their projects. So you end up with 10 DevOps teams building and operating 10 different platforms to deliver and run their applications, and this can be hugely inefficient 🤦🏼♂️ and wasteful as well as have high cognitive load on individual engineers in those teams.
And with complex systems like Kubernetes, sometimes the part of managing infrastructure becomes more effort than writing application code and producing business logic itself. So you have teams that are too busy building a platform and have less time to build the business value in the applications. 😟
Hard to Scale
Plus you need expertise of so many things within a single team if they have to manage the entire infrastructure stack underneath the application, which means many experienced engineers to add to many teams, which naturally also means higher human resource costs, right?
And finally this becomes hard to scale, because each new project team will have the initial time and effort in setting up the infrastructure before they can even release the application to the end users and very very important point, even though you have these teams managing their own infrastructure and platforms they may actually not have enough expertise to do everything correctly. So you may end up with Kubernetes misconfigurations or lack of monitoring and logging entirely or security issues all over your systems.
Plus when you have one compliance or security team in the whole company and tens of teams with 10 completely different tech stacks and just different different ways of running their applications, it will be pretty hard for them to get insights and help all these teams implement proper security. Because it will be really hard for them to understand what's going on in all these individual projects. So this becomes hard to scale, because we have no standards.
Also when each team uses different tech stack with different configurations this leads to inconsistency across the organization.
And finally I want to mention that the concept of: "you build it, you run it", which we know from the SRE was created back when applications weren't as complex as today and the underlying environment for running the application wasn't as complex either. So in today's highly complex, multi-cloud, multi-cluster or hybrid cloud world with thousands of microservices and hundreds of services for those microservices, it's a bit too much to ask developers to integrate this concept in their work.
Like asking an expert front-end engineer stop your work and focus on properly configuring Kubernetes cluster is not really cool and not the most efficient usage of that engineer's skills.
So to quickly summarize:
➡️ We either have autonomous DevOps teams going wild and doing whatever being fast and flexible, but also leading to too much responsibility on one team with high cognitive load and organization-wide inconsistency.
➡️ Or we have the traditional separate Dev and Ops, where infrastructure is managed and secured but with a painfully slow process that really limits the work of developers.
And that's where Platform Engineering comes in to save the day, but only when implemented correctly! 🤓
So how does platform engineering solve these problems?
Standardize usage of tools
Platform Engineers take the tools that are needed for deploying and running the application and standardize their usage across teams.
So if 10 teams use 10 different CI/CD solutions make a standard CI/CD offering or if every team uses Kubernetes, but in different ways standardize usage of Kubernetes. So basically platform engineers standardize everything that is part of applications non-functional requirements.
Non-Functional Requirements
So what are the things that we need or the so-called "non-functional requirements" of the application? So basically things that are not business logic, but necessary to deliver the application to its end users:
Every application needs a Version Control System
Every application needs CI/CD pipeline
The application needs to run somewhere, like on a runtime environment like Kubernetes
Kubernetes cluster of course needs an underlying infrastructure like AWS Cloud platform or even a multi-cloud platform
The application and the underlying infrastructure also needs logging and monitoring
The application also needs proper security
So as you see there's a lot of things going on that need to be set up for the application to run properly and each of these categories have lots of different tools and technologies, right?
There are loads of CI/CD platforms out there, there are different Cloud platforms and so on.
So platform engineers standardize usage of tools that offer these services for the platform. Now this is a pretty large list of services that platform team takes over.
So does that mean that platform team now becomes completely responsible for all this or what exactly are they taking over? 🤔
Do they create Kubernetes cluster and configure it?
Do they create the whole CI/CD pipeline and manage it for the teams as well as operate these tools or do platform and product teams share the responsibility for those services?
And if so where do we draw the line between those responsibilities?
And that's exactly where it gets interesting and why I mentioned that platform engineering only works if implemented correctly 💪
So let's talk about and really understand what platform engineering is responsible for?
Separation of Responsibilities - What Platform Engineering is responsible for
When we think about the tools that application needs, like GitLab, Kubernetes, Jenkins, Cloud platforms, databases and so on, each of these tools has two sides:
admin side
user side
The admin of the tool sets up and configures the tool, make sure backups are in place, access is secured, they install any needed plugins and so on. So all the things to make the tool ready to be used for the actual task that it's meant for.
So for example Kubernetes cluster needs to be provisioned, network plugin needs to be installed, access and permissions need to be configured for security, load balancer configured for the cluster and a bunch of other stuff to make the cluster ready to be used to deploy applications inside:
So once the admins set up and prepare the tools to be used, the users can come and use the tool for their intention., like application developers access Jenkins and create pipelines for their application.
So you have a role that operates and manages the tool and a role that uses the tool. So these two responsibilities can be easily separated.
2 separate roles - Platform takes over admin side
Now in DevOps teams as I mentioned, you have both of these responsibilities in one self-sufficient team and that means individual application teams can decide how to operate and how to use the tools, but as I mentioned these are two separate set of skills and you actually need separate knowledge base to do each. There are even separate Kubernetes certifications for administering the cluster, which is a "Kubernetes administrator" certificate and deploy into the cluster, which is called "Kubernetes application developer" certificate, because again you have to specifically learn each aspect of the tool.
So in order to standardize the tools across teams, platform engineers need to take over the operation side of these tools, which means selecting the standard tools, setting them up, again one standard way with production and security best practices.
At the same time this is an improvement for the application teams, because it takes the load off the application developers. So at least one part of the services they aren't responsible for anymore. 😌
So less cognitive load and more capacity for creating the business value.
In addition you can use the expertise of your engineers more efficiently, because now instead of needing to have an expert on Kubernetes cluster administration in every team, you can have fewer in platform engineering team, who take over this work for all application teams. Same for CI/CD tools, database administration and so on.
So you basically extract the need of expertise to administer these tools from the application teams. So instead of engineers who kind of half know this in that tool in every team, you have one expert team, who has the expertise to operate these tools properly. ✅ Plus because it's their core responsibility, they also have more time for it, because they don't have an additional stress of having to release new features. ⏰
So this distributes the pressure, responsibility and the need of expertise among multiple application teams and one organization-wide platform team.
And now instead of each team deciding which CI/CD tool to use or which Kubernetes cluster set up to use, platform team offers a ready solution for the application teams.
And instead of each team building their pipeline steps with security scans, platform can standardize that these scans are part of each team's pipeline, like if for example the company has specific regulations for their industry or country these regulation specific scans will be part of every pipeline by default.
But wait! ✋
But wait, didn't we put Dev and Ops together to avoid the siloed teams that have separate responsibilities? 🧐 Because now it sounds like we have a separate platform team that decides which tools are going to be used company-wide and sets up all these tools as they see needed and gives access to those tools to the application teams. Sounds a bit like that traditional approach that we definitely don't want to go back to!
Well, no worries because it continues from here, this is just the baseline 😊
So now how do app teams access these Services?
How Platform Engineering works - Standardizing without creating silos
Obviously it would be no improvement if we went back to the slow inflexible process of developers requesting resources from platform team to give them access to some services.
So how does that work?
Self-Service Platform
1. Platform team takes all these tools like Cloud platform, Kubernetes, databases that application teams need applies their expertise and configures them properly, so they are secure, up to date etc.
2. Then they create an abstraction layer on top with a user-friendly interface like a UI or API, so that application teams can now come and self-service whatever services and tools they need.
Internal Developer Platform (IDP) 🚀
So those provisioned configured secured services with an interface to easily interact and access them to use for the applications, is a "platform" and since developers can just log in and self-service without going to platform team to ask for the resources, it is a "platform as a service" for the internal developer teams or also called an "internal developer platform" or "IDP". 💡
So platform teams are essentially building the IDP or internal developer platform hiding away and abstracting the complexity of operating and managing the services that developers need to release and run their applications. So basically instead of application team logging into an AWS cloud and provisioning EKS cluster they go to the platform or IDP log in to that platform and use the EKS cluster, which is pre-configured with the proper security, backups etc by the platform team within minutes independently without asking platform team for anything.
So application team has the flexibility and speed to access the services for their applications without needing to worry about operating those services 😎
Now let's go into how this all looks like in real world and think about the following actual scenario.
How Platform Engineering looks in real-life
Remember I said platform standardizes the tools that are used across teams instead of five teams using five different CI/CD tools. Now let's imagine platform offers Gitlab CI/CD as a standard solution, but what if application team A says "I want to use Circle CI instead". So basically teams want to have freedom to use new modern cool tools or tools that may fit better to their workflow. Maybe they want to use Argo CD or a specific service mesh for their microservice application.
So it seems like with platform team and the whole standardization we are locking down the selection and saying: "That's what we use in this company and that's it. Everyone abide."
Well of course not. That won't actually be an improvement and will take away a lot of the flexibility and creativity that autonomous DevOps teams have. And the last thing platform engineers want to do is become a blocker and have a weird dynamic with application teams, because that will kind of ruin the whole concept.
Freedom of Choice 👏
So instead of saying you can only use this CI/CD tool or you can only use this cloud platform. The platform team will say "oh you want to use Circle CI instead? Okay we will help you set it up and configure it with best practices". And once they do that, they can now integrate it in the platform and offer it to other teams as well, who may also benefit from using Circle CI in their workflows.
And this way, when new services are added to the platform instead of limiting application teams to only use the CI/CD tool or this Docker registry and so on, you are saying you can use any of these registries or CI/CD tools or any services that we offer as part of our platform, because then we know that they are all properly configured and operated in the background and with time the platform may add more such tools that application teams can select from.
Now again in real life there could be cases, where one specific tool may only be needed in one team in which case, platform team can decide that that application teams stays the owner of that team specific tool and they can operate it themselves instead of integrating it into the platform or the IDP.
Avoiding old way of working ⚠️
So in no case platform engineering should be mixed up with the old way of working, where the infrastructure or operations team analyzes several tools for security compliance etc decides on one correct way of using that specific tool and lock this down and say to the developers this is the only way you can use this tool and that's it, because we already did our analysis and that's the way to go.
So when implementing platform engineer team in your company you want to keep the platform flexible, while adding guard rails and pre-configurations to ensure security consistency, proper configuration and so on.
So it's important to understand that platform engineering is a step forward from DevOps not a step backwards with Dev and Ops separated again.
But I have to say in reality I think if people don't understand the concept of platform engineering properly, there is a risk of it drifting towards the step backwards and I talked about the right approach, but later in this blog I will go a little bit in more detail to how to approach building platform engineering teams in a right way to avoid that. 👍
Flexibility with Infrastructure as Code
Now avoiding these strict rules apply not only to which tools developers can choose, but also the usage of those tools. Like saying: "this is the only EKS configuration you are allowed to have".
Well, we want to give developers flexibility in the usage of the tools as well, not only in the selection of tools. And as I mentioned if we split the responsibilities, we see that platform is there to take off the load of application teams and create consistency in the organization. In the same way they're helping the product team to correctly use the tools by introducing automated guardrails integrated as part of the platform.
So now the question is, how can they integrate those guard rails for using tools correctly into the IDP and make it as part of the offering?🤔
IaC Templates
And that's where infrastructure as code or configuration is code templates come in. Platform team can leverage infrastructure as code tools like Terraform, Ansible or Pulumi to create the templates. This means that these templates can have baked in best practice configurations.
They will be used to automate provisioning of resources and additionally offer the flexibility for product teams to pass in various parameters based on their individual project needs to create and configure those services.
So we have a fully automated self-service process with a high flexibility. Again an example would be to have various pipeline templates so if product team has a Python application, they can use the pipeline template for python app specifically, which has security scan tools or test steps for python applications pre-configured:
And this leads to the point of how to implement this concept successfully in a company.
Implement an internal developer platform successfully
The way you absolutely should NOT approach this, is by starting off with a huge master concept and this ideal IDP or self-service platform that has all the coolest features and modern tech stack integrated inside and is super flexible and powerful and can do thousand things:
This is not gonna work in almost all cases and there are several reasons for that, which we're going to talk about in this section. Instead we want to take a very popular agile approach here as well.
Small steps that immediately add value 💎
You should start with small steps, which can immediately add value to at least one team right away. The reason is because in many cases when application teams are using old, outdated technologies, maybe older versions of modern technologies and so on, it will be very hard for them to migrate to this full-fledged modern tech stack platform in one full swoop, right?
So it's not going to be much improvement for them, because they will now have all the effort and work on their side to actually start using that platform. So as a platform team or when implementing internal platform in your organization, you should always first consider, where the product teams are actually starting from. So what is a status quo of technology usage and then help them slowly move from the current state to the ideal state in steps. And this is the approach that is way more efficient.
Treat the IDP as a product
So the first thing is, you should treat the IDP as a product. What does it mean?
The IDP or internal developer platform is not a project that you just implement once and that's it, application teams should just take it from there. Instead it is actually a platform as a service that needs to be developed over time and then continuously improved over time. So just like the applications that product teams develop, platform is the product that platform engineers develop. And just like application team introduces new features to the applications as well as updates those features, makes improvements and so, on platform teams also need to manage and upgrade versions of the services they offer to the product teams as well as new services and new tools and tool combinations and so on.
So it is a product with its own development and release life cycle. So they are developing an internal product or internal platform for developers and that's why it's called IDP. And as all other products, it needs ongoing work and iterations.
And as I said just like you develop an application, one step at a time, one feature at a time, starting with version 1.0 and iteratively improving it, that's how platform should be developed as well.
So now the interesting question is: What is the version 1.0 of platform? Where do you start? 🤔
Well, I have some practical steps to answer that. 🤓
Identify common tools
Start with low hanging fruits!
For example if you identify the common tools that many teams use across the organization, this could be the first candidates of tools that can be integrated into the platform and be offered as a service.
This could be Jenkins, Gitlab CI/CD, Kubernetes, Vault. So basically any tool that has kind of become a standard. So a lot of teams are using it.
In order to do that you need to work closely with application teams, because you're developing the platform for them to make their work more efficient. So it makes sense to see what blocks them the most, what is the most challenging thing for them, like managing Kubernetes cluster and take over that part. Developers will be willing to cooperate if they see that you're actually solving them an issue or a bottleneck in their work process.
If you start with random stuff like "Hey teams, you are all using different CICDs, so we want to introduce a few standard offerings and you all have to switch to one of those".
When you do that you're actually adding more to their work without improving their processes at least not in the short term. So such things should be done more in a later step, maybe version 2.0., once you have proven to them that you're actually making their work easier and more efficient and already offloaded some of the work. So now they have a little bit more capacity to do this kind of initial additional work.
So as you see building a platform team successfully is as much about human aspect and how to manage the work with application teams and how to create a culture around it, set collaboration rules and clear responsibilities, as much as it is about tools and technologies that allow implementing that self-service internal developer platform.
And in long term you have a company-wide platform engineer team and a bunch of app teams and instead of each application team doing their own thing and handling application runtime and infrastructure in their own way, they use pre-configured services, that they can self-service via a platform that platform team has built with the best practices and standards and all the expertise already baked into it 🚀
So now a very interesting and logical question is..
Does this mean we don't need DevOps engineer anymore? Platform vs DevOps Engineering
We talked about the shared responsibility between platform and application team, right? That platform takes over the operations part, while application team is responsible for properly using the tools and integrating them into their development workflow.
➡️ So application teams don't need to set up and operate the cluster, but they still need to know how to deploy their applications into the cluster properly, like create correctly configured manifest files.
➡️ They don't need to know how to create Terraform modules for infrastructure, but they still need to know how to use those Terraform modules and maybe integrate them into their pipelines.
➡️ They may get a CI/CD template from the platform, but they still need to set it up and add additional needed steps for their application.
So in addition to application development they still have some non-functional requirements they need to worry about, even though the scope of that has become way less by distributing that to the platform team.
And this means you still need DevOps engineers in product teams, but they now have shared their cognitive load and don't have to have deep expertise in cloud and Kubernetes and Helm charts, monitoring, security, compliance, development and hundred other things. Because now they are focused on properly using those non-functional tools, rather than operating them.
So the work is more focused and easier through this load distribution, but they still need to do those tasks properly. And need expertise in using those tools.
But here is where it gets even more interesting.
DevOps for Platform 💪
As I said the platform is also a product, right?
It's a product for the application teams. The same way you need to add features, make the UI more user-friendly, offer services for new cool tools, fix bugs in the platform, develop Terraform modules and using GitOps, create pipelines for their infrastructure as code that is underlying the platform.
Again if you have a separate cloud or on-premise infrastructure team or security team platform team needs to work closely with them to build their platform product.
So this means platform just like the application needs a continuous development with many feedback iterations and close input gathering from the end users, which are mostly application teams, but sometimes also governance and compliance people, because they need access to the information about whether systems are compliant across organizations.
So all of these that I just described and listed are actually processes that require DevOps, because they're the same processes that we use in the application development.
So you have tons of the DevOps processes needed in the platform development process, which logically would mean that you may need a separate DevOps engineer role in the platform team as well.
A lot of variations 🏢
Now in reality as we know, when it comes to DevOps there are lots of variations of how organizations implement that.
➡️ It could be that companies hire platform engineers, who do the DevOps and Cloud engineering tasks and they will just call it a platform engineer role. So different job title, same skills.
➡️ It could be that they move the DevOps engineers from the product teams completely to form a separate platform team. But this would then create a vacuum in the application teams, because as I said you still need someone, who will create Kubernetes manifest files or create CI/CD pipelines and integrate it with various platforms.
So companies may make these tasks as part of developer work. So you may have application teams without a dedicated DevOps engineer role, where developers are taking over those tasks, which is already practiced in many organizations.
But the bottom line is that whether you have a dedicated DevOps engineer role in both teams or not you need the DevOps processes both in the application and platform development. And again how companies decide to structure the teams and the roles that is most probably gonna vary across organizations. So based on that, you essentially end up with application or product DevOps team and a platform DevOps team:
Do we teach Application DevOps side or Platform DevOps side?
Now there is one question we get asked a lot so I want to address it here in this context many people ask, which of these parts do we teach in our DevOps bootcamp and courses. 🤔
Do we teach the application DevOps side or the platform DevOps site and this question became way more common since the introduction of the platform role.
In our DevOps bootcamp, you actually learn both parts of DevOps:
✅ administering and operating or setting up the tools as well as
✅ using those tools to streamline the development process.
For example our Kubernetes administrator course is completely about setting up and administering the cluster as the name also suggests, which would be part of Platform engineers responsibility.
While in Kubernetes module in our DevOps bootcamp, you'll learn mostly the Kubernetes usage side, but also the part of configuring proper monitoring and setting up alerting in the cluster or setting up load balancer and automatically deploying to the cluster from a CI/CD pipeline for example. When it comes to infrastructure as code with Terraform that we talked about, here in the Bootcamp you learn how to automatically provision AWS infrastructure, like EC2 servers or EKS cluster, but you also learn how to use the existing Terraform modules and integrate it in the application CI/CD pipeline for example.
And same with every other tool that we cover in the bootcamp: Jenkins, Nexus repository for Docker images etc:
We basically provision these tools from scratch on dedicated virtual machines
Then write infrastructure as code scripts to automate the provisioning and configuration of these tools
Learn things like installing plugins and doing Jenkins administration, creating users and accesses, cleanup policies on Nexus for example. So tasks that would actually be part of the platform engineer's skills. But we also use these tools for setting up application pipelines on Jenkins, learning different types of pipelines and how to configure them, how to integrate and hook them into various other tools or uploading application artifacts on Nexus and creating those repositories on Nexus and so on.
And then in the GitLab CI/CD course for example it is very similar. You learn not only how to set up the CI/CD pipeline for the microservices application, but also the architecture of Gitlab CI/CD and how to configure GitLab runners locally as well as on AWS virtual machine. How to configure different agents on those runners based on your pipeline tasks, which again would be the knowledge that platform engineer would need.
Having the skillset of both 😎
So we've had for a long time DevOps engineer needing to have this skill set of both. Setting up the cluster and using the cluster, setting up and securing AWS infrastructure and using the infrastructure to deploy and run applications.
Now these tasks and roles are split and rightfully so. Not because knowing both is too overwhelming or because you can't know everything, I definitely love knowing and doing both parts and I have been working on those in my projects and you can actually learn them. But in reality depending on how complex a project is, it may be unrealistic that one person or role will have time and capacity at their job to do both.
So you can decide what you do with your full complete DevOps knowledge after finishing the bootcamp or the courses:
➡️ You can join the platform team and use your knowledge there to configure and administer tools and build the developer platform with the knowledge.
➡️ Or you can join the development team and streamline application development and release processes there, while being the interface or intermediary between the platform team and your application team.
And what's absolutely obvious is that you can do any of these jobs much better when you have the full picture and complete knowledge of these tools from both perspectives, because as a platform engineer you need to work closely with application teams and understand their processes to find any bottlenecks or things that are needed in all teams that can be standardized. So the full knowledge of understanding both sides like we teach in our courses and bootcamp, you can do the job much easier, because you understand both aspects.
And the final topic I want to address is..
What is a difference between Platform and Cloud Engineer?
Well, generally speaking platform engineering is an enhancement of all other concepts, like DevOps, Cloud, SRE as we saw throughout this article.
Cloud Engineer must be an expert in cloud services
But if we narrow it down to the main differences, cloud engineer needs to know cloud services, be an expert in that. Usually even specializing in one of the cloud platforms. So they need to know how to migrate from on-premise to cloud, how to set up a hybrid infrastructure, manage the storage and backups on cloud, manage cloud costs.
So basically everything cloud related. And they should be able to combine cloud services to build infrastructure that maps to what company needs.
Platform Engineers have wider range of knowledge and tools outside the cloud
But platform actually has a wider range of knowledge of the tools outside the cloud alone and they actually build a platform that developers or product teams can use to self-service any resources they need on top of the cloud resources and various other tools. So basically they're taking the infrastructure and service that AWS for example offers to custom platform as a service for the company internal teams:
So essentially they build a layer on top of cloud with bunch of cloud services as well as other services and tools which are not part of cloud.
Wrap Up 👏
And I'm sure as always each project will look different and implement these concepts in various ways.
Many companies will hire DevOps engineers as Platform engineers
Many Cloud engineers will probably become Platform engineers as well in smaller companies Platform engineers will probably take over the DevOps role.
In larger company cloud team will work with platform team and share their expertise. So cloud layer with platform layer on top.
And and this may be like this for a while until an industry standard evolves of one standard way to structure the teams. It could be a large company that implements this successfully at scale and then other companies can basically replicate that successful model.
So we have some kind of standardization there, but at its core that's the foundation. 😊
And from an engineer perspective it really helps you in your job search as well as to actually do your work properly when you are hired for a specific role, when you understand these differences and the vision of responsibilities, because you can then guide your team or you you can guide your company into having more clarity around these roles as well.
So we've talked about a ton of things in this article and I really hope I was able to help you understand what platform engineering exactly is, how it fits into the existing DevOps and Cloud world and I hope you got some valuable information from it that you can use in practice in your own work or generally in your career 🙂
If it was helpful, give me some support and share it with your colleagues 💙
Like, share and follow 😍 for more content: