As VMworld starts this week I'd like to follow up on my last post on SDDC solving fan-out problems. I closed the post by showing the diagram below and asking whether or not an application manifest can be automatically generated.
It is possible to infer an application manifest based on what part of the business value chain it belongs to.
For example, consider the proper placement of a marketing and sales application within a data center. This application ingests massive amounts of market data and then stores it in a format that assists internal business operations. Based on this high-level description, I can infer that this application contains a component known as a message gateway.
In a previous post I shared the following description of a message gateway, and then attached a table displaying the functional profile for a message gateway:
A Message Gateway is a connection point between applications inside the company firewall and EXTERNAL applications (e.g. Markets, Clients). The main task of a message gateway is to mediate protocols that require handshaking with strict rules around response times, response sequences, reactions to failures and the translation formats and semantics. Sometimes these gateways are used internally to support STP (spanning tree protocol) efforts, with little user intervention.
In this post I'd like to reference the table below as a means of begining to understand how EMC Adaptivity can automatically map applications and data to the best-fit infrastructure. Here are a description of the qualities from the columns above:
Message gateway functionality, therefore, creates a workload demand that is characterized as follows:
- Unit of Work Appearance (High): Message gateways are highly involved in the main flow of work. This is due to the fact that they are constantly performing protocol exchange and conversion between elements inside and outside of their company. Example of functional patterns with a low unit of work appearance would be exception handlers.
- Unit of Work Apportionment Across Instances (High): The message gateway workload is split across the number of instances of this element.
- Unit of Work Effect on CPU (Low): Mediating protocols, handshaking, and translating work done by a message gateway is typically not CPU intensive.
- Unit of Work Effect on Memory (Low): Data is just passing through and not collecting in memory.
- Unit of Work Effect on Disk IO (Low): Disk IO is also not heavily generated by message gateways.
- Unit of Work Effect on Network (High): This is where the message gateway is doing most of its work.
- Variability of Usage: for nearly all components, the variability of usage is low, with the exception of the CPU, which is "fluctuating".
In general, if we can infer that an application is located logically between Marketing/Sales and Internal Logistics within a Business Value Chain, then there is a good chance a message gateway is involved, and we have a well-known workload profile (the yellow columns above) that can inform the mathematical algorthms of an SDDC.
If we can actually specify the design patterns (as opposed to associating) involved in a deployed app, then we can do much more fine-grained placement. I'll address this aspect in future posts.