Voices in Cloud – Episode 7: A Conversation with Bobby Allen of CloudGenera

Guest

Bobby Allen serves as Chief Technology Officer (CTO) for CloudGenera based in Charlotte, NC. Bobby is a veteran of Intel, Bank of America, TIAA and multiple startups including one that was successfully acquired by the former CSC (now DXC). He went into corporate America after being an Intel fellow at the University of Michigan. He frequently advises CXO's on cloud strategy and "logical equivalents" in cloud technology. His goal is to provide data-driven output to move decision-makers from information to clarity to insight.

Transcript

Dave Linthicum: Hey guys, welcome to the GigaOm Voices in the Cloud podcast. This is the one place you will hear from industry thought leaders, providing no nonsense advice on how to succeed with cloud computing, IoT edge computing and cognitive computing. I'm Dave Linthicum—best selling author, speaker, executive and B-list geek. This week is my special guest Bobby Allen. Bobby is the CTO and Evangelist for CloudGenera, veteran of Intel, Bank of America and multiple startups including successful acquisition by the former CSC, and he's basically trying to take this whole cloud selection process really to the next level.

I had a briefing with these guys about four weeks ago. I'm very interested because I'm kind of lazy and I would love to hand off the cloud selection process to guys like Bobby and his company. So Bobby, you fill in the missing pieces: you're down in North Carolina, so how did you get to CloudGenera? What was the last five years of your life like?

Bobby Allen: Thank you David. First thank you for having me on the program. Great to talk to you. I really respect a lot of your thought leadership in the industry. You're right, CloudGenera is actually headquartered right here in Charlotte, North Carolina which we call "Silicon South" for those who don't know, and I got to CloudGenera... it'll be actually five years in August that I've been here and I got here by way of a couple other startups.

I was at a startup called ServiceMash which is in the cloud management space, before they got acquired by CSC and just really loved the feel of a small nimble company that's really attacking problems aggressively, and CloudGenera kind of fit the bill for that because one of the things I saw in the CMP space is that people were doing a lot of things, but couldn't really answer why. They didn't really have the upfront justification, they were just kind of connecting the different tech, and it was more like a science fair project than a way to really add value to the business.

And so [I] bumped into Brian Kelly, who's based right here in Charlotte, who's also a fellow Michigan grad, (Go Wolverines!) and he had built a company that was really kind of doing what I wanted to do: which is really to help people demystify things and try to take what seems kind of like smoke and mirrors in many ways in terms of cloud and really distill it down to real business values so people can have good conversations and make data driven decisions.

Got it. So CloudGen-era, that's the way you pronounce it?

Yes sir. But we're not overly sensitive about the name. So but yes, it is CloudGenera.

Yeah and the worst is mispronouncing names, specifically company names, things like that. It's not a common word but it's kind of a cool word. So this is kind of an interesting space because I've been looking at cloud governance and looking at intelligence systems and looking at easier ways to do migrations and cloud selections and my world is that I'm writing these position papers and these presentations for clients and the fact that we're trying to figure out what's the best bang for the buck, what are the best in breed cloud technologies, considering skills that they have, use cases, sectors, you know things like that; and it just seems to me that if I'm doing this over and over again there's got to be some kind of a common system that's able to provide a better jumping off point, at least even just to get to the basics in terms of what things cost to build.

And so when I saw your system the lazy side of me said “you know this would be just the thing for many client organizations who are looking to make these decisions without having to pay for guys around to do these deep analytics on these cloud technologies and typically come up with different answers.” So tell me about the technology and how it works?

So the technology again... I'd to give homage to Brian Kelly, the CEO. He actually wrote the first algorithm that we call ’cloud rank’ as a homage to Google's page rank. And so the whole point is that we want to take input from users about what it is that they want to do and then we want to align that with capabilities in the industry. So the analogy I often give to people is think of it kind of like Expedia or KAYAK, you put in your itinerary for where you want to go and then we map you to the carriers or "cloud providers"—public or private, that are going to best meet your needs.

