Voices in Cloud is no longer active. Please see our new Podcast Voices in Innovation where GigaOm Analysts and industry professionals discuss many of the same topics in round table discussions every week. Listen Now

Podcast Episode

Voices in Cloud – Episode 2: A Conversation with Lori MacVittie of F5 Networks

:: ::
In this episode of Voices in Cloud, host David Linthicum speaks with Lori MacVittie on blogging, content, and what the metrics for success look like.

Today's leading minds talk Cloud with host David Linthicum


Lori Mac Vittie is a technologist and principal evangelist in F5 Networks’ Office of the CTO with an emphasis on emerging architectures and technologies including cloud and edge computing, network automation and orchestration, microservices, and containers. Mac Vittie writes and speaks on technology trends with a focus on impacts on the network and network professionals. She has over twenty-five years of industry experience spanning application development, IT architecture, and network and systems’ operation.

Prior to joining F5, Mac Vittie was an award-winning technology editor at Network Computing Magazine.

She holds an M.S. in Computer Science from Nova Southeastern University and is an O’Reilly author. She serves on the Board of Regents for the DevOps Institute and has been named one of the top influential women in DevOps.


Dave Linthicum: Hey guys, welcome to GigaOm's Voices in the Cloud podcast. This is the one place where you can 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, bestselling author, speaker, executive, B-list geek and joining me today is Lori MacVittie.

Lori has been an application developer, system engineer and consultant, writer, author, strategist and evangelist. Specialties include: App Dev, App integration, App infrastructure, App delivery, App security, SDN and devops. Wow, that's quite a resume Lori, so why don't you fill in, -- since it's your first time on the GigaOm podcast -- fill in the details for us. Where do you come from, what are you doing? And what do you do in day to day?

Lori MacVittie: Oh wow, so where I came from was App Dev and that led me into publishing when hands on reviews and labs were the thing. I wrote for Network Computing for a while. And that's where I learned about networking and all sorts of application of fine technologies [like], SOA Gateways, acceleration. It just married the two -- the network and the application and it just fascinated me. I went from publishing at f5 where I've been the last 12 years primarily authoring content, writing blogs, speaking, compiling data and surveys and trying to figure out how the application delivery market in general is going to be changed and impacted by technologies like Cloud, like SDN, like just application architecture changes. How does that impact the network? It's a fascinating area to look at and to  guess what's going to happen in the next few years.

So what do you think is the difference between blogging, -- say 10 years ago, five years ago and today in terms of your ability to get ideas out there and people to listen to you, things like that? I'd be interested in that because I've been thinking about it over the weekend, -- how it's kind of changed a bit.

Well you know back when you were publishing, even if you were doing blogs and articles, people subscribed to a source and it was very specific. So one, they had to find you, which was not all that difficult back then because there were only a few sources, and then people would follow rather regularly. And when we moved into blogging there was just this explosion of people blogging all over. You were never sure if it was someone officially speaking on behalf of the company or not, --that ‘my thoughts are my own’ [approach]. And it's all over and then social media kept growing and in some ways it's made it easier to get the message out, to to share content, but it's also opened up a broader audience that's very... I don't know, cynical about corporate sponsored content, with reason.

It's often just marketing content that gets out there, so today it's very hard to walk that line. If you're writing especially for an organization, you have to be cognizant of the fact that you're speaking on behalf of your company. So you know you don't want to bad mouth partners or the company itself. But at the same time you want to be honest for your customers and for the market at large to say “this is what we see happening,” even if it's not the best news or even if it's only tangentially related.

So it's it's a delicate balance and then push that out, but people prefer that. I think people are looking for honesty and just the ability to have someone talk in a... readable format about what's going on and what they see, so that they have some more insights and the ability to kind of go, ‘ok that makes sense, or that doesn't,’ or to find out about a new topic that they want to explore in the emerging space.

Yeah. I find it's just getting a little bit more difficult to get a message out there just because of the amount of noise that's out there now, because in the olden days, I used to write for PC magazine and magazine and you know Database Programming Design, and there is no internet around and no one else could write, and that was kind of cool because no one could get their messages out there. But it did take three months to get something published and then it was typically out of date by the time... and the interaction that we have now I think is probably better, -- especially the number of media outlets, like we're on one right now which is podcasting stuff, which is maybe 15 years old now and certainly the videos on YouTube and things like that and people choose to learn.

