Increased developer productivity with cloud-native
How can cloud-native shake up the traditional workflow? Cloud-native tools are appealing to many developers, and it is easy to see how. In this article, Senior Product Manager at Heptio Ross Kukulinski discusses why cloud-native is a developer’s dream.
I spend a lot of time working with software teams that are starting to explore the cloud-native ecosystem. The two questions I’m most often asked are:
- What is cloud-native?
- How does cloud-native benefit me as a developer?
There’s plenty of confusion about what exactly cloud-native means. Kubernetes co-creator, Joe Beda, has written extensively to define cloud-native. In particular, he suggests that, “cloud-native is structuring teams, culture and technology to utilize automation and architectures to manage complexity and unlock velocity.”
For developers, one key benefit of going cloud-native is a shift of responsibility and ownership to increase velocity for product development. Instead of relying on siloed operations teams, developers are enabled to manage the entire lifecycle of the software they have built, from conception to production. After all, who better to operate software than the team that created it?
To efficiently and quickly operate their applications, developers need to have programmatic access to the necessary resources (e.g. infrastructure, compute, networking, databases). For many traditional organizations, these requests are managed through opening an IT support ticket, which requires a human to manually provision hardware or make the appropriate software configuration changes. This process often takes significant time which slows down development and product velocity. Furthermore, this manual process is prone to user error. Even the best operations teams make mistakes and automation is one mechanism to help prevent them.
Cloud-native organizations, on the other hand, are driven to automate these processes by providing APIs for access-controlled management of resources. In these organizations, the Operations team runs the underlying infrastructure and provides API-driven management of resources. Developers are then able to either write software to dynamically request things like load balancers or TLS certificates or alternatively provide declarative descriptions of the end-state they desire and let the automation platform, like Kubernetes, handle the rest.
As an example, enabling developer autonomy through cloud-native practices was a key reason why we built Heptio Gimbal, which provides API-driven management of HTTP/HTTPS load balancing. It is an open source project that was developed as a joint effort between Heptio and Yahoo Japan’s subsidiary, Actapio, to modernize Yahoo Japan’s existing OpenStack-based infrastructure by integrating Kubernetes.
Actapio approached Heptio to architect and co-develop a cloud-native load balancing platform to increase their deployment agility and ability to scale web traffic in their 85,000 servers distributed across 10 data centers. They needed a consistent and flexible HTTP load balancing platform that would enable their development teams to safely self-manage and route traffic between legacy and containerized environments. As a cloud-native solution, Gimbal gives developers a tool tailored for the highly dynamic nature of managing Kubernetes workloads, which expensive, existing solutions are not designed to do.
Traditional hardware load balancers provide incredibly high throughput but are expensive to replace and upgrade, and often lack flexibility and programmability for rapid iteration. Whereas this model worked in past decades, the popularity of containerizing workloads and Kubernetes as the de facto standard for managing containers require load balancers that can be provisioned quickly and work in hybrid environments. By leveraging Kubernetes, Gimbal provides a horizontally scalable software load balancing platform that is easy to upgrade. Kubernetes’ native role based access control (RBAC) paired with its extensible and flexible API allows for safe self-service configuration of routing rules by development teams.
Gimbal enables development teams to manage their own ingress load balancing configuration without negatively impacting other teams. This provides the safety that the operations and security teams desire while increasing development velocity. Furthermore, Kubernetes and Gimbal are both designed to operate on commodity hardware, virtualized platforms, and in the cloud. This provides significant cost savings over proprietary hardware based solutions and enables companies to integrate cloud-native tools into legacy IT infrastructure without ripping out and replacing previous generation technologies.
It’s easy to see why Heptio Gimbal and other cloud-native tools are so appealing to developers. Engineers are able to self-serve IT needs which can reduce development time from months down to weeks. These technical advancements translate to business level benefits. Cloud-native technologies, like Gimbal routing traffic in hybrid environments, help companies transition legacy first infrastructure to the multi-cloud world. It’s exciting to see these next generation developer (and operations) tools paving the way to faster innovation and product time-to-market.