 Hello welcome. I'm glad you guys could join us. Glad you guys could find the room. My name is Tim Puer. I'm the squirrel in the middle and You know we tried to come up with some funny names here But basically I travel around the world and talk to IBM customers and non IBM customers about DevOps and automation And I'm really excited to be here in Tokyo. I apologize that that I don't speak Japanese I Have a colleague that that that told me the joke one time and so I'm gonna tell it here What do you call somebody that can speak three languages? Tri-lingual what do you call somebody that can speak two languages? bilingual and what do you call somebody that can speak one language? American so Apologize for that my colleagues here Michael elder Hey, I'm Michael elder. I'm a senior technical staff member with urban code. So I do technical product leadership and We built the products that we're going to be highlighting some of the products We're going to be highlighting in the talk today And I'm Tyson Laurie. I lead all things DevOps for the Apple and IBM partnership All right, so Michael's gonna start us off here I'm not going to speak too much today because I had a really fun karaoke night the other night So my voice is going All right. Thanks, Tim All right, so just to kind of set the agenda our goals today are to really talk to you about the Apple and IBM Partnership that was formed last year. We're going to look at some of the challenges that Apple and IBM have together to deliver on the goals of the partnership and look at some of I think some of the same challenges that large enterprises Are going to have as they try to do a lot of the DevOps services particularly for mobile and these other kinds of systems of engagement We're going to look at the technology we used and how we solve some of these challenges with Open stack with heat with blue box with urban code We're going to show you a live demo We're going to highlight some of the capabilities to help really try to drink drill at home Right to make it real and then we'll talk about some of the lessons learned that came out of this and some of the Experiences and things that worked well and things that were still working on and improving So with that, I'll hand it over to Tyson to talk about our partnership Thanks, Michael. How many people actually know or have heard about the Apple and IBM partnership? Okay, that's how many people who are not IBMers Have heard about it. Okay. Good. Good. So It started July last year and in that space we've aimed to build enterprise iOS apps That are to challenge and change the industries that they're being built in and we're building together with Apple About hundred iOS apps all focused on implementing analytics or You know heavy data manipulation Services with the back end, you know, you know real enterprise services And hook into systems of record now an example of that is we have an app called sales assist So that app not only had to do simple check out and maybe some additional things like Learn what you guys like when you shop at the store But do something else do something challenging change the industry change how You visit a store and work with the people You know at that store. So one of the things that was implemented was eye beacons and things like that So we're actually doing a lot of analytics, you know in real time as you walk around the store You know being assisted with you know selling and and that's you know got huge Impact on a back-end mobile first platform, which is what we use to do all of that And what I think is really really neat about this is as Tyson was kind of telling me what what's going on here it's as much about injecting the same kind of mobile interfaces into an enterprise to help change the way their workforce operates like helping clients with retail sales or Interacting with airplane airline clients or insurance clients It's about helping that enterprise grow and change with this technology in the same way that consumers have been doing For the last five or six years It's all about engaging the customer in new and innovative ways One of the ways that many of you may have experienced on the way here is flying right? It's dear and near to my heart because I do not fit into planes, but You know if I get a connection if I'm my flight's running late then my head stewardess can come tell me Hey, okay, you're gonna miss your connection. You know, it's an international flight But I've already gone ahead and booked you on another one and you're gonna leave you know an hour after you land And you're gonna make your time back up. That's extremely beneficial to me And I will continue to book with that customer so long as they you know that airline stays in policy I will continue to book with them because of that right those those the kinds of engagements that These mobile apps are now enabling companies to do absolutely So because of that Because of the number of apps we're building we have a lot of developers all around the world. This is a huge scale implementation from IBM and That's led to apps across 16 industries That means there's 680 API's give or take one or two 160 compute nodes to back those hundred apps Just across QA and prod and then we've got all of the development environments that you would normally have with this It's it's a massive scale across geographies 24 by 5 maybe by 7 if We get them operating faster There's organizational pressures on the skills that are required to do all of that around the world the amount of Automation to make it repeatable and implementable from our point of view without using you know hundreds of people from a deployment purpose And at speed and then we've got to take all of that is spread across a hundred and fifty source code repositories Just for the iOS apps the frameworks in those apps the API services and then you know what's not mentioned here is You know all of the the heat documents the the amount of automation to make that repeatable so That's the amount of scale that we've got in implementing it so Tyson we want to talk about a little bit about you know the size the scale Okay, I can't step backwards Hold my head so in this case. We're really We have this this challenge of scale and if we look at existing methodologies They're not really sufficient to start addressing that so we look at traditional IT methods. They're somewhat rigid We have long request cycles to get new environments There's typically a more system administrator role more intervention manual human intervention required and It's magnified because we're dealing not with one company creating a mobile experience Not even one industry But 16 different industries with unique challenges and unique customer challenges customer interfaces, etc Magnified by all the implementations and apps within each of those industries. You can imagine what kind of Guarded in a traditional IT infrastructure. You would be very guarded of those environments, right? You would have an administrator that says you were not allowed to touch this ever All right, even to deploy new code because if it breaks, I'm responsible for it, right? but with you know Trying to move away from that model now We have the ability to fire up some of these environments on demand and we don't necessarily throw away, right? So All that scale in a traditional IT infrastructure would just not be possible No, we won't be able to move at the speed that you need to for mobile So we came up with a design full stack automated Design that we wanted to implement as a program and we worked with these guys to do it so We wanted the the OS the virtual machines The resource sizing so that includes everything from the public private networks the disk space the load balancing To all be fully automated. We didn't want to do any of that by hand and That's where you know open stack fit nicely on blue box We wanted the middleware to all be fully automated so that there was no manual work to be done when putting that on The stack we'll go through that a bit later And even the configuration and the deployment of the API is You know when you're talking about 680 API APIs across, you know that many industries that many environments You know if there's any manual intervention in that you're going to slow things down we're doing deployments of Probably one in every two iOS apps every day and probably across the week Hundreds of the APIs in the QA environments and the dev environment so none of that can be done Without automation. It's just not possible Not in a good efficient way So let's talk a little bit about the concept behind how we address this challenge of scale and and ultimately it comes down to using techniques like automation to install and manage software and The software to find environments in the APIs that support them to deliver these kind of full stack patterns So everyone's familiar I think with open stack and these concepts of compute network and storage I think probably how many people here are familiar with open stack heat even if you haven't used it Okay, good amount. How many people have used heat to deploy a full stack? Okay, a smaller number So as we've been working with heat we found it to be a great technology for orchestrating infrastructure When we look at an enterprises Software and we you know Tyson's talked about the API is you think about the sales assist example You think about the airline example of someone using a mobile device as a employee as a sales representative as a flight attendant They're connecting to a set of services on the back end that are giving that mobile interface its data And that's really what we're trying to stand up more quickly We're making it possible to build these APIs and actually deploy them very quickly and so we're leveraging urban code deploy and The rich web-based editing solution we have for open stack heat documents to make that real so Heat becomes this glue That ties together the infrastructure the compute the network the storage and the software and we're going to see that demonstrated in a moment and So if we think about the full stack patterns We need to run them somewhere and in this environment we've chose to run them on blue box, right blue box recently joined the IBM family and It's been great to be able to go and get a ready to run ready to go open stack environment That allows us to stand up these patterns We've defined them in a way that makes them portable It was originally using some API's out of the software environment but what's neat about the blue box environment is that it provides a scalable managed open stack standards compliant API that we can use for this Dev and test and in this case When we provision these patterns We're actually standing up running virtual machines We're taking care of all of their networking and storage as required and set out by the heat document and then we're coming back in and installing software on those hosts to Configure the IBM mobile first platform, which is running those API's backing the mobile app and What's really great is that not only can we do this in a dedicated blue box environment? Where it's running on my sort of focused hardware from my client or my enterprise But also provide that to the client locally in their own data center and it's not just about doing it in one cloud How many people have a cloud that they use in their company today on a regular day-to-day basis? Okay, smaller number. Okay, so the next question. I'd like to ask is is sort of how many people think you're gonna have exactly one cloud period If you think you're gonna have only one cloud that'll run dev test QA production everything Okay, so one person so that's great I think that what we have seen as we talked to clients is that really clients have many different use cases and needs some things They want it to be Just local just in their data center and we have solutions to help with that Some are comfortable with having it dedicated. It's in a different data center They don't have to manage the hardware they don't to worry about that and they can run their applications there And some application types work well in a shared or public context The way that the patterns are defined we're able to deploy them across each of these without making significant changes And one of the key sort of demonstration points. I think about this concept That we experienced in the last four days is that the blue box environment? We're gonna show you to blowing today. We had access to on Friday We traveled over the weekend to Tokyo from North America and in that time We were able to take the same heat blueprint that had been used in other soft layer and open-stack environments the same software automation and Set it up and deploy it into this new blue box instance over the weekend while traveling 15-hour international flights So the ease of portability is critical to make sure that as cloud environments change over time or they're upgraded We don't have to go and reinvent the wheel each time in the context of the iOS apps for for mobile first We're gonna have some customers that are going to connect these apps to Systems record right and in some cases some customers are okay with having some of that data out on a public cloud In which case IBM could host that for them no problem Other customers are gonna be very more restricted either through regional Requirements or their own personal preferences to keep that information in their own cloud and not make it accessible Or not have IBM host that right so what we've done and what we've demonstrated just this weekend right by deploying to the new Blue box cloud that we just got on Friday Is that we can take this automation that we have in place and we can deploy it in an IBM cloud hosted model Or we can deploy it on an on-prem Local model right and there's very little if any change necessary to the automation This makes it extremely easy for us to manage these environments going forward when we have to do upgrades We have the troubleshoot problems because we know exactly what's been deployed and what's there? And how it got there so with that Tim is going to walk us through a live demonstration and just because of his voice. I'm going to help with a narration here so This is a live running environment with our web-based designer for heat, which is part of urban code deploy We get logged out again. Mm-hmm. All right live demos so in this example What you're looking at is a visual representation of a heat blueprint Each of the large gray boxes represents a virtual machine Each of the smaller yellow boxes represents a piece of software required to run the platform and that's backed by urban code deploy in This case what we're going to do You can actually see in the palette. It's going out to our open stack cloud to get details We can use to compose a new blueprint like virtual images from glance and Then it's also pulling in. Let's actually We'll show a quick demo. I guess of creating it. It's very easy to do a drag-and-drop gesture here pull over your server Pull over your network. We can link the actually just drag the server onto the network Or draw the line whichever works and then we can go and grab components So what we're doing in this quick example is just highlighting We make it very easy to reuse these different pieces of technology to put together our applications So in this case, we'll switch back over to the QA node to the QA blueprint and we'll go ahead and kick off a deployment when we provision the environment When we provision the environment what we're actually going to do is have the heat engine begin provisioning virtual machines We're going to get the agent installed The agents then going to manage the deployment of software and in the end we're going to have the complete application stack ready to run So for each of these different parameters exposed in the heat blueprint We're able to provide specific examples like in here binding the public network to the external network And if we wanted to change the flavor and Drop that down. I don't know if we're using medium here If we wanted to change the SSH key that we wanted as well each of these values is being read from the cloud provider So that we can provision it and make it ready to run And if you've ever dealt with heat You know that you end up putting a lot of IDs into your heat documents the reference these things and so Under the covers it's doing all that for you but showing you the actual displayable human readable names. Exactly and Then once we provision it it's going to go through a validation phase This is another common thing we found creating heat blueprints if you're doing it by hand in a text editor You often have many failure attempts to get it right. This is meant to help you do that more quickly Now when we provision it, this is the heat engine running We've added some plugins to it so that it integrates with our software orchestration layer from urban code deploy But other than that in this example, it's just a regular heat We're actually I think running Juno in this example. We'll have kilo available later on and When we provision it in blue box, we're going to see these instances immediately get spun up It may be going into the admin tenant So we have different tenants here in this case whichever cloud we're connected to When we go to do the provision it'll deploy into and you can see here the zero minute time right, we've just kicked those images off and We're able to quickly have them come online from blue box The boot up time is actually really dramatically fast and then get the agent installed and once the agents installed We go over to deploy And we'll go to the dashboard and we'll see that running process that we've just initiated we can go to the details view and What we're going to get is a complete representation of not just the servers coming online But also the software being installed into the servers and So we can get access to the log details that we saw on horizon a moment ago We can have that right in line with all of the other software orchestration and you can see the different software components So just kind of highlighting one installation manager and the component process It's required to execute and as those begin to run you'll see the status turn green over on the right So let's go back. This will take a few minutes to run this actually for the QA for four nodes For five pieces of middleware with the various interactions will take I think we're at an hour. Yeah about an hour and that includes deploying The runtime and API is on top of the middle one correct And so the key thing is here. We're not just standing up for VMs We're standing up a complete working environment with many components for our middleware platform So we're gonna go back to the designer We're gonna go to the environments tab And on the environments tab will filter it down to look for just the ones that we want to highlight here There's actually a lot of stacks that are running if you'll click into the environment table. It'll come up faster The environment filter over here. Yeah It's just the second one down Cool This was one that we provisioned earlier today Or I think today we may have done it last night, but it was provisioned earlier And we have all the details of what the heat engine created And then we also know if we click on instances we get details about the virtual machines that were created as part of this This was just a dev example. So it's one node and then if we go to the outputs link These are the components that were installed. So I know exactly what software is there But I also have a link that we've provided in a heat blueprint that will give me access to my IBM Mobile first platform that was stood up as part of the of this deployment And so just to kind of reiterate what's happened here you can click remember if you'd like We had a complete full stack design in heat We're able to provision that into blue box get everything up and running a full IBM mobile first platform To enable the developers the testers, etc Working across each of those 16 industries to get their job done more efficiently. All right so we'll go back into full screen mode and Then we're two slides ahead Cool So what did you just see there right? You saw a full stack not just software not just the infrastructure, but a complete stack We did it with a consistent predefined pattern Had we not had it already running in another open stack environment another software environment And we got a brand new cloud Friday We wouldn't have been able to port it over so quickly the pattern gives us that consistency regardless of the specific cloud We're targeting it's easy to maintain it's easy to edit and As we're making new changes to the platform new changes to those API services that are backing those mobile apps We're able to quickly deploy them and see the results of that change The reason we did all of this is not really because it's a neat example of Provisioning and automation But we're helping developers and testers who are supporting that partnership and that goal of delivering apps for 16 industries We're making it easier for them to do their job better and So if we think about the design we saw every layer in the stack had some deployable object in the blueprint the operating system the Virtual machines the networking the storage the software all Tracked as a resource described in a document I can source control the blueprint I can iterate and collaborate with people to make changes and We can replicate this over and over and over again For dev for QA for production for any new environment that I need I would say that that's one of the key parts right is when we take this to customers on the local side Being able to send out a sales engineer or tech engineer or support personnel and say this is exactly What is deployed at this customer site? We'll save them a huge amount of time and problem solving or Problem resolution, right? He'll know exactly what's there instead of having to go dig and try to find it Exactly and so with that, you know I be a mobile first is a great platform for delivering your applications and ties is is gonna walk us through a little bit more of What's really in that solution? Thanks, Michael. So we started off with the full stack automation design. It had five layers Michael's taking us through the demo where you've seen, you know, each of those layers as a tracked object It's it's in the YAML file. It's you know It means that there's the consistency that we can do it every time against any of the clouds We've got both soft flour and blue box running But from a middleware point of view which are all those little yellow boxes that are on top of the virtual machine They're the same regardless as well regardless of a dev blueprint a QA blueprint production blueprint, right? These stay the same which is another benefit. So all of these pieces are your traditional middleware Software pieces that you need to run, you know, a mobile specific channel back end. So we've got DB2 We've got web sphere. We've got a hdp server. We've got cloud and got the mobile first platform, you know, we've got the API's All of that They're just nice consistent, you know, I guess puzzle pieces that you can just drag and drop in the same designer That's gonna control blue box or software So that's the neat Picture that we wanted as a program to deliver this both for ourselves internally and for our customers And I think this highlights the complexity of the final solution that we're delivering here and why he was such a vital part of that because Trying to automate a very complex full-stack solution like that what you see in the diagram here would be extremely difficult using a traditional Build tool like like say Jenkins exactly I think what's neat to me about this example as we worked with the mobile first team is that The types of products are seeing our traditional middleware products. Many of our clients have the same kind of Stacks in their environments Some of our clients are looking at docker and containers for how they might roll things out But in this example because of the traditional architecture we felt it was more comfortable to still have virtual machines as the underpinning and We needed a way to still have the portability and the encapsulation of each software package Even though in this example we chose not to do it on containers because of the fact that it's a more VM Centric workload the skills involved for the teams that are maintaining it and managing it or more VM centric So what was just better for a better fit But we're still able to get that same kind of portability that you might have if you were using a full container solution So this just drives home the difference and and what you saw in the demo This is a dev pattern all those components are on that pattern. It's still got the network It's still got you know security groups, which is you know that we've got stored in blue box It's got the virtual machine. We can add storage if we want Don't know whether you'd want to stand storage in a dev pattern, but you could and the qa pattern The blueprint is different the yaml underneath is different, but we can still point it at blue box We can still point it at soft flour. We can drag on the same component So this we haven't coded it twice. We haven't coded it three times when we get to production. They're the same which means You know, it's all version tracked urban code deploy does a fantastic job of Managing all those version dependencies between, you know, which version of DB2 was it which version of mobile first platform was it? and in this design you can even you know see which version of I Guess pretty much everything you can point at different tenants as you change your open stack You could have you know one version of blue box Which is kept on a particular version of open stack and another one which is upgraded and you can slowly go and test and make changes And not increase that so yeah, and I think the one of the advantages here. That's not vitally apparent is that Not only are they using this to just install and configure, but they can actually use this to automate the maintenance of this pattern going forward as well right So when we look at the the stack delivery Really what we're showing here is how we can provision these predefined blueprints That's what you saw in the demonstration. So you saw on the highlights for the the screen caps Being able to perform not only the initial deployment But we can leverage things like the heat autoscaling groups to have the automation to scale up or down We may decide to use a long meter for that We may use a different monitoring tool, but we can still leverage heat to do some of that One of the key things that that I think is interesting about this use case is that when you look at open-source solutions Like Jenkins they have really wonderful applications in many different contexts for build and for workflow automation when we start looking at the challenges that an enterprise has like Knowing which versions are deployed in which environments or knowing what roles are able to see and access and modify different environments That's not something that that most of those capabilities are designed for out of the box That's where Products like urban could deploy help us deal with that challenge It understands the separation of duties model It understands the rules about environments and promotion and governance and what was deployed or managed in which cases And then the last point here that I want to drive home is this Notion that infrastructure changes and I think we've seen this revolution with OpenStack and with other technologies Around a software-defined environment and having an API that we can provision a server provision networking provision storage and What's neat about that is that the infrastructure now just becomes and another artifact to manage like application source code And we can promote infrastructure changes through a pipeline Using artifacts and this sort of automation approach Just like we did for installing the actual application code on the operating system Yeah, and I would say that you know from my experience going out and Implementing this at customers and and working with Tyson and the mobile first team It's really important that this technology makes using OpenStack heat Easier, right? I mean, I'm a fairly technical person, but I don't like to copy 16-character UU IDs And YAML is like my worst nightmare sometimes So having a drag-and-drop designer right having a visual process designer Having knowing that they work with the open source tools a great open source tools from OpenStack and heat and compute and Nova like all that It's fantastic because it's an open model, right? Ultimately if I don't like What IBM is doing right as a customer? I haven't locked myself into anything right and that's what is great about the open open source community And I think vital to to this application because as this program grows and evolves You know, we're going to be looking at things like containers right moving to that newer model to see it Does that work for us right now in this instance? it didn't but six months from now eight months from now it may right and a Tool like urban code deploy gives us the ability to kind of abstract away the the the technical challenges of moving from a traditional OpenStack-based heat to you know, maybe using heat or magnum with with Containers right and that's something we will evaluate evaluate exactly And so with that let's take a couple of minutes because we've got four minutes left To talk about some of the closing benefits and so Tyson if you can take us through this Yeah, so this this was quite a challenge for us as a program I mean moving away from the traditional methods moving into using OpenStack I mean, that's a big big jump for any enterprise and an IBM had the same jump and now customers will have the same same process so We started off slow We continued on as a you know kind of all of it being a living breathing Organisms together whether it was the the OS and the networks whether it was the middleware whether it was the applications on top That's that's one thing personally that I love about this solution love about you know using All that defined and tracked whether it's in the YAML and the six thousand lines and that or whether it's in you know The the six hundred eighty APIs It's now all living and breathing together right so As we progress it'll just keep changing with us right and that's that's a big thing for us We saw a reduction from about five weeks to stand up that QA blueprint You know if you traditionally just go and go to your data center whether it's IBMs or any any other clients You request some virtual machines, and there's usually some engineers or operations people that'll do that for you You know there's there was another talk talking about it being faxed in on a form like you know That's still around And then manually installing that middleware, you know and if I want to do it again in six months I might not actually know what they configured because sometimes it's not tracked Now it takes us we say three hours that that blueprint actually only takes an hour But then we've got you know verification steps to do and we'll slowly automate those as well and then You know eventually you could easily say that you'll get a QA environment in a day And we actually recently stood up 12 of them in one week fully verified fully deployed and actually release the iOS apps Into our test environment that were pointed at those new environments So it's a you know the speed that we use you know moving at scale is just huge Well, now Tyson is moving some of his guys away from just trying to maintain and and build these these new environments to Looking at more useful things like okay What kind of monitoring solutions can we now automate and put on to these patterns so that we get real-time feedback, right? And those are the kinds of shifts that are really valuable to Tyson and his team to Provide more value for IBM and IBM's customers rather than just standing up an environment It's a the smaller dedicated teams like we've managed to branch off. You know, they're doing their sprints We've got teams looking at that monitoring, which is we've actually been looking at that while we're here We've got teams, you know Changing those patterns and making them more efficient, you know, we're looking at the performance We've reduced it from three hours to an hour All those things are great for us as a program, right? Time is is cost. That's one factor, but I've actually got smaller highly skilled teams now actually Functioning and not just seeing their maintaining things trying to restart VMs, you know That just chews up. Yeah, they stopped to be being babysitters of environments and start becoming more educators of environments Right, so they're educating themselves and what can I do better? Right How how can I make my job more interesting by doing things that I haven't had the opportunity to do before and one last point on this is that there was Moving to blue box and I know we only got it on Friday But when we decided as a program to host the QA and production environments for all of those iOS apps as you know, the 16,000 sellers go out and show and demo these apps On blue box and the solution and the efficiencies that we got out of that So not just the cost of the infrastructure, but the efficiencies was a 40% reduction. That's that's huge for us So I think I just mentioned that We've now moved to blue box You know, it's open-stack. You could have used, you know, any of the providers out there I mean blue box is now an IBM company. So that made that, you know, nice partnership And we started talking to them just as that partnership started And I'm really really impressed with it, especially now that we've proved we can do it over a weekend whilst flying You know So we've stood them up, you know Limited time when we need more environments as we grow, you know, I've done 12 industries at the moment when we get to our full 16 You know, that's that's growing again. They the the environments will breathe the new life If by any chance we make drastic changes will stop just stand up new environments, right? There's no sense of Operations people telling you all that's going to take, you know, 12 weeks and it's going to be a huge thing Especially for internal environments production slightly different. But because it's being used by mobile apps We can just switch where they're pointing So I think the key thing with with blue box is that we have a lot of very smart open-stack people within IBM that could set up and manage an open-stack for us but They usually are hard to get a hold of sometimes and and the fact that blue box can do it for us Means that Tyson and his team don't have to worry about, you know, managing that or monitoring that or maintaining that themselves It's it's an open box of resources through which they can request new resources to handle their workloads And they can move on about their business, which is adding value for IBM's customers And it's reflective and that's kind of the point. I think Tim's driving home here It's reflective of what we see with other clients is that we're enabling them to focus on what they need to do better By applying this kind of solution mobile first is focusing on how they solve that problem for their clients in those 16 industries Within those industries the automation that they're bringing to bear helps those industries solve the problem for their clients What is continually kind of rolls down and helping Helping drive that better user experience, which is what it's really all about So I want to thank everyone for your time today We've already got the slides up on the on the slide share. You're welcome to copy the link down We'll all three tweet the link here in a few minutes. If you follow us on Twitter MD elder deep warrior Tyson Laurie Tyson Laurie and We love your feedback. Please let us know. Please reach out to us Let us know if this resonates for you or if it's completely off of the kind of problems You're trying to solve today. Please please come down and talk to the blue box guys or anybody in the IBM booth You know and in fact tomorrow at one o'clock in the IBM booth We're gonna have or no, yeah, it's one o'clock in the IBM booth tomorrow Some of the development team for urban code deploy will actually be there showing some of the same kind of live Demonstrations as well. So come on down and chat with us. Thank you. Thanks