So it's just the variety of ways in which people are getting the messages out there with the amount of information and the ability to organize the information into something that's useful. I think it's going to be a difficult challenge for us going forward. Speaking of difficult challenges, I wrote a blog on February 1st, Three Ways the Cloud and Data Centers Will Work Well Together. I did this for The Info World and will data centers go away when the public cloud grows like crazy?  No votes. They're going to keep both in a booming economy, but to get them to work, to play together is a challenge. This is something I think people need to focus on more as we're dealing with complexity that exists on premise.

We're kind of replicating that complexity that exists in the public clouds and the ability to get these systems communicating together at the data level, the process level, at the network level, -- all these sorts of things is a challenge and it's almost like a Bermuda Triangle of technology that the cloud folks and the data center folks are dealing with right now, and I'm finding that at least in my client base, we seem to be separating things into different new silos, which is a little disturbing to me, -- and not necessarily trying to figure out how the on premise stuff, which is just not economically viable to move to the cloud. We just can't afford to do it based on what it costs, there's no value there. And the stuff that exists in the cloud, which is a good deal of applications out there, typically the net new and the things that were built in the last 15-20 years.

There seems to be no synergy and integration between them, nor do they have strategies, even though we seem to have the tools and technologies out there. So a question to you Lori, is what should enterprises be thinking about in terms of making that move and what what technologies are available to us at the network level, data Integration level, service level? Is this all about micro services, all about containers or is this all about dealing with a potpourri of technology and making them work and play well together?

Wow. It's hard to find an organization that doesn't already have a presence in the cloud and that's not counting SAS. So when we [do] our survey and we ask people ‘How many different clouds are you in?’ we specifically excluded SAS because everybody does that. And it's not quite the same because you don't have a lot of those same challenges that you just went through with a SAS provider. Little different challenges, data integration of course, maybe security access control, but you don't have the network and integration challenges and operational challenges that come with other clouds.

And we still find that the majority of people are running in more than two different clouds: private and something else. And usually it's private and something else and something else. So it's usually about three different clouds and they're very different operational domains. And I think what people don't think about is who and how. The difference with cloud is it expects a different skill set in order to achieve operability, so the operations teams are running in a cloud differently than perhaps the other teams. And then you've got a lack of one skill set, -- say networking -- they're really good at ops and using APIs and automation and they've got that Devops approach to dealing with cloud because it's very well suited to it, but they don't necessarily have all the network knowhow.

But the guys that do have the network knowhow to be able to deal with ‘how do I set up a BPC or integration or improve the bandwidth and the performance of apps across this WAN that we have to use to get out there…’ They've got that knowledge but they don't know how to translate [it] into ‘How do we make that work in the cloud?’ where this operational model is completely different than what we're used to. So we've got a real disconnect because of the silos that we're building where we've got a mismatch of people who who don't seem to want to come together and share that knowledge in a collaborative way to be able to make this happen. So organizations moving forward, -- if they were just starting to really get into that and look at what am I going to run into -- the first thing they should do is really sit down with experts on both sides and form a more collaborative team to go ‘OK how do we do this correctly? How do we make this actually work so that we're not creating more silos because those are hard to get rid of?’

Yeah they're very hard to get rid of. I wrote books and books and books about getting rid of them, and here they are coming back again because it does seem that we're getting into more complexity when we really should be getting into less complexity. I understand there's there's big thinking approaches to it. There's the ability to  decompose everything as micros services and leverage containers and things like that. But there's true costs and true risk in doing stuff like that for most enterprises out there. And there has to be something that comes down to do some very simple fundamentals they need to think about when they're moving stuff into the cloud.

So I think [as] I wrote about in the blog, I think first really kind of ‘think data’ and I always start with the data because it seems to lead everything along with it in terms of the bound services and bound processes on top of it. We have to think security. You have to think governance and process integration, but really it depends on who the enterprise is and what's there, and they're so different in terms of the way in which they approach technologies in the past.

Some enterprises don't have mainframes lying around. If they've been built and started in the last 30 years, they may have gone directly to distributed based computing and they may have you know 10,000 NT servers in their particular data centers and replicating those out to Azure, or replicating those out on AWS, and then trying to make them communicate one to another. I'm finding even if the technologies are analogues, -- in other words, we have Windows NT servers on premise and Windows in NT servers as virtual in the cloud.

They're still using different approaches in terms of how they manage, monitor, deal with security, deal with governance on each level and seems to me we should be thinking holistically [about] how to solve those issues instead of very tactically what we're doing now,enterprises are doing now in terms of just solving the problems, so they may modernize the security on the cloud, because everybody's paranoid about having stuff on other people's equipment, but leaving exposures out with the existing on premise systems and moreover they're not communicating one to another. There is no process integration, no data integration, so everybody is operating in a particular silo (using that word again, I guess it is a four letter word) and to make things work and play well together is ultimately going to be the challenge I think over the next five to 10 years.

