Private and public clouds can pool and abstract data storage, but the physical location of mission-critical data is of paramount importance to financial services providers such as State Street Corp.
That's one reason why it was an easier proposition for State Street to launch a private cloud, where it has physical control of the infrastructure. The Boston-based company does not use public cloud storage and is actively exploring the possible migration of only "more general data," according to David Saul, senior vice president and chief scientist.
Saul discussed State Street's private and public cloud philosophy as well as the company's use of open source OpenStack cloud technology during a break at last week's Cloud Industry Symposium in Boston. The symposium was held in conjunction with the technical meeting of the Object Management Group (OMG), a nonprofit trade association. Saul is co-chair of the steering committee of the Cloud Standards Customer Council, an end-user advocacy group formed under the auspices of OMG.
How do you view the cloud in the context of major technology shifts over the years?
David Saul: In a lot of ways, the cloud creating a shared environment is like going back to the mainframe. What you want from a really good cloud in terms of real separation of the workloads and very good security [and] high reliability -- well, you've just described the mainframe. We don't have any immediate plans to retire our mainframes. They're doing a really good job on what they're doing, and at a price point, they're competitive.
I think the cloud is certainly a major transformational change, but I also think that it's in a lot of ways consistent with the path we've been on for the past 30 years for computing. I don't hold to 'The cloud changes everything.' It changes a lot of things, but it's not an entirely new way of doing things.
State Street has been active in the OpenStack community. To what degree is OpenStack changing the way State Street does storage?
Saul: Our cloud project got started probably four years ago, and from the very beginning, we didn't view it as a cloud project focusing on the commodity hardware connection. From day one, we always referred to it as 'stack in cloud.' And the fact that the stack comes first shows that our emphasis has always been on the software stack.
If any State Street data is being stored externally, that kicks up a whole due diligence process up to and including a physical site visit to see what the surroundings are.
senior vice president and chief scientist, State Street Corp.
We have our own software stack, a lot of which is open source. Our stack is the stack we developed ourselves prior to OpenStack being available. It matches up in a lot of places, but in others, it doesn't. It's a platform as a service stack [with] Linux, lots of other open source pieces for Web services. It's all designed to be service oriented. From the very beginning, it was designed so that applications could be developed against this software stack and deployed in minutes.
Today, it's in-house on a private cloud, which is commodity hardware. And what an application developer today can do -- and this is all defined in terms that developers understand, the set of services that are available to them -- they can write an application and go from development to test to production, promoting this with a set of services that are completely automated. But to do this and take advantage of this stack, they can't do things like lock in specific storage. Everything's done with a service call, and that extends to security. Authentication is done with a service call.
Was the main impetus for the project to speed application development?
Saul: You hit the nail on the head. It was to be able to respond to requests from the business much more quickly. If we're able to identify a business opportunity and are the first ones to come to market with a solution, then that immediately establishes us as a market leader. And more and more, those things are in the data space.
How does State Street determine which applications are good candidates for the cloud?
Saul: The architecture group has come up with a series of questions to ask about an application to determine, on a scale [of] 'Is it extremely well suited to go to the cloud right away?' to 'It can go to the cloud and maybe get some benefit from commodity hardware, but it would require too much modification.' One of those points is: 'Is the processing separated from the data?' And if it is, right away it's going to go into the category where it's [better] suited to the cloud.
Does State Street use public cloud storage?
Saul: Not yet. We are actively seeing where we could migrate. But, as we migrate, it's still going to be under our orchestration model, so we'll be able to move back and forth. The model we've got, think of it as concentric circles where the middle of it is the crown jewels. Those crown jewels -- data -- would not move off premises. In some cases, regulatory constraints say it can't move geographically. Data for this country has to reside in this country.
We're actively looking at creating that hybrid cloud environment as you move farther and farther out and get into more general data, or you get into development and test where you're dealing with synthetic or masked data -- and we're a big user of encryption -- and it's more economical to do it externally because you've got different service-level requirements.
What's the philosophy behind State Street's private cloud storage?
Saul: Conceptually, architecturally, we think that along with the processing cloud, there's a data cloud. I don't think it gets as much attention as the processing cloud, but it's clearly just as important. That data cloud -- where it physically resides -- is in a lot of different places. The more you can separate the processing from the data, the more you're able to take advantage of the processing cloud. The more the data is tightly wedded to its processing and has to travel where the processing goes, the less able you are to take advantage of cloud technologies.
Does State Street always view the cloud holistically, as computing and storage? Or do you sometimes look at cloud storage separately?
Saul: We always try to look at it holistically. But there are some software services that we get from an external provider who writes on the cloud. Probably the best example is some of the human resource applications. The retirement plan runs on an external site. That's software as a service. Clearly there's data, and that data resides in the cloud, but it's part of the service. It's not really visible. Now, we still go through the due diligence to make sure it's secure and backed up. But the ordinary user doesn't see the underlying storage.
We have our own risk-assessment management program, and I spent six years as our chief information security officer, so I'm very familiar with the program. One of the very first questions we ask is: Is any State Street data being stored externally? If it is, that kicks up a whole due diligence process up to and including a physical site visit to see what the surroundings are.
You always have to think about where the data is, no matter what you're doing.
Saul: That is at the top. Think of the data as an asset. We need to know where the data is, who has the ability to access it [and] to change it, because ultimately our clients and the regulators are going to hold us responsible for where this data came from, who touched it, the whole lineage. That's actually being written into regulations, that it's not good enough to just show the result. You have to show every step.
Outside of regulatory requirements, what do you see as the main challenges of public cloud storage from a technology standpoint? What do you see as the technical barriers?
Saul: I tend to be a technical optimist. I think there may be technologies out there -- fuller exploitation of encryption, for example -- [that could help, so that] if the data is being stored in a way that if it were compromised, no one could actually do anything with it, interpret it, change it [or] cause a bad transaction to occur. I don’t think we’ve fully run the string on what we can do with encryption technology.
And we've made a lot of progress. At one point, encryption was too expensive because of the additional computational overhead. Now with hardware encryption, that's really not an issue. You have to deal with the key management issue. So, there is still some work to be done, but if you really are only using it as a low-cost, convenient storage device, and you could be absolutely guaranteed that it couldn't be compromised, that would open up a whole new set of possibilities.
What do you see as the key challenges of private cloud storage?
Saul: Private is easier to begin with because you have physical control. As soon as you've got that, that really simplifies the issue. But some of those technologies, like encryption, can help us in the data entitlement space. While someone may have access rights to data for production, we don't necessarily want to give those same access rights to an application developer. So, maybe the application developer is seeing a masked copy of the data or a partially encrypted copy of the data versus someone who's actually doing a transaction. A lot of it has to do with core application design in the first place, in setting up separation of duties and the appropriate levels of controls. So, there's a lot you can do in the design space.
Storage is not the primary consideration when State Street decides which applications are good candidates for the cloud. But the storage has to be a service to the applications. Isn't that a new way to think about storage? The application developer isn't even going to be concerned about it.
Saul: You're absolutely right. Before I did this and before I did information security, I spent nine years as our enterprise architect. What you have said is something that I believe fundamentally, which is, you start with the architecture. The architecture has to include everything from end to end, including the storage. The options you have for storage today are well defined, and if you set up your architectural requirements in terms of what you need for capacity, speed, availability and all of those other criteria and cost, you can now select from those options. But those have to be part of your overall architecture.
Does the developer have a menu of options for storage such as low latency or high capacity?
Saul: I don't know if it's a menu, but we've laid out the various categories. In other words, if you're using a database from this manufacturer and this is what your requirements are, here are your options, and here is what they cost.
There are a whole series of tollgates you go through, and as you go from the requirement stage through each stage of the development process, you have to indicate what you have selected. If you came in and said, 'Well, I didn't pick anything from the standards. I'm going to go buy this from my cousin who is building storage arrays in his garage,' you wouldn't get very far.
How was the storage designed for the private cloud? What kind of storage do you use?
Saul: It's primarily based on performance -- a lot of very traditional storage from the big vendors. In some cases, appliances for performance reasons, where we need to, and then some in between. Some of the database vendors have their own appliance versions.
How do you think the cloud changes storage?
Saul: In some ways, it complicates the connectivity. But we've been on a path where we've been connecting storage to different places in the network for a long time already, with network-attached storage and the storage appliances and the way in which they operate.
A primer on cloud storage options
Private versus public cloud market: Which one rules?
Examining the benefits of public and private cloud integration