BT

Brian McCallion on Enterprise Considerations for Cloud, Hybrid Strategies, and Amazon RedShift
Recorded at:

Interview with Brian McCallion by Richard Seroter on Feb 25, 2013 |
23:19

Bio Brian McCallion is a cloud strategy consultant with Bronze Drum Consulting and spends his time advising Global 2000 firms. His enterprise experience has given him unique insights into the challenges and objectives that large companies have when assessing the cloud.

The AWS re: Invent conference is the largest gathering of the AWS community. Attendees have the opportunity to learn valuable best practices from sessions delivered by AWS architects and engineers, customers and partners, to gain experience in the Hands-On Labs, and make new connections.

   

1. My name is Richard Seroter, I'm an editor at InfoQ. I'm sitting down here with Brian and why don't you introduce yourself here for a moment?

I'm Brian McCallion, and sometimes I describe myself as an accidental Cloud Strategy Solution Architect. I've worked with, somehow, I managed to work on stage at a large enterprise. I'm the unknown, unmentioned architect of the proof of concept of $160 million application that Amazon featured prominently yesterday afternoon but I will remain nameless as far as that application is concerned.

So I worked on Cloud strategy with Fortune 500 in New York City and I've had the pleasure of being embedded with corporate IT but I also have a strong development background, so in a way I'm kind of an ambassador or a liaison. I've worked for 15 years in the enterprise, mostly financial services. I've also had a startup that was essentially a DevOps startup.

And so, I bring to the enterprise a perspective of being a person who they can identify with and who has a common experience in terms of the technology and the way their organization operates, but yet, who has taken a deep interest in development and Cloud and the kinds of technologies that enterprise considers disruptive.

I've always considered technology as being hampered by way in which it's deployed and fettered, that the business for better or worse hasn't really taken full advantage. I don't think that's the case today. But I think one of the reasons people are excited about Cloud is that they see that these shackles are coming off and they see that maybe the types of things that they wouldn't say or would be afraid to hope for are starting to become possible when we look at the Cloud kind of technologies that Amazon and others are starting to unleash.

I think there's a lot of individual freedom and spirit and expression of ideas they build and need to try things and to sort of become, or to learn and to unleash that sort of inner, I guess that inner super person that you can be or that you feel you could be if you only had the resources or if you had this frictionless world like the Matrix or something.

   

2. [...] What's the thing that still keeping someone from maybe making a big play with any Cloud?

Richard full question: Sure. So one of the big themes it seems like at re:Invent and from your background as well is that enterprise push. It's AWS, is enterprise ready, I can look at the slides and see that plenty of companies are already using AWS. From your experience though, what are those still big enterprise-class concerns you hear about either small projects, big projects? What's the thing that still keeping someone from maybe making a big play with any Cloud?

The support model is not easy to do. What you find in the enterprise is you find people who are good at supporting the enterprise stack, and also that the way enterprise technology is built. It's built that way for a reason. So it's great in the Cloud that you can do things cheaply and that if a server dies, you can basically toss it.

In the enterprise, those things are supposed to be rare. They're not actually that rare. There are a lot of things that go wrong but you don't get; those types of failures tend to be contained to specific systems. They're usually specific to an application. You don't get these large control plane or service plane-types of outages that you see in Amazon as it experiences this hyper growth phase.

And so, it's very difficult for an enterprise to understand the support model in the Cloud which is to my mind, it's automation that essentially nobody should; so enterprise basically wants to log in to Cloud instances and run scripts and do troubleshooting, figure out what's wrong and maybe fix it. And in the cloud the, perhaps better approach, which is unspeakable inside the firewall, is to simply terminate the instance.

And so, part of the issue is that the way that enterprise tends to gravitate, and this isn't simply operations, this is also the developers. The developers like the Cloud because they get instances and they can do things. They don't have to wait, which is great. But on the whole, in enterprise, their interest in infrastructure and architecture stops right about there. So auto-scaling and high availability, those types of things are not their primary focus, they tend not to get done.

