By Neeraj Arora, Staff Consulting Architect, Professional Services Engineering/Emerging Technology
The terms “Public Cloud”, “Private Cloud” and “Hybrid Cloud” need no explanation. We’ve come to know them to represent placement and operating models. By extension, these terms also reference financial or commercial ownership of the cloud providing infrastructure, product or software services.
We believe that there’s another distinction that needs to be made from a services perspective: whether a solution component consumed as part of a solution architecture is “Self-Managed” or consumed “As-a-Service”.
To explain this better, I’d like to present a rather simplistic overview of how solution components are consumed at an enterprise level. Note that solution components could be hardware, software or services that you procure off the shelf from a vendor, or ones that you create yourself. They may or may not break down into smaller components. From a solution architecture perspective, they’d be somewhat indivisible. For example, in developing a LAMP (Linux, Apache, MySQL and PHP) application, your solution architecture is “LAMP”, and solution components are:
- A platform that supports Linux to run the LAMP components
- One or many MySQL containers or VMs based on Linux
- One or many Apache containers or VMs based on Linux
- PHP installed with Apache
Clearly, you could further subdivide the platform, the MySQL design and install depending on replication needs, the Apache instances depending on whether they exclusively service static page requests or dynamic content requests, and PHP installations in Apache should there be incompatible extensions deployed together (competing versions, for instance). However, to understand the professional services commitment required to deliver the “LAMP” solution architecture, this level of detail is usually enough. The technical architecture will be useful and will feature later in the process.
A Distinction in Professional Services
Should you have procured professional services to implement the above LAMP solution architecture over a decade ago, you would have most likely received the following services:
- Procurement, installation, and configuration of physical infrastructure in a datacenter. You might have owned the datacenter, or you might have leased space (power, cooling and network) from a datacenter provider
- Design, deployment and configuration of a hypervisor on your physical servers
- Design, deployment and configuration of a virtualized infrastructure manager
- Design, deployment and configuration of Linux in VMs
- Design, deployment and configuration of MySQL
- Design, deployment and configuration of Apache
- Development of application in PHP
Fast forward five years, and you could have realized the solution architecture differently:
- Lease and configure Amazon RDS for MySQL
- Lease and configure Linux AMI based EC2 instances with Apache
- Development of application in PHP
In the former solution architecture, you’d be taking on responsibility to maintain each component from the app right down to the hardware. Alternatively, you could choose to lease hardware, outsource effort, or hire contractors to avoid the need to build the skillset in your organization. As you did that, you’d be migrating to the latter solution architecture. Nevertheless, the solution components would be customized to your needs.
In the latter case, however, you’re consuming well defined services that are maintained by a provider. You’d be taking on the responsibility primarily for development and maintenance of your application. And it is this last solution component that adds most value to your business.
Other than a change in the way the solution components are being delivered (public or private clouds), there’s a change in the professional services you might consume to realize your solution architecture. As you move from a component you “Self-Manage” to consuming it “As-a-Service”, you expect the provider instead of your team to perform all maintenance tasks required to keep that solution component running to a SLA.
This is the distinction we need to recognize when consuming and delivering professional services – whether solution components are “Self-Managed” or consumed “As-a-Service”.
Until not long ago, it was true that we could tether “Self-Managed” to on-premise solution components and “As-a-Service” to services providers IaaS, SaaS or PaaS. However, recent developments have led to a breakdown of these tethers.
Mapping to a Familiar Example in Networking
The distinction between consuming some components that are “Self-Managed” and others provided “As-a-Service” to create a solution is clearly evident and prevalent in the world of networking.
In running offices, an organization often leases a network connection from one or more ISPs. They lease everything up to layer 3 i.e. get a public IP presence from ISPs. However, they may often run their own network services. In this simplistic case, they are consuming layer 1, 2 and 3 terminating at their organization’s network border from ISPs.
They would then lay their own local area network in their offices (layer 1), provide switching (layer 2) and routing capabilities (layer 3) to the ISP’s connection at the network border. To complete the network and provide their offices a connection to the internet, these two solution components would be stacked on each other to complete a networking solution.
Of-course, there’s plenty of other bits that we’re ignoring, such as DHCP, DNS and NTP, to keep things simple. Should you lay out a solution architecture of say a DNS solution, you’ll realize that similar dependencies exist. The organization can run their own DNS server taking over from _*.myorganization.net_, but they would need to consume registry services via a registrar and depend on entries in the .netdomain servers, thus consuming these latter components “As-a-Service”.
Whereas this organization would “provision” their own network, they would “adopt” the ISP’s network for their network solution. Similarly, whilst they would “provision” their own DNS servers, they would “adopt” the registry’s and root level domain’s DNS services.
Let’s say this organization wants a more reliable connection to PaaS and SaaS services. They may choose to get VMware’s NSX SD-WAN by VeloCloud.
Unlike many other WAN optimization solutions (NSX SD-WAN does much more), NSX SD-WAN doesn’t need this organization to deploy both the edge and datacenter components of the solution. The customer can consume the datacenter components “As-a-Service” from VMware or their ISP and invest only in edges deployed at their offices. They would then “Self-Manage” their configuration (profiles and business policies) from within the SD-WAN solution’s interface hosted by their SD-WAN provider and provided “As-a-Service”.
When we look at the solution components from the perspective of “Self-Managed” and “As-a-Service”, it opens up our Solution Architecture to novel options. We’re now open to mixing in components from different domains and can combine them into a truly Multi-Cloud Solution that spans public and private clouds and across IaaS, PaaS and SaaS. Whereas this may increase complexity, we successfully deliver by recognizing that and offering professional services that have adapted to this new understanding.
At VMware, we implement the IT Value Model or ITVM for short. This lets us stack solution components and distinguish between “Self-Managed” and “As-a-Service” per component for components that comprise a solution stack. The ITVM also enables consistent communication across the Professional Services field. And since it allows modularization, we can help customers by swapping a component they may need to “Self-Manage” with one they can consume “As-a-Service”.
Drilling Down to Infrastructure at the Edge
Businesses have consumed infrastructure, whether deployed in their offices or remote sites with varying levels of in-sourcing and out-sourcing of effort. The graphic below illustrates some structures that we are familiar with.
The simplest of these structures is when a business owns and manages everything. Usually, they still don’t own the WAN connection since this is usually provided by an ISP.
For financial and operational reasons, many organizations choose to lease space in a datacenter to house their server infrastructure. They would also pay for electricity and cooling as services. Hardware may be leased or owned, and they might choose to maintain and administer the server infrastructure themselves or outsource it to a consulting company. We’ve illustrated one such combination in the graphic above.
In these models, we consider leasing physical space as consuming physical space “As-a-Service” and leasing hardware as consuming hardware “As-a-Service”.
Of the other possibilities, two that interest us for the purposes of this discussion and are illustrated above. In one, everything but the physical site is consumed “As-a-Service” and in another everything including the physical site is consumed “As-a-Service”. With either of these models, the business is able to focus solely on the value proposition they offer to their customers.
Whereas, businesses might run their primary datacenters in the cloud or with any model across the spectrum, at the Compute Edge, of which businesses might have many, they may benefit by outsourcing the physical deployment, installation and maintenance. This frees them up to focus on what matters most – the application their customers and staff use to generate revenue.
With products such as VMware’s Project Dimension and VMware Cloud on AWS Outposts we’re taking the distinction in professional services down a level to the infrastructure layer. Customers will soon have the ability to consume hardware, deployment, installation and management of their infrastructure “As-a-Service” from VMware.
Conclusion
By highlighting the distinction between solution components that are “Self-Managed” and consumed “As-a-Service”, we’re adding clarity to solution architectures. As our choices increase with technological advancement, it is important for Professional Services to consider what it takes to implement, enable and operationalize a customer for both scenarios; products that a customer will maintain themselves, and products where a provider takes on this responsibility.
We now have a way to capture this nuance and give customers a way to move between solution architectures that throttle consumption of “Self-Managed” products in favour of those delivered “As-a-Service” and vice versa. Watch this space for the next blog in this series that explains how we do it.
About the author:
As Staff Consulting Architect, Professional Services Engineering at VMware, Neeraj Arora leads the development of service offerings for IoT, Edge Computing and NFV. Previously, Neeraj was
part of VMware Professional Services field organization delivering integrations to Fortune 500 companies using VMware and non-VMware products. Industry experience includes gaming, utilities, healthcare, communications, finance, manufacturing, education and government sectors. Neeraj has published research papers in the areas of Search Engines, Standards Compliance, and use of Computer Science in Medicine.
