 Hi everyone, I'm Josh Davis from platform consulting group. I'm a platform architect My name is Frank Haruba. I'm VP of software development for Metsis International And we're gonna talk to you today and this presentation around the journey that we took in an eight-week project to move from really zero code no code on the mobile side and also on the microservices all the way through to deploying out to PCF and having a Working mobile app. So last year we were given a problem from the World Health Organization of The vaccine international vaccine record. Does anyone have a yellow book or have has anyone heard of a yellow book? I'm gonna go ahead and bring a show bring a couple of them out to people. Okay, so So what this does is this allows you to This allows you to travel from country to country What happens is is that you need to have certain vaccinations to go to different countries and to Have a valid record. You need to go to a doctor get a vaccination. They have to fill this book out and then you have You're able to travel to another country to Africa say Well, what's going on is you can easily get these books by just going to the World Health Organization website Downloading them or purchasing them You fill them out. Now you have a valid record because it's not digitally And there's tremendous amounts of fraud happening when they go when someone goes to a border In Africa per se, they may be actually refused entry not because they don't have a valid passport but because there's a presumption of fraud from the yellow book, maybe it doesn't look right or You know, someone says well this this yellow fever vaccine is an older yellow Vaccine it could be any sort of combination of factors because it's it's a piece of paper That's not really able to be validated So what our solution is is we created a new Booklet and in the back of the booklet we actually embed an NFC chip This is imprinted with the actual vaccine record. Also, it has the citizens Biometric artifacts on it. So then when a citizen goes to a border and tries to cross They scan the citizens biometrics iris fingerprint or facial using a mobile device Then we scan that this chip and this chip will do a one-to-one Biometric link that validates that the actual booklet belongs to the citizen So we had a few challenges in putting this together If you really think about how we're gonna go about, you know doing this you have to really We we started to You're really coming on from an approach standpoint. We were really thinking of well, how we're going to secure this how are we going to imprint this chip and Started out really thinking about the security implementation We decided that we really needed to have a heavy security presence that was as far as requirements This is probably about like 50% of our requirements 50 to 60 in that eight weeks So it was a pretty heavy, you know focus on security And one of the other problems that we had was finding a vendor for an NFC chip to work with us to have the proper file structure We really are trying to target the NFC chip in the back of a passport because eventually what we want to do is utilize An allocation of memory that's reserved for future loose to write our vaccination record into it that way We no longer need our booklet it could actually just be embedded into the back of the passport So we worked with the manufacturer and we have that File structure to allow us to future-proof our application the other You know if you think about how we're going to construct the application you're talking eight weeks, right? How are you gonna get started and get finished in eight weeks? you really have to have a very solid view of what your data is and We really tried our best to Really push the development in such a fashion so that it was using you know standard domain modeling techniques So, you know, we really we combine that in with micro services And the challenge really was was doing that in a short You're trying to do that in an extremely short period of time and the lessons learned You'll see through the presentation really is is that that's that's quite difficult to do in a short You know spurt of development now The other piece of that was was how do you allocate resources to actually do the work and we combine really you'll you know We think about the challenge of allocating, you know six individuals across a large set of micro services That was a big challenge for us and the other issue that we had was our initial setup of our pivotal cloud boundary We had to make sure that we configured it the correct way We weren't sure exactly what configuration or registration services that we would need for our micro services and also what you know other services as in rabid mq or of all For PCF secrets also like the my sequel service broker We had to make sure that those things were set up correctly for our size of the project What do we use the Kafka service broker? Do we use rabid mq? Do we use the configuration broke, you know configuration service within? You know within cloud within cloud foundry the key really is is that you got it You only have eight weeks you have a very short period of time and you want to make good decisions in order to make it to That MVP that minimally viable product So what we did was we drank the Kool-Aid We were very agile at the time But before we actually broke code. We already had some Plan in place. We already had a mobile design workflow. We had admin portal wire frame And we really stuck to an open collaboration with our team if it wasn't for Having that open collaboration and everyone having a say for a solution I don't think that we would have been able to make this eight-week period so Key is agile is as agile does you really have to maintain to to really execute On this plan that we had we knew that we needed to implement in an agile way We needed to have the team really work at one-week sprints. We needed to have you know All of the ceremonies that you would normally do we try to accomplish them as much as possible But the key piece of it was really to have the development team do test-driven development and extreme Programming as much as possible. We didn't have time to have this long QA process I mean if if we had you know think about if we have a giant, you know this long QA cycle Probably would have been for the amount of work that we did probably around three to four weeks We never would have made the development So what we did is really embedded the team the development team is being the QA team and then we also had quite a bit of Continuous integration with moving out to PCF as most as much as we could pivotal cloud foundry that is and One I guess the essential piece is we failed we failed multiple times during that that eight weeks We had stuff that broke But we didn't we weren't afraid of failure and we weren't afraid to actually make mistakes and try different things even in an eight-week You know quick development cycle. We failed fast often and better each time that was the key for to our success and really For the eight period the eight-week period. We really had to have really short sprints So one-week sprints were our goal We did have the first week I believe it was a two-week sprint and we realized that that was too long for the amount of time that we had so we Did one-week sprints and we were able to do that a very effectively and Cloud foundry really played a big part in this because it enabled us to move very quickly to an integration So I'm not sure if anyone is familiar with get push force anyone catch that by the way. Do we want to go back and see it again? We go. Oh, sorry. Hold up So it's not one of my favorite memes So, you know every project has source control. We use github But we didn't do branches The way that our team was designed and the user storage versus design We were able to have our developers work on a single repository at a time Allowing them to collaborate and every and every every repository represented a microservice So we were able to have these work, you know individual work streams all working at the same at the same time and extremely agile and Within this about the sixth week. We got concourse up and running to do our unit tests and We realized the biggest lesson that we learned is to be able to be really successful We had to push the cloud and push the cloud often because one person is working on one repository well if they pushed to the cloud it might not work with what's already there because Everyone's working on a separate positive especially if they change the interface on that always seems to happen But if we you know what we did is we had what was it three different spaces? Yes And we and what we did is we we separated them out and had releases out to the mobile application We had we had our dev dev plus one and release so the dev plus one for us It's really just a kind of like everyone needs to push to that as much as possible in their development cycle and test Everything out in that environment now the issue was really though is that that's that's all dependent If you have a PCF environment up, you know in an eight-week project and you're starting from scratch Do you always have PCF up or or CF up immediately isn't always the case so We had to use some Docker magic to actually get container magic to actually start from scratch and make it work Now I know this is you know when we talk about Docker It's it's not really in my opinion the preferred technology, but this is where we started and this is we actually were using Docker for our Concourse, so we used it as a starting point for doing our testing When you think about what we went to we keep talking about is that by the fourth week We had everything in place the fourth to fifth week for our our PCF environment So you immediately were able to start testing with that prior to that You really need to have something to test with you have to do integration testing you have to run your unit tests You have to have everyone running and one of the biggest Dependencies that we had was that we needed to have a security container up and running During while we were running our own tests So that also created a scenario We really needed to have something and in this case we use Docker now This is it's one of those things where it was just the most available tool for us to use But I think and you I think the new dev Pete the dev CF that's something we're moving to as soon as possible now that that's been really soon as they put Onto Linux another thing about Docker that people don't realize is if you're doing Android development on a Windows machine Docker and Android Studio emulator do not play well because of the hyper V So it's right that was a actually delay for us. Yes, we hit a we hit a problem with that So there's a big lesson learned is In fact have some just research beforehand because that can be a real problem You know but in essence we were able to overcome that and and what we did is we actually separated the teams We said into these individuals are only going to do basically mobile development and to finish up the mobile app And then the rest of the guys just you know, you don't you know, you're just going to work on the microservices So he created You know in a week project, that's not a big deal, but that's not a strategy. You want to use long term So in order to implement that I keep talking about security I keep talking about what we used we used UAA is anyone familiar with taking UAA out of a PCF and using it I've never actually your first person that I've ever seen actually raise their hands So it's actually unusual, but we found that we needed to have a quick implementation of OAuth 2 and It actually is it's open source it UAA is a nice piece of software What we and it it works immediately when you bring it down and it works perfectly in PCF So there isn't really like any sort of integration that you have to do it just works problem is that was what we thought So our lessons learned on that was you know, what how long did it take for us to get that going? Probably about four or five weeks. Yeah four or five weeks for us to really use it part, you know Yes, the struggle is real the struggle is real But one of the things that we learned I mean we'd love to share with you guys is that You must have a spring security person if you're doing, you know spring boot Which is what we're using have a spring security guy on hand because you're gonna need them If you're gonna do any sort of OAuth 2 implementation What what we learned was is that the it does work by the way it works really nicely It's just there's a lot of repeated code a lot, especially when you have multiple microservice repositories You're gonna have a lot of extra code a lot, you know, so what we did We in our present MVP is we've actually pulled all that code out and made annotations for it so that's something that I would recommend anyone do if you're gonna use even It doesn't I guess it doesn't really matter whether you're gonna use. Oh, well, you know If you're using UA or any other OAuth 2 implementation Yeah So some of our next steps that we're going to be taking for our next MVP One of the biggest things is that we're going to be upgrading our PCF version to 2.2 That's gonna allow us to use the new cred hub security to keep our secrets and also we want to start using The new Kubernetes functionality in that platform, you know, we we have quite a few You know, I don't know three or four I guess you to put a number on it services that we use outside of PCF we would like to Deploy all of that onto Kubernetes and in the future. So that's that's what we're really looking at We also are really looking at Implementing an event queue. Now. What am I mean by that? Oh is that we the system that we have right now is What I would call more of a collector of data it collects information. It's it's not an it's not the system of record So when we collect the data, what's going to happen is is that it's gonna push it's supposed to be pushing that data to a central Central data repository maybe a data lake perhaps that would then get analyzed and squished back down meaning that if you have someone who Perhaps uses the same name or which happens a lot in countries where there's no real identification of individuals That we're gonna try to do as much normalization as possible But we're not gonna try to do that on our operational database We're actually using a separate tool that's gonna use artificial intelligence to Refactor the data and then push it back up to us in order to implement that what we're gonna have is an event queue that runs every Single time we have a create update or delete on any of our data It will send out an event that will go on to a queue. We'll get processed And then we're also going to implement advanced biometrics What I mean by advanced biometrics is currently we only do a one-to-one match What we want to do is implement a one-to-n or one-to-many match. So that will allow a civilian to enter one of our clinics Have them get scanned in and if they don't have their document with them then they can be our database will find them From their biometrics artifacts because normally you'd have that the document if If they're not found in the in our database then we can create a new record and issue them a new booklet Or we can if they're found then we can print out a new book for them if they lost their books say For example, the net the other one of the other major pieces were looking at developing is an advanced what I call advanced workflow and this is the ability to add At runtime be able to let's say that you have an individual that's Using that's that's going to basically do a registration for someone They may go through and do all the processes or they may not they make there may be an individual who just Takes the person's name and scans their passport and then the second person actually does the iris scan But today that process is pretty much a linear process So you wouldn't have the ability to have different individuals They'd have to pass the the actual device or phone from one person to another what we would like to do is create a almost like a People workflow but have that work asynchronously with with the device that's all I'm going to be done using microservices and the you know and the event queue that we're putting in place and Then we also want to deploy to different cloud providers currently. We're only deploying to gcp But in the future we want to be able to not only deploy to different Cloud providers, but multiple at the same time that to be able to have our services running on You know three different crowd cloud providers Yeah, depending on cost and and whatever you know the actual government entity wants us to work I remember we could have an on-premise scenario We could have could be gcp. It could be Amazon or any combination of the of all of those So we're working to you know kind of work out, you know a common denominator between all of them. I do have a Demo on this phone It does not do the biometric scans because I don't have the biometric devices inside this device We have a specialized device for that Yes, but if you'd like to see what we have done Outside, I'm more than happy to show you Any questions any questions? Yes. Yes because most Android so we only have an Android app because iPhone won't allow you to and also it's a modified device that has a third-party FIPS certified Iris scanner and fingerprint reader because so we have access to that data Say that again Well, we want to be able to deploy You know applications that are really aren't a good fit for a PCF implementation so Maybe it's a pack. It's a piece of package software or It's something that wouldn't be easily put into you know, maybe it works with Port something and what comes to mind but isn't really a good example something like Kafka because there is a there is a tile for Kafka right now Let's say there wasn't we would really like to You know to have that deploy it onto onto Kubernetes and we're really looking at some Different databases we have a you know group working with us from a data perspective and That's gonna perhaps to use a different port than 80 or 443 and it seems like just a better fit to work on Kubernetes Does anybody have any other at week zero? We had The workflows already in place we had a little bit of planning prior to that at week zero What we really did was we did a Scoping of what functionalities we can do in eight weeks So we took those plans and we broke them out and made sure that we can make the time frame We use the inception process that pivotal has for pivotal labs And what that does is it really kind of prior? It's really a prioritization scheme where you come to to basically put on to you know What into different quadrants what makes sense to do what's most important to do right now? What isn't that hard what you know what is complex what you can fit? And you what you try to do is actually try to see what can you actually accomplish in an MVP of x number of sprints? That's something we're moving to to make that decision For right now. We we are not using anything specific Any any other questions? I'm not sure I understand what your question is as far as role We're not on a percent sure yet. We haven't really done that. You know we're What we do and I think it's a we look at these at these questions like that's one of the questions We're actually looking at right now. What what decision can we make now? We couldn't even really make that decision as far as having it integrated how well, you know having it be under one Environment we couldn't even really talk about that until now because it wasn't part of of pivotal Cloud Foundry So now that it is we really want to start looking at what would be the right approach And what can we fit it into our next big cycle any other questions? mostly well We had an issue with this is just something that came up over the past few weeks we've Are we have a small what's the version of PCF? We're using like a smaller? Yeah, PCF light. We're using PCF light which doesn't allow us to put in the Kafka tile so we are actually hosting that separately right now and in a in a Base in a virtual machine that's would like to move that to to you know underneath with Kubernetes And we're trying to figure out what the right solution is But those are the types of things where there isn't a tile it doesn't make sense to have it within Within we also are looking at perhaps doing things like You know my maybe a MySQL cluster that doesn't exactly look exactly like what you know what PCF creates Remember that the PCF When it has the tile it's really great It creates a nice cluster, but it may not have all the features that we would want doesn't particularly doesn't always have exactly What you need and so you sometimes you have to use you know, it's a good it's a good choice to use it that way another Item is that we have another group creating some applications around data, right that that isn't going to be in PCF So that's the other choice. That's the other Piece that we're really looking at that's why we're considering Kubernetes. Does that help? That's a really good question. It goes so that's in that get good thing, you know, right? I actually am a big fan of feature branching and when I talked to you know When I let me add let me let me have Frank answer that a little better. So I have a microphone so The reason why we used master and not feature branches because each developer was in charge Due to their stories, we made sure that the sprint that developer was only working on one repository So when they did a get push, there was no or get pool. There was no conflicts and then Once the push happened they deployed to the cloud and then they were able to see if their Branch was actually working. So if you think that's the whole fail fast fail often Yeah, in this case the way that we did our user stories is really to tailor it to that methodology for such a short Now this isn't something you can maintain over a long period of time In fact now we're looking at different ways that we can you know, maybe we do pull requests now because we're we're getting to a Point where we have people actually working in each other's repositories But you know, we're talking about an eight week. We're talking very specifically around an eight week project This worked for the first eight weeks. It's not going to be able to but sustain itself I do think though, you know, my personal kind of approach this is to create you need to craft your user stories in such a way that your team it follows into a pattern of work streams and That works very well The hard part is as getting the product manager getting everybody else on the same, you know It doesn't always work that way. They may say well that but in reality if you want to finish something in eight weeks With going from zero to mobile you almost have to go in a situation where you have Everyone stepping in in in the same Like almost like stepping in line. Everyone's stepping in the same direction at the same exact time in order to make it Does that answer your question? You obviously you have to have lots and lots and lots of test cases if you're doing test driven development You have a ton of you know test cases unit test cases are extremely important I mean, they are the foundation for everything that you're building So I would answer that the assumption is is that you have tons of unit test cases, but if you have an individual who's going to Who's going to develop right on top of someone else's code, which does happen a lot? It doesn't make for a for work streams that will actually work that will that will Actually can march together in an eight week project Does that you know does that sort of make sense? So you have to focus on as a as leaders You know, you have to focus on creating a scenario where your team could be successful and that's what you have to do So we're really that's what that's our lesson that we learned was that once you do that Once you have everyone working in in a correct way and it's agile and test-driven development a lot of all of the Kind of like the stuff that goes around the conflict that goes around Projects kind of falls away and people just get to work Not sure what you mean by that You mean the which interface is the user interface or the user interface or the To a certain extent. Yes, we did the the hard part really was is that in this project? we developed a lot of the microservice like models early and then that defined the How the mobile the mobile app was gonna work. So we did in a way. We did that, but that just seemed like the right thing to do So Do you want to show a demo? Oh, it's 1155. Okay, any you know if anyone wants to see the app We'll have it out there for anyone who wants to look at. Thank you