In this great rush to seize resources, to be able to build something quickly and then get it done, at the end of the day, the types of operational concerns are often left undone and it's not that easy to go back and retrofit an application. So whether it's built by the development teams in the Cloud from scratch or whether it's something that's being migrated, if you follow the enterprise paradigms, it doesn't work the way people think it's going to work. You don't get the kind of efficiencies that you expect.

People at this conference and on the whole, people who speak about Cloud, talk about the cost of resources. They talk about the CPU. They talk about memory. They talk about network. Those kinds of costs are really very, very tiny compared to the cost of supporting. So, Tiffani from Gartner was presenting yesterday, and she showed this chart where you see 70% of the cost going towards running the applications.

So if that's 70%, then getting cheaper bandwidth is not going to lower that cost. It's arguably designing applications so that they can - not just so that they can scale. So auto-scaling in my mind is not about, at least in the enterprise for most of the apps that they have, it's not for achieving a massive scale. What it really is, it's about designing for failure, designing an application to be resilient, designing an application so that it's autonomous.

So that if something fails it can be restarted without having to open up a Remedy ticket and then escalate to three different people and dig them out of bed at three o'clock in the morning and have them log in to the box and try to fix it. That kind of stuff is really expensive. I think that's where enterprise really needs to focus is, it's great, this concept of lift and shift and let's do some development. But I think in order to really drive the value from the Cloud, I think that it's necessary to fundamentally change the way they're designing applications. They don't necessarily have to completely change the stack but they may have to build applications differently.

So for example, WebSphere clusters and WebLogic clusters, they don't play that well in the Cloud. Those types of application servers are really designed for a static environment, where in order to buy or bring another node online, it takes three months. In that situation, that type of paradigm is okay. It's still not great but it's acute in the Cloud once you start to try to add and subtract things that there's just, it doesn't really work. There's a lot of overhead, it's not very easy to do and it's a questionable value.

   

3. [...] Should I be targeting the newer apps that I can build for cheaper run by putting them in the Cloud?

Richard's full question: Some great points in there. So you're calling out some of the differences between, obviously, greenfield apps building from scratch where I can take advantage of Cloud scale or building for failure and trying to reduce, as you've said kind of 70% run cost where that's where the real savings are, not necessarily cheaper bandwidth, it's how this operation is easier. So what do I do with my legacy apps? Do they stay in my data center? Is it worth shifting those legacy apps so I get to realize the benefit by putting that in an AWS or a Google Compute or putting Azure? Or should I be targeting the newer apps that I can build for cheaper run by putting them in the Cloud?

In the enterprise, I think Cloud can work great with legacy apps but you have to look at it from a slightly more holistic perspective which is that you also need to move your data and that's what enterprises really have is they have is they have data already because they've been in business for a while. So inevitably, they have data and that data is in databases. And so, if you have Oracle RAC which a lot of enterprises have, that's not something that runs very well in the Cloud.

So you either need to find a strategy, like a direct connect where you can place that you can decrease the latency and increase the bandwidth between yourself and your Cloud service provider. There are some enterprise Cloud providers that are very close to major hosting firms like Equinix or CoreSite, I think those are the types of things that will make it more appealing for enterprise to run applications in the Cloud is that if you can, the more that they can understand this latency issue and address it with solutions that have basically become available within the last 8 to 12 months.

It has become a lot friendlier for enterprise to deploy real applications in the Cloud because it's easier for them to move their data and to be able to get the kind of response times that they need. I also think that enterprise should be looking at integration technologies. So something like Informatica, or Dell Boomi, or other solutions for taking existing data and being able to synchronize it out to the Cloud.

So beyond data, I think, is identity management. So, Corporate America has all their stuff behind their firewall. They have their Active Directory. They have their LDAP. They have their Oracle Access Manager and they have their Tivoli. They have these existing solutions; I actually haven't ever worked in an enterprise where they had this concept of single sign-on. Basically, they had some sort of a kludge where you were taking data from one system and sort of copying it or synchronizing it. I have never been anywhere where there was a real single sign-on.