And so to net it out: what ends up happening is we take a bunch of different factors, not just technology, which is kind of a misconception, you've got to look at security; you've got to look at service level; you've got to look at distribution of users; and you have to look at the tech stack. And part of why we look at those other things is to make sure we're looking at unintended consequences of change. So if something is cool but it doesn't have the security you want, you need to know that upfront rather than get stung by that later.

So we take all this generic input and then we map your "itinerary" or your applications to the different providers that are going to meet your needs, and then we give them what's called a cloud rank score. So that's almost like a credit score or a FICO score for cloud. And so we're coming up with this application. It’s going to have a score of 87 if you put it in this provider, 56 if you put it in this one. And those can be a mix of public and private environments across IaaS, PaaS and softwares and servers and multiple venues, multiple deployment models.

And that's really what we're trying to do is to try to give people guidance on where to put it, guidance on the configurations and the details. So for example, we're not going to just tell you this application is a good fit for AWS for every component in their architecture. We're going to tell you this component would go on a T2 micro that's going to be configured this way and cost you this much. This type of compliance is an issue in that Amazon data center. This service level criteria is not satisfied if you do single AZ, but if you do multi AZ, that's the level of detail that we get down to and we typically do that, oddly enough, in 30 seconds or less.

So our tagline is that we want to make sure that people get insight in minutes, not months. And so this should be very quick. So even in the case of something like a working lunch, you can do multiple iterations of ‘what if?’ scenarios as we interact with C-suite leaders and tweak and tune different things to make sure that we're meeting their needs. So data driven output really in seconds or minutes if you want to do more expensive things, so that people can get their information quickly. So the other way we talk about it David, is we want to shorten the distance between question and answer. You have a question; we're bringing the industry data to the table; you should be able to get details about that in seconds or minutes.

Yeah one of the things that kind of blew me away when Bobby and I were on the phone for the first demo is that when I asked questions, he would not only say “yes” which everybody says, but actually bring up a screen display and actually show me how it would work out.

So it's a very flexible system and I think is that the way that the database is designed where it's kind of multi-dimensional; where you're able to take different dimensional views of information and apply different characteristics to it. I guess at the end of the day, it's just kind of a big smart database that you guys are going to be improving over time. I'm not getting to state secrets here, but how do you guys keep up with the data, keep up with the changes out there?

Yes, a great question. So we actually have a whole division of a company we call the ‘cloud research team’ and their purpose built to keep a pulse on the market. So without giving too much away, we do kind of integrate the API with the major providers.

And so when Amazon is pushing out changes each night, we're not necessarily pushing those changes into our database every night because we run through our own QA process, but I'll say that we're aware of the changes that come and go on a nightly basis. It goes through our process and then we push it out and those guys are even good enough that when there have been anomalies, I'll call them in the pricing of different public providers they've even found those. Right? This doesn't look right: 3-year reserved pricing in Asia is never this cheap, something may be wrong. So that's something that we're not going to push out.

But that's how they stay on top of it, leveraging API for the quantitative stuff, but then also qualitatively we're trying to understand what the "logical equivalents" are, and so the example I often give is if we talk about something like geo load balancing, we want to make sure that people don't stumble on what these services or capabilities are called in different venues.

So geo load balancing may be implemented as the classic load balancing on Amazon traffic manager and Azure to use a bad example, something else in Google, something else in something like an HP Synergy, and we're going to take that requirement and translate that into what that means in each venue. And so you can really just focus on capabilities and features and business value, not acronyms and alphabet soup. And so that's really what that team does and how we try to stay on top of the market.

The other thing that's interesting though, David, is not only do we try to stay on top of what the providers are doing but we try to give you a Rosetta stone of how the different services they offer relate to each other. So for example, we want to give people a path from IaaS, the path to SaaS and backwards and forwards and their end providers. Let me talk about this for a second. If I'm looking at running maybe something that's kind of a SharePoint like application that I've grown myself, we can show you what that looks like. If you run that as infrastructure as a service, we're going to show you every node and what's going to be an F Series, versus an A series, versus a D series. We're going to give you all that stuff: storage, recommendations, networking et cetera. That all comes out...

