Utilize as-a-service approach to virtualize infrastructure, platform and automation functions

Problem

Deployment of IT platforms requires a combination of physical resources, such as servers, storage and network; together with infrastructure and platform functions such as load-balancers, routers, message queues, monitoring, etc. Cloud-based solutions deployed in conjunction with virtualized resources require the same functions, with the added requirement of automated, on-demand provisioning and de-provisioning to meet changing demand patterns.

Solution

Design IT functions as-a-service by abstracting out the core and management behaviors of the function into a service interface. The management interface should provide basic capabilities to provision, configure, set access controls and monitor. The functional interface should provide access to the core operations that the function is purposed for. By decoupling the interface from the function and providing API compatibility with industry implementations , the function can be enabled to scale horizontally, provide a consistent interface and be highly available.  The interfaces must be accessible through direct, proxy or multiple protocols depending on how the function is used.

Click to Enlarge

Application

Impacts

• The interfaces may not provide access to all the underlying behaviors, as all implementations may not be the same

Anti-Patterns

• Direct access to the function and its behavior, with manual administration. Dynamic scaling may not be available
• Multiple implementations of the platform functions leading to inconsistent behavior

Related Patterns

Service Implementation Patterns

• VM Blueprinting Pattern
• VM Factory Pattern
• VM Façade Pattern
• VM Pooling Pattern
• Stateless VM Pattern
• Instance State Management Pattern

Service Management Patterns

• Provisioning Pattern
• Configuration Pattern
• Access Control Management Pattern
• Monitoring Pattern

Service Interface Patterns

• Direct Access vs. Proxy Access
• Language Specific Access (Java interface, C# interface)
• Simple Query Access (AWS Query, REST, etc.)
• Fast Data Access (Google Protocol Buffers, Thrift, etc.)
• Fully Decoupled Access (WSDL, SOAP)
• Multi-Access (language specific + simple query + etc.)

Example: Load Balancer-as-a-Service

The following example depicts a load balancer delivered as a service. The service exposes two sets of interfaces: the first is the functional interface that enables direct access to the load balancer for in-bound data; the second is the management interface, which allows a client to remotely control administrative aspects of the service. The management functions that are exposed include the ability to validate authorized users, provision a load balancer, monitor the health and to modify the configuration. The implementation of the LB-aaS may use very different techniques. In this example, the service chooses to use a virtual machine centric approach to resolving the non-functional concerns. Hence, it implements a set of patterns which enable scalability, high availability, efficient resource consumption, etc. all through VM patterns.

Click to Enlarge

Example: As-a-Service Direct Connect Pattern

The following example depicts a scenario where a “caller” (e.g., an application using the function) makes its calls directly to the API exposed by the underlying implementation. For example, a Database-as-a-Service might provision a new database instance and then allow applications to connect directly to it via traditional means such as JDBC. The advantages of this style are: 1. All functions of the underlying implementation are available to the caller; and, 2. since the caller doesn’t have to go through an additional proxy layer, no extra latency or failure point is introduced. The disadvantages are: 1. Calling applications are more tightly coupled to the implementation; and, 2. connecting directly to the implementation may limit scalability, high availability, etc.

Click to Enlarge

Example: As-a-Service Proxy Connect Pattern

The following scenario depicts an example where all callers/consuming applications make their calls to the exact same service (in an availability zone).  There is never a need to ‘provision’ an instance of the service for your application needs. Instead, the service is always running and shared. You only need to provision a slice of the service for you to use (e.g., a topic in pub/sub, not an entire pub/sub engine). The advantages of this style are: 1. You own the service interface and can swap out the underlying implementation to fit your needs; and, 2. complexities associated with the management of VMs or instances are hidden from the developer. The disadvantages are: 1. Designing massively scalable, highly available services is very complex; and,  2. the implementations are typically forced to compromise features (e.g., message queues not in order, DBs are eventually consistent.)

Click to Enlarge