So if they can't do it behind the firewall it because, invariably, enterprise is complicated. They do a lot of acquisitions. It's not an easy problem to solve. But once you start trying to do business in the Cloud, you've got to ask yourself, "Okay. Well, why am I doing business in the Cloud in the first place?" And so, "Am I going out there for the cheap bandwidth? Am I going out there for the cheap CPU, for the cheap storage?"

My argument is no. I think that there's another reason that will come perhaps in a second wave which is that when you take your data or your services and you make them available to start playing in an ecosystem, then you create this crowdsourcing model or this opportunity where other companies can - and it could be just two people or one person or a guy who's doing it part-time. He sees a way to use your service or your data in a way that your team of 50 people dedicated to solving this problem never will.

So what identity management enables you to do, and this is a hard problem to solve. But the reason it's a good problem to solve is because I think that the enterprises who do solve this problem, who are able to suddenly start doing business in a system that doesn't have clear orders that's based on rules and based on access and a more dynamic type of security and identity management. I think solving that problem enables very, very massive, multiple in the value of the data or the value of the services that they have behind their firewall.

So I think that that's a problem for enterprise that enterprise needs to solve but it's also a huge opportunity and so, those were some of the things.

Richard: Yes, that's great. I mean, you're also pointing out again this kind of a hybrid future to some extent. It seems like one of the hardest things about moving apps and even new apps to the Cloud is that no app is obviously an island. I mean, even the simple E-Commerce site has got to talk to inventory and shipping and catalogs.

   

4. [...] I mean, are systems going to get a lot more complicated?

Richard's full question: So I mean you've got to move stuff, if I move a legacy app, I'm probably moving integration points. I'm moving identity. I'm moving all sorts of things. So if it's not realistic that's almost going to shift their entire data center somewhere then you've got to do this hybrid thing. Is that what you're seeing when you talk to folks, is you've got to kind of piecemeal and say, "This is going to stay here, this will stay here, this is where we have to bridge latency problems or we might just do caching." I mean, are systems going to get a lot more complicated?

Well, I think they seem complicated if you try to use the same approach. If you think that all the infrastructure that you need is the infrastructure that you'd provision and build yourself, then I think enterprise applications are extremely complicated. I think one of the strategies that the enterprise can employ or embrace to make it a little bit easier is to think about Cloud in terms of consuming services. So it's not just Software as a Service but identity is a service.

So rather than standing up your own infrastructure, like if you look at identity management as, "I need three servers and I need this installed on them and I need to back it up," then that makes it very slow to the deploy your enterprise application. So where is all the speed if you have to basically drag forward all these systems that are already being managed and have already been built, and now you have to essentially replicate that in the enterprise.

If you try to do that, then it's going to slow you down enormously. If you embrace the concept that in the Cloud, really what I think we're doing and this is a big change, is that the way we're building applications is we have some specific business problem that we're trying to solve or objective. And to do that, we choose the best services that are available. So if it's something that doesn't exist or we absolutely feel we have to do it ourselves, then you can provision an infrastructure.

But I think to the greatest extent possible, what you need to do in the enterprise and other businesses is you need to consume services. So you need to embrace a whole new world of vendors that goes beyond maybe the four or five enterprise infrastructure service vendors that you've looked at and are comfortable with, and you have to really start looking at who are the best service providers in the Cloud that are available in your Cloud.

And the other interesting thing is that latency works as your friend when you work that way. If you can find a service that's running in the same Cloud then the latency issue is gone, whereas if you try to run that, if you try to access that service from your web server and make a call all the way back over your VPN back to your access manager that's in your data center, then you have the latency working well against you, and Amazon charges you for that too.

So, I think they're giving you a hint but I don't think it's about the money so much, is that essentially it's this sort of a prod or maybe a guide mark that, well, it's like also the Roach Motel in a sense that the more stuff you get into a particular Cloud, the more of a gravity that data has, that it will pull more data. So for example, what was this? Was it Red Lift? Red Cliff?

Richard: Redshift?