I think it really is going to migrate to cloud and go ‘Oops, we need to get common security, common governance, common management monitoring…’ things like that. And by the way, we've made things from very complex using a lack of architecture planning over the years to even more complex because we're not using architecture planning [or] anything as we move into the cloud. And so then we have to kind of loop back and fix it.

And so what enabling technologies would be available to do that or is this even a tool-based thing? is this something we just have to rethink and coordinate stuff because enterprises love throwing money and tools and stuff? But I think this is a planning problem and almost a training problem. Am I off base there?

No I think it's part of both. I think you hit on it when you said “There's no planning, there's no process integration... everything that we're doing is really about a process. How do we deploy, how do we secure, how do we react?” Those are all process questions that no one's really asking before they put the technology in place or even asking ’Can this tool or technology help us in answering these questions?’ And it's really I think ‘process first.’ You have to think about what you're doing and how and then then you can start worrying about what tools you're going to use to actually achieve that.

And so I think we've got it backwards. We've got the cool technology and we go ‘Well how can we use... how can we make  use of this?’ because we like this technology then we find out it doesn't suit our purposes. The cloud native X security service that we got was great, it was easy to integrate and wonderful but it didn't actually address the policy or governance concerns that you had because it's not capable of implementing your policies that you already have. You forgot to sit down and first define what that policy is and then determine if the tool could actually implement that policy or enforce it.

You have to start with that planning. I think you're right there's a disconnect here. We just want to get out there Choosing speed is good and we want to be speedy and we want to get things to market faster, but we can't do that at the expense of losing time later. If you're just kind of kicking the can down the road... well we'll worry about that later. That never works because it's always harder to come in and retrofit something like refactor an architecture after it's in place than it is to properly plan it in the first place.

So let's give the audience something actionable. So if I'm going to go out there and solve this issue today, do I need centralized command and control, do I need training, do I need money? In many instances this stuff isn't funded so you can't get anything done unless it's funded within enterprises. Am I gonna be reactionary where I'm gonna run into an issue where we're gonna buy a company and realize we can't integrate the systems because we have all these various silos that we built in the cloud and on premise and therefore the board of directors is gonna go nuts and fire the CIO and they're gonna get new CIO and they're going to integrate everything and they're typically going to have a very short time do it. They're not gonna be able to get it done. They're gonna to get fired, get somebody else in there telling a sad story, I've seen [it] over and over again.

So what is step 1 through 3? Is step 1 having centralized command and control, step two: training people on the value of doing this (and I'm not even sure where you would get the training these days; it doesn't seem to be said anywhere other than on this podcast). And number three: put together metrics for success and so they can measure the fact that we have synergy between the existing on premise stuff and the stuff that exists in the public cloud. Or is this a lost cause? Should I quit and go find something else?

We should just quit. I mean this is just... it's been 10 years, haven't we figured this out yet? That's 10 years of cloud [and] we still can't get it. I think that the metrics piece is interesting -- that it came last in your list, because isn't that the first thing we should do is define what the metrics for success are, or at least what success looks like?

Well what I was thinking about is you've got to have command and control to get the metrics together. If there’s someone centralized, CIO or integration specialist (or whatever you want to call him or her) that's in front of the board getting funding for this? We're not going to get the metrics in place because we can't fund the consultants or fund the work or fund additional employees to come on site.

I'm not sure it's central command and control. I think it's more centralized strategy and maybe decentralized execution. So you need that roll up look. But if we think about it like an application, you can have an application that is an amalgam of many different sources of data and applications that is pulled together into this one Master Application. If you view it more like that, you can start seeing, OK, yes I need to know how this is performing over there or whether this has got the right security policies, but you can pull them from different tools or different monitoring systems in the cloud to pull them up to that kind of centralized view.

The dashboard is important for higher up, and you definitely need to think about what data you're going to need, but before you can measure it you have to know what you're measuring. So I still go back to: you need to know what metrics you're using. Is it performance? Is it security incidents management? Is it time to deploy? What are you trying to measure because that's going to determine how you collect and monitor in the first place. So if you don't know what you're measuring, monitoring doesn't really help. Then you're just getting a bunch of data that makes a pretty chart that you  can make it say whatever you want then.

So the kind of metrics I'm thinking about would be the ability for -- say the top 75% of the applications, are able to share information using a federated data access layer where the information may reside on premise, in the cloud, or even within a partner system or even on the Internet someplace, and it doesn't really matter where it exists, and we're typically able to deal with the latency stuff with a super sophisticated caching system, but that would be one, the ability to link some of the core processes, and perhaps API enabling the systems that will share information, share processes and share behavior across the networks between the cloud and on some of the on premise systems. What else would we have to do?

