Platform Engineering is a rapidly evolving field that is reshaping the way we build and manage software. It’s a discipline that focuses on creating scalable, reliable, and efficient platforms that can support the development and deployment of applications. However, as with any emerging field, it’s riddled with both patterns (best practices) and anti-patterns (common pitfalls).
The power of patterns
Patterns in platform engineering are tried and tested strategies that have proven to be effective in various scenarios. They are the building blocks that can guide an organization toward creating a robust and efficient platform.
For instance, the “You Build It, You Run It” pattern empowers developers to take full ownership of their applications, from development to deployment and maintenance. This not only boosts accountability but also enhances the quality of the applications.
The peril of anti-patterns
On the flip side, anti-patterns are practices that seem beneficial at first glance but can lead to inefficiencies and problems down the line. Recognizing and avoiding these anti-patterns is crucial for the success of any platform engineering endeavor.
Platform engineering, a field that has gained momentum due to its relevance to DevOps, has several anti-patterns that can hinder its effectiveness. Now we will talk about the 7 most common anti-patterns.
7 anti-patterns you need to know to avoid them
A classic example is the “Not Invented Here” syndrome, where teams resist using third-party solutions, opting to build everything in-house. This can lead to wasted resources and slower time-to-market.
One such anti-pattern is the creation of overly complex platforms. These platforms may use unfamiliar configuration file formats, lack consistent API conventions, have no documentation, or fail to alleviate developer pain. For instance, if a platform uses a configuration file format that the developer is not familiar with, it adds to the complexity rather than reducing it.
Another anti-pattern is the “Field of Dreams” platform, named after the 1989 movie. This refers to the assumption that if you build a platform, developers will automatically use it. However, without involving them from the start and addressing their specific problems, the platform may struggle to be adopted.
The skill concentration trap is another anti-pattern where the most experienced individuals are moved to the platform engineering team, causing a potential knowledge gap in the development teams. This can lead to issues when development teams lose the knowledge they need to run their software or lose the people who could migrate them onto a platform.
“Magpie platforms” focus on shiny new technologies rather than solving problems developers face with existing systems. This can lead to a platform that supports a greenfield project but fails to help teams with their existing production software.
Underinvested platforms are those that lack long-term investment to keep them usable. Once a platform team disbands after delivering a product, the platform can become an anchor that adds drag to all who depend on it.
Lastly, “stretched platforms” try to solve too many problems, supporting all existing tools and technology, which can lead to the platform team being overloaded.
Consume innovation, begin transformation
Subscribe to our newsletter to stay updated on the latest best practices for leveraging technology to drive business impact
Striking the balance
The key to successful platform engineering lies in striking the right balance between patterns and anti-patterns. It’s about understanding the context and choosing the right strategies that align with the organization’s goals and culture.
It’s also about fostering a culture of learning and adaptation, where teams are encouraged to learn from their mistakes and continuously improve their practices.
Talking about culture…
Today, it’s quite easy to build a team and make things consistent, collaborative, and communicative, and for that, there’s a lot of documentation, frameworks, and techniques to build teams embedded in company culture, but if you have any culture-related issues, platform engineering itself will not solve these problems.
Conclusion
Platform engineering is a journey, not a destination. It’s a continuous process of learning, adapting, and improving. By understanding and leveraging patterns, avoiding anti-patterns, and harnessing the power of data, organizations can build platforms that are robust, efficient, and ready for the future.
