We get questions regularly about the difference between the industry standard Infrastructure as a Service (IaaS) provider Technical Account Manager (TAM) and the Foghorn specific FogOps Technical Account Consultant (TAC).  The truth is that even though these acronyms are only one letter off, they couldn’t be farther apart in terms of what they deliver and the benefits that are realized.  In fact, most organizations that are leveraging an application stack in the public cloud could likely benefit from both TAM and TAC services.  This article explains the differences between the two offerings and how to ensure that you have a support and engineering model that ensures success for your application’s full stack in the cloud.

TAM Backstory 

The traditional TAM offering was born from the need for additional, white-glove, manufacturer/provider support  that allowed enterprise customers to get an increased level of assistance for the products and services they used in their information technology environment.  Familiar examples include operating systems providers like Microsoft and RedHat, hardware companies like NetApp and cloud service providers like Amazon Web Services (AWS) and Google.  In the world of cloud, escalating vendor support tickets, providing additional non-public insight into bug fixes, escalating root cause analysis (RCA) and helping to provide product and service roadmap insights are common industry cloud IaaS provider TAM services.

Since the term TAM has been adopted by lots of technology companies for many different varying services, and since Foghorn is a cloud company, I’ll focus my comparison around IaaS provider TAM services.

The Challenge

Like the support services they oversee, the cloud IaaS provider TAM is able to provide guidance, advice and information.  But when it comes to leveraging those things to provide hands-on engineering, configuration, upgrades, etc., the TAM is usually not contractually able to assist.

Cloud vendor provided professional services are usually available to provide hands-on expertise to attempt to pick up where TAM’s leave off.  However, the many layers (and accompanying vendors) in most application stacks along with the desire for more enterprises to leverage multiple cloud providers results in the need to leverage multiple TAMs and multiple vendor-based professional services groups.  This is far from ideal given the expense and common finger pointing that occurs among providers.  Best case, your project’s velocity suffers while the various groups figure out how to work together towards a common objective.  Worst case, your site’s environment suffers from availability, security, and/or performance issues caused by gaps among vendors.

Enter FogOps TAC

A FogOps TAC picks up where the cloud TAM leaves off, providing a named Consultant who bridges the gap between advice and execution in a multi-cloud, full stack environment.

Similar to a TAM, but with multi-cloud capabilities, a TAC can join customer work sessions, presentations and meetings and ensure that financial commitments with pay-as-you-go services are continually optimized.   Additionally, the TAC can actually implement best practice advise and solve engineering challenges.

Best of all, there is no finger pointing, or lost time due to gaps among providers since there is one named resource looking out for issues site wide and stack deep.

The most visible and immediate benefits are increased velocity and inter-operability cloud wide and stack deep.  But easily taken for granted is the value realized from the TAC’s leadership and technical project management capabilities–none of these projects matter if business value is not realized and the TAC ensures that happens.

A few brief examples to help illustrate:

• Resource Emergency! – Let’s consider the example of a cloud provider who has some sort of cloud resource limit that cannot be exceeded by their customer.  Theoretically, a cloud provider TAM may work to escalate an exception to this limit, but in some cases an exception may not be possible.  The TAM will explain the situation and possibly advise the customer on a strategy to circumvent the limit through best-practice, cloud-provider recommended engineering and architecture.  The TAM’s role in this situation likely ends here and that’s where the FogOps TAC continues.  After confirming the strategy won’t have adverse impact, the FogOps TAC executes the required engineering, likely involving changes to automation code.   No finger pointing, no delays, with the breadth and depth of the site taken into account.

• Scaling is Broken! – Now consider an auto-scaling environment built according to IaaS provider best practice.  All works well except for the larger than anticipated IaaS usage charges.  Streamlining the entire system from web server configuration, to auto scaling rules, to server bootstrap process would be a typical FogOps TAC activity.  The result?  Seamless scaling and more connections per server, increased site performance and reliability while simultaneously reducing IaaS cost and usage.

Engineering and Support Models

A common and successful enterprise cloud support model includes IaaS provider enterprise support along with a FogOps TAC for hands-on, full stack architecture, engineering and execution.

But what happens when one named resource is not enough and your desired velocity exceeds your ability to execute?

That’ll be the topic of a future  blog post.  For now, I’m off to enjoy the next episode of Westworld!