 All right, guys, good afternoon. We'll wait for one more person. Good afternoon, everyone. My name is Manuel Silvera. And with me today presenting are going to be Sean Murakami. We're both senior cloud architects in the Cloud Labs team. And we have Andrew Haley, who's our distinguished engineer and CTO for Cloud Labs. And today, we want to talk to you about OpenStack in the financial services sector. And really, with an example from the insurance industry. We just wanted to give you some of the lessons that we've learned working with these customers. And we wanted to also talk about some of the issues and recommendations that we have that we think OpenStack can really thrive in this industry and how we can do that. So I'll start off with the introduction. Then I'll hand it off to Sean. And he'll do an insurance industry customer use case. And then he'll give us some of the impressions and some of the feedback that we've received from the customers. And then we'll hand it over to Andrew. And he'll do a lessons learned and a conclusion. And since it's a really small audience, if you guys have any questions at any time, we'll be happy to answer them. So in IBM, the financial services sector, FSS, is the largest of our six industry sectors. It includes banking, financial markets, and insurance industries. And there are really two things that when you look at the customers that make them unique. On the one hand, you have the reality that it's one of the most regulated sectors. So you have, for example, Sarbanes-Oxley, PCI-DSS, HIPAA, and insurance. And then on the other hand, these are really very large customers. So as very large customers, they have the typical requirements that you see from large enterprises. So you have these two big factors pulling against each other. But the good news is that really a lot of opportunities exist for cloud computing, and specifically for OpenStack. Recently, IBM conducted a survey of 1,500 of the world's CIOs. And what they found is that in the financial services sector, firms are adopting cloud computing platforms faster than any other industries. And half of these respondents reported that they're already using private clouds. And more than half are planning to use public clouds within the next year. They really see cloud. They don't see it just as a new IT delivery method. They really see it as a key enabler for business model innovation. And basically, what they're seeing is that cloud, one in three of the respondents, really see cloud as an opportunity to drive new revenue streams. And in a recent Gartner survey, what they reported is that they're predicting that the insurance industry is going to see a compound annual growth rate of 36% through 2016. So the fact is that the good news is that opportunity really does exist for OpenStack in the financial services sector. So a quick introduction to our team, the Cloud Labs team. We've been working in cloud technologies for over a decade. We started with high performance on-demand websites. We started doing data center automation. And we've been moving up the stack towards private and public cloud engagements. And our main mission really is to drive customers to realize the potential of cloud computing. So as a result, we've been working for the last couple of years on these OpenStack and newer technology opportunities. And that's the whole idea of this presentation. We want to be able to share back all the feedback and all the information we receive from these customers. And we'd really like you guys to leverage this. And hopefully, we won't let this opportunity pass. So let's talk about a use case. And here's Sean. I'm Sean Murakami, colleague with Manuel on the Cloud Labs team. In my section, I'll talk to you a little bit about what we've done with this particular customer. A customer that we worked with is a large American insurance company. They're really looking at ways to grow their businesses in new areas and really to look at cloud computing and realize the benefits of it. They were doing the traditional data center operations. Folks would come in, request hardware. They would have a build team. They'll deploy that stuff. And it'll take a few weeks to get the compute resources that they required for their applications. And they're really looking to revitalize that, look at bringing things faster to market and to improve the productivity of their operations teams as well as their customers. So like any insurance company, as Manuel was saying, they have a lot of concern around these compliance regulations, things like HIPAA, SOX, PCI, being able to audit, log, track information, track who uses those resources, how they're using it, and really concern about securing the data and encrypting the data on the cloud systems. And like with any other large enterprise, they have to put this in their data center. So they're looking to be able to take a solution and tie it in with their own, in this case, active directory, enterprise directory systems to be able to provide that mechanism and to provide that level of tracking of who did what and what times. So that was very important to them. They're also looking at new network technologies. So Quantum at the time was something that they were really looking into, looking at new software-defined networks. And they also wanted to use some of their script automation they have built over the years and be able to reuse that. And OpenSAC has made it available for them to actually help with that automation. So this is a typical OpenSAC deployment design. So what we did for one of the pilots was take a few nodes. We had a dedicated network node with a Quantum L3 agent and the HTTP server, sorry, the HTTP agent, a single controller node with the majority of the OpenSAC score services. And then a couple of compute nodes that were used for the virtual machine testing, running Quantum plugins. And so what you see at the bottom in the data network, they also wanted to look at leveraging, as I said, the software-defined networking, being able to utilize GRE tunnels that Quantum provides to provide a multi-tenant network capabilities for their customers. So what were their impressions and feedback from this pilot? They really liked the APIs that OpenSAC provided. It really allowed them to integrate into their existing scripts and system services. They were using, I think, Foreman and Puppet to help drive some of that post-configuration automation on those virtual machine resources. I think at the time, they're also using VMware, and they're looking at other opportunities for hypervisors. And during this pilot, we introduced them to KVM, so they're really interested in what kind of capabilities that provided and the performance that came with it. And from a networking side, they also liked the notion of being able to pin multiple floating IPs. Some of their use cases across some requirements require them to be able to have multiple interfaces where some of their applications running those systems may take in different types of track from different end users. So what could be improved from, I guess, what came out of that pilot? At the time, we were using OpenSAC Folsom. Grizzly wasn't released yet. And as we know, Quantum was a bit immature at that point. And so they were really looking to improve some of those capabilities, like scalability in HA for things like, at the network node, being able to provide mechanisms where HA's sort of out of the box. So these are some of their kind of feedback from what they saw from a standard installation. There's no built-in backup of recovery systems, being a large enterprise, and being able to keep and track data, and keeping that data secure, and being able to look back in time in case they get audited. It was very important. And so backing up that data in turn becomes very important to them. And then the customer was using Active Directory. And at this point in time, Active Directory integration with Keystone wasn't, say, rich in feature or function. And we had to go through a lot of hoops to integrate Active Directory. Some of the interesting points with this particular feedback was the way that Active Directory and Keystone was integrated, and the way their end users were using OpenStack in the end required them to replicate users into their corporate directory, which doesn't make sense for a service provider model. And that's something that we're hoping that changes. And then finally, looking at monitoring capabilities, I know with the latest release, with Solometer and being able to meter those things is very important. So I see the community doing a lot of good work to tackle some of these problems that they're looking at. So I'm just going to go over some of the lessons learned we had with the customer. Thanks, John. So there's probably two reasons we wanted to share this view with you today. So one is a bit of a selfish reason. Are there any OpenStack developers in the room here? OK. I guess my first reason won't hold then. So part of this was actually to share with the community what drives some of our involvement, IBM's involvement, in OpenStack. And this is coming from a private cloud perspective, people who are figuring out how to use cloud technology in industries that a lot of people actually think would be slow to adopt cloud because they're regulated, because if you read that early cloud material about the kinds of things and the kinds of workloads you should take to cloud, a lot of the analysts and a lot of the consultants would actually say, do not take a regulated workload to cloud. And what we've seen in the past two years is that has completely changed. It has become almost normal for a number of enterprises to put any kind of workload on cloud. So what we have to do when we look at OpenStack is really get aggressive around closing the gap between cloud implementation and the processes that these companies have been using to run their business. One interesting story, I actually spent a couple of years working in South Africa. And there was a major bank at the time that had a number of IT challenges. And there's a quote that stuck with me from one of these projects. And he said, think of a bank really as just an information technology company. And I thought that was a little strange. You think of capital and you think of going to the bank and getting money and going to the bank branch and that experience and the ATM network and all that stuff. And he said, so we asked him why he thought of the bank as an information technology company and that it should be an aggressive adopter of IT. He said, well, if we lose a branch building, some people will be upset. They'll go to a different bank building. If we lose two buildings, that's OK. We can rebuild them. If I lose all my buildings, that's fine. We can rebuild them. We can bring in temporary ATMs. If I lose my data center, I'm out of business. So their number one concern is being an excellent IT provider. So it's kind of interesting for us to get really deeply engaged working on cloud computing and figure out if these are people who are striving to be, in some cases, the best at information technology, what can we learn from them that would apply not just to the banking and insurance industry, but that applies generally to people using cloud. So a lot of their experience is, OK, how do I look at my information technology assets as potential new businesses? How do I extend, essentially, the internet into my data center was a lot of the thinking here. They're not just looking at this as an example of, I want to be cheaper. A lot of this, as Manuel was pointing out, was actually about accelerating their business and really taking new businesses out to the market. What that means is they've got to look at what they already have and the processes that made them great as a company and figure out, how do I leverage these to do something new? And they aren't necessarily thinking that to do something great, they have to take their back end transaction systems and put them on a public cloud. They're looking at the systems they have in place today and the processes that they have in place running those systems and figure out how to extend new customers in and almost extend the idea of a public cloud or extend the internet. So their data center is just a way of delivering new services out to new customers. Now, when you tie into these existing systems, as you can imagine, and Sean was pointing out some of these things, is you're tying into something that runs the core of their business. You're tying into their customer records. You're tying into a transaction system. You're tying into CRM systems. So there's paranoia. And there should be paranoia about tying into these systems. I mean, that's your banking money. That's your health insurance information. So the top things on their list were about protecting them. It's about protecting those assets. So when you come to them with something, and at the time it was OpenStack Folsom, you say, I don't exactly have best of breed integration into user authentication and authorization systems. It's a non-starter. You just can't deploy a cloud solution that doesn't tie in properly to an enterprise and authentication authorization system. So that was kind of expected, but the importance of it, and the focus on it, and the amount of time we spent just on that one problem getting that right. Now, you think, OK, well, but that's not the transaction system looking for user data or customer data. It's just a cloud system. But why does that matter so much? Well, the regulations they have to live by to keep their licenses to run their businesses, they have to prove that they are in control of their systems, that they know who changed what when. And the first part of that is the who part. So if you are a cloud administrator and you deploy a new system, and it has a negative impact on the system next to it, you have to know who triggered that. All laws that regulate these industries are written about people doing things or organizations doing things. They're not written about what autonomic agent did something. It has to be accountable to the company and the person. So it is critical, critical, that they can actually tie into a system they trust that identifies the people who do things. And once you get past that, everything else is just fancy technology. So that was just one of the key things. And it was interesting to see how much of their business and how much of the way they run IT is tied into just identifying who did what when. And when you really dig into some of those things, like SOX compliance and best practices for running a data center, a lot of it is just keeping track of what happened when so that you can prove, should something go wrong, that you made a best and reasonable effort to keep your IT systems in control. So these people are happy to adopt cloud, which was kind of interesting. I mean, we actually thought regulated workloads, they wouldn't go near this. What they were bringing to us weren't dev test use cases. They were bringing new business-based extensions of their company that required them to extend out to the internet, reach new markets, connect with new partners, connect with new developers or external parties, building new systems. So they're building ecosystems around insurance, but they had to start from a solid base. So integrating into the existing network and storage, I mean, a lot of this was just, you need to unleash from what we have, right? We're not gonna spend $20 million to build the best cloud in the world. We need you to tie into what we have. Leveraging existing procedures and script and code libraries. And that was the other thing. They figured out quite a bit of automation over the years, right? All those insurance websites, internet banking channels, things that you go to, those are already reasonably automated. So going in and telling them, cloud will help you automate things. They'll just come back and say, I am 99% automated already. So cloud isn't about just automation to me. You have to tell me how I tie in to those existing scripts, those existing automation frameworks. So it's great that you can deploy a VM, but I've got this whole other automation library I need to leverage. And the last thing here, if I haven't said enough, security, security, security, security, right? It really is not just the authentication authorization part, but we got into some horribly deep discussions about every hypervisor technology we bring in, every network technology. And one thing that would really accelerate is to pick certified technologies. Things like FIP certification and things like that. So every time you introduce something into a regulated organization, they kind of have to do a bit of a threat analysis on it. So it actually helps if you can build from proven technologies. So the more that we treat OpenStack as a proven technology to build on, that many other companies have built on and even maybe take it that next step to certification, which is something that, at the end of this, if anybody has some feedback on that, I'd love to hear it. But to some extent, we probably will have to go and OpenStack that next, through that next boundary at some point and think about actually certifying some of the code to the standards that help them stay in compliance in their industry. So again, another thing that we just kind of learned, we did a lot of, I think we've been doing cloud engagements. I think we called it request-driven provisioning before we called it cloud. A good part of that we did was always about the return on investment for dev test was the classic business case, right? People can reuse systems, you get 700, 800, 900, 1,000% return. The cost story around cloud is not what was driving these clients anymore. It's not what was exciting their business stakeholders. It was, I need to reach a new business and come up with a new business model and I need IT infrastructure that helps me do that. I can't build end tiers of network perimeter security and still expect to be able to do something innovative like buy a new company or partner with a new business and actually deliver a new service that none of my competitors have. So the kinds of things that get a little surprising is when we talk to a lot of the CIOs of finance companies now, they will say my goal is to turn my IT organization into a service provider and do things like white-labeled banking, insurance marketplaces. Those are a bit famous in the US. If anybody's from the US right now, the insurance marketplaces, cloud should help you do those right. I mean, you actually want a scalable dynamic infrastructure. You want, anybody here from the US? Okay, so the healthcare.gov thing resonates with people. There's a better way to do this, right? And so they actually look at cloud as an architecture that scales well that helps them extend out, connect to new business partners. There's no way that a health marketplace works, except for it to almost be an extension of your data center to the internet, right? So if your architecture doesn't help you define a network that securely connects to your partners, it doesn't help you grow your business. And one other thing that was needed was they really needed to meter this, right? They wanted to go to a shared model and internally it's always a struggle. We've actually done a lot of financial studies with customers and one of the biggest problems they have is how do I actually convince my accountants that doing a cloud model internally is gonna work? So externally they have no problem buying cloud from the internet. For those who use accounting, that's an operational or OPEX budget, right? I just use a credit card or I use a purchase order and I buy X amount a month. Internal accounting systems for capital acquisition of software hardware and assets do not work that way. So internally to become a service provider, they almost have to flip their accounting models around and to do that, they're building a new model internally that has metering and things like that as well. So they actually, if you don't provide them that instrumentation, they can't build the accounting model to actually make it work internally. So actually the very first cloud engagement we did with a health provider in the US, the single longest part of our implementation was actually upgrading their accounting system. It wasn't had nothing to do with cloud or virtualization or technology or any of that kind of thing. So the thing we're kind of excited about now is the metering has gotten kind of baked into the architecture. So when metering gets baked into the architecture, at least on the IT or the cloud side that problem's taken care of, you may still have to wait for the accounting upgrade, but when we were first doing this, we had to do both sides of the problem. We had to come up with a metering architecture for private cloud and then go work with the accounting system people and figure out how to make those things match. Because the existing accounting systems looked at every piece of the cloud as a physical asset that had to be depreciated not something that was metered out to individual services. And we didn't even have the metering framework at the time. Okay, so go through a few kind of high level things we've learned, a couple calls to action for the people in the audience here and then we should have time for some questions. So insurance industry, I don't know how much I believe analyst papers and the stuff we get sometimes, but this one kind of bent my head a little the first time I read this. The industry that's expected to use the most cloud was insurance, and at first it didn't make sense, but this was about a year ago and this was before the idea of insurance marketplaces happened. And this was before we started realizing that healthcare is a worldwide issue and insurance in the growth markets that the growth rates of those being up around 30%, it just means that those are businesses under extraordinary growth pressure, right? So the dominant architecture for onboarding new businesses, cloud just kind of the math works out that insurance becomes one of the leading consumers of cloud over time, which actually means all that nasty regulation stuff like HIPAA and PCI compliance, because there's a lot of payments involved that those certifications of cloud infrastructure become quite important to the business that's going to consume the most cloud. So it's kind of an interesting wake-up call for some of us that the problems we needed to focus on in cloud were industry aligned, right? They were business aligned, they were aligned to stuff that we used to harden into mainframes. Just another part of this, I mean the way we're now kind of looking at some of the things we do in OpenStack, our use cases are shifting a little. For the past few years, it's been just focusing on hardening OpenStack as a technology, right? Looking at what does OpenStack need to do so it's better for storage? What does it need to do so it's very flexible with respect to software-defined networks? Yeah, all that stuff is gonna continue, but there's another set of use cases that we need to spend some time on, and some of those have come quite a long way. If we look at what we were doing in these pilots when we were first trying to convince IBM customers that it was the time to look at OpenStack, I mean we were doing that on the fulsome basis from well over a year ago now. And a lot of these things that were real inhibitors like proper authentication and authorization, proper logging techniques. One thing I probably didn't talk about enough was the challenge of doing proper auditing and logging, because again, the record keeping is a critical part of these. If you look at what's really behind some of these regulations, it isn't just being able to prove who accessed it when, but you have to keep those records in a reasonable form that you can interpret, that an external auditor can interpret for up to three years. So sometimes it's five years, sometimes it's six months. It just depends on the industry and the procedure, but there is definitely this common theme around having a standard way to look at your system logs and to look at system logs for distributed systems. So that was actually something we were quite proud of was working together with the community to bring in the cloud, C-A-D-F, cloud auditing. I always forget the acronym, but it was the DMTF format for helping make sense of auditing and logging records, helping register certain triggers like login events or critical resource access and things like that. Just improving and testing as a basis. I was actually a little disappointed in one of the panels I attended this week. The panelist, I think, was the CTOs. Three of them gave, in my opinion, the right answer to this question. The question was, is cloud ready for production? For business. And three of them said, yes. I would say those are the three companies that probably had the most mature technology implementations. And one said, oh, maybe. I think that was a bit of defensive maneuver from where they were in their own product cycle with using OpenStack, but OpenStack has clearly become the basis for a lot of companies to do business. And moving on to Grizzly and moving on to Havana, that will become even easier with that, focus on testing, focus on stability. If you're running patient records, transactions, insurance claims, and you're doing that in a cloud infrastructure, this stuff just has to work. So the focus on testing in OpenStack is absolutely fantastic. We're thrilled about it. The idea that a change is made in the source or 700 changes results in 700 builds, it halts in 700 test cycles, and that happens in one day. I mean, there are very, very, very few enterprise application and software products that are tested as much as OpenStack. And that actually really does resonate with enterprise customers. The idea of extraordinary focus on testing. And the last one, it's a subtle one. I don't think we're 100% of the way there in the community, the zero outage window business. This is something that will require continued focus, but the kinds of businesses we're talking about here, is anybody like going to an ATM on a Saturday night and it says it's down for maintenance? I mean, it's just not acceptable. So if we're running business channels, external channels, if we're running real life transactions, we're in a zero outage business. So what we're doing here with respect to continuous upgrade, that's critical stuff. And you know, these industry requirements, I actually think we're kind of where we're starting to head. And this is my soapbox and this is my view and people in the room may have a different opinion, but software defined networking, that's gonna happen. Software defined storage, it'll happen. Enhancements to availability and hypervisor and all that stuff, that'll happen. But understanding what people need to run on OpenStack and making sure that we're closing those gaps on things like auditing, things that probably don't excite all the developers. But those let people run their business on OpenStack and that's a big deal to us. So with that, we did leave about five minutes for questions. So us, Sean and Manuel, they come back up here. If you wanna read more, so a lot of what we do is not always industry focused. We have a little blog on the internet. Sometimes we post videos up there just short demos of OpenStack, stuff like that. We have our YouTube. We also post it so you can download them online. Yeah, so these charts are, yeah. So it's cool that you're taking pictures. If you want the higher fidelity, you can keep taking them. We like being famous, don't get me wrong. So take as many pictures as you want, but the charts are actually already available in PDF form online and then the, sometimes when we do something cool, we post a video of it, a one minute video of a technology. I didn't know until this morning that we had a Twitter account. You think I would, but, so we do have a, we have a Twitter account where we post ingenious things, 140 characters at a time. With that, if there are any questions, we can go ahead and answer them. Let me say a company, a company like IBM. Yeah, so the question, as I understood it was, where we're going is about software defined data centers, software defined environments. Yeah, OpenStack is about. Right, software defined everything. And what does IBM think about that? Cause we make lots of hardware and we do, we make cool hardware. Actually, I've been in the software business with IBM for about 14 years. It was probably about 10 years into my career before I ever plugged in a machine. And then I realized, the hardware still matters, right? Yes, it's software defined anything, but there is still a base capacity that makes sense. That makes sense. There is still a set of workloads that when you actually get into really analyzing the workload, you can probably run them more efficiently on one platform or another. So there's still optimizations, right? And there are still things, there are workloads. So we used to say, don't move regulated workloads. So now what I tell people is, don't move your most optimized workloads, right? Because you'll actually struggle to reproduce that optimization right now. The next turn of the crank for software defined is actually how we express these optimizations we did in things like power infrastructure, mainframe infrastructure, and actually express those as policies, right? So there are certain things, maybe it's a firewall, for example, that don't make sense to package into hardware anymore because you can deliver those just as efficiently and perhaps in a more scalable way by moving them on to standard workhorse kind of units in a cloud. And we're all for that. And the last thing is we're a company that's done okay as far as going between technology waves. The office I started working at at IBM actually made typewriter balls, right? Now they weren't making them anymore when I worked there, but this is a company that's gone through actually one of the most humbling experiences of my career was going to some of the original IBM offices and realizing how many carpenters we had on payroll 100 years ago because we built beautiful wood cabinets for some of the early tabulating machines. So if you actually want to think about where we've gone as a company and how many technology waves we've gone through, but cloud is a massively disruptive technology wave, right? Which is why it's really, really important for us to not only be here and participate in this, but also to lead our customers to get through that. Because we want to get people off the electric typewriter balls, we love them, they're really cool, but we have to get them onto cloud and what comes beyond that. So I don't see it as a conflict, I just see we still optimize certain workloads and over time we will express those optimizations as policies that can be used by a software to find an environment. I think that is a today's statement, right? I think that's today, today there are still some highly optimized workloads that are still hard to move to cloud because you will not get the same performance. But I think that's a today's statement and one of the things we're doing is looking at those platforms as good places to become software to find environments. There is no reason actually some of our most successful cloud implementations are cloud on mainframe. Because we've started to figure out how to express the capabilities and qualities of service offered by the platform up through standardized interfaces. And those platforms become, whether it's quality of service, whether it's transactionality, whether it's redundancy, whether it's resiliency, those are policies we can express in a software to find way. And not all platforms are gonna be equal. So not all clouds will be equal. They will have different policies that the workloads can leverage from the underlying software to find environment. So great question. I should have paid you for that one. You had to change the accounting process of a customer in order to make the open stack capability available because traditional accounting looks at the each cloud as a separate depreciating item. I didn't quite get it. Can you explain that further more for us? Sure, do you want me to take that one? Okay. All right, so what I meant was not so much that cloud is a separate, but the pieces that make up cloud, right? So if a business unit wanted to do something with IT historically, they would go through a design cycle, right? The way that a project got kicked off, they would say, well, how much is the project in a cost, right? And then they would go do an information technology acquisition. And the way that they actually implement their budget cycle for a project would involve an acquisition cycle, which would result in them getting capital assets, servers, hardware, storage, networks, cables, and so on. And the system that actually figured out how that IT project budget was doing was built around the idea of there being assets, physical assets tied to each IT project. So if you actually looked at their accounting system for IT projects, it was a capital accounting system. So internally, if two departments wanted to run two IT projects and share a capital asset, the accounting system wouldn't let them do it. So one group or one business line on the asset, not two. So it was actually just kind of an interesting, when you actually really dig into what are the barriers for adoption, it just blew our minds that in one of our engagements, it was actually the way that the accounting system treated internal private clouds and the assets to build them as capital assets that had to be charged to one business unit. So it was actually, we had to actually figure out how to produce the right level of information out of the cloud environment so that it could match the different departments and on the flip side, they had to figure out how to adapt their accounting system to actually look at internal systems almost as operational expenditure or regular expense as opposed to you own a bunch of servers. Does that answer the question? Okay. All right. So we've actually hit the end. If you've got really tough technical questions, both Manuel and Sean are here and I always like to give them really tough, meaty technical questions, but we're happy to stay around. We'll be in the hallway if we're running over in the next session. So guys, we're gonna be around all week in hours there. So if you guys ever see us, all right? Thank you. Thank you again.