Thought Leader Q&A: Talking Platform Engineering With Dillon Courts
In this Leadership POV Q&A, we discuss platform engineering with Dillon Courts, Callibrity’s Cloud Practice Lead.
With today’s challenging economic climate, it’s more important than ever that businesses operate as efficiently as possible, while still delivering demonstrable customer value. Platform engineering is becoming a proven way to contribute to any organization’s bottom line in various ways.
Dillon, please give us a quick overview of what platform engineering is and what it does.
Sure. It's commonly known in the software engineering world that dependencies are the antithesis of productivity. So the whole idea of platform engineering is to design and build internal developer platforms, toolchains, and workflows that enable developers to self-service operational tasks. The immediate goal is to shorten feedback loops by eliminating, or at the very least minimizing, dependencies on other teams. And the ultimate goal is to improve the software developers’ productivity by creating a platform they can use to develop and release code to the end consumer as quickly as possible. That includes the accompanying guardrails, too: like continuous integration, continuous deployment pipelines, the security that's baked into those pipelines, and automated test generation, just to name a few. Another pillar of platform engineering is observability, which gives development teams the ability to monitor how their applications are performing in production, and allows them to respond to potential problems very quickly. All of these capabilities are baked into the platform and can be performed automatically and/or at the click of a button.
Why are we seeing so much chatter in the DevOps community lately around platform engineering?
This is an interesting question because it really comes down to the role DevOps plays within an organization. Organizations are always looking for ways to get an edge in terms of releasing their newest features to consumers ahead of their competition. And historically, DevOps is supposed to break down any silos between the developers and operations for a more streamlined process. But lately, there's been some pushback within organizations that development teams are expected to do too much. Developing the software, while also having to know all of the operations around it, is a tall order. Fortunately, a pattern we’re seeing is platform engineering taking some of those operational tasks and putting them back into the hands of the operations team to build the platform.
How can platform engineering specifically address today's and tomorrow’s top business trends/challenges?
I think a lot of organizations are trying to figure out how to squeeze as much juice out of their software engineering investments as possible. And the whole point of platform engineering is to multiply the impact of every investment dollar. If platform engineering is done well, it can lead to those invested dollars generating a much higher return. And that means your features, application, and new ideas—the things that are going to generate revenue—are getting to market faster.
Platform engineering also allows rapid ideation and prototyping—trying out various ideas and failing fast. Platformed teams can test much more quickly than non-platformed competitors. Platform engineering mitigates the long development-cycle times that delay getting things into production, and most important, into users’ hands. Turnarounds are much faster. You can fail quickly to identify the biggest revenue generator faster.
How does platform engineering help decrease the complexity of modern software architectures?
One of the trends DevOps and Agile brought about was providing teams with ownership over their products and the entire associated technical stack. They’re empowered to make whatever decisions necessary to get that product out and start generating as much revenue as possible. The issue though, is that it may lead to an organization with several different teams and technical stacks. And that leads to cognitive overhead for the entire organization and introduces a ton of complexity. For example, with 10, 15, or even 20 different tech stacks, every time a team is struggling with something and another team comes in to help, they have to learn all of the various idiosyncrasies of the struggling team’s tech stack that’s likely completely different from the stack that the assisting team may be using. Moreover, having teams going in various independent directions with their tech stacks or architectures doesn't allow for efficient reuse or repurposing. Platform engineering unifies all of that underneath a more common thread that allows for a lot of reuse and extensibility for greater organizational productivity.
Please provide a use case example of how platform engineering can immediately benefit a business looking to drive cost-savings and/or customer value through accelerated application delivery.
We helped a large, national bank define their platform for delivering software into the cloud. We identified patterns that reduced lead time (time from when a developer starts coding to the time code is released into production) from one month at best to less than a week. It was a huge win for the organization in terms of greatly shortening delivery to customers, receiving actionable feedback, getting to market, and generating revenue faster.
Additionally, we were able to use feature flags to separate the software release from the software deployment. Historically, deploying a new version of software is synonymous with the release of that software. Meaning you’re deploying a new version of untested code to all of your users at once. The problem with that is if something were to go wrong with the code, it could potentially cost your financial institution thousands to even millions of dollars in damage. And so being able to deploy a new version of the software behind what we call a feature flag allows us to perform a trickle-release. That means, for example, maybe just a subset of users are able to test out new functionality to ensure it works properly before rolling it out to an even larger audience, and then eventually to a full release. This approach greatly reduces the risk involved with delivering new functionalities and features to our end users and it provides our customers immense peace of mind.
Finally, observability was baked right into the platform with the use of an Application Performance Monitoring tool and a Centralized Logging tool. This piece of the platform allowed for quick response times to production problems and reduced mean time to resolution for those problems. It also created the ability for tracking custom user metrics so the bank could better respond to how their users were using the bank’s software.
How does platform engineering contribute to innovation?
Most organizations are trying to develop a one size fits all platform solution. But it's very difficult to walk the line between having a platform that solves everyone’s needs, while also offering individual teams the flexibility they need to make the changes necessary that support whatever they’re trying to accomplish. This has led to some really interesting solutions and some really creative engineering around platforms allowing for individual teams to make plug-and-play changes and manipulations to drive specific business value for their customers.
What is Callibrity’s POV on the present and future role of platform engineering in DevOps and broader business applications?
It's not a silver bullet. Adopting platform engineering is not going to suddenly solve all of your engineering woes. It may actually seem counterintuitive to creating a partnership between your development team and your operations team. You have to be careful a platform engineering effort doesn’t recreate the same silos that the industry has worked so hard to tear down. Developers are not going to know a lot about the inner workings of the platform itself and won’t be well equipped to fix problems themselves or make changes to the platform to support what they're trying to accomplish. So they need to then reach out to the platform engineering team in order to get help. It is incredibly important to foster collaborative relationships between the development teams and the platform team.
The same is true with platform engineering teams. They can easily end up in an ivory tower where they’re building a platform but not using it themselves. So they may not understand or even be aware of the pitfalls and implications of what they’re building into the platform. Maybe they’re adding security scanning through the pipeline, but that security scanning is taking 30-plus minutes to get done, which is an eternity in pipeline time. Platform engineers need to be incredibly aware of how the decisions being made will affect the end user—operating as if they're delivering a product to development teams. That means engaging to understand what their pain points are and asking them to pilot changes to the platform to make sure those changes are going to work as intended. Maybe even taking some time away from platform engineering development to work on a development team to consume the platform themselves. “Eating your own dog food”, as they say. They can then take those experiences back and incorporate them within the platform.
How is Callibrity planning to incorporate platform engineering into its capabilities and customer offerings?
Platform engineering is something we’re doing today. It’s a core competency that we treat similarly to what we just discussed as best practice—treating it like it is a product being delivered as a platform for a potential customer. And because Callibrity has developed a variety of platforms, we’re well aware of the various pitfalls and have created a solid development method. But we know every organization is a little different and can easily flow and flex to their needs. For example, some organizations have a culture where developers only want to perform application development and have absolutely nothing to do with the operations side of the house—while others are the exact opposite. For an organization where the developers don't want anything to do with operations, you might have more of a white glove approach that does everything for them right out of the box without a lot of customization, because they wouldn't take advantage of it. And an organization that's a little more engineering savvy, you might build in a lot more flexibility that allows them to make their own changes.
To learn more about how platform engineering can help your organization, email us at contactus@callibrity.com to schedule a time to connect.
