New Research: ITaaS Coverage

Our second research document looks into requirements for IT as a Service and covers three of our sponsors: SIOS, Turbonomic, and Zenoss. IT as a Service (ITaaS) covers a wide range of products that monitor, automate, and manage cloud, virtual, and physical environments. The products include those for performance, capacity, and event management. We also bundle into this topic those tools that provide ways of integrating all products to preserve institutional knowledge. In previous articles, we looked at event management, security, and analytics. Now, we show the entire ITaaS coverage picture.

We break ITaaS into fourteen generalized topics ranging from application detection through security functions. Security functions, analytics, and automation figure heavily in all our coverage research and resulting graphs. Here is a quick look at our first ITaaS coverage graph.

ITaaS Coverage Graph
ITaaS Coverage Graph

As you can see, we have looked into many areas. This is one reason we use a multi-axis radar graph. We started with twelve categories and expanded out to fourteen. The end goal was to include those items that deal with the environment and those that deal with handling the data that comes out of the environment. Both go hand in hand. We found that being able to maintain institutional knowledge is a crucial component of any system.

Our categories break down as follows:

  • Application: Where we look at all things application, including determining what components are needed for a multi-tiered application—which may come from architectural decisions or be automatically determined—and evaluating associated licensing data.
  • Services: Where we look at all things services, including determining what services are needed for a multi-tiered application—which may come from architectural decisions or be automatically determined.
  • Relationships: Where we look at the relationships between objects that make up the application and where the application is run.
  • Infrastructure: Where we look various components of the hybrid cloud infrastructure and whether or not the tool uses or works within these components.
  • Metrics: Where we look at the metrics inspected within the hybrid cloud environment.
  • Views: Where we look at how metrics are viewed for the hybrid cloud.
  • OS: Where we look at how the operating system is determined and the various data about the operating system that runs the applications.
  • Communication: Where we look at the various ways the platform communicates, stores communications, and picks up external data to be used during issues. The goal of this is to keep institutional knowledge available and to provide it as the workforce changes.
  • Integrations: Where we look at integrations between vendors’ products and hardware requirements.
  • Data Path Functions: Where we look at how the data path is monitored and controlled during outages, etc.
  • Automation and Orchestration: Where we look at all things automation and orchestration of the tool and by the tool.
  • Events: Where we look at how events are handled for the hybrid cloud.
  • Analytics: Where we look at available analytics and their basis, type, and destination.
  • Security Functions: Where we look into all security functions for IT as a Service—not only at what is available, but also at how the data can be used.

Closing Thoughts

Whether the product is for capacity, performance, or general management, there are some common themes. The most common is the presentation of data so as to spark the next question one would ask of an analytics platform. These questions are ultimately based on institutional knowledge with a spark of creativity or genius. More ways to view the data offer a good set of ideas for the next question to ask of the data. How the results are used differ. Ultimately, the use will be to improve the environment, to allow more services to be run, and to smooth out the running of existing services. To get there, we still need to cover the bases. Root cause analysis is a big part of all these tools; however, we also found that root cause analysis is limited by the data gathered. Those systems that gather hardware and software data have a better chance of finding more root causes.

The entire ITaaS coverage research can be viewed at IT as a Service Coverage Report – SIOS, Turbonomic, and Zenoss 201703 as a logged-in subscriber to the site.

Share this Article:

The following two tabs change content below.
Edward Haletky
Edward L. Haletky, aka Texiwill, is an analyst, author, architect, technologist, and out-of-the-box thinker. As an analyst, Edward looks at all things IoT, big data, cloud, security, and DevOps. As an author, he has written about virtualization and security. As an architect, Edward creates peer-reviewed reference architectures for hybrid cloud, cloud-native applications, and many other aspects of the modern business. As a technologist, Edward creates code prototypes for parts of those architectures. Edward is solving today's problems in an implementable fashion.
Edward Haletky

Latest posts by Edward Haletky (see all)

Related Posts:

Leave a Reply

Be the First to Comment!

wpDiscuz