But the engine is also smart enough to say ‘you know what? You might want to run this piece as a database as a service, because Microsoft has a great offering as a PaaS where you can run sequel server in a managed framework and actually lower your labor and have a different licensing model. But we can also map you to a FaaS like an Office 365, and the cool part about this is we can actually show you all three views of that, and put that next to something like your on prem paradigm for running out homegrown apps and give you that in 30 seconds, give you a detailed report in another 30 seconds and actually give you a take home item to share with the rest of your team.

We feel like it should be that easy to make these kinds of decisions because the data is only part of it David, as you know, the data is one factor, budget is a big factor, appetite for change, all the other cultural aspects of digital transformation. So when it comes to the data, our thing is: don't do stuff in a spreadsheet for weeks that we can do for you in seconds or minutes. That allows you to focus on the other important parts of how to make sure your organization is ready to decide what they want to do—not just to jump after something because they spent a bunch of time doing an analysis on it.

So you guys aren't replacing cloud architecture, just making their lives much easier and how they can pick the technology and understand what's going to happen and likely outcomes things like that, so it's the complexity of making those decisions which I think is where a lot of cloud architects get hung up and actually come up with different solutions.

One of the things that both drives me crazy and it's also very interesting, having run multiple cloud projects at the same time, the selection of the technology and where they go with it typically arises from the biases of the particular architects that are in there and what they know. That doesn't mean that what they pick won't work. The question that comes up to me if you're picking technology based on a bias that that's typically not going to provide you with the most efficient thing going forward. And that's kind of the same thing whether you're hiring employees or buying a car, picking anything, and so this thing kind of removes the bias from the equation. Is that correct?

It does remove the bias from it, or the goal is to remove the bias from the equation. The thing that I'll say though David, is we don't dismiss the bias, because the bias is often grounded in something that people have trouble quantifying. So for example maybe someone is leaning heavily towards VMware based solutions because that's what the organization knows. There is something that's quantifiable there because you've got to retrain your people, you've got to retool some of your automation and orchestration technology. That is something that can be mathematically quantified. And so we do a lot of that.

If you're on a VMware stack today and you're looking at a cloud provider that does or does not have VMware that actually comes out in our algorithm, we will try to quantify those biases in those gut fields and help people quantify what that looks like, because in some cases, again as you know, if you're going to move up the stack anyway to leverage things like a PaaS then the platform or the hypervisor doesn't matter. If you're going to stay on IaaS, that may matter because it could break some of your apps. So we're trying to make it as data driven as possible not to remove the hunch or the bias, but to just put a finer point on it. So that leadership has a way to make a good data driven decision.

So I guess we're talking about technical debt as well, in other words, your ability to not toss your existing legacy stuff out the window. That seems to be a huge factor that we don't think about as cloud engineers and cloud architects, and we go and talk to someone about cloud computing; we look for a wholesale replacement of everything they've bought in those five years, and the CIOs will laugh in your face about that because they've already made the investment in that they’re depreciating that, the CFOs have kind of counted in the budget. Does your technology provide the ability to in essence kind of look at the value of that and factoring in the fact we do have an existing…? I guess it does, based on the response to your last question an existing bias or an existing technical debt we have to consider and the ability to kind of look at that in terms of our decision points?

Exactly David, I think you hit the nail on the head. We're really trying to look at how a mature enterprise would adopt technology and we know there's going to be baggage and technical debt and bias and you know stuff costs in terms of knowledge base and tools. We're trying to look at all those things. So we look at this as: this is like a family who's moving from point A to point B. This is not a college student who is broke and has nothing. There are things to consider: what do you need to give away? What you need to sell? What you need to purge? What just doesn't fit in the new environment? So we're trying to look at not just the greenfield stuff but the brownfield stuff.

