Yesterday, AWS confirmed that it actually uses physical servers to run its cloud infrastructure and, gasp, no one was surprised.  The actual news about the i3.metal instances by AWS Chief Evangelist Jeff Barr shows that bare metal is being treated as just another AMI managed instance type (see also Geekwire, Techcrunch, Venture Beat).  For AWS users, there’s no drama here because it’s an incremental add to processes they are already know well.

Infrastructure as a Service (IaaS) is fundamentally about automation and API not the type of infrastructure.

Lack of drama is a key principle at RackN: provisioning hardware should be as easy to automate as a virtual machine. The addition of bare metal to the AWS instance types validates two important parts of the AWS cloud automation story.  First, having control metal is valuable and, second, operations are expected image (AMI) based deployments.

There are interesting AWS specific items to unpack around this bare metal announcement that shows otherwise hidden details about AWS infrastructure.

It took Amazon a long time to create this offering because allowing users to access bare metal requires a specialized degree of isolation inside their massive data center.  It’s only recently possible in AWS data centers because of their custom hardware and firmware.  These changes provide AWS with a hidden control layer under the operating system abstraction.  This does not mean everyone needs this hardware – it’s an AWS specific need based on their architecture.

It’s not a surprise the AWS has built cloud infrastructure optimized hardware.  All the major cloud providers design purpose-built machines with specialized firmware to handle their scale network, security and management challenges.

The specialized hardware may create challenges for users compared to regular virtualized servers.  There are already a few added requirements for AMIs before they can run on the i3.metal instance.  Any image deploy to metal process requires a degree of matching the target server.  That’s the reason that Digital Rebar defaults to safer (but slower) kickstart and pre-seed processes.

Overall, this bare metal announcement is signifying nothing dramatic and that’s a very good thing.

Automating every layer of a data center should be the expected default.  Our mission has been to make metal just another type of automated infrastructure and we’re glad to have AWS finally get on the same page with us.