 All right, I I think it's 305 so I think we'll get started So when I start of this Thank you guys for coming. That's for you Brad So Thank you all for coming today. We're going to do something a little bit different. We wanted to do a Sort of spend a little bit. We had some time this afternoon and we wanted to You know, we wanted to figure we wanted to figure out something different something a way to show you guys Sort of a high-level concept show you a practical sort of a practical example and The problem we had was that When when you do you either do a whole spend the whole time doing a demo or you spend the whole time talking And either way you don't get you sort of don't get both both things. You don't get a if you try to do a demo You don't do both things properly so Since we had the whole afternoon what we decided and said to do was to talk about microservices and and beyond that we actually have a really interesting example and we have a good demo and Sort of in the first in the first presentation this the part one. I'm going to be talking about microservices and how Sort of how a new way to look at them a more More complete way of looking at them and then in the next session We're going to start thinking about what it means to build a microservices application We're going to we're going to then start looking at sort of the backing services the services that that aren't doing the actual work of your application These will be the services sort of like your databases your file store stuff like that In part three, we'll look at your actual workers. We'll look at the Sort of the the microservices that are deployed out there are deployed on OpenStack or Cloud Foundry or or containers And then finally we'll bring it all of that together with DevOps and we'll show how You know using DevOps how a developer can can build something on their laptop can commit and then sort of related to the discussion this morning at the keynote with infra how there's this automated workflow and the whole idea is to basically show how You know much more than OpenStack and Cloud Foundry and Docker. There's all these Open technologies open cloud technologies that come together to to sort of make this easy okay, and You know what I was thinking now. Why why would we talk about microservices? Well, it turns out that that a lot of the people presenting today including myself Are working on on this Apple Swift? It's not the the OpenStack Swift. We're actually working on this Apple Swift Website internally for IBM for for the server what we call the server site Swift And it's something called the the Swift package catalog And so this is a website that we manage right now and that we've built We are building and we manage and we operate and this website is sort of an instantiation of a lot of the things that we're going to talk about today. It is Based on microservices. It's architected for that. It has really Interesting it has a really complete workflow devops workflow. We actually based it on what infra what the info project is doing and then And sort of the the interesting thing here is that so we're we've been working a lot with with the Swift programming language And what we're going to do today is the demo and we'll talk a little bit more about it and near the end of this But the demo itself is going to be a demo that you all can download and can follow along if you want It's it's something called the IBM blue pick Okay, and it is a demo that and it's the codes available on github We just updated they just made a release this week and it's basically a Swift And I'll tell you a little bit more about it, but it is a server site Swift application that has an open-wisk serverless component had connects the databases connects to to Swift the Open-stack Swift objects storage and it basically does a very some some interesting processing connects to Watson Does some interesting processing so we'll so anyway, so this is where we're coming from we understand We understand open technologies. We we work in the open technologies team, and we understand microservices And so today I think we'll We'll go I want to get started with sort of this This problem that we're seeing when we talk about microservices The issue that we see is that people really think about Microservices in in a couple of ways they really focus on the either the technology or the tools that you know Do the or how do you know the technology the tools? but also how do you like decompose an application the architecture and We sort of feel that that that's an incomplete way of thinking and What that means is that we've we've come a long way, right? I joined IBM in 2000 and Since 2000 since I mean I can tell you firsthand since we joined we sort of been progressing Along this way of development When we started building when when I joined IBM the the the way to build applications Was really a basically a document driven development process you would have The offering management team create a document of physical like a word document a lotus document in our case and You would create this document, and then it would have all the requirements It would be then handed off and given to the architects The the architects would then sort of develop high-level view of the application They would give that to the devs the devs would then create a plan their plan would be like specific You know even a calendar plan that would be then given to the testers would take the features and and write out a test plan That would then be given to your support team and then the the documentation people to create installation guides operation guides and The problem was that everyone was separate you had huge silos and beyond the silos There really was this huge area friction between them I mean I remember times when we would open up we would create a feature and then test would open up a bug against it and We we'd you know development would fight with with tests. That's not a feature. That's not a bug That's what it's supposed to be tests would fight back There would be this back and forth and until it got escalated would the issue be either either close or it would be resolved And so they were there ended up being a lot of you know a lot of inefficiencies it was taking us you know 12 to 24 months to get through this whole process we would see as developers you when when project management and architects were defining something we were doing nothing as soon as we were done with development we would give it to test and For a couple weeks we would wait for a result and so for the longest time and that happened for everyone for the testers for Architects for offering management you were you would do a lot of work late nights. They would buy us pizza and The rest of the time you just wait And so and actually that that's the rest of time was when you would take your vacations do all that and so The this was something common not just an IBM, but in the industry and so you started seeing This move towards agile, right and agile had this idea that the the release of a 20 for the 24 months It took to release a project a product was was crazy We should focus on smaller work increments instead of having these massive projects Let's start trying agile wanted us to start focusing on on more frequent iterations And the idea was that you would quickly get prototypes out so that people could use them and so As we started moving into agile into agile teams we started seeing We started seeing that you know The the the business requirements gathering the architecture and the development sort of became Closely tied right there was less friction there The idea was that By using once we were an agile we started we started seeing some improvements there But there were still issues right we were Testing was a big problem with testing. We still had there was a dedicated phase for test actually multiple dedicated test Phases for test But what we started seeing and what we started realizing was that you could actually we were automating all our code all our testing There was already virtualization was available. We were creating automated test test cases and Basically you started seeing this move towards People started thinking well if the automated test case pretty much covers Does exactly what what our our test phase is doing right now? Why don't we just build it into development? Why don't we just include testing into development so that if every time I put a commit? We we just get an automated test and that was a situation Where we had this combination right? We were now we were now continuously integrating our code All right. Well, then there was a sort of a mental change in people's minds and management's mind and We were saying development and tests were saying look the code that we have is stable We know it works. We know we could get it out there without any consequence Why don't we instead of instead of having to do a separate test? We know it'll pass everything Why don't we put it into production and you know a couple brave companies decided to do that and these were all probably you know startups who didn't have the the baggage of it or the the the Memory inside of the their companies to know otherwise and they started pushing into production directly from commits and again this is something that you see an open stack and So what ended up happening is you had this this move from continuous integration where the testing was automatic to continuous delivery and so you had the gap between Business development QA and now operations was all that all these squads were now be becoming sort of Unified squad the teams were getting big we're getting more focused on a task and these silos were were disappearing and so What we saw at this point was that The because these were now we were moving more towards a cloud delivery cloud applications We started seeing a situation where? the developers were operators now and You know operators are very different Then the role of an operator is very different or was very different than the role of a developer An operator had to worry about you know run books had to worry about Getting called having beepers getting called at the middle of the night worrying about Dis failures and server failures communication failures and what we saw now was that Because the developers were used to you know, they were different used to working different hours used to doing Automating a lot of processes you started seeing that the development teams started actually working to optimize the the flow of Operations so they they a lot of the manual processes became started to get automated a lot of the run books were scripted a Lot of the a lot of the processes the day-to-day processes were were sort of optimized but another big change was that This really was the first time that developers saw What it meant to run their application right? What did it mean to? How downtime affected them how it affected their customer because now they were the customer and what you started seeing is this move this change of architectures You started seeing sort of a Because the developer didn't want to be bothered at 3 a.m. On Friday They started building in resiliency Failure failover they they knew they expected things to crash But it doesn't mean that they expected a service to crash But it doesn't mean the whole environment would go down So now they would get a notification like right now We'll get a notification on Saturday that a service went down But it doesn't really affect anything because orchestration brings up another one and and the environment continues to be available So anyway, so what at the end of this sort of move from continuous delivery to devops you had this idea of of greater resiliency and of a higher automation of your day-to-day tasks and so as I sort of hinted before The last big move was that you made these technological you you made these changes based on the virtualization the changes in your organization and The changes in your methodology really the the final big change that we we've been seeing in the last couple of years is This move from the monolithic Applications to your microservice sack application If you're obviously if you're building a new application, you're you're starting with a cloud native application This isn't the case. This is something you don't have all this baggage to move to sort of migrate from and so what There was a couple a lot of actually benefits from microservices. There's some downsides, but the biggest benefits are you know It used to be when you had them I mean, I remember well, I won't say project names Well, we used to work on on project and as the crunch time We were a couple weeks from from from the due date The that they would just throw more people at it, but the problem was that we were all working on this on this very You know this fixed set of Lines where we could own where we could contribute to so the more people we got it really didn't help anything But with microservices because you're splitting everything out you can actually have more p the the amount of Parallelization is actually greater. You can actually have more people if this is more important or if this needs to scale faster You you can work on that and there's Because another big advantage to microservices is that because they can be released at different versions your development velocity is different It actually makes sense. It makes it possible for you to focus on key microservices And prioritize them over others if this is working now, let's start adding features over here We don't have to touch this for now But then the microservices themselves they give you this greater stability and really greater utilization of your hardware Because now your services themselves can run between serve server and server their containers or or VMs. They can move around But beyond that now that your services are up and running you can actually pack them in tighter in in In your hardware Again, I remember we would just order if we wanted more reliability with these monolithic applications We just ordered, you know redundant CPUs redundant power supplies more More hard drives rate everything more memory and these were very expensive servers, but now we can actually just Pick cheap cloud servers and just deploy to them if something happens to the server or something happened to the service But it's it's not something we worry about And then because these services the microservices themselves if we if we build them right, they'll be smaller And more targeted and this is code that we can reuse another within other With internally with an organization or we can open open source them making available to everyone and so The big thing the big advantages to microservices are one The increase in speed of development right from 24 months This is a real increase from like 24 18 months when I started to now we in a couple of months You can get the first version out and then you can iterate constantly So every couple of weeks you can get new versions and beyond versions this concept of versions It doesn't really apply anymore. You have new releases a daily I mean I've heard of you know some of the cloud companies where they're having releases Like 20 30 releases every couple hours. So it's something that it just becomes It just becomes different way of thinking and then your cost is reduced it's reduced in a bunch of ways You're not buying this huge expensive hardware, but beyond that your developers are developing all the time They're not waiting. They're not on the bench, you know for huge percentage of time Waiting for other people to do their jobs. Everyone's doing everyone's working at that at sort of a constant process Your resilience is improved now You have the advantage of having your application be sort of architected for failure And so you can you can you can it because we know that failure is a reality We can just work around that and we can have We can understand that reality and just work around that and make sure that the application is always available You have increased flexibility, right when you build your application when you for example the way we work We we develop everything on on containers and so on our on our MacBooks we can develop and it's the same exact Same exact back-end same exact micro services are going to run here as they're going to run in our cloud environment and then One of the bigger things one of the bigger tenants of micro services is that you want Visibility into your into what into everything basically you want greater you have greater visibility Into your processes your services running But then your applications are also built with a different paradigm now we because these are web and we get It's a constant connection. We know how our users are using them. We know we can do a B testing We can we basically have a better understanding of Everything from the deployment from the hardware the software to the way that the tools are being utilized and so really It ends up being these four things that we focus on the most right with that these are the most important components of micro services You have like I said the architecture and technology, which is what everyone talks about But I think it's equally important to and it's and if we don't consider the last two the organization the methodology I think that really puts you at a disadvantage when you're building your solutions What ends up happening is that you you may have the best technology, but if your teams can't leverage it Or if you don't have your methodologies your procedures ready The greatest technology really can't can only get you so far So when we look at the architecture We we look at these these key principles to micro services, right? And I in a little bit. I'll talk about the 12 factor app But I like these because these are you know as an old Linux guy I really this really reminds me of the Unix principles, right? So do one thing. Well have your micro services Whatever they're focused on whatever they're supposed to do don't let don't let feature creep get into them Let let whatever does let them do it. Well, if it needs to do something else build another micro service If you need to change the way something works just version and create another version There's no need. You don't have to be stuck in this world of ever-increasing micro services build afresh if If your API almost does what you need and but you have consumers using it right now Just create a next another version Build off of it, but don't don't because you were always The idea is that the beauty of micro services is that people can continue to come or services can continue to consume a Version you can just create a new version and in OpenStack. We know that right? We've seen that in the changes of the API And this one's these two are kind of obvious right expect the output to become an Input to someone else so a service the that that returns something should you should assume that a Human being isn't asking for for that isn't connecting to that service You should assume that it's going to be another automated process Connecting and expecting a result so you know Sort of an addendum to this is that you know this goes to the fact that the all the information should be in the request It should be stateless Again, this is something that there really is dealt with more comprehensively in the 12 factors The next one's try early man Don't don't wait to to release it after six months if you let's work towards a an MVP a Minimal viable minimum viable product. Let's get it out there. Let's get it if people like it We can work on we can We can sort of improve and add on to that But if they don't like it if no one's using it then why are you why are you wasting your time develop? They were developing that then throw that away and start with something else Next and to me, this is the most important one invest in automated tooling The and again, I was really happy that that the info team was was up there this morning. It's It Takes time to do it, but it takes time to do it. It takes time to set it up once After that it is it's done. You don't have to occasion. You may have to tweak stuff all those Ted like for example just No matter how much time the open stack team Spent creating the infra after I think was a number 1.7 million test runs Imagine how much time if a human being had been involved with each of those And when we look now that the next factor is the the technology that you use, right? The the big obvious one is cloud provisioning you you have to have an auto an automated approach an automated way to deploy Either containers virtual machines bare metal whatever it is. It has to be an automated way So that means that you have to standardize and standard eyes and easy ways to standard eyes are choosing virtualization Containerization Platform as a service whatever it is you have to standard eyes and that really helps you when it comes to deployment and managing your deployments You have to worry about your the way you integrate your applications, right? Where do the Where do where does the authentication sit? What are your communication? Methods what is the anyway? You have to worry about how you integrate because at the end of the day That's the key to the application all these services have to be able to talk to each other They have to be authenticated. They have to be you want them to be secure Right, but then again, there's always this constant. You will always have legacy technologies. So what does that mean? It means, you know relational databases Perhaps some some Files that you have that you have to read but when you're working with these you have to find interfaces that that sort of abstract them or or use them in a way that don't have like for example with some databases you have Always on connections that that's not a good way to do it if you have these microservices that are designed to Live and die and it doesn't and it doesn't affect anyone Again manage your security now. There's all these considerations about how do you manage security? Do you have an API gateway? Do you have single old sign-on tokens? How is that managed? your And then you know the the other big one to me is the the beauty of this open cloud is this polyglot nature in Not only languages and databases But really in everything else in the the messaging do we what do we use for message cues? What do we use for databases? What do we use for programming languages? And really the answer is It's a combination of what's the best tool and what's the best tool that we can use? So are your organizations built for Java development for PHP for? Swift for whatever Let the the beauty of this is you can build something release it And if and if you find that your skills have changed and migrated to something else You can now the next version you release build it and release it on something else Right and so, you know when we look at the technology specifically Technologies the core ones that that that we consider that we talk about are really Containers I mean containers a way to encapsulate either containers or virtual machines Then we have this idea of service discovery, right? So that the there's no the containers the virtual machines because though this is the world of IPs and ports We really we really have to invest in a way to automatically detect the the IPs and basically the resources as they exist in in IPs and ports and then we need an automated way to sort of Deploy to grow to shrink your resources your deployments And then finally the the big thing the big advantage to API gateways is that your security and Your routing is all managed by this sort of your your your front end And so it's the single point that handles authentication security Access control and the big thing it and the reason that it's advantageous is that we don't have to put that code in the actual services The services themselves can be simpler Okay, when we look at When we look at the organization When we look at the organization the keys success to the organization. We're really thinking about What are our teams aligned to right are they aligned to to business to lines of businesses? Or are they aligned to technologies and sort of the difference here is that if they're aligned to sort of a Our project is something for example us Are we aligned to this? Swift package catalog where we are all working for its success or do we all have our own vps and executives that we have to You know in worst case go to them and ask them to fight for us or again or fight against somebody else So is there like are we removing these political barriers? Do are we working as a team? How are the responsibilities divided right that's again an extension of that first one do we Every time we need a design resource Do we need to go in and talk to an executive to get it? And when they give us the resource or if we don't implement it to the people yell at us if we don't do it Exactly the way they said it and then You know because we're operators now because we're deploying and running this in the cloud How are we doing DevOps? Do we do we have like a Dedicated team that does DevOps and then we just hand it off to them in which case we as developers probably don't care Don't care how I don't care if things break don't really care about the infrastructure all we care about is getting my code out and getting fixing bugs or If we're all we're or if we're all working as a team You know where everyone does Produced like releases and develops and does you know We all fix stuff and we all work as a team then you know It's in my interest to make sure that the application is stable and reliable So that you know that not only does the team do not get calls on Friday night, but I don't get calls Friday night And then whatever what are the size of our teams? How how big how small should we make them? Well, you know There's a couple there's a couple stories. I heard yesterday. I think Jeff was mentioning that Bezos wanted his teams to be two pizza size teams Right, so if you can feed to if you can feed your team with two pizzas That's about as large as you want your team to be well That might be a good rule of thumb And the beauty is that if your microservice is getting to to be bigger than that you might be able to split it up and and separate the Separate the the functionality into multiple microservices And then how do you handle your your communication between teams right is this and This really comes down to and you know in in seeing it work is like how Some teams are like really aggressive some are passive aggressive some are so it ends up being how do you communicate? How can you best work together? And I mean large organization large projects like OpenStack We see this a lot and so this is one of those things where how is it that your your team? Communicates and works together right and then finally, where's the power is is this project sit under? Under-designed does this project sit under development under saddles who owns it because at the end of the day you really want to have Everyone sort of feel be on the same boat and going in the same direction Okay Next is your the final one here is the methodology right and again when we're building when we're it's really important to know Are we releasing a? a Product that will have a release and then we will work on the next one and we can improve Or do we have this long live project where we don't really care where we don't really care about today? We know we're gonna release it forever We're gonna maintain it forever and really the idea should be that These services get released and then you move on to the next version next version basically the next product And the idea that way is that you really you're never complacent you're never you're never tied to something You can always you can always you can always change you're not married to any any approach any technology Is your development agile? Are you move? Are you working together? Are you doing fast or you're doing this waterfall where everyone's separate and it's taking us a lot of time? You know and the other one is who controls your business requirements right is is it coming from does again? This is sort of like the power thing is it coming from the is it coming from? The business the the business side you're you're offering management who's saying you need to do This this in this feature even though it hasn't been even though we have user testing that says that No one's gonna use that and nobody cares or is it coming from the fact that you have this instrumented? These in because your application is so instrumented you actually have numbers to back up what users are doing and what they want right This this one the the next one's you know my sort of my pet one the one where the fear of change or the fear of continuous delivery You know I'll tell you an IBM that was really a big one when we when we with our website when we release We release all the time to production and that was such a big thing and actually the way we got it We we basically we ended up doing it was just After a while they forgot about us so we just kept doing it and pushing into production and now They all think it was their great idea to do it so And then again the your automation man It's very very important that we you know that we automate the heck out of everything Every process that you can do if there's a human being that that's involved somewhere It's it's critical that you that you extract the human being from that if you have Sort of this idea that everything works But but you know if somebody is the only expert in Docker and then he leaves then that's not a good He has to click a couple things before it works That's not a good idea you need to make it automatic so that every so that everything can flow without touching a human being and you know this is the And so this is the mantra when you're building these new 12 fat these new microservices right this idea of the the 12 factor app and so You know it it's almost obvious. It's almost in retrospect. It's almost like I can't believe we didn't have this before We I can't believe we hadn't communicated this before it's such a clear way to Basically build your your cloud native applications and it also provides a Really clear guideline to how what you need to do to migrate your existing monolithic applications Right, so I think for the rest of the day What we're gonna do is we're gonna go over these and we're gonna see how we can use How you know the backing services your services your what we're calling your infrastructure services your databases your your messaging your File storage how all of those are handled by some of these how your microservices themselves your your functions are handled By another some more and then how finally DevOps handles the rest so the rest of the day. I think we'll spend looking at that right in in part two and in the next part Dan's gonna talk about or actually Sean and Andy are gonna talk about your Infrastructure your back ends right and they'll cover these they'll talk about your back-end services how we handle logging and how you we handle your special admin processes in The microservices you're delivering application microservices Dan will talk about the dependencies your how your applications handle dependencies configurations the processes themselves How you bind the ports your your service concurrency and your disposability Okay, and the final part Megan and Michael will talk about your dev ops deploying with dev ops and this will really focus on how you use sort of the git and Jenkins to manage how you handle use git to manage your code base How you have your Jenkins and Garrett and whatever to do your build release and run and then how you basically How you develop on an environment similar to what you you run in production Okay, and the way we're gonna show you this so again what we're gonna do is half the time about half the time we'll spend talking about the theory and Using examples from open technologies, but then the other half is we'll walk you through this demo The demo is something called IBM blue pick if you guys just do on github Switch I will search for IBM blue pick. It is by IBM Swift and this is what it is. We have this Microservice application on the left-hand side. We have the there's two client access methods We have an iOS Swift application for those of you with the Mac you can test it out that way or we have a web app For for those of you who don't don't have a Mac or don't want to use that Then the main service is this yellow the central one. It's a ketura. It's a Swift ketura ketura is A web framework for Swift for server site Swift and we have a ketura back end and basically the iOS application or the web app Connects through this mobile access client Uploads a picture puts it in sends it to ketura ketura then takes your picture Stores it in object storage Then creates an entry in your cloud and back-end database At that point an open-wisks action is triggered open whisk is sort of this open-source Serverless framework. It's similar to lambda or the what was the other one cloud functions The idea is that it's an event-driven Event-driven serverless applications are Anyway, it's that and what we what open-wisk does is then it's triggered It says that you upload a picture it connects to the to the Watson alchemy vision And it does an analysis of the picture It also uses insights for weather to see if there's any weather related information from the picture And then it posts it publishes that back in your cloud and it connects to cloud it and uploads it and tags your picture So what we'll see in in the demo today After we're done we've done building it in the last one will actually see this work We'll take a picture and then we'll analyze it and tell us what what it sees All right So again guys, this is these are our keys to success and I have Admitted for questions. Oh And it's very important to for you guys know that after the next session there will be beer over there So so you had a question The first This one all right guys if you have any questions if not, we'll I mean we're here all day Doll afternoon. I think it'll be an interesting day Say that again Part two is in five minutes and in ten minutes absolutely, so You know it's it's interesting when we came to the summit I I really like this summit a lot for a lot of reasons right one of the One of the big reasons is that you're not focused on on just this is this is such a community that realizes that there's much more than just this one technology and Beyond that the technology itself really really embraces others so you see that in the embrace of Docker you see that with the with when we talk about cloud foundry We always talk about open stack and you see that in actually with with canonical talking about their their Container technologies and so you see that and so what we didn't want to focus on a specific on a specific tick doll in a specific You know Project what this is is a high-level view Using the and all of this a hundred percent is applicable to to open stack Okay, well specifically on this we'll see the the object storage. Will you be using the object storage? We can talk about that so the his question was that one of the most Problematic problematic areas is global transactions and we see that also and that so I said that microservices and many advantages of The biggest disadvantage is that as you create more microservices There's more time communicating between things and so we can talk about that out after but yeah, I agree That's that's the that's the biggest issue Okay, thank you