7 Platform capabilities I: Shared application concerns

 

This chapter covers

  • Learning requirements of 95% of cloud-native applications
  • Reducing friction between application and infrastructure
  • Addressing shared concerns with standard APIs and components

In chapter 5 we created abstractions such as databases and message brokers to provision and configure all the components required by our application’s services. In chapter 6, we extended these mechanisms to build our platform walking skeleton.This platform enables teams to request new development environments that not only create isolated environments but also install an instance of the Conference application (and all the components required by the application) so teams can do their work. By going through the process of building a platform, we defined the responsibilities of a platform team and where each tool belongs and why. We ended chapter 6 with clear guidelines for where tools like Crossplane, Argo CD, and Tekton would run to manage and enable different environments with capabilities that teams will need to deliver more software in front of customers.

7.1 What are most applications doing 95% of the time?

7.1.1 The challenges of coupling application and infrastructure

7.1.2 Service-to-service interaction challenges

7.1.3 Storing/reading state challenges

7.1.4 Asynchronous messaging challenges

7.1.5 Dealing with edge cases (the remaining 5%)

7.2 Standard APIs to separate applications from infrastructure

7.2.1 Exposing platform capabilities challenges

7.3 Providing application-level platform capabilities

7.3.1 Dapr in action

7.3.2 Dapr in Kubernetes

7.3.3 Dapr and your applications

7.3.4 Feature flags in action

7.3.5 Updating our Conference application to consume application-level platform capabilities

7.4 Linking back to platform engineering

Summary

sitemap