Building an IT Assembly Line


By Ephraim Baron

Any student of industrial history can tell you about the assembly line. Pioneered by Ford Motor Company, the idea was to improve manufacturing by division and optimization of labor. One of the keys to the assembly line’s success was the concept of interchangeability – the ability to make parts identical to the point that one could be swapped with another without impacting system quality.

In the software world, assembly lines and interchangeability morphed into software engineering and code reusability. Rather than hand-crafting every module and routine, a software coder relies on libraries of pre-built modules to assemble a finished product. Close examination of almost any codebase reveals that only a small fraction is original, but it forms the central glue that ties together the pre-built parts.

Fast-forward to today’s world of cloud computing and we find analogies to both manufacturing and coding. The focus of cloud providers today is to build highly-functional parts that can be consumed as services. By combining these services we can build, in essence, an information technology assembly line.

(Everything) as a Service

Cloud purists – if they exist in such a nascent world – divide the cloud into three main groupings:

  • Infrastructure as a Service (IaaS) – Abstracted facilities, compute, storage, and networking serving as a foundation for computing platforms
  • Platform as a Service (PaaS) – A development platform including database, runtime, and development tools used to build applications
  • Software as a Service (SaaS) – Application software consumed through a standard (typically web-based) interface rather than running locally

From this taxonomy, the sequential nature of cloud computing is clear:

  • the IaaS bone’s connected to the PaaS bone
  • the PaaS bone’s connected to the SaaS bone
  • the SaaS bone’s connected to the user bone
  • (Now hear the word of the Lord)

But what if we dig a little deeper?

Taking IaaS, for example, it’s possible to break the single service up into several components. To illustrate I’ll use a recognizable example, Amazon Web Services (AWS).

Within the IaaS category, they offer

  • Compute – Elastic Compute Cloud (EC2)
  • Block-based storage – Elastic Block Store (EBS)
  • File-base storage – Simple Storage Service (S3)
  • Domain Naming Service (DNS) – Route 53
  • Load balancing – Elastic Load Balancing
  • Monitoring – CloudWatch
  • (and more)

Amazon does not offer a monolithic IaaS service; it offers many component services that can be used to form an IaaS environment. A user who only needs file-based storage can consume AWS S3 without having to purchase EC2. This leads to a best-in-breed – or, perhaps, commodity pricing – approach to cloud services. If I find a cheaper/faster/better component, I can swap it into my environment in much the same way that interchangeable parts are used in assembly lines or code libraries are used in software development.

Gathering Clouds

The model just described, where services can be assembled from a variety of parts, depends upon an active ecosystem of cloud providers. The analogy I frequently use is that of a general contractor and subcontractors. Before I build a house I need to gather an inventory of skilled tradespeople: surveyors, masons, carpenters, electricians, plumbers, roofers, etc. Some of these I may do myself, and the rest I’ll sub-out. Similarly, if I want to build a cloud-based application I need a matrix of services: hosting, compute, storage, networking, etc. By integrating best-in-breed components, I’m free to focus on my core strength and my greatest value-add.

This leads to the concept of “cloud hubs“, locations with a high density of service providers. Simply put, cloud hubs offer choice. They also make it much easier to connect services together. Say, for example, you have a great idea for an Electronic Health Records (EHR) application for small-to-medium practices. Your expertise is in software development for healthcare. Rather than running your own service delivery infrastructure, you want to work with one or more service providers.

Here’s how this might work in a cloud hub:

  • Starting with a cloud management and automation platform, you design a service topology allowing you to deploy to one or more regions and/or cloud infrastructure vendors
  • Using a provisioning tool, you provision initial compute capacity. This may include storage, or you might contract for storage with a different provider. It can also include auto-scaling features allowing your capacity to scale with your load.
  • You add features like data bases, web servers, caching, and content management
  • To ensure compliance, you add a security layer to ensure you meet HIPPA requirements
  • You add an encrypted backup service for data protection and recoverability
  • Using a disaster recovery service vendor, you replicate application data between multiple regions
  • You add a big data vendor for business analytics and information management

Far-fetched? No.

All these things are available today in Equinix cloud hub data centers. We host over 300 cloud service providers among our 4,000+ customers. We give you access to nearly 700 network providers, with connectivity options including:

  • Direct connection – fast & secure connectivity within the data center
  • Carrier Ethernet – layer 2 connectivity to millions of lit buildings worldwide
  • Optimized Internet – delivering substantial improvements in performance and availability

With these building blocks, just think what you can assemble.