I know. I think in that case because you're trying to involve so many different groups, one of the things that I've seen in the last few years and we use it internally as well is this notion of an X Council. So as you're you're moving forward with an API strategy, you form this API Council as it were -- that's comprised of people, the stakeholders that need to know and need to be able to collect and report this and are actually responsible for setting some of the standards for it.

So if you're trying to standardize on shareable components across your applications or your data, you're going to want people that are touching all the different pieces of data and applications to understand what the implications are because there's not a lot of monitoring. There's no technology really that gives you that. It's more the experts reporting back in so you need them to be involved upfront, so maybe forming some kind of collaborative council, if you will, to go ‘OK these are our goals.’ How far are we from it? What's it gonna take? And then kind of setting up some standards for it for people to follow.

They need guidance, they need to understand why it is they can't just do X, and to understand that it has a business impact or a technical impact that that they need to avoid. So it's important to get that documented so people understand and have guidelines when they're actually doing the work and making the decisions in other areas of the business.

So are you really telling us to solve this by committee?

Is that what I just said? No I didn't say that. Did I say that?

Well you said a collaborative working group.

Yes I think so. You know when it comes to process, this is really a lot of process and measurement. I mean I don't know of many tools that are going to show you how much reusability you're getting across multiple different applications. Maybe there's some scanning and software that can do that, but generally that's going to be people that have to pull together that information. You almost have to get people involved and any time you say the word ‘process,’ people should be first, and your technology tooling should be second. It's really about people because that's what you're talking about is this process of how do we do something.

Yeah I think it is about people. That's why when I've had to solve these problems in the past, I've insisted on having the power over people's budgets and be able to fire the people, and you're able to get things done fairly quickly. I mean there is democracy you can set up around committees and in organizations that come together to solve these issues. But at the end of the day, if you're trying to move things along fairly quickly, there is this kind of tyrannical command and control you need for a short period of time to solve some of the issues even though it can spur morale problems and things like that.

But am I Attila the Hun of IT, if I'm doing that, or is this something that I'm actually serving the business better [by doing] or do I need to be a little bit more diplomatic in terms of how I roll this out to the IT employees?

I think it depends on how badly the command and control is needed, -- how much of that you need to get the ship steered in the right direction. If you're going off the rails already and you really need to get back in line and figure this out, maybe you need a strict: “All right here, for the next three months everyone is focused on this initiative, period. This is all we're doing and this is how we're going to do it, -- to get us back to where we can relax the rules.”.

And maybe that's the key. I mean Attila was good about celebrating too, if you ever read about him. I mean yeah, he was very ‘command and control’ but then he was very good about celebrating after everyone did what he wanted. So you know maybe you need to have that carrot and the stick when you're you're talking about making this kind of a shift and implementing these kind of policies to say, ”Look we need to do this because otherwise we're not going to make it through this challenge. So we need to be a little bit more responsible, considerate about how we're approaching this and here's our guidelines and our rules and this is what we're gonna do for three months. Let's go.”

So we went from ‘managed by committee’ to Attila the Hun. Yeah about theory X and theory Y, that's as far as we're able to do. I think this really is about people; this is not about technology and I think that when I speak with enterprises who have this issue, the first thing they want to know is what kind of tools I can throw at this. And I think the reality is there is no tools at the end of the day. You have to have your approach first, create your requirements, figure out your details and back the appropriate technology and your requirements and you'll find that there's even a lot of ‘one off’ stuff you have to do to fix it, and there has to be a lot of migration that may occur because we're on the wrong silos. You have things in the public cloud that shouldn't be there. We may think you have things on premise that should be in the public cloud and we have to make some sort of a normalization there.

I find there's no rhyme or reason in terms of what workloads and datasets people pick to move to the public cloud. In some instances it's contraindicated. So anyway, please pick up a copy of my book Cloud Computing and Silo Convergence available on Amazon and other places books are sold. Also make sure to follow me on Twitter at @DavidLinthicum, as well as LinkedIn where I have several cloud computing courses on LinkedIn Learning. Lori, where can we find you on the web?

You can find me on Twitter @LMacvittie. I'm also on LinkedIn and I blog at www.f5.com and our community site www.devcentral.f5.com.

Follow Lori, she's one of the better minds in the business, and if you see her speak, she does a great job, and so she has a blog at f5 and f5 is lucky to have you. Lori, thank you very much we'll get you on the podcast again soon. You have a good day.

All right thanks. Have a good day.

Leave a Comment

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.