Challenge Your Inner Hybrid Creativity with Cisco and Google Cloud

In recent years, Kubernetes has risen up in popularity, especially with the developer community. And why do developers love Kubernetes? Because it offers incredible potential for speed, consistency, and flexibility for managing containers. But containers are not all sunshine and roses for enterprises – with big benefits come some big challenges. Nobody loves deploying, monitoring, and managing container lifecycles, especially across multiple public and private clouds. On top of that, there are many choices when it comes to environments, which can also create a lot of complexity – there are simply too many tools and too little standardization.

Production grade container environments powered by Kubernetes

That’s why earlier this year Cisco launched the Cisco Container Platform, a turnkey-solution for production grade container environments powered by Kubernetes. The Cisco Container Platform automates the repetitive functions and simplifies the complex ones so everyone can go back to enjoying the magic of containers. The Cisco Container Platform is a key element of Cisco’s overall container strategy and another way Cisco provides our customers with choices to various public clouds.

Figure 1: Cisco Hybrid Cloud for Google Cloud

Hybrid cloud applications are the next big thing for developers

At the beginning of the year Cisco joined forces with Google Cloud on a hybrid cloud offering that, among other things, allows enterprises to deploy Kubernetes-based containers on-premises and securely connect with Google Cloud Platform.

In July at Google Cloud Next ’18, we kicked off the Cisco & Google Cloud Challenge.  (You still have until November 1, 2018 to enter the challenge and win prizes.) The idea behind it is to give developers a window into the possibilities for building hybrid cloud applications. Hybrid cloud applications are the next frontier for developers. There are so many innovation possibilities for the hybrid cloud infrastructure. That’s why we even named it “Two Clouds, infinite possibilities.”

Figure 2: Timeline for the Cisco & Google Cloud Challenge

An IoT edge use case for inspiration

Consider the following use case –assume we have a factory which generates a huge amount of data from sensors deployed across the physical building. We would like to analyze that data on-premises, but take advantage of cloud services in Google Cloud Platform for further analysis. This could include running predictive analysis with Machine Learning (ML) on that data (i.e., which machine part is going to break next). “Edge” here represents a generic class of use cases with these characteristics:

◈ Limited Network Bandwidth – Many manufacturing environments are remote, with limited bandwidth. Collecting data from hundreds of thousands of devices requires processing, buffering, and storage at the edge when bandwidth is limited. For instance, an offshore oil rig collects more than 50,000 data points per second, but less than 1% of this can be used in business decision making due to bandwidth constraints. Instead, analytics and logic can be applied at the edge, and summary decisions rolled up to the cloud.

◈ Data Separation & Partitioning – Often data from a single source needs to go to different and/or multiple locations or cloud services for analytics processing. Parsing the data at the edge to identify its final destination based on the desired analytics outcome allows you to route data more effectively, lower cloud costs and management overhead, and provide for the ability to route data based on compliance or data sovereignty needs. For example sending PCI, PII, or GDPR classified data to one cloud or service, while device or telemetry data routes to others. Additionally, data pre-processing can occur at the edge to munge data such as time series formats into aggregate, reducing complexity in the cloud.

◈ Data Filtering – Most data just isn’t interesting. But you don’t know that until you’ve received it at a cloud service and decide to drop it on the floor. For example, fire alarms send the most boring data 99.999% of the time. Until they send data that is incredibly important! There is often no need to store or forward this data until it is relevant to your business. Additionally, many data scientists now desire to run individually trained models at the edge, and if data no longer fits that model or is an exception, to send the entire data set to the cloud for re-training. Filtering with complex models also allows intelligent filtering at the edge that support edge decision making.

◈ Edge Decision Making & Model Training – Training and storing ML models directly at the edge allows storing ephemeral models that may otherwise not be possible due to compliance or data sovereignty requirements. These models can act on ephemeral data that is not stored or forwarded, but still garner information and outcomes that can then be sent to centralized locations. Alternatively, models can be trained centrally in the cloud and pushed to the edge to perform any of the other listed edge functions. And when data no longer fits that model (such as collecting long tail time-series data) the entire data set can be aggregated to the cloud for retraining, and the model re-deployed to the edge endpoints.

Figure 3: Hybrid Cloud, Edge Compute Use-case

As a real-life example, here in Cisco DevNet, we developed a use-case for doing Object Recognition using video streams from IP cameras. The video gateway at the edge analyzed the video streams in real-time, did object detection at the edge and passed the object to the Cisco Container Platform which further did object recognition. The recognized object, and all the associated meta-data, were stored at this layer. An application to query this data was written in the public cloud to track the path of the object.