And so let me put a fine point on this. If you've got a legacy application, we want to ingest that information in and we can show you how well the existing providers, public or private, can accommodate that. So real world use case: If you've got an application running on Windows 2003 right now (I won't get specific about providers because I don't want to seem biased) but I'll say all public providers won't treat that workload the same way. Some will accommodate Windows 2003 and some will not. And so you might get great savings if you go to provider A, but you have to upgrade that workload to be at least Windows 2012. There's a cost to do that, so one of the things that sets us apart, David, is we look at not only the cost of the new destination but the cost of the journey.

And so one of the things that we're very excited to roll out as an extension of our platform in the next 30 to 60 days is what we call transformation cost. What is it actually going to cost me to get there and what is the payback period? If I invest X and I'm going to save Y in that venue, what is the cost of Z to get from point A to point B? How does all of that play out? And so if I'm running on a legacy operating system or legacy database, I've got something like a bare metal Oracle database and I want to go to something like a virtual Postgres and move from proprietary to open source, we can help you quantify the cost to make those changes and see if you're going to really save as much as you think you will.

So putting you on the spot a bit, I'll give you a use case. And so we have a fictitious midwest tire company, they do about $20 billion a year in sales. They're leveraging our three system that we painfully installed 20 years ago. I remember we went through that kind of pain point at one time and have very little things in the cloud, maybe a few SaaS things, are looking to in essence move their R-Tree system, move their storage systems, with their database processing from an existing data center where their lease is up to aspects of the cloud, or see the potential of cloud.

So how would your tool affect the ability to analyze the value of such change or what things would cost, or what things would be saved and shouldn't? Now take your time in your response to answer kind of a tough question.

Yeah it's a great question, David. So we we can tackle this a few different ways. Our software is made mostly to look at applications because typically the decisions are made at an application level: I'm moving this app and I'm not moving that app or this app this moving has a dependency on another app that's not. But we also look at entire data center transformations or moves where all the infrastructure, all the software, all the assets [are] going to move from point A to point B.

And so what we want to do is we want to look at, typically in the current enterprise paradigm, servers right, physical or virtual. And then we want to look at all the stuff that's running on that server: operating system, configuration under the hypervisor, compute-memory-storage. We want to look at things like networking characteristics, storage characteristics. What sort of latency or IaaS do we need to support if we're really trying to get down to quantify what do you really need. But then we also get above, what are the versions of software that you need? What are the dependencies that you have around databases and middleware and application software?

