 |
VOOZH | about |
|
VOOZH | about |
We’re so glad you’re here. You can expect all the best TNS content to arrive Monday through Friday to keep you on top of the news and at the top of your game.
Check your inbox for a confirmation email where you can adjust your preferences and even join additional groups.
Follow TNS on your favorite social media networks.
Become a TNS follower on LinkedIn.
Check out the latest featured and trending stories while you wait for your first TNS newsletter.
What do you think of when you hear the term “bare metal”? To me, it conjures up images of something that’s very tangible, rows upon rows of servers connected together with colorful cables, with loud fans spinning and locked away in a basement or warehouse.
As an Ambassador for the Cloud Native Computing Foundation, I spent most of my time much higher up in the stack, at “level 7” (application) and at “level 8” (people). I’ve become accustomed to using APIs and tools like Terraform to get compute whenever I need it. One of the defining parts of my career has involved persuading people to forget about servers.
So what does bare metal have to do with “cloud native,” and if you’re new to this space, what do you need to know about it?
I’m spending some time getting familiar with bare-metal provisioning projects. What’s your favourite, and why? #baremetal #provisioning #oss #devops #itoperations #hybridcloud #privatecloud #onprem #pxe #firmware pic.twitter.com/ClOpwugPbW
— Alex Ellis (@alexellisuk) April 14, 2020
I asked my followers on Twitter to share their favorite bare-metal tooling and that resulted in a curated list: awesome bare metal. Read on to understand how bare metal compares to cloud native, and some of the concepts involved and challenges faced by administrators.
When it comes to deploying a piece of code, let’s say a REST API — there’s nothing simpler than heading over to your AWS dashboard and pasting the code into a text box and seeing your code execute with per-second billing and autoscaling from AWS Lambda. The overall interface for Lambda functions has changed very little since its inception, making it a relatively stable platform to work with.
AWS Lambda is a SaaS product, which is closed-source, so if you are worried about the risk of getting locked into a single vendor, you may be looking at Kubernetes. Kubernetes, in contrast to AWS Lambda, allows portability between clouds by leveraging Docker or OCI-format container images. Once packaged in an image and pushed to a registry, your code can be moved between Kubernetes clusters with relative ease. If you enjoy using managed products for the reduced maintenance burden, there are plenty of Kubernetes services available that are quick and easy to set up.
One of the drawbacks of a platform like Kubernetes is that it changes at a rate of knots. Between each minor release, you may see breaking changes and have to rewrite any integrations you have, not to mention the third-party tools and code generation tools, which change at a similar cadence. For this reason, managed clouds like Amazon EKS often run several releases behind the community.
See also: your team may not need Kubernetes
The most popular software in the Cloud Native Computing Foundation (CNCF) focuses on the top level of the stack. Kubernetes was the first project in the foundation and many of the subsequent projects are complementary to it — at an operational level, or at an organizational one. Tools like Prometheus and AlertManager increase operational efficiency and allow for monitoring of our many services. NATS provides high-speed messaging across local networks and the internet. Linkerd builds a mesh between containers to add metrics, policies, and end-to-end encryption.
My wife asked me why we had a “tower” in the corner of our living room. She was referring to the server I’d just received from Ampere. The way I explained it was: that using a virtual machine on the public cloud is like living in a block of flats. Most of the maintenance is taken care of for you, sometimes the utilities (gas, electric, water) are pre-paid, it can work out cheaper, but there’s a risk of “noisy neighbours”.
When you need more space, you may move into a detached house where you can spread out a bit more, but sometimes it can be hard to use all of the space you have, and it can go to waste. Costs are higher now, so you’ll have to handle maintenance and utilities on your own.
As a practitioner and maintainer of a popular Serverless project, I often get told “but there are servers in serverless.” It’s almost like they thought I didn’t know. For me, serverless has always been about the developer’s focus: it is not about hardware specs and network VLANs, but about APIs. Reasoning in terms of APIs is the cloud native way.
In a similar way, bare-metal servers are the substrate for Kubernetes, and for all cloud native applications, whether accessed directly, via a hypervisor, or through an IaaS provider’s API.
You should know that “they are in there somewhere,” and for many that’s as far as it needs to go unless you have a specific need for them. Some companies like Cherry Servers, AWS and Packet provide a nice balance between the advantages of bare-metal isolation and performance, and the powerful APIs usually associated with VMs.
For the rest of the post, please assume that we’re talking about self-managed bare metal.
With bare metal: what you see is what you get, quite literally. There are no confusing marketing terms like “serverless,” instead you get GBs of RAM, Gbps of network bandwidth and GHz of CPU. That is quite refreshing, and it’s also something that hasn’t changed very much since inception.
Around 20 years ago I worked with bare-metal computers on a daily basis at my school. I helped out the network admin staff by installing Operating Systems onto i386 and i486 and newer computers with Intel Pentium processors. The machines back then still had hard disks, RAM, network cards, and storage, just like they do today.
We had around five labs with 30 computers+ in each and sometimes that would involve walking up with a CD-ROM and reinstalling the operating system, but other times it would involve booting the computer over the network to deploy an image to it remotely. This was much more scalable and took much less time than walking around with a handful of CDROMs.
That’s where it all starts with bare metal, with the operating system, and once it has been installed, you probably won’t be able to tell the difference between it and an EC2 Virtual Machine running on AWS.
I mentioned that Kubernetes moves at a relatively rapid pace. It turns out that hardware does not. We’re using the same tools and technology to boot systems on the network that I was using in the lab 20 years ago.
Just as Kubernetes and Cloud have their own set of jargon, bare metal has its own terminology. I’ve put together a quick glossary on concepts and tools:
Not all bare metal is equal. Consumer equipment like a workstation, home PC, an Intel NUC, or a Raspberry Pi is unlikely to come with a management port for IPMI.
Here’s a sample workflow for booting a computer over the network:
At that point a filesystem may be mounted over the networking using NFS and an operating system will be run remotely, or a temporary environment will be used to install an OS to the local system. On a subsequent boot, the hard disk will be used to load the OS.
Some of the concepts like netbooting and network interfaces have a crossover with virtual machines. The equivalent of IPMI on AWS would be your EC2 Dashboard where you can select a disk image (aka. Amazon Machine Image/AMI) to boot up, and customise the behaviour of the machine.
I recently asked my network on Twitter what their favourite bare-metal provisioning tools were. There were many different answers, with gravity around a set of 5-10 projects with some of them being newer, and others more established.
It turns out that whilst bare metal and the low-level tools like DHCP, TFTP and NFS haven’t changed much over 20 years, people are trying to make them easier to automate. Many data centers contain heterogeneous hardware, some with RAID arrays, some without, some with one disk, some with two, along with varying firmware and capabilities.
Provisioning tools need to help us with:
I’m spending some time getting familiar with bare-metal provisioning projects. What’s your favourite, and why? #baremetal #provisioning #oss #devops #itoperations #hybridcloud #privatecloud #onprem #pxe #firmware pic.twitter.com/ClOpwugPbW
— Alex Ellis (@alexellisuk) April 14, 2020
You can see the results of the Tweet in my curated awesome bare-metal GitHub repository. It covers bare-metal provisioning software along with tools that make it easier to work with low-level networking such as MetalLB and inlets.
Here’s a short selection of projects that the community mentioned:
The most popular tools help automate the various tools we looked at in the sample workflow above: PXE, DHCP, TFTP, NFS, hard-disk preparation, and OS installation. Once installed, a Kubernetes cluster could be bootstrapped, but these tools are designed to be more general purpose. Once your Operating System is installed, a management tool like SSH, Ansible, Puppet or Chef is generally used to manage the computer and its software packages.
Now a number of newer tools that the community shared are focused on building upon these tools to bring up a Kubernetes cluster, and so we close the loop on bare metal vs. Kubernetes. Examples include:
Of the Kubernetes tools mentioned, some go a step further and embrace an abstraction called Cluster API (CAPI). CAPI aims turn a set of VMs or servers into a functional Kubernetes cluster.
The Cluster API is a Kubernetes project to bring declarative, Kubernetes-style APIs to cluster creation, configuration, and management. It provides optional, additive functionality on top of core Kubernetes to manage the lifecycle of a Kubernetes cluster.
More on Cluster API:
When considering modern cloud computing there’s a spectrum of control and portability. At one end, we have AWS Lambda, a closed-source SaaS product that’s highly proprietary, and offers little control, but high utility and efficiency. Moving up, we have Kubernetes which brings along scale-out superpowers, but at a cost. And finally we have bare-metal servers that need to be managed thoughtfully with specialist tools. Personally, I think that the intersection of the two is interesting, which is why I’m excited about tools like Metal³ and Metal Stack which aim to smooth out the experience of going from heterogeneous bare-metal hardware to Kubernetes.
I’m also watching the Tinkerbell and Plundr projects closely. Plundr takes a monolithic approach, bundling as much as possible into a single binary and simple workflow engine — “turning bare-metal into cloud”.
Tinkerbell is a set of microservices-based upon the work of Packet over the past six years designed with security and heterogeneous hardware in mind. I like the way that each step in a Tinkerbell provisioning workflow is defined as a Docker image. You define a Dockerfile and then build an image and store it in a registry, enabling portability, versioning and reproducible artifacts.
You may also like:
Have you got comments, questions, or suggestions? Email alex@openfaas.com or reach-out on Twitter.