Redshift! Yes, Redshift. I mean, that word "Shift," I think that word "Shift" really applies to shifting data out of the Enterprise into the Cloud where you can now start running these analytics on it. That's an application that I see is pretty interesting to the enterprise. I think that we're going to see that, pulling information out of the enterprise into the Cloud, and that in order to load those data warehouses. I think enterprises are going to start deploying things like cross connects or direct connect in order to be able to open up the bandwidth and reduce the latency so that they can constantly reload these systems.

It's also a great service for the midmarket and I think it's going to be a really compelling application for a lot of businesses that up until this point haven't really explored the Cloud. And, again, it's a service. So that's what's great about it, is you don't have to build it yourself. You can start using it. And I think that's what people want is they want time to market. They want agility. If you try to do it the old way, like take all your stuff and rebuild it out in the Cloud, that's extremely slow. There's no reason to think that it's going to be any faster.

So for VMware where I've seen - I've been in companies where it takes three months to just get a virtual machine provision. So, virtualization in itself does not get you the time to market or the agility. It's really starting to rethink from a server-centric to an application-centric vision of an application, or the application ecosystem, or the business, if you will.

Richard: Yes. I mean, we're seeing the real-real value of SOA finally taking shape. But also now, with this added dimension though of networking and distributed systems, like just understanding SOA won't be good enough when I might naively have an architecture diagram that has my service on-premise talking to my data center in US-East then all of a sudden, yes, it's SOA but I completely hosed the performance I guess.

Exactly.

   

5. Do you see that the skill set of architects of , I mean, where is the role shift to kind of have to take place so that somebody who just knows good architecture also understands good network architecture and engineering of an actual solution?

Well, people use the word "flattening" a lot and I think that's for sure. They talk about T-shape. I think people working in technology will need to be much broader in that. It goes against the overall grain of the enterprise which is to define very, very specific roles and to have many different roles and to require many, many different people to; so you have a storage person, you have a security person, you have a server engineer, you have an application engineer, you have a network engineer, you have a firewall engineer.

Right now, the other problem is that for all the computational power that corporate IT has within its custody, the business has all the really cool apps. So, on the whole, the corporate IT has spreadsheets and doesn't have these nice ERP applications for managing and monitoring the workflow of systems as they are - it goes through the build phase, from development to production. There's very little workflow and automation there. A lot of it is painstaking manual work, emails, meetings, phone calls. That is something that's probably going to change over time.

So the roles are going to change and they will probably flatten. I think if nothing else, the Cloud is a really great model and that it shows you the value of wrapping an API around the infrastructure. I think that overall, some of the big acquisitions we've seen in networking as it moves from hardware to software, maybe we won't see those things manifest themselves right away in the enterprise. But I think that it's pretty clear that the genie is out of the bottle that it's not going to go back to the same way that software is going to essentially be the wave, the future, the hardware that can't be scaled or provisioned easily through an API or that has guardians.

So people talk about the mainframe for example, I think of the old mainframe days and you have these high priests of computing. I think what I see for the most part is I do see enterprise essentially trying to do like-for-like the Cloud. So, I think one of the reasons that presently Infrastructure as a Service has been popular is because it's easy to say, "Okay. I've got one of these in my data center. I'll get one of those in the Cloud."

And so, I think that's the way in which it sort of is the comfort zone. But as far as what surfaces would the enterprise be looking for in the Cloud? Security services I think are useful. I think what I see a lot of is monitoring. I think CloudWatch is okay. Generally, enterprise wants to be able to take information that they've got in the Cloud and integrate back into their own systems and CloudWatch generally is great in so far as it's sufficient in some ways but it's not what enterprises used to. It also doesn't really look at the business value of transactions.

So, I think one service that would be interesting, although, it may not be immediately on the people's shopping lists. It is some way of taking the resources in the Cloud and associating them with the business value of the application. That might be an interesting service for enterprise. They like to look at ROI. I guess everybody does, right?

General Feedback
Bugs
Advertising
Editorial
InfoQ.com and all content copyright © 2006-2014 C4Media Inc. InfoQ.com hosted at Contegix, the best ISP we've ever worked with.
Privacy policy
BT