 |
VOOZH | about |
|
VOOZH | about |
We’re so glad you’re here. You can expect all the best TNS content to arrive Monday through Friday to keep you on top of the news and at the top of your game.
Check your inbox for a confirmation email where you can adjust your preferences and even join additional groups.
Follow TNS on your favorite social media networks.
Become a TNS follower on LinkedIn.
Check out the latest featured and trending stories while you wait for your first TNS newsletter.
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 they need to respond quickly to customer feedback and incidents.
Organizations that successfully adopt 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 secrets 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 also assume that you 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.
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.