Give the Cisco & Google Cloud Challenge a try

There’s no doubt about the popularity of Kubernetes in the developer community. Cisco Hybrid Cloud Platform for Google Cloud takes away the complexity of managing private clusters and lets developers concentrate on the things they want to innovate on. Start with our DevNet Sandbox for CCP, reserve your instance and test-drive it for yourself.

The Cisco & Google Cloud Challenge is an awesome way to brainstorm and solve some real customer problems and even win some prizes while you are at it. So, consider this blog as me inviting everyone to give the Challenge a try, and wishing you the very best! You have until Nov 1, 2018 to enter the challenge and win prizes.

Continue reading

Containers in Production: Accelerate the Learning Curve

There is a learning curve associated with scheduling containers in production on Kubernetes. But if your cloud architect or platform engineering team can integrate and configure the set of tools needed for deploying and managing containerized workloads, then Developers, Application Ops, and Cluster Ops teams can move up the curve and accelerate time to value for your business.

But before we discuss how one can move up the learning curve, let’s first get a little context on why containers are a forcing function for change.

Historical Context

When virtual machines (VMs) were new, the technology learning curve primarily affected Ops teams who had to learn about the management, snapshotting, and migration of this new abstraction. The primary unit of management was the VM, not the physical server. Development practices didn’t change much in order to get the most value out of the technology.

But the transition to containerized workloads, as well as the deployment of containers in production on Kubernetes, have a big impact on both Dev and Ops. Containers change how applications are architected and written, and also change how applications are managed, monitored, and supported in production.

So, now both Dev and Ops have a new technology learning curve.

Developers Learning Curve

Rewriting your application for containers is not as simple as taking an application running on a physical machine or a virtual machine and just packaging it in a container. Rather, developers need to do some things differently with containers. This includes:

◈ Packaging – consider packaging with build instructions stacked in layers.
◈ Service discovery and catalog – since you’ll be running services across multiple containers, find and bind to dependent services.
◈ Key management – managing authentication and rotate keys across services.
◈ Logging and monitoring – obtaining data about the application, container, and node levels, as well as dependent services.

Ops Learning Curve

Ops arguably has an even bigger learning curve. Virtual Machines introduced a lot of dynamic things within an infrastructure environment, but containers make an order of magnitude worse because now you can spin up workloads within milliseconds, kill it, and start it somewhere else. This learning curve involves:

◈ Compute capacity planning – planning CPU and memory at a different level that includes multiple containers on a single machine (physical or virtual).

◈ Networking –. managing networking within and between Kubernetes clusters, especially since more containers means more east-west network traffic. These clusters may include both private infrastructure and public cloud.

◈ Persistent Storage – requires higher service levels than ephemeral applications.

◈ Logging and monitoring – there are usually more containers than an equivalent number of VMs for a monolithic application. And they may move if Kubernetes health check replicates pods on a different host.

◈ Data – a VM or virtual disk might include 10 different containers, so you need to shift thinking about snapshotting data at a container level.

◈ Namespaces – coding to namespaces as a variable, or mapping and managing namespaces across your various environments.

◈ Tracking changes – IT remaining responsible for Service Levels and tracking the history of simple changes. This is especially crucial with the ephemeral nature of containers and Kubernetes’ replication across nodes.

Overall, many of the Dev and Ops tools and processes that were optimized for VMs, now need to be updated and re-optimized for containers.

Don’t Get Bogged Down in the Stack

To make this work, you will likely need someone assigned to an AppOps role that works in production to support containerized applications. Also, you’ll likely need a specialized IT Ops role, call it ClusterOps, to manage Kubernetes and field requests for namespace resources or cluster lifecycle management.

But if you run Kubernetes on premises as part of a hybrid cloud solution, you’ll also need a cloud archteicture or platform engineering role to build the Kubernetes tool stack and connect to and secure the cloud. They can deploy and integrate all the tools needed to lifecycle manage your Kubernetes clusters, including underlying compute, network, and storage on private infrastructure.

Building and maintaining this type of integrated on and off-premises solution takes work — both upfront systems integration and configuration work, and the ongoing management and testing of individual tools and platforms through their upgrade cycles.

If all the tools you need to deploy containerized workloads on premises or in the cloud are integrated and tested working together such as the Cisco Hybrid Cloud Platform for Google Cloud – then it will be faster and easier for developers, as well as Application Ops and Cluster Ops counterparts, to move up the learning curve and accelerate time to value for your business.

Continue reading