Kubernetes (also known as K8s), the container orchestration tool originally developed by Google, has quickly become the platform of choice for deploying containerized applications in public and private clouds.

For the DevOps teams, K8s provides a common platform for deploying their applications across the different cloud environments, abstracting the intricacies of the underlying cloud infrastructure, and allowing them to focus on their tasks. For organizations, this translates into flexibility to deploy the applications in the cloud that best meets the needs of customers, while optimizing costs at the same time.

This flexibility to deploy applications in any cloud, however, creates the challenge of making them accessible to end users in a reliable and consistent manner. For example, as an application is moved from a private to a public cloud (such as AWS or Azure), how do you ensure the same level of accessibility, performance, reliability, and security, as in the private cloud?

For making applications accessible to the end users, Kubernetes supports the following options:

NodePort: In this, a port is allocated on each node (known as NodePort) and the end users can access the application at the node’s IP address and port value. With this option, you have to manually configure a load balancer to distribute traffic among the nodes.

LoadBalancer: Like NodePort, this option allocates a port on each node and additionally connects to an external load balancer. This option requires integration with the underlying cloud provider infrastructure and hence, is typically used with public cloud providers that have such integration. This tight integration, however, makes moving an application from one cloud provider to another difficult and error-prone.

Ingress Controller: K8s defines an Ingress Controller that can route HTTP and HTTPS traffic to applications running inside the cluster. An Ingress Controller, however, does not do away with the requirement of an external load balancer. As in the case of the load balancer, each public cloud provider has its own Ingress Controller that works in conjunction with its own load balancer. For example, Azure’s AKS Application Gateway Ingress Controller is an Ingress Controller that works in conjunction with the Azure Application Gateway. This again makes the access solution specific to a cloud deployment.

Clearly, none of the above options provide a truly cloud-agnostic solution. Also, while using a cloud provider’s custom load balancing or Ingress Controller solution may be quick and easy in the short term, overall, it increases the management complexity and inhibits automation as you now have to deal with multiple different solutions.

A desired solution would have the following key attributes:

Cloud-agnostic: The solution should work in both public and private clouds. This means it should be available in different form factors (such as virtual, physical, and container) so that it can be deployed in a form that is optimal for that environment.

Dynamic configuration of load balancer: The solution should be able to dynamically configure the load balancer to route traffic to the Pods running inside the Kubernetes cluster as the Pods are created and scaled up/down.

Support automation tools: The solution should support automation tools for integration into existing DevOps processes such as CI/CD pipelines.

Centralized visibility and analytics: The solution should provide centralized visibility and analytics. This would enable proactive troubleshooting, and fast root-cause analysis, leading to higher application uptime.

“As a payment service provider, we needed to respond in real-time to any kind of demand spike and to give our merchants the instant response times they expect,” said Marco Incalcaterra, Head of Technology at noon payments. “Microsoft offers the most comprehensive solution in the market; the products are connected to one another. The company’s large, flexible offering was one of the key factors in choosing Microsoft as our partner that will enable us to develop a strong, resilient, easy-to-scale platform.”

“Being a holistic payments platform, organizations like noon payments play a crucial role in enabling digital transformation for enterprises across the world,” said Naim Yazbeck, Regional Director, Enterprise and Partner Group (EPG), Microsoft UAE.

The Microsoft Azure cloud deployment was also expected to meet noon payments’ requirement for zero downtime by leveraging Traffic Manager to divert transactions to other regions during times of maintenance.

Nico Popp, Chief Product Officer, Tenable says, “Just as IaC opens the door to programmatically embed policy checks earlier in the development lifecycle, Terrascan detects compliance and security violations across IaC to mitigate risk before provisioning. We are committed to ensuring Terrascan remains open and available to all development teams and are excited to contribute to its growth.”

Terrascan features:

• The ability to identify security risks in more IaC and container definition formats
• Integration with all major container registries, including to identify vulnerabilities in container images referenced by IaC
• More flexible developer workflows, including the programmatic enforcement of security policies before changes are committed into the code repository and before they are applied to the runtime environment
• Improved ability to filter and prioritize findings according to user needs
• Deeper integration with external dashboards and reporting frameworks
• A new graphical user interface to simplify creation and testing of new policies

Terrascan fundamentally enhances the value of IaC used by organizations to define and manage cloud infrastructure, and improves security by enabling teams to eliminate risk before infrastructure is deployed. In addition to Terrascan, Tenable offers Accurics by Tenable, so enterprise customers can protect the full cloud-native stack throughout the DevOps lifecycle, from the time it is defined in code through production usage.