Brain Blog for Chronosphere by Eric Newcomer
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.
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.
Tools from Google Cloud and Chronosphere are designed for this new and different environment, and deliver the observability needed to keep teams on track and productive.
Click here to read the entire post.
