In planning your application and infrastructure environment, an essential step is to determine their cloud suitability. How do you go about determining that? Since each application and infrastructure element may have its unique provisioning needs, how do you transform or modernize these elements to run on one cloud foundation? Can you plan all this upfront or have to play it by ear as you unearth the intricacies?
- George Surdu, Executive Vice President and Chief Technology Officer, Comerica
Cloud suitability is an exercise that requires a large amount of forward thinking. But it may not be a necessity because not all functions of the cloud should be positioned to become the platform for all infrastructure and application elements in the future. In this way, it would be best to approach this process in pieces rather than holistically, only focusing on the “non-core” capabilities that won’t have cause for concern.
While the financials of any shift to the cloud will improve, it’s always important to consider the confidentiality, security and safety of sensitive customer and company data.
It’s additionally key to move forward in bite size chunks because the Holy Grail for suitability standards does not currently exist across different cloud models. Simplification and standardization will always remain fundamental and a way to drive costs down and move more quickly. Just as organizations are moving in the direction of building on industry standard architectures, cloud providers are doing the same.
Speed will continue to be a primary driver of value in the organization. So a focus on testing applications and development environments will both be critical components in the development lifecycle. In addition, architectural patterns on which to build solutions on top of will set the constructs for the infrastructure.
Organizations have come a long way in recent years to create these architectural patterns and build applications on top, and in most cases it will not require a major overhaul to take advantage of the infrastructure in the cloud.
Sanjog Aul: Welcome listeners this is Sanjog Aul, your host, and the topic for today’s conversation is “Cloud Suitability and Transformation.” And I have with me George Surdu. George is the Executive Vice President and CTO for Comerica Bank. Hello George, thank you for joining us. So the topic today focuses on an essential part of planning your application and infrastructure environment, and that’s cloud suitability. It’s something that requires a lot of forward thinking and brings up a lot of different standards and questions that need to be answered. So hopefully we can clear those up today. So the first question I have for you is, cloud suitability may be a good exercise for some organizations but not all as it could be a function of cloud that is positioned to become the platform for almost all infrastructure and application elements in future. How do you determine the threshold at which cloud
suitability should become a necessity?
George Surdu: Well, let me first step back for a moment and talk about cloud computing if I could. If we had this conversation two years ago, I would have said there’s nothing magical about cloud computing other than it tends to be an ASP on financial steroids. But really over the last two years we’ve got much more serious at looking at it because the automation, the auto-provisioning and the virtualization capabilities have finally come to life. So we’re energized by it but still pretty cautious. So to answer your question directly, we are looking initially at areas that really I would call “non-core” kinds of capabilities, things that we don’t have to worry relative to privacy, confidentiality of customer data.
Sanjog: So should we be approaching cloud suitability with a broad holistic view across all infrastructure and application elements or is this a project better tackled in bite size chunks?
George: From my perspective we’re looking at it in pieces. We have a pretty robust set of applications that we deliver internally to our colleagues and externally to our customers. As a result of that there are some things that we feel may be suitable for the cloud and other things that quite frankly aren’t.
Sanjog: So could approaching it holistically make certain elements unmanageable and at risk to haunt us later? Why do we have to do this in bite size chunks?
George: I’m not sure it will come back to haunt us, but for us it’s all about the confidentiality, the security and the safety of our customer data and our company data. Almost two years ago now we took a look at some non-differentiating areas such as email and quite frankly said, “This ought to be something that we can host externally, something that we can put out in the cloud, protect it sufficiently and actually save some money.” So as we got deeper into it, what we realized was as we started adding things that really we require, things like encryption and archiving of emails, the price tag went up materially. And as a result it really wasn’t a good financial deal for us.
“There are some things that we feel may be suitable for the cloud and other things that quite frankly aren’t.”
I think over time the financials are going to improve, but we’ve got to be very, very careful in terms of what, at least from our point of view, what we’re putting out in the cloud. So if we aren’t careful, I guess it will come back at us and haunt us. But again, we’re being very careful and as a result quite frankly we’re building out our own internal cloud. We really like the automation side of it, we like the auto provisioning piece of it and the technologies that are being built in external cloud solutions are also available for companies of our size to build our own cloud. So we’re in the process of building out our “Comer iCloud” with a view that says at some point in time, we want it to be federated to external cloud solutions as well so that we, in essence, have a hybrid solution for our company. So our view again isn’t “everything is inside” or “everything is outside.” We really think that at the end of the day this technology is going to allow us to provide hybrid solutions that best service the bank.
Sanjog: Would you like to see different suitability standards for different types of cloud models?
George: Quite frankly you’d want them to be the same. I think OpenStack is finally coming to life. In a perfect world we really want our architectures and our solutions around an open stack set of prerequisites. By doing so you can more easily connect your internal solutions with external solutions and bring those solutions back in house if you decide later that they really need to be in house. So I think a standards OpenStack direction is really the way that were going to go, and I think more and more we’re going to see people are going to be going in that same direction.
Sanjog: Do you think there could be a clash between suitability standards that are being looked at from a pure technology standpoint versus another set of standards which offer more value and a better business case?
George: Well it’s a good question, and I think it’s the classic question: “Can I deliver something quicker and less costly with a point solution versus thinking of it more as an enterprise capability?” And I think over time we found out, especially in our profession, that unique solutions are very troublesome. At the end of the day simplification and standardization is fundamental in our business. It’s a complex business in and of itself, and to the extent that I’m able to drive standard solutions, I really do keep the environment a whole lot simpler. At the end of the day, that drives cost down and enables us to go faster. So that’s really what we’re looking at doing. We’re really looking at ultimately building on industry standard architectures. More and more you’re seeing the cloud providers are moving in that direction anyways.
“In a perfect world we really want our architectures and our solutions around an open stack set of prerequisites. By doing so you can more easily connect your internal solutions with external solutions and bring those solutions back in house.”
Sanjog: So if you were to look at one common cloud foundation as the final frontier, how would you actually get to see that Holy Grail when you’re just starting out? If you’re just looking at one infrastructure element or one application, could you ever reach that one common cloud foundation?
George: Well that’s why you don’t do it all or nothing. That’s another reason why we’re doing it in pieces. We’re crawling before we’re walking and walking before we’re running because that Holy Grail isn’t out there today. There are indicators that are telling us and giving insights as to what direction we should go, and I keep coming back to an OpenStack architecture. You put your bets in places that you think provide you the highest probability of success.
So the question that may come up is, “If it’s that immature, why are we even going in that direction?” The answer from our perspective is that we do think in certain circumstances it is going to allow us to go faster and is going save money. So we think it’s a direction that is worth pursuing, but we’re going to be very cautious about it.
Sanjog: Considering the unique provisioning needs and external compliance requirements for each application and infrastructure element, how would you determine which ones should be the first candidates to be adopted for cloud?
George: To put this in perspective, let me start off by telling you what we are focused on. We are focused on speed; we believe at the end of the day the real value to our customers and to our bank is to be able to deliver solutions quicker than we have in the past. So speed is really the secret sauce for us. We think at the end of the day if we can go faster, we can do more for the same amount of money or for less staying focused on quality.
“We’re crawling before we’re walking and walking before we’re running because that Holy Grail isn’t out there today.”
So with that as a backdrop, there are really two areas where we are going to start. The first is really in the test area. Testing applications is an important part of the development lifecycle; it’s a material time-consumer. So building test regions more dynamically, i.e. using the cloud, is really an area that is of great interest to us. And then the other is for our development environments, such as building out dev environments and multiple dev environments for our various development teams. We have a significant number of projects that are in flight every calendar year as we’re delivering new functionality. And building all these individual development environments is time consuming, as are the test environments.
Sanjog: Based on your experience, will you be able to get away with just tweaking applications, or will you have to go through modernization or a complete revamp of these applications and infrastructure elements in order for them to become cloud suitable?
George: On a development side, it’s pretty straight forward. We’ll have developed and created a set of architectural patterns on which we build solutions on top of today. So these architectural patterns set the constructs for our infrastructure, and it’s those same patterns that we will instantiate out in the cloud. So from a new development standpoint, it will be pretty straight forward for us. If I’m going back into the next tier of potential opportunity for the cloud, it would be to host existing non-critical applications or non-confidential applications. That may very well require some tweaking.
“We are focused on speed; we believe at the end of the day the real value to our customers and to our bank is to be able to deliver solutions quicker than we have in the past.”
We’ve come a long way in the last five or six years to actually create these architectural patterns and build applications on top of those, so unless these applications are very, very old, like living on old infrastructure and old architectures, for the most part it shouldn’t be a major overhaul for the applications to take advantage of the infrastructure that’s running in the cloud rather than in the walls of our data center.
Sanjog: What lessons have you learned in dealing with third parties or service providers in being able to keep control?
George: There are really two things. Really living your architectural patterns and your standard designs is really, really critical, such as enforcing those on our third party vendors, who are delivering either hosted or applications that we will host. The extent that we allow applications to go in or be hosted on the cloud that are not consistent with our architectural patterns will really come back in the long term to haunt us. And we really have to stay true to these architectural patterns going forward.
“The regulatory requirement that comes with the management of those applications has got to build into those contracts as well. So contracts become an extremely important part of a cloud arrangement.”
The other comment I would make relative to maintaining control with your cloud providers and third party application providers is, at the end of the day, it goes into how strong you build your contractual agreements with your partners. SLA requirements are really vital, performance and availability requirements with both penalties and rewards are really, really important. In our profession, the regulatory requirement that comes with the management of those applications has got to build into those contracts as well. So contracts become an extremely important part of a cloud arrangement.
Sanjog: While we looked at the contractual side, there may be some technological issues or hazy elements that someone considering complete cloud suitability would need to keep in mind. Do you have certain experiences in that regard? We cannot tell a provider that they are at fault if they don’t have clarity. It’s in the very process of us trying to move towards a path that is unchartered, and that’s true for both the vendors as well as organizations such as yours.
George: It’s a little bit too early for us to be in a position to have uncovered those kinds of anomalies. Our applications are pretty straight forward, and I think for the most part we found that most of that can be built into the contractual arrangements that we have. When we start getting into active applications in some of those things, I think the complexities go up and the maturity level of a cloud partnership becomes more complex, and we are just not there yet.
“From confidentiality and a privacy standpoint, we have not seen public offerings of value to us or meeting our needs, so as we begin looking at private solutions, again the cost is going up, and when you overlay other technological requirements that we have in our designs, the cost goes materially up.”
I think the bigger issue again that we’ve had has been historically, cloud providers have offered a public cloud solution in their version of a private cloud solution. “Public” meaning, you are hosting on or their hosting your applications on technology that’s been shared by a lot of other customers versus private meaning on your own hardware in their facility. And obviously the private solution becomes materially more expensive. From confidentiality and a privacy standpoint, we have not seen public offerings of value to us or meeting our needs, so as we begin looking at private solutions, again the cost is going up, and when you overlay other technological requirements that we have in our designs, the cost goes materially up. So again, we’re to date not finding large numbers of opportunities yet in the cloud space.
Sanjog: Should we be thinking far into the future based on what functionality we want to adopt into the cloud, or would it be smarter to take baby steps and move forward accordingly?
George: In our instance at Comerica, we’ve been a little bit of both. We are taking baby steps in certain areas, but on the other hand, we have a lot of confidence that this technology is going to pay off in a big way down stream. So we’ve been a bit innovative. As I said earlier, we are building our own Comer iCloud with automation and virtualization technologies that again are fundamental to external cloud providers’ capabilities. We are doing that and learning at the same time. We find that we can be much more conversant with third party cloud providers because we know from our own experiences where the pitfalls are and know what kind of questions to ask. I believe very strongly that we’ve got to put our toe in the water, and we are finding those non critical areas that we are actually going to do some of this. And it’s going to be a learning factor. So we are going to learn as we build it out internally, and we are going to learn as we partner with some our cloud providers.