Metal as a Service is a new layer in the stack under IaaS and is described by Mark Shuttleworth as, “…bringing cloud semantics to the bare metal world.”
Essentially MaaS supplies bare metal that can be deployed similarly to cloud instances, however you are actually deploying physical nodes. Traditionally deploying hardware is time consuming and technically complicated, MaaS simplifies this and makes it possible to interact with physical devices similarly to AWS instances (with a greater time frame and without automated API deployments).
Canonical invented and were the first to market with an offering like this, and have integrated the JuJu deployment system with MaaS. Using JuJu, operating systems and services can be deployed allowing rapid scaling without the need for a senior engineer or network architect. JuJu is similar to Chef or PXE and in a similar way allows the rapid and simple interconnection of services across multiple physical hosts.
This is compelling and Canonical are certainly offering a unique service in the hosting sector. I’m sure it will not be long before competing services become available. Look at the open-sourcing of OpenStack as an example of how a technology is adopted and shortly becomes a standard in the hosting sector as an example of this. JuJu is available for download from Launchpad.
I am curious about how this service is going to be adopted. This is not a cloud service and Canonical do not claim that is, however ‘as a service’ products are in the majority of cases sold, and interpreted, as cloud products. Using terms such as ‘hyperscaling’ in marketing material certainly connotes cloudy-ness and does nothing to dispel how I think customers will initially perceive MaaS as a cloud service.
Is it really possible to hyperscale a MaaS environment quickly enough as an application demands it? MaaS is not AWS and it is unlikely that it will be possible to consistently ‘instantly’ deploy a physical host. However MaaS is clearly an offering aimed at the type of engineers and users who will be using, or have considered using, a cloud instance based service but require separation and dedicated / reserved resources.
MaaS appears to be mainly for enterprise users and the majority of these will already have deployment and server management systems in place. From my own experience dealing with clients like this they do not greatly care about the spec of the underlying commoditised servers themselves. This presumption aligns with the comments by Mark Shuttleworth, however enterprise care even less about how a service provider deploys and manages these services themselves. If the service is available (and fast) this is often all that is required to keep a client happy.
MaaS can also be run on virtual machines or instances but why do this when any cloud host worth their salt offers templated application and OS deployments during the instance deployment phase? MaaS itself in a hosting and IT sector heavily influenced by on-demand, affordable, cloud instances is certainly a challenge. JuJu as a standalone deployment system has clearer value add but I’m sure we will see rapid development and alternative MaaS like offerings beginning to emerge in 2013.
Currently I think MaaS would be very comfortable in a lab or development environment, and this may well be Canonical’s intention. I’m sure that MaaS will develop and as suppliers with the CAPEX required to fill multiple racks get involved there will undoubtedly be MaaS based offerings released. With racks of servers waiting to be deployed MaaS services will undoubtedly be instantly deployable with a preferred flavour of application in a clustered, scalable environment. I’m looking forward to seeing how this market develops – this certainly challenges suppliers such as CatN to innovate in the ‘on demand metal’ segment of the hosting market.