 Good afternoon, I'm Tony Irwin, with me is Brian Martin, and we're going to talk about migrating a monolithic app to microservices on Cloud Foundry, sort of the experiences that we're having with the BlueMix UI. And just to give, to level set, the IBM BlueMix is an open standards cloud platform that has a pass layer built on Cloud Foundry, of course. And the UI that we're going to be talking about is the front end to our BlueMix platform. And there's a fair amount to the UI, just some small little screenshots here. But we have a home page, as you might expect, some marketing pages, information about pricing, a dashboard that shows you your app status and services bound to your apps and those sorts of things, a catalog and a separate page also for managing your orgs and spaces. Now, we started this like two, two and a half years ago, probably, and we've ended up with a bit of a monolith, or not a bit of a monolith, but an actual monolith. It's a single page application. The front end, the UI, the browser side is all in Dojo. How many non-IBMers here have used Dojo? So that'll be a theme that we'll talk about here in a bit. So we've got this big, we're loading all of our JavaScript HTML CSS into one web page, and it's all served by a Java app that's running in Cloud Foundry. This was kind of a state-of-the-art architecture in some ways, kind of when we started. Now, if you've been to the various talks, microservices are the thing. But even with that, single-page applications are still popular, they're still frameworks, AngularJS, et cetera, that sort of go down that route. So here's a picture of our current, or where we started, I should say. So the home solutions catalog, et cetera, running up in the browser as Dojo components. The back end that's labeled BlueMix Paz there, Cloud Foundry Paz, has our big Java server connected to an SQL database service. The bottom layer is really the Cloud Controller plus other APIs that our Java server calls. In a lot of cases, calls from the client are just passed through straight to Cloud Foundry. So the monolith has given us a few challenges. One, when you're getting all your static resources to the browser, as well as making a bunch of back-end AJAX calls, the volume of your client-side request starts to create some bottlenecks. So we have some performance issues that we would like to make better. We've got a number of other teams within IBM that want to be part of the BlueMix UI experience. And aside from those teams, just within my own team, we have subteams in China, Raleigh, North Carolina, Princeton, New Jersey. I'm kind of an island in Rochester, Minnesota. So we're very, in Toronto, Canada, another place. So we're very spread out and it's kind of difficult to get sort of that continuous delivery model with a monolith with folks so spread out. We want to get to a point where we can push smaller changes as they're ready, as the subteams have them ready rather than monthly or bimonthly pushes of one big code base. I asked the Dojo question earlier and I don't think anyone raised their hand. So that's one of our issues with the monolith is it is built in Dojo. And when we want to add to our team or hire outside of IBM, where do we find Dojo developers? And the last point there is with the single-page app and sort of the client-side routing of URLs we're doing, our SEO story isn't great. So I'll go a little bit into what we've started to do with microservices. Sort of what we've hoped, I'll show sort of where we're at. We're sort of in the early stages all in all and moving in this direction. But we think microservices will help us in these areas on this chart. So they'll help us. We want to get onto a more modern stack, really. A stack that is more performant, lighter weight, kind of the simplest solution that will solve the problem. So we want to get to the small services. If you saw Matt Steins talk next door, he was talking about that service-oriented architecture where you decompose into smaller pieces to solve the problem. Serving bare bones, HTML, CS, JavaScript, trying to get away from the huge amount of stuff that we bring over for Dojo. A stack that will make it easier for folks to find answers on Google, not as Dojo again can cause problems there. We think it will help us to allow more regular updates to the code. And like I mentioned, they're sort of my team with subteams. There's other teams within IBM, and you can imagine in a large company and probably even in small companies, there's a lot of opinions about what technology stack you should build on. So we believe microservices will help give teams some flexibility. Not everyone has to use node and dust like we're kind of starting with. And not everyone has to use. Someone could still use Dojo if they wanted. Teams don't have to wait on others necessarily with these loosely coupled pieces. And by moving to microservices, we're sort of, and you'll see on the next slide, I'll just go ahead and go there. We introduced a proxy layer which helps us, instead of doing our client side routing, we can now do friendly, cleaner URLs which helps our SEO story. So this is actually a diagram that represents where we are today in this migration. Remember the top box had six or seven little purple boxes in it. We started to push those boxes down behind the proxy now. So home and solutions kind of are more static pages are now sitting behind the proxy. We have a common microservice, which is sort of intended for other microservices to call to get things like the header and footer. So that can be shared. The monolith is still back there, but it now is behind the proxy. And we've started, there's some other little boxes here. This is kind of simplified, but we're also using services for session store and those sorts of things. And I might just drop quickly into a demo to show what's live now. So this is the Bluemix UI, actually live running code. And this is our dashboard. So this is actually being served from our monolith. This is one of our more dynamic pages that we have not yet started to break apart. But if I click say on solutions, that's actually being served from one of our microservices. So that solutions microservice I showed. Yeah, so if I actually click on the URL, you see now it's Bluemix.net slash solutions. So we have a friendly URL surrounded through our proxy and to our solutions microservice. If I click on the home icon, this goes to the home microservice. And if I click back on the dashboard, then it's the monolith. And you notice we've tried to make it look like it's still all one single page application, but these are actually separate HTML pages being served by separate services. See, I've lost the presentation. I need some microservices to help me run the Mac here. So I showed the slide and just gave a demo of this architecture. I mentioned our common microservice. That is kind of one interesting thing we're doing to help bring some consistency to the whole thing. The page at the bottom shows our home page. And it's, as you might expect, has a header and a footer. All of our microservices call this common microservice to get an HTML snippet basically to insert both places. So this allows our microservices to have a consistent look and feel. And if other teams build on another stack, as long as they're using HTML, they can call our common microservice. And at least we all share the same header and footer that way. So this is where we want to get to, of course. We want to eliminate, in this picture, the Java monolith has been eliminated. We've moved all of, we've added dashboard and pricing and origin spaces and catalog down below the proxy. This is still going to take us some time, but it's the direction we're headed. Now, of course, there are some new challenges, as you might expect in this world. There's more moving parts, more complexity. Again, if you're at the chat next door for the last just before us by Matt Stein, there is a lot of talk about some of the challenges and how to manage those challenges as you break things apart. Collecting status and monitoring the health of this ecosystem is more difficult. Seamless navigation with the monolith, I just sort of demoed how we've done that. But there's some challenges and you'll still sort of notice some places that we want to make better, where maybe the header doesn't show up right away when you're toggling between the two. Developer skills, now I've mentioned this new stack and microservices will help us with developers and find new developers, but the developers we have, we're still all sort of dojo experts. So there is some learning curve to get folks on to our Node.js stack. And blue-green deployments, I threw in as another bullet, has been sort of a, it just makes you think about it differently, right? Because I think everyone, most everyone in this room may have at least heard the term blue-green deployment, where basically you swap URLs from your blue as the currently running one and you switch that URL to the green, which is your candidate to promote. And so one way we've done that is, you know, the blue box in this case is a proxy in all of our microservices, so you can consider that a big A app, I guess, that consolidates all those things together. The green box is that same stack, but the brand new code. And so for us to do a blue-green, we can deploy that whole stack and switch our main URL to that URL. So that's one approach we took there. Now, those of you who are astute would probably say, well, wait, microservices should be able to be deployed independently and I should be able to just swap out a home microservice. And, you know, those are things we can do as well, but when we do have a whole unit that we've tested together, we've decided not to try to swap URLs on every little sub component. Excuse me. So now, Brian, I think we'll get you on board here. Brian's going to sort of talk about some of the enhancements to Cloud Foundry that could help microservice solutions. Hi. Again, Mike's working now. So I'm Brian Martin. I'm one of the architects for the BlueMix platform and I've also been working in the Cloud Foundry community for quite some time since back in the beginning in which BlueMix was kind of a grassroots effort inside of IBM in which a bunch of volunteers across IBM started working on a PAS platform and we really kind of developed this outside of any organizational structure in IBM. So, you know, having developed or used the microservices architecture from the beginning would have been really great because we were kind of building up from this very distributed team. But, you know, one of the things that we want to talk about are how can we enhance Cloud Foundry, the platform, to better enable us and you, our customers and fellow partners, to build applications using a microservices architecture more effectively on Cloud Foundry. So I did think I attended Matt Stein's presentation before this one and I think, you know, we had a good comment there which was, you know, you have to be kind of this tall to start on this journey because, you know, if you're migrating from a monolith application to a set of microservices, it definitely increases the complexity of what you have to manage and monitor. So you need to make sure that you have everything under control before you embark upon this type of journey. So, you know, some of the features that we see that can help with enabling this type of microservice architecture is having context path routing. So this is a feature that has already started within the community. We have, you know, a committer from IBM who's actually working with the community to get this into the Go Router and I think this is going to be, you know, a really nice feature especially those who are coming from, for example, a Java EE kind of mentality where, you know, you used to be able to deploy web applications with, you know, web paths onto the same host and you come into the Cloud Foundry architecture and you can no longer, you know, have multiple apps all on the same host name with different context routes. It's a bit of a shock at first. So I think, you know, getting this feature in will be good and this, you know, allows us to, you know, efficiently start sharing cookies. Like, we don't have to share cookies at a domain level if we just need something happening within the app. So, for example, in the case of, you know, what was happening with our HUI, you know, once you're logged in and you have kind of a session with that app, you want to be able to share that session information or that session ID across just that one application but without sharing it across, you know, other applications in your domain. So having a feature like this context path routing can really help with that. So, you know, this is a good one that's already underway. I think, you know, the next kind of problem that I see that we may want to consider tackling in the Cloud Foundry community is the concept of an application version. So today, you know, when we deploy all these different applications to Cloud Foundry, you know, there's no real formal concept of an application version. So we may do a bugering deployment like Tony described, deploy our app like, you know, MyApp-1.0, you know, deploy a new one MyApp-1.1 and then maybe we switch the route for MyApp to point at the new version or back and forth, et cetera. So, you know, this can work, but it definitely does complicate when we talk about a distributed monitoring problem. Now we have, instead of having, you know, one application that we're trying to keep track of for that monolith, we may have, you know, tens or hundreds of applications we're having to keep track of. And if at the same time those application names are constantly changing, that can, you know, create, you know, problems from our change management database or from a monitoring database. So I think, you know, it would be useful if we could, you know, actually deploy multiple versions of a Cloud Foundry application. Just give it, you know, under the same app name, but maybe different binary versions that are versioned and be able to easily, you know, switch back and forth which one we want to run. So, you know, this is still kind of an idea that's kind of an infancy, but, you know, looking to get feedback in the community around concepts like this to see, you know, what others think about it and, you know, if it's a useful concept. You know, when we were talking about, you know, Netflix OSS, for example, there's certainly a concept of versioning that are associated with applications that are deployed there. Yes. Yeah, I think it can be easy to implement. And like you say, there are approaches that you can use to implement it on your own. But I'm wondering, you know, especially when we talk about within the community, we want to build up common sets of DevOps tooling. So we want to build up, you know, delivery pipelines and other types of tooling. And if everyone just kind of invents their own kind of ad hoc versioning concept, then that doesn't allow us to build kind of a standard set of tooling that can help us manage, you know, all these different deployments. So I think that's where making a formalized concept can help, because then it allows us an ecosystem of tooling to, you know, rise up around that API. Versus just, you know, having a convention which doesn't allow that to occur. So advanced routing policies. This is another key thing, and there's a lot of work happening within the GoRouter community today to enable this in the future. And I think this is important. You know, we want to have, as we're rolling out different microservices or different bits of the app, we want to be able to have, you know, maybe testing occurring. We want to be able to set policy so that we can route, you know, some percentage of our requests to the new version, some percent to the old version. Maybe target specific user groups. So all of that is going to be, you know, made possible if we can get the right extensions into the GoRouter to enable those advanced types of routing selection policies. And, you know, I think this is, you know, even more important when we think about microservices. Do we need to have any type of coordination of different bits of the microservices? You know, if we select, you know, one user for, you know, say this AB testing, does it affect any of the other services we may need to select for that same user. So I think that's an interesting problem to also solve. One of the biggest issues, I think, that we see when considering to do a microservices app on Cloud Foundry is what I'm calling private applications. And this is the ability to, you know, hide microservices applications from public routing. So, you know, I may have a whole set of services that are composed in the application, but I really want, you know, a couple endpoints, like the proxy endpoint that Tony showed in our architecture to be the one that's exposed to the end user. We don't necessarily want people to, if they could discover the URL for, you know, the billing service. We may not want to expose the billing service directly, but only via some other path. So an ability to, you know, really separate which parts of your application are public and which parts are private, and then, you know, potentially put those onto their own software defined network within your space or org so that only your space or org can access those microservices and you're not making them available, you know, to the world or into, you know, the flat networking space. And with regard to that, you know, we'll have to solve the problem of how do you get access for routing. In the case of a software defined network, I think that's, you know, pretty easy and obvious, but maybe we want to enable some kind of cross space or cross org access as well. So composite applications. And in the previous talk from Matt, you know, he was calling this kind of the big A application. But I think, you know, once you actually deploy an application that's composed of mini microservices, you want to understand the health and status of your application as a complete picture. So what we, I think this leads to is a desire to have some kind of composite application that could allow you to group your applications together for status and for control potentially. I'm not sure if you want to control them all at once, but possibly, but certainly for status, monitoring, logging, you want to be able to group together a set of related applications so you can understand those all at once. Service registry. So, you know, another thing I wanted to mention, you know, as we're talking about, you know, how we can extend Cloud Foundry to better enable microservices types of apps, you know, one approach was mentioned using, you know, Spring Cloud. And, you know, while using Spring Cloud, you know, maybe an option, I think, you know, one of the potential downsides to that, at least, you know, we would see inside of IBM is that, you know, we want to be able to adopt new technologies. So, you know, not everyone may want to run with Java Spring. We may want to have some people writing in Node, some people writing in Ruby, some writing in Go. So we want to be able to compose different parts of our architecture based on the right language to solve that problem. And it may not always be, you know, a particular Spring Cloud platform. I think there's, you know, even though we can solve these problems maybe in a very specific way, if we can bring some of these services together at a greater platform level, then we can enable them, you know, for everyone or all the different types of apps. So, service registry is a key one of these services. You know, how do we actually discover the active endpoints for our microservices rather than having, you know, hard code to pass or hard code to versions and that kind of thing. So we need a place for your services to register into the service registry at registration time and then a discovery protocol so that you can actually discover those and dynamically invoke them properly. Part of that should include, you know, having routers that can allow, you know, like the history type of thing and ribbon to have, you know, fast failover. So I think Tony, you know, brought this up and, you know, what we have seen as we've decomposed our application already, you know, having the best performance monitoring tools and log tools are really required when you're looking at this type of architecture. So, you know, when you break your application up into many microservices, you know, if you have a performance problem in one of those services, you need to be able to, you know, have dashboards in place so you can easily discover, okay, my overall application is performing slow and now I can really dig in and find out, you know, where the application is the cause. So this kind of goes back to that composite application view where we can collect all the interesting statistics about the composite out together in one place and so we can easily drill down into, you know, which microservice or which part of the application is really causing the problem. So related to that is being able to, you know, aggregate, you know, all your logs into a common log source and then I think also a potentially missing feature from Cloud Foundry is some capability to insert correlation IDs, you know, automatically into your request flow so that, you know, as we're tracking requests from, you know, one entry point into several other services, we can flow these correlation IDs along, have those contribute to the log stream so that we can really track individual applications as they hit all the different services within the flow. Finally, I think, you know, are there any capabilities that we can add in terms of testing your services? So of course, you know, as you're moving into a microservices architecture and you're deploying more and more of your services, they need to be, your testing needs to be integrated to your CIECD pipeline and, you know, a big advantage of this type of architecture is that you can deploy smaller chunks more often and without having to, you know, do the big monolithic deploy where all the different teams have to come together. But, you know, the question that I'm kind of raising for the community here, is there anything else that we can do within the platform that's really going to make the test problem easier? Because I think, you know, as we have all these different disparate pieces coming together in, you know, they actually have to all work in conjunction to, you know, deliver the function, I feel like there's probably some more that could be done from the platform perspective to help you, you know, go through that test life cycle. Part of it was, you know, advanced routing features like A-B testing and such, but is there anything else, and I would like to hear from the community, you know, partners in general, if you have good ideas about how you think the platform could help you in your testing, let's, you know, let's get those, let's talk about them out on BCAP Dev or otherwise, and so we can really make this a better platform for everyone. And that's really all I had for the platform today. So, you know, if you want to reach out to me or Tony, there's our email addresses and our Twitter handles. So, you know, what I like to do is, you know, we threw up some ideas about how we think the platform could evolve to better support these architectures and, you know, we shared some of the pain that we're currently enjoying, that we're getting from, you know, taking our monolithic application and migrating into microservices. I think, you know, really look at our team and I suspect many other teams are like this. You know, we have this very distributed team, you know, all around the world, every time done. And I think, you know, that's the beauty of something like microservices is that we can really now not have all these team members contributing into one code base that gets delivered as a single app, but we can have them working on their own individual pieces, delivering them, you know, developing locally within their small teams, delivering their pieces incrementally. And, you know, we're already seeing the results of that and it's really helping us out quite a bit. So, we're really excited about this architecture. But we are realizing that, you know, there's some challenges like Tony has mentioned and I think, you know, what I like about this is that since we're actually living the pain, we're actually developing the solutions in terms of better monitoring, better logging, better deployment policies, et cetera, to enable others who are going to build the same type of applications on your Cloud Foundry platform to do it better. But, you know, if you have more ideas and more input about it, you know, we'd love to hear from you. And are there any other questions in the audience right now? Yes. The question is, you know, what is the impact on networking? And I think, you know, one of the biggest impacts that I've seen on networking is that it really pushes home for me the need or the desire to have more of a tenant network, more of a software-defined network that could be more tenant private because, like I said, what I'm seeing is I decompose my application into smaller and smaller micro-services. You know, I may want to have those not be public in many cases. I want them to be more internal and the fact that I have to today, you know, maybe they're kind of hidden because you don't know their host names or their paths and maybe you need some secret authentication keys. But the fact that they are generally available is a little bit troubling to me in general in terms of the micro-services architecture. So I think, you know, one of the key things that I would like to see is a move towards an ability to have software-defined networking within Cloud Foundry to put your different parts of your applications onto different networks which are potentially private and really separate those that are public. So that's kind of the biggest... I wouldn't say it's general. Definitely added requests to the system. I mean, it was kind of a surprise to the folks who monitor our entire fabric, you know, Tony, why are there so many more requests? Because, you know, things come to the proxy but then they're also going to go to whatever so there's... Yeah, and I think that's another good point which is, you know, do you... I think it kind of also leads you to either want to do direct routing. So from in your application tier do direct routing to the application instances, which is possible via some of the new Cloud Foundry features, but you have to use smart client libraries to enable that or you want maybe to have a different kind of mid-tier router, which is different than your front-end router potentially because you may not want to come into your Cloud Foundry instance and then, you know, go back through the front door again over and over and over again. So, you know, those are two patterns that we're looking at is either like a new mid-tier type of routing layer or ideally probably, you know, client libraries that are tied into the Cloud Foundry essentially NAT's publishing so that they can do direct access. Okay? If you have any more questions, come up afterwards.