Unlike other software vendors that are part of the Kubernetes community, Heptio doesn't want to build a software distribution of Kubernetes. Rather, the Heptio Kubernetes Service (HKS) is about support and services to help organizations deploy and manage upstream Kubernetes. It's an approach that Heptio has referred to as being an Un-Distribution.

"Our goal with the whole idea of the un-distribution is we want to provide the best parts of a distribution without necessarily some of the downsides that come along with that," Beda said.

Beda said that generally what happens with a distribution of an open source project is that a software vendor takes the upstream code, cleans it up so it's fit for enterprise consumption and then shipping a combination of tools that are prove to work well together.

"Upstream Kubernetes doesn't need a lot of clean up, because the community is so strong and we want to keep it that way," he said.

As such, a lot of the work that Heptio is involved with is all upstream with effort to make Kubernetes easier to install and use. Beda said that Heptio is putting a lot of effort into the kubeadm installer effort from the upstream project as well as the cluster API effort. As part of HKS, Beda said that Heptio is developing a set of validated designs, which integrate best practices for deployment.

• Difference between Docker swarm and Kubernetes

  When you are on learning curve of application containerization, there will be a stage when you come across orchestration tools for containers. If you have started your learning with Docker then Docker swarm is the first cluster management tool you must have learnt and then Kubernetes. So its time to compare docker swarm and Kubernetes. In this article, we will quickly see what is docker, what is kubernetes and then comparison between the two.

• Stop Killing Your Cattle: Server Infrastructure Advice

  If you've spent enough time at DevOps conferences, you've heard the phrase "pets versus cattle" used to describe server infrastructure. The idea behind this concept is that traditional infrastructure was built by hand without much automation, and therefore, servers were treated more like special pets—you would do anything you could to keep your pet alive, and you knew it by name because you hand-crafted its configuration. As a result, it would take a lot of effort to create a duplicate server if it ever went down. By contrast, modern DevOps concepts encourage creating "cattle", which means that instead of unique, hand-crafted servers, you use automation tools to build your servers so that no individual server is special—they are all just farm animals—and therefore, if a particular server dies, it's no problem, because you can respawn an exact copy with your automation tools in no time.

  If you want your infrastructure and your team to scale, there's a lot of wisdom in treating servers more like cattle than pets. Unfortunately, there's also a downside to this approach. Some administrators, particularly those that are more junior-level, have extended the concept of disposable servers to the point that it has affected their troubleshooting process. Since servers are disposable, and sysadmins can spawn a replacement so easily, at the first hint of trouble with a particular server or service, these administrators destroy and replace it in hopes that the replacement won't show the problem. Essentially, this is the "reboot the Windows machine" approach IT teams used in the 1990s (and Linux admins sneered at) only applied to the cloud.

• Running Apache Cassandra on Kubernetes

  The Cassandra controller can, of course, perform operations within the Cassandra cluster. For example, want to scale down your Cassandra cluster? Instead of manipulating the StatefulSet to handle this task, the controller will see the CRD change. The node count will change to a lower number (say from six to five). The controller will get that state change, and it will first run a decommission operation on the Cassandra node that will be removed. This ensures that the Cassandra node stops gracefully and redistributes and rebalances the data it holds across the remaining nodes. Once the Cassandra controller sees this has happened successfully, it will modify that StatefulSet definition to allow Kubernetes to decommission that pod. Thus, the Cassandra controller brings needed intelligence to the Kubernetes environment to run Cassandra properly and ensure smoother operations.

  As we continue this project and iterate on the Cassandra operator, our goal is to add new components that will continue to expand the tool's features and value. A good example is Cassandra SideCar (shown in the diagram above), which can take responsibility for tasks like backups and repairs. Current and future features of the project can be viewed on GitHub. Our goal for the Cassandra operator is to give devs a powerful, open source option for running Cassandra on Kubernetes with a simplicity and grace that has not yet been all that easy to achieve.

When choosing a server for your business several considerations come into play especially cost and security. But the most important consideration of all, at least in my opinion, is your business. You should always bear in mind that there is no point cutting corners on getting a server when your business depends on it.

• Kubernetes is the new operating environment (Part 1)

  This is the first in a series of articles that consider the role of Kubernetes and application servers. Do application servers need to exist? Where does the current situation leave developers trying to choose the right path forward for their applications?

  Why Kubernetes is the new application server

  By now you’ve likely read “Why Kubernetes is The New Application Server” and you might be wondering what that means for you. How does it impact Java EE or Jakarta EE and Eclipse MicroProfile? What about application servers or fat JARs? Is it the end as we’ve known it for nearly two decades?

  In reality, it doesn’t impact the worldview for most. It’s in line with the efforts of a majority of vendors around Docker and Kubernetes deployments over the last few years. In addition, there’s greater interest in service mesh infrastructures, such as Istio, and how they can further assist with managing Kubernetes deployments.

  All these factors are drivers for the current trends within development—pushing more concerns traditionally associated with development down into the lower layers of the entire stack, with concerns moving into infrastructure or the operating environment an application runs on.

  Throughout the series, we will see that there is no need for doom and gloom. Although the mechanisms might change, there’s still a place for application servers and fat JARs when developing applications.

• Understanding the State of Container Networking

  Container networking is a fast moving space with lots of different pieces. In a session at the Open Source Summit, Frederick Kautz, principal software engineer at Red Hat outlined the state of container networking today and where it is headed in the future.

  Containers have become increasingly popular in recent years, particularly the use of Docker containers, but what exactly are containers?

  Kautz explained the containers make use of the Linux kernel's ability to allow for multiple isolated user space areas. The isolation features are enabled by two core elements cGroups and Namespaces. Control Groups (cGroups) limit and isolate the resource usage of process groups, while namespaces partition key kernel structures for process, hostname, users and network functions.

• Lightning strikes put Microsoft Azure data centre offline

  Microsoft's Azure cloud platform has suffered a massive outage that affected customers in various parts of the world, with cooling problems being identified at about 2.30am Pacific Time on Tuesday (7.30pm AEST Tuesday).