In this video we show how to leverage a popular Service Management tool such as ServiceNow as well as Ansible to allow end-users to consume on-prem physical IT resources in a cloud-like fully automated fashion from both the web interface and their mobile app. When people talk about IaaS (Infrastructure as a Service) they typically refer to provision virtual machines. So for the lack of a better term we will refer to our “physical IaaS” demo as BMaaS (Bare Metal as a Service)
Introduction
As more and more organizations are experiencing the true cost of public cloud the mantra has been shifting from “we have a cloud first strategy” to “cloud is not a place, it is an operational model“. It is no surprise that these same organizations are repatriating workloads to run in on-prem infrastructure because the financial benefits are not there for most workloads. However, the expectation is to have the same cloud-like experience from their internal IT department. So, what are the characteristics of such experience? In other words, what are the pillars of that “operational model” they are looking for? They are primarily four:
- pay per use
- infrastructure maintained by the provider
- automated agile provisioning of resources
- self-service consumption for the end-user
Pay per use
Most vendors have stepped up to offer flexible pay-per-use offerings that can be provided on-prem or at a co-lo and are maintained by the vendor. One such example is the recently announced Dell Technologies APEX
Agile automation
When it comes to provisioning resources the expectation is that most resources, specially the simple ones will be available a few minutes after the request, rather than in days or weeks. This is perfectly possible by using modern automation tools that follow the Infrastructure-as-Code paradigm. These tools, in many cases originated in the configuration management space to configure operating systems and applications. Over time they evolved into full-stack automation tools. Nowadays they can also manage physical infrastructure components by using their RESTful API under the covers. So as long as this or that piece of infrastructure has a RESTful API, it can be automated, it doesn’t matter whether it is physical or virtual infrastructure. A tool that comes up more and more frequently in conversations with customers is Ansible. Ansible is what we have used in our video demo
Self-service
Finally, we have the self-service experience. Let’s face it, we are now used to consume everything (from groceries to holidays and everything in between) online and by ourselves. The same expectation applies to infrastructure resources. Most companies already use tools like ServiceNow to enable employees to order their own laptop or mobile phone, so why not leveraging the same portal to consume IT infrastructure resources? This self-service experience is a critical element of the overall digital and IT trasformations. Furthermore, a frequent mistake many organisations make when considering automation is to focus on the “infrastructure engineer“, ie automate to reduce repetitive tasks. This often results in each different IT infrastructure team automating their own silo, while keeping in place inefficient inter-team handover processes.
A true cloud-like experience means that we must put the “end-user” in the driver seat and offer higher level offerings in the service catalog. The end-user doesn’t know and doesn’t care about details of the infrastructure such as LUNs, zones or VLANs. These higher-level offerings will typically require automating multiple layers of the stack in a way that is transparent to the user.
Conclusion
In previous blog posts we have seen examples of how to enable this cloud-like experience for IaaS, STaaS and applications. The question was, can we do the same for traditional bare metal infrastructure? As we have explained in this article, ultimately, automation is about using a tool to interact with a REST API, it doesn’t matter whether it is the REST API is of a physical or a virtual piece of infrastructure. So the answer is “yes, we can“.
To learn more
During the creation of this demo we had the opportunity to play with technologies that we hadn’t played before and we learnt a ton. We have documented all the technical lessons learned. However in order to keep today’s post more high level we have posted those learnings a separate posts:
{{ vExpose }}.Blog 