What we do David is we map those things to the different venues you're looking at, some that you expect, but then also some that you don't. And so that could be something like an AWS or something like an Azure that also could be a co-lo, like a Flexential or a Rackspace that could be or an Expedient (shout out to Expedient who's a partner of ours actually got I think named VMware Provider the Year earlier today... there are someone who has a VMware software defined stack). But then also when you think about things like the BMC and AWS. So here's a bucket of resources that I can purchase, but I can't necessarily break it down to a T2 micro type level. Well what would it look like if I took my data center, my physical data center and moved it into a software defined data center like the BMC and AWS?

Those are all things that we can help the business look at, and so here's what we often do: we'll start with whatever data paradigm they're comfortable giving us. And so that could be a dump out of ware, that could be a CMDB export, that could be something like an rb tool or RISC networks or another discovery tool that's running. We'll take any of that data, ingest it into our platform, and then will mock up or kind of model what it looks like to move those assets to each of those different venues and so the scoring and the comes into play.

But the part that I guess some of our secret sauce is: many of those enterprises like that power company you mentioned, know what they have maybe and where they want to go maybe, but what they don't have often is what is this stuff costing us today? And that's usually where these exercises lose a lot of time. So what we bring to the table, because we've been doing this for the past 6-7 years and have hundreds of thousands of scorecards, we can tell that tire company: ”Don't stumble over what Oracle costs or SQL Server or VMware. We can tell you labor rates and software rates and hardware rates. Let's give you our industry standard cost as a baseline, layer that on top of all your assets in the data center. And that's going to allow us to quickly tell you if you're going to save money or not, when you go from your data center to these other venues that you're looking at.”

And that entire process can be automated so that if people disagree with any of the assumptions, [it’s] very easy to kind of inject new expertise in there, run it again, several iterations. And literally we can do this many, many times even in the course of the week, so that people feel like they've gotten multiple layers of how to attack this in the smartest way possible.

You're giving them options, [but] you're not actually selecting the solution? That's kind of the power of the thing, right?

Exactly: recommendations, not anything that's forcing anyone to go one way or the other. And those recommendations are put in front of the customer to poke holes in because they may have certain things that come out because often when we put the first set of analysis in front of people, they reveal: well the reason why they're leaning towards one provider over another is X. That could be “we've got a licensing discount that's going to go here” or “we've got a better infrastructure discount if we go there.” So then we incorporate that back into the model, run it again, and then the recommendations are tuned up.

But you're spot on: we don't force anything down anyone's throat. We want them to have the information and make the right decision. One thing that I'll share that we've said often in the market when we talk about insight—what we're trying to do is to give people insight. And so one of our taglines is what people need is not more information only. What they really want to do is to move from information to clarity to insight, but how do we define insight?

We believe that analytics without advice is really just going to be information overload. Advice without analytics is just opinion. Advice plus analytics is how you get to real insight. So we're trying to give you data driven output on your data, but also bring other things to the table that we've seen in the market the past six years and give you real insight on how you can get value quickly.

One of the things I want to go over as the last question is: you guys are able to look at things via application types and data types, things like that and use cases, and I understand, analyze applications directly, but if you're looking at a particular online transaction processing system or a data lake or a data warehouse—it's going to have different fit, value, cost associated with it whether it exists in one public cloud provider, or the other on premise private clouds any platform options that we have. So tell us how you're doing that?

In terms of looking at those different applications? Yeah, it's it's a multi layered way to attack the problem. I think the biggest thing is, what I'll say is that people often don't even know where to get started, David. So just a couple of tips for the audience real quick: a couple of things that people miss often when they do this. I'm gonna answer your question and also give a couple of things that we've seen. Number one, networking costs are almost always missed because the reality is that the compute is what scares people, [although] security really should concern them more.

I often tell our customers that price keeps people up at night but security will turn that into a resumé generating event often. So we need to pay attention to that. But storage, data movement, networking are the things that people always forget about. So because we have a methodology and we've done this so many times, we're often asking people questions that they haven't thought about before. They're looking at how much data they need to put there. They're not looking at the different classes of storage it needs to rest on. They're not looking at the different compliance around how that data needs to be encrypted or move at rest or in transit. They're not looking at the egress charges which is really the secret killer or the hidden killer that's really burning up a lot of folks in their bills. They're not thinking about a different paradigm, right?

For a specific example, if you've got what used to be a family of applications that you now divide up, you took one part and put it in the cloud, but it's very chatty with something that sits in your data center, you're processing stuff in one place but sucking all that data back down—that could be a nightly bill for a dev team, and then egress can totally eat up your potential cost savings.

And so our methodology is... because as part of our model we're asking people upfront what is your egress? What sort of store does this need to sit on? And if they don't have the answer, then we will humbly tell them ”This is what you asked about that I'm answering but this is what you didn't ask that you should have. We recommend you plug in this assumption maybe 4x of the data that you store, you start off as egress and let's see where that lands” so people can start to visualize that there are some major tipping points as the meter's running on things like data that they didn't think about.

Now that's a very good way to leave it—it's a very valuable tool. So we'll learn about where to find you guys on the web in a second. So please pick up a copy of my book Cloud Convenience, Silo Convergence available on Amazon and other places books are sold. Also make sure to follow me on Twitter @DavidLinthicum as well as LinkedIn where I have several cloud computing courses on LinkedIn Learning. So Bobby where can we find you guys on the web and you personally?

We're at www.CloudGenera.com and specifically we have lots of videos and white papers at Resources.CloudGenera.com. I'm on Twitter @BAllenCharlotte, just representing ’Silicon South’ that we talked about and you can see us at events sometimes speaking on the queue, being at events like VMworld and re:Invent and honestly just trying to help people, especially in the southeast, make good decisions.

Yes it's one of my favorite parts of the world.  Until next time guys, take good care. We'll talk to you in about a week.