“There needs to be a way to make Kubernetes more approachable and manageable”

JAXenter: Thank you for taking the time to answer our questions. According to the new report from Dimensional Research, 66% of IT executives do not believe that their business can have both a flexible and usable Kubernetes environment. Can you expand on this? Why is this?

We speak to businesses around the world about accelerating application delivery and the use of new technologies like Kubernetes and hear the same sentiment that appears to be reflected in this datapoint: Kubernetes is still fundamentally hard and putting Kubernetes into production at scale is even harder. A part of this complexity is the fine line that IT is forced to walk, trying to balance the controls that corporate IT needs to have vs the freedom and speed that developers need.

As apps move from development to production more frequently and more quickly, things get serious for Kubernetes platforms: security, compliance, availability, performance and governance become priorities. IT has been forced to lock down developer individuality and innovation and force standardization to even have a chance at managing these critical management requirements. IT teams have felt they’ve had to do this regardless of the unique needs of their organization which vary based on preferences, project nuances and the like.

So, while Kubernetes represents a great opportunity for businesses to accelerate their digital transformation plans and further build customer intimacy, it has failed to live up to its potential.

There needs to be a way to make Kubernetes more approachable and manageable; meeting the needs of both developers and IT. Identifying this need for a modern approach to Kubernetes management is not lost on the Kubernetes industry and open source ecosystem organizations such as Cloud Native Computing Foundation (CNCF). Cutting-edge projects like Cluster API are evidence of the ecosystem helping simplify and make the adoption journey easier for organizations.

Today’s modern enterprise platform must support the use of one-to-many Kubernetes distributions that may span any combination of on-premises and public cloud environments, providing developers with a choice of tools and IT access to complete day 1-2 operations including security, cost optimization and policy-based management. Spectro Cloud brings this modern approach to Kubernetes management to the table with its Palette platform, with a fresh approach and its advantage of not being “stuck in the middle” due to legacy technology.

SEE ALSO: “Proactive security scanning of code is a must”

JAXenter: Despite this, Kubernetes has become the de facto standard of containers and grows in usage every year. Why are some enterprises still holding out, despite its rampant popularity?

The same study that Dimensional Research conducted has some very interesting data points relating to your question: one of them shows that the majority of organizations using Kubernetes actually only run less than half of clusters in production. In another independent annual study conducted by Google, it is the first year that containers rank above virtual machines in terms of what developer operations (DevOps) teams are deploying code on primarily. All this is telling us that Kubernetes is really the new status quo and as mentioned earlier, there is an explosion of clusters which need to be deployed in the pipeline. This does not mean adoption is easy. In fact, every organization is unique in terms of how they end up adopting Kubernetes, the goals they want to accomplish with Kubernetes, etc. The bigger the scale, the more complex the adoption can be, since you have multiple locations, physical and virtual infrastructure, more teams etc. To sum up key challenges, these include: guardrails for enterprise environments, multi-cluster and multi-cloud management, integrations with systems and tools, security and compliance considerations, etc.

Another key point to make: you don’t need to switch all your infrastructure to Kubernetes. In the tech industry, we sometimes have the tendency to oversimplify and position the new shiny thing as a panacea, but reality is different. This is important for companies skeptical of Kubernetes deployment to keep in mind. Some might ask, for example, “Why would a big manufacturing company mess up with an internal system that does not really need updating or ‘modernizing’ which is still doing its job? Would it need to be moved to Kubernetes-based infrastructure?” This is probably not a priority. The big bet and more impactful set of deployments to consider, which I think is on the trajectory to happen soon, is on the new apps coming out of developer teams. Kubernetes is now the de facto block for new apps. As such, Kubernetes utilization and management will become more of the norm from a virtual infrastructure perspective.

In short, to answer your question more directly, we will get there.

This is because containers really are not solving a problem for infrastructure or for IT: they solve a problem for developers. And they enable developers to move faster and deploy Kubernetes anywhere — with the right management platform of course ;).

Kubernetes is still fundamentally hard and putting Kubernetes into production at scale is even harder.

JAXenter: Managing multi-cluster and multi-cloud Kubernetes in the enterprise comes with its share of challenges. What challenges do companies face in this regard?

Let’s start with multi-cloud first, but the challenge is similar to multi-cluster Kubernetes. There is an interesting datapoint in one of the questions in the report from Dimensional Research: 77% of executives think it is vital to have Kubernetes in different environments, but makes management much harder. Multi-cloud is not a choice or a “solution”: it happens because development teams want to leverage the best innovation that is coming out of cloud providers or to be able to deploy apps where it makes sense. (This includes their own data centers and edge locations.) Furthermore, it is not really the development team’s responsibility to build those tools. So for a technology that was actually built to package application code and runtime with the promise that it would work everywhere, I think being multi-environment (or multi-cloud) is a must by…design!

Why is it difficult to get there? Because you have all those different platform-specific management tools and opinionated stacks that get in the way. And the multi-cluster challenges are similar. It might sound simple to have an organization with a data center that deploys on top of virtualization and bare metal and then on just one cloud environment, with only three development teams, but it can be a nightmare. You can end up with three management methodologies. Then multiply that by the various requirements of your development teams in terms of required flavors, integration, versions and so on. Every management methodology will have platform-specific tools associated with it, manual scripting and its own micro-complexities. And across all the above: zero consistency. This is where modern Kubernetes management and next-gen platforms like ours of course come in!

JAXenter: Is there a one size fits all solution for choosing a cluster deployment size?

There isn’t really any best practice, and perhaps it is too soon for that, when it comes to cluster sizing choices. This is also validated in our study. Generally, multiple application teams working on different things would translate to a large number of smaller clusters so that apps can be isolated. On the other hand, depending on the Kubernetes adoption phase of the organization, it is likely that a few larger clusters can be easier to manage and standardize. That really shows again how unique and different organizations and their requirements can be.

JAXenter: Are there any features that Kubernetes lacks that you would like to see implemented (or improved upon)?

Aha! This is where we get technical: I think the existing “out of the box” support for application rollout (blue-green, canary, etc.) can be enhanced. Yes, there are toolings like ArgoRollouts and others which provide this, but it’s another component which needs to be managed. More functionality and use cases on managing resource quotas is another one, enabling teams to manage across multiple namespaces; at the moment they cannot. Finally, too frequently we see customers incorrectly using Pod Disruption Budgets (PDBs), which often results in outages during upgrades. It would be great to see some sort of PDB simulation mode or test mode before the PDBs are activated.

JAXenter: Let’s talk about Spectro Cloud. Spectro Cloud recently announced the release of Version 2.0 of Palette, an enterprise Kubernetes management platform. Could you tell us some more about Palette and what the latest features are?

Sure! Palette is a complete and integrated next-gen platform that enables organizations to easily manage the full lifecycle of any combination of new or existing, simple or complex, small or large Kubernetes environments whether in a datacenter or the cloud. We have a unique approach to managing multiple clusters, giving IT teams complete control, visibility and production-scale efficiencies to provide developers highly-curated Kubernetes stacks and tools based on their specific needs, with granular governance and enterprise-grade security.

We believe we have an answer on how to easily run Kubernetes in production without giving up on flexibility or control, making it more accessible and manageable for any organization. Our goal is to enable our customers in their Kubernetes adoption journey and accelerate their container-based application innovation by making the underlying management complexity invisible to users.

We referred to the “Kubernetes conundrum” and the perception that it is really a fine balance between control and freedom for innovation. Palette is the answer that makes that dilemma obsolete. Why?

Because it is based on a true full-stack approach to declarative management, which means that as opposed to most of the other commercial solutions out there, Palette doesn’t only look after your Kubernetes infrastructure, but also all the add-on application services that development teams use. A feature called Cluster Profiles enables this. In addition, multi-cluster, multi-cloud and multi-distro are key capabilities. Users can choose from a Spectro Cloud repository or bring their own mix of layers. We just make sure it works. Finally, everything is built from the ground up for the enterprise, so Palette supports every feature to support the full lifecycle of Kubernetes, from day 0 to day 2 operations!

Version 2.0 was a significant release and besides a major user interface update, we delivered enhanced end-to-end cost visibility and optimization, additional enterprise controls for teams to work across projects even easier and a unique approach to edge and bare metal deployments for both new and existing clusters!

SEE ALSO: Using NoSQL Databases With Jakarta EE and MicroProfile

Palette is a complete and integrated next-gen platform that enables organizations to easily manage the full lifecycle of any combination of new or existing, simple or complex, small or large Kubernetes environments whether in a datacenter or the cloud.

JAXenter: Finally, what predictions do you have for Kubernetes in 2022?

Well if we said that Kubernetes adoption is going to continue, we wouldn’t be shocking anyone! When it comes to more specific areas, perhaps one of the most “organic” developments as more and more IT and development teams adopt Kubernetes, will be the need to manage multi-cluster and multi-distro clusters by investing in better automation and orchestration. I just don’t see a way around this, since those developers need to be able to support diverse use cases, without having to be Kubernetes experts: actually it’s quite the opposite —it should almost be invisible to them!

The other big theme that we see coming and one of the most frequent discussions we have with organizations when discussing our unique approach, is bare metal and edge Kubernetes deployments. While similar, they are not the same, but they both are based on the premise of optimizing for efficiency: there are so many benefits with running Kubernetes directly on bare metal physical servers without the need for virtualization(a layer that ultimately just adds costs and complexity). Similarly, edge deployments – in combination and relevant to the 5G infrastructure modernization, will unlock many new application use cases. That said, they require a different approach to management; since we are oftentimes talking about unmanned locations from an IT perspective, unreliable networks, etc.

The post “There needs to be a way to make Kubernetes more approachable and manageable” appeared first on JAXenter.