Typically application developers, take J2EE for instance, don't prioritize infrastructure-related concerns when designing an application. It's hard to interface with the traditional non-programmable infrastructure. A traditional approach is to build a .war file that could then be run in an app server such as JBoss. Traditional frameworks such as Spring (except the new flavor of Spring Cloud) take this as a premise. Now, if there is a fault-tolerant, elastic deployment runtime available as it is provided by Kubernetes for instance, it seems as if writing the business application the same way would ignore capabilities such as scheduling, that are provided by the runtime. A concrete question: is it typical for applications to talk (and benefit) from the runtime (i.e. Kubernetes, Mesos, etc) API? If so, could you point to a good example. Most of the resources I have found are focused on the Ops side more than the Dev.
No, the point of Kubernetes is that your app doesn't have to be 'aware' of it. (Mesos has more of a "apps need to know about us" philosophy.)
In Kubernetes, each pod just starts up and listens on a port. The app doesn't register it's presence, or even tell what version it is. When it needs to talk to another service, it uses DNS (or even a fixed service IP) to find LB for that downstream service.
Typically application developers don't prioritize infrastructure-related concerns when designing an application
In general, there are only two things to worry about:
1) Make your service stateless, so you push the state out to the edges (Databases and/or clients). This allows Kubernetes to 'scale' your app by running more copies. Stateful services are nearly impossible to scale.
2) Break up your app into multiple "microservices" so you can scale the "product view" function without scaling the "customer login" function.
3) Optional: Head towards 12factor apps.