Modern platform engineering in an AI-led software development era (Part 1)

This blog is part one of a series that will look at technologies and processes that have consolidated in the industry regarding platform engineering. We’ll focus on explaining how the concept has built upon all the past practices commonly used in the DevOps space to demonstrate a true evolution in design, implementation, and thinking.  We’ll also examine the changing landscape and key drivers of platform engineering.

In part two, we’ll explore platform engineering’s role in driving competitive advantage and describe four key benefits for consideration. Lastly, in part three, we’ll discuss the future of platform engineering and the next steps for your organization as a whole. 

We call this series: Modern platform engineering in the era of AI-led software development.

Can platform engineering be modernized?

Since the dawn of large-scale computing, we’ve only seen the pace pick up, and this has been no different in recent years. These days, companies face stronger competition, leading to more pressure on organizations to succeed. To free up more time for core competencies and creative thinking, platform engineering might be the key to your organization's success.

For many years, the freedom of choosing your tools and what works for you has been a key message to keep developers happy and focused. Gaining flexibility in the composition of teams or working groups requires less cognitive load on onboarding developers to a potential new business domain. Shifting from a highly explorative period, we’ve seen a big consolidation of tools and practices, which still gives enough headspace for individual teams to adjust to their needs.

A closer look: The changing landscape of DevOps and platform engineering

When we look back at the big shifts in our industry, we saw bringing development and operations closer together with DevOps practices often lead to a faster time to market, which can come with a price (something we’ve seen over the years). The price may not always be monetary, but it’s often on the cognitive capacity of the developers. When we’re introduced to a new field of work, we see speed, cognitive capacity, and agility drop as the natural cause of new knowledge needing to be ingested and processed.

While “You build it, you run it” is important for ownership and thereby urgency for the teams, many developers had to learn operational practices they had never been introduced to. This need came from the reality that operations skills weren’t present to scale with the number of teams that needed them. Moving away from the queued tasks in a classical operations setup did require a significant shift in mindset, and in many cases, we’ve seen that not every organization has put their bet on. The shift in mindset was and still is a key to success for not going back into silos (and in some cases, trenchwars) that penalized the competitiveness for everyone in the organizations. The flip side of the DevOps coin means developers have had to build knowledge in basic cloud networking, how to configure Kubernetes, and content delivery networks. These knowledge domains require specialist knowledge to do well in regards to operations, flexibility, and economy.

To ensure a developer can focus their scope of knowledge on the business domain they’re in, how to build well-architected code, and focus on the creative freedom, platform engineering has become the leading approach. With a high focus on developers' demands for writing, building, testing, deploying, and operating software, platforms have been built to reduce that cognitive load. This means giving back a slice of freedom for a unified way to operate, which isn’t bad when the side effects of platform engineering come into play in a world with rising demands on governance and compliance as well.

What are the key drivers of modernization in platform engineering?

While we’ve seen many organizations migrate to cloud, we’ve also seen a shift towards a more cloud native approach. This doesn’t necessarily mean we’re all going cloud (though many have), but it’s more in the mindset of leveraging technologies that have been central building blocks to the clouds we see today. This could include many architectural patterns in software development, but there is no doubt that virtualization, containerization, and Kubernetes have been the big players in the cloud native journey. Building smaller, focused services that are easier to debug, scale, and maintain is among the keys to success. This is a big contrast to the days of packing as much as possible into that single service, and squeezing out that last slice of CPU and memory on the server.

We’re now operating hundreds, thousands, or even more services in our organizations, and we rely on the platform to ensure we bin pack all of those services on the actual servers and get the most out of our monetary investments.

By embracing the platform engineering journey, we can start optimizing our usage of resources we have at hand, whether it’s servers on-premise or clusters spun up with a cloud provider of your choice. If we don’t embrace the platform engineering journey, we can for sure run our systems, but it does require the specialized know-how to make it all run profitably without burning all our money on many individual clusters and repetition of the supporting services.

Analyzing the datastreams from the platforms, we can take deliberate actions to improve and expand the capabilities offered to the software developers using the platform. This is a major keystone that has gotten more attention over the last few years. More and more organizations have realized that the platform is built for developers and hence it should support their needs. We are moving increasingly towards running platforms as products. However, we aren’t there yet, as we see many take on platform engineering as a technical challenge while the whole concept is a sociotechnical exercise. Getting the users' feedback in both quantitative and qualitative settings is important to ensure that we build the right things, that it is being used, and that the consumers like working with the platform.

Last but not least, the industry has seen a rising demand for running AI workloads on platforms. This has sparked many discussions both for us as platform builders and security professionals and for big hardware companies like NVIDIA. How do we build a platform that can leverage the potential of the hardware and make it work in a manner that fits with the cloud native approach of shared hosting?

From the initial steps of hardware being directly configured to individual workloads, we’re now seeing more and more steps towards a model where the hardware is shared among multiple workloads. While this has been possible for a while, we’re seeing standards emerging in the industry that will help us operate long-term.

How we can help

At Eficode, we’re more than happy to help you on your platform engineering journey, whether by defining your platform, building your platform, or providing you with more food for thought through our articles and specialists in the field.