Why platform engineering is different for cloud native applications

As described in the previous article in the series, creating an internal developer platform (IDP) for cloud native computing is challenging because cloud native computing is different and complex and therefore it’s challenging to get it right. 

Getting it right, however, is key to achieving cloud native benefits for the business, enabling developers to build and deploy applications more quickly, reliably, and at lower cost. 

Understanding why developer platforms are different for cloud native computing is an essential first step to getting it right.

Cloud native applications differ significantly from traditional applications primarily because they are designed and developed for cloud native “scale out” infrastructure and typically use multiple cloud provider services.

Public cloud providers offer hundreds of system software services, any number of which may be relevant (or not) to the task at hand. It can be very time consuming to sort through these services to identify the ones you need to incorporate in your IDP.  

Furthermore, developing cloud native applications typically involves breaking functions into microservices, packaging the microservice code into a container image with required artifacts, and deploying the containers to Kubernetes clusters. 

Going down this path helps achieve cloud native benefits, but all software tools are not equal when it comes to microservice, container, and Kubernetes support. 

Traditional tools often don’t support cloud native developers because they are not designed for the cloud native computing environment of microservices, containers, and Kubernetes. 

A microservice is a discrete unit of work, typically an application feature or function. A microservice exposes an API to encapsulate its function and interacts with other microservices over the network.

Cloud native developers need to develop and deploy microservices rapidly and at scale to keep pace with the modern pace of change, and need to respond quickly to customer feedback and incidents.   

Organizations successfully adopting microservices achieve the greatest benefits with small autonomous teams supported by a central internal development platform that enforces organizational standards and consistent tooling.

It’s much easier to patch and update an individual microservice than it is to redeploy a monolithic application just to fix a bug, for example. 

Success with this model requires the right organizational structure and governance, the discipline to carefully coordinate breaking changes that affect multiple microservices, and the right combination of cloud native technologies and tools in your IDP.

The goal of platform engineering is to create an IDP that works as a product for developers that abstracts away infrastructure issues and tooling concerns.  

And because of the differences in the cloud native environment compared to traditional IT environments, these abstractions have to work with microservices, containers, Kubernetes, and cloud provider services. 

Cloud native best practices put additional responsibilities on developers. In traditional IT environments developers request the operations team to provision their databases, event stores, and secret vaults, for example. Cloud native environments do not have operations teams that manually provision required software. 

Instead, developers use an IDP that exposes declarative APIs, configuration files and scripts so developers can self-serve. 

Consider a request to provision a database. The site reliability engineer  or operations teams would have set up available databases in the IDP that meet security, availability and reliability concerns and monitoring out of the box.

A developer declares a requirement for a relational database, for example, without having to specify which one. This level of abstraction permits the database to be swapped out for another database without affecting the application. 

Let’s assume that you work in a cloud native environment and develop microservices using containers and Kubernetes.

Let’s further assume that you also follow the best practice of organizing your developers into small autonomous teams responsible for at least one microservice throughout the entire development life cycle, including production support. 

All of this is to provide a great customer experience, develop and deploy rapidly, increase developer productivity and release application code to production more quickly and with higher quality and resilience.  

The success of these choices significantly depends on including the right observability tools in the IDP. 

Traditional observability tools only monitor post-deployment code — that is, they monitor code in staging and production. This is, of course, important but it’s also important to reduce the number of incidents and outages that take time away from developing and deploying code that improves the customer experience and business competitiveness. 

Observability solutions that simply capture data are inefficient and impede productivity. The cloud native world of microservices, containers, and Kubernetes requires  a solution that filters and tailors data specifically for small autonomous teams developing, deploying and supporting microservices. Google Cloud and Chronoshpere provide this for IDPs.

Engineering for cloud native applications is the way to get the best value and greatest benefit from cloud native computing. 

Engineering an IDP for cloud native environments requires not only abstracting the cloud provider service infrastructure but also incorporating an observability solution that provides immediate feedback as early and often in the development process as possible.

Observability in the IDP designed for cloud native applications provides useful data to developers as quickly as possible to keep them productive and happy. 

Google Cloud and Chronosphere offer such a production-ready observability solution that can be included in your IDP to help fully realize the benefits of cloud native environments.

Copyright © Intellyx LLC. Intellyx is solely responsible for this content. As of the time of writing, Chronosphere is an Intellyx customer. No AI chatbots were used to write this content.