All right, we're gonna get started. It's 1205. My name is Richard Schellberg. I run OpenStack services at Mirantis And with me today on stage is Anna Dipanu here who's a project manager or program manager at Mirantis and Christian Humner who's a cloud architect. They'll help me today with the presentation before I launch in that be nice to know Who we have in the audience here. And so first of all, do we have any open stack developers here a Few. All right. How about users of OpenStack or want to use OpenStack? All right. Good How about vendors, product companies? All right. Okay. Good mix. It should be useful for everybody So we're here to talk about project cloud cloud projects and how they go down and when we look at projects and the customers that we Work with we try to put them into this pyramid and at the bottom of the pyramid We have companies that are primarily looking for services and this can be you know in the worst case easy to and Otherwise rack space or Mirantis OpenStack Express outsourced services primarily and as we move up Into the pyramid a little bit more. There are companies that are looking for product kind of black box Drop it in Integrate with some of my support systems and this or business and operation support systems and Further up we get to companies that are really into open source and they do like OpenStack and other open source products for that matter and they'll pick components put something together But they really like the community and they like staying close to the trunk, etc And then finally at the top you have the true custom developers these companies have large development organizations They'll pick and choose code pieces from here and there and really build their own solution if it's a we usually call if it's a Stack we call that a Franken stack usually in in the office, but anyway as you move up into the pyramid the complexity and customary involvement increases significantly Another way to look at it is you have the true ninjas at the top and you get the small medium business at the bottom Today we'll be talking about the upper part of this pyramid because this is where a lot of the interesting stuff happens and some of the complexities and challenges all right to Go through this we organized ourselves into three ease we start with engagement level already before the project gets started we have to do a few things on the engagement side and then Anna deep will cover execution and Christian will cover some of the engineering aspects of these highly complex projects All right, so the first thing we have to do on the engagement level is to level set with the leadership of the customer and There's an expectation from the leaders who are heavily Invested in the effort that we're about to embark on and they believe cloud can be transformative technology They'll have a more agile organization fast at time to market fast to turn around for the developers etc and This presents a number of challenges so for example The project within the organization will have interfaces to other parts of the organization These can be the worst case external companies that you have to work with But oftentimes they're just other departments within the company and that's a challenge because those other Organizations are not agile The experience in agile process is sometimes a challenge even though there's a willingness and a desire to do an agile project That is not a substitute for experience. So a lot of times the experience level needs to be brought up overall And of course you have to have buy-in from all stakeholders the primary stakeholders The ones who took the initiative. They're always they're bought in but there are other stakeholders Operations teams networks groups etc. Who are impacted by this and that we need to get buy-in from them as well So that takes us to the stakeholders so from the core stakeholders their expectation is that they'll be doing a Agile project and so we'll be operating iterations. There will be Incremental results that we can see and we can use this will of course drive efficiency and Overall they want to get a adopt a more modern approach Approach to project execution and there are challenges with this as well So again, the rest of organization operates in a waterfall model typically. That's a problem Because of that and because of the Increasing speed that you're gonna see over time when you go agile The the external Dependencies tend to lag and you run into problems on with timelines, etc There's often also confusion around planning. So in some cases we're running into a situation that well It's all agile now. We don't need to plan. It's all in the backlog, right? That's a big mistake. You do need to plan. So planning is really important. You need to plan often and Before you embark on the project now in the on the other side planning is done elsewhere So there's a planning team that is doing a lot of the planning and actually it doesn't translate into the project and the agile model That we're doing so anyway, so we'll get into how we can solve this on an organizational level The expectation is that we're gonna create self-sufficiency throughout the organization push button IT I want the server. I can push a button, right? There's gonna be a lot of automation now when we're done with this. That's awesome and You know, we really want agile to be pervasive throughout the whole company when we're done these are the expectations organizationally and Of course, this has a number of challenges. There are some existential questions. They rise some organization or some departments wonder if they have a role to play after we're all done So that's create some resistance at times and they can be related to Operations where they've traditionally been very hardware focused and they now have to be focused on user experience So that's a change Networking the network topologies for cloud may not be aligned with various security security policies or traditional networking, etc hardware as well, they may have had a Process of acquiring a certain type of hardware and we're now suggesting that you should go with some You know commodity hardware of some other kind etc. So All right, so step one is to manage the expectations. We have to organize to manage expectations throughout With the core stakeholders and elsewhere in the organization. So we have to get the executive level buying from day one This is a transformative evolution of your organization and it has to really be Visible all the way up to the top You have to identify a project owner from your customer side. This is the Agent of change if you like this person should be empowered and be able to really push others to to get things done Decide or agree on a minimum viable prod product This is your first major milestone. This is something that is it has a tangible Useful application for your users. It should have the minimum set of requirements and features to be Able to handle core workloads and create value quickly This is really important and then remind everybody involved of what that minimum viable product is every day or every week Plan for gradual organizational changes, you don't need to change your whole company on day one You can sort of draw different parts of organization in incrementally as you need to rate through the project and milestones for that matter Identify external stakeholders all the time they're gonna be in other stakeholders later in the project as opposed to in the beginning Pull them in get commitment And identify communicate risks always assess risks not just in the beginning but throughout the the project That helps manage expectations Step two. This is a fairly typical governance model. You layer it like this. You have project execution Let's see if this works at the bottom And you put project governance one step up This allows you to separate the execution part from other issues that encounter that you encounter throughout the project You may have Escalations you may have scope creep or you will have scope creep You will have a number of different issues that you should try to get out of the project execution path right away And you deal with it at a governance level and that's where the stakeholders meet etc And of course at the top this is where the executive sponsorship and of course from us the vendor side Our account management leadership sits as well pretty standard governance model step three Establish an agile model. So everybody's heard of scrum perhaps It's a great agile methodology, but it's has some assumptions It assumes that everybody's involved in the project is a universal soldier essentially so given that the customer will have Most of time in these kinds of project the customer will have their team members participate as well You're gonna have people that are not universal soldiers They may be good in certain things and not so good in others and you need to plan for that. So pure scrum might not be suitable You got a easing to agile so you do that by accepting that everybody has strengths and weaknesses Set the sprints the iterations at three weeks not two weeks or one week It gives you a little bit more time to do demos, etc Plan carefully like I said before plan often replan prune your backlog Etc. You got to do that. You got to communicate these things Within the team and with the customer all the time You should not share people a lot of times you do you execute these projects as a number sub for Projects that are all executing in parallel can be anywhere from three to 15 parallel tracks depending on the size of the project Don't share people between these different sub projects. You can move people but don't share them between you're gonna lack commit you're gonna lack commitment to What you sign up for when you do that Also identify an overall architect can come from the customer it can be from us And a program manager on that one person who is in charge overall for architecture and a person who's in charge for the program Okay in terms of organizing Try to look at how you organize a project in three different layers There's a business layer a technical layer and operational layer and this allows you to do Essentially two things a lot of times people are just focused on the technology But by focusing on the business layer and the workloads that you're gonna run in your cloud You can actually get the users engaged early and of course they don't have a cloud to run on however there are you know Solutions for that as well You can go to rack space you can go to Miranda's open stack express you can get the users familiar with how Open stack works. In fact On Miranda's express we You can actually have a whole cloud and you can actually manage the cloud from hardware and up It gives you a lot of really good experience on on open stack Early on in the project operations is all equally important. This is usually the biggest issue We have once the cloud is ready to start Going into production the operations team if they're not pulled in early, they're gonna be Having all kinds of issues in taking ownership of the cloud. So they should be there day one They should be part of all the planning and they should be Part of the development of the logging monitoring operations tool tools that they they'll be using once the cloud is up and running All right Fine, I think this is finally set up the interface model So you're all up or operating in in a agile model, but the rest of organization is not However, you can talk waterfall when you have to deal with other people So just look at where you are in your sprints or in your iteration and see what the focus is For example, it can be on the deployment side For a while. Well, then you are in the deployment layer in the waterfall. You can be doing testing while you're doing testing So when you talk to others you talk about it in a waterfall way knowing that you're in a particular iteration or whatever Very easy to actually translate between the two So we'll talk about execution now and I so liken that to being handed the baby And you have to ship them or her off to college, right? So in some sense, you're left holding the baby The first thing that I would say is well, you are now one team The organizations that you go into whether you're the vendor or you're on the on the side of the Customer who's who's hired the vendor it all becomes one team So when you do that the first thing you do is clarify and verify the team roles that Rickard was talking about that were would then identified so now they may have changed or The organization chart that you had was formal, but there's always an informal Organization chart who's the go-to guy for program management? Who's the go-to guy for testing? Who's the go-to guy for architecture? They're not sometimes. It's not the chief architect. It's someone else You have to get you have to know those Definitely really find out the next thing You'll find is when you have these big organization the ninjas. They are geographically dispersed. It's almost a given I have had and then you have the vendor and they'll be geographically dispersed so What you got to do is you know Make some Arrangements for that just keep that in your mind They also each of these teams that you have they will have some interest that is that is that needs the cloud but is not Exactly aligned with just deploying cloud. So again make make some arrangement for that Keep that in the back of your mind and they will have a different timeline than the cloud deployment So they want something deployed by X and you your you want something to apply by Y and then there will be tension between that and you've got to negotiate that So make sure you know that now Excuse me the the biggest problem you'll You'll face Is you know, you know the technology you know what to do but coordination And it's coordination of not just it's not just people certainly people but Also your your systems You know your user stories your Documentation your processes so make sure that you are you start with that The other thing is in modern management, you know everything is matrixed The deployment team is where the rubber meets the road. There is one deployment team however stakeholders are there's hundreds literally and You have and guess what you have some responsibility to the stakeholder You just don't report your management chain But you also have responsibility and that's the matrix and it's not it's not like the movie. It's not fun so so then One thing you will notice is Excel spreadsheets are are not Good coordination documentation mechanisms right there and got to have online tools The only thing worse than Excel spreadsheets is emails You shouldn't have to rely on only our email system for coordination Again, sorry So look at look at all the stuff that you have that you know ticketing user stories source code control unit test integration test smoke test documentation all of these there are tools and guess what Your customer and the enterprise or and the and the vendor they will Invariably use different tools. So when you start the project, you know, there's a lot of pushback That someone's tool must be used at least use one right start with one and apologize later and it and as the project goes on your your tools will align But you've got to make sure that you are using a ticketing system from day one. Otherwise, there's got to be a lot of pain All right, so let's look at some of the challenges and I'm some suggested solutions that we have The I wanted to use my my French since we're in Paris. We have Boku stakeholders. We talked about that There's just make one source of truth, right? This is the ticketing system and it's not enough just to make hey We are using JIRA, right or we're using bugzilla whatever, but you have to make sure that Nothing gets looked at unless it's already in ticketing and that every single developer They even touch that problem. It's it's reflected in the ticket and that's that is hard to do because developers want to develop right and And then there's a crisis and people want to Want to know what's going on and they call you so your answer should be look at the ticketing system Believe me, that'll save a lot of a lot of problem and people will appreciate what you've done later on the critical dependencies that you have and this was in Rickards diagram With the other teams You've got to make sure you have a connection with those teams You know what their plans are and that you have a sponsor lined up on your side either the champion of the project or Someone that you have a relationship within that Otherwise you're not going to get deployed If the network engineering team doesn't give you the switches in time the load balancing team doesn't give you the load balancer Stuff in time you can't deploy so it is critical the Don't do too much too soon minimal what Be don't be ambitious about the MVP Demo demonstrate stuff first make small things work take out the risk and Do this in phases and then you have you have an opportunity to replan every time And you can you can then see what your velocity is You you have a transformer to change you want to do everything all at once don't do it That's not good. Oh that is going to cause a lot of Expectation mismatch, I don't know if it's unique to the cloud But it seems to be magnified by it because there's so many people who are interested in this transformative change They are they they are expecting you to build different cloud. They think that they'll get Stuff that you haven't promised or vice versa. You promise something that they don't want so every time Every day My program and a job is that I am talking to some stakeholder Clarifying what we're going to be delivering and and making course changes if there are differences This probably is unique to the cloud You know we use whatever it's Tempest or you know other tests that are there in the community, but they tune for different things right? What you got to tune the cloud for in the multiple ways you can tune the cloud everybody, you know It's if someone like is storage heavy or network heavy There's the you tune it differently so use the real test cases that belong to the users of the cloud Not from the team right there so because eventually the users of the ones who are going to say oh This is good or this is bad Understanding is a problem everybody has a different definition for cloud everybody And not everybody's heard of open stack that might come as a surprise to you, but not everybody knows what? Solometer is right, so you've got to get that and then also about agile all of these things you should make sure that there is Some common understanding and you fill the gaps with training or mentoring opaque planning and this has got to do with The cloud is seen as a transformative IT, you know our business technology or movement and The the the entire enterprises involved not just a small department in in doing that kind of Transformation so they there are people who have who are making plans for that transformation and they may not be talking to your team If they're not go talk to them Find out what they're going to do And and absolutely be involved in the plan, you know be in that circle of planning that they're Then the last one is you know lots of jobs chasing open-stack engineers right so Do not rely on that one person who knows neutron or Or knows you know how to tune your your cloud Always make sure you you have multiple people and expect your right and plan for it so Those are some of the suggestions no question. Oh do you? Okay, so Management has decided you want they want cloud the manager comes oh Yeah, good the manager comes to your office and says well we are going to get into the cloud space and first of all, of course there's many ways to skin a cloud skin a cat and So you're sort of left in the cold usually only get the very small chunk of information that you are Going to have to work with and then finally you Get told by the by the same manager. Oh, and by the way, we've hired this company to install the cloud for you So this is what we oftentimes get seen as guy who comes in folks people with a sharp instrument and makes it Takes it over takes your job over Makes you look bad to management because you Are not doing in the eyes of management are not doing the job and that's not at all how it is in reality we have The challenges of course you can do it by yourselves open stack is open You can download it you can install it you can configure it If you have to ever try to do that manually you'll find out it's not it's not fun And it usually does not lead to what you wanted to lead to so To ease the pain of doing that you can use deployment tools They will take away some of the problems that they will experience But even more so if you don't have somebody who has already made those mistakes and has seen other companies Make those mistakes. You're going to run into those problems anyway even the deployment tool is not going to help you with that second thing is we come in and First of all we sit down. We have a stack of paperwork and we are talking to you about this and that and the infrastructure and your team and Skill sets and anything that you can imagine of architectural assessment and Of course Yes, it's boring. Yes, sometimes these meetings seem like they are leading nowhere, but we have the best Practices that have we have developed in a long time of actually doing this in the field we with people with other companies that are Seeing the same problems that you have and then It's a better. We understand your Infrastructure. Yeah, but the better we understand the business problems that you face the Users that you are working with the better. We can help you Build a cloud that matches the expectations of management of the users and of yourself, of course and then finally you Yes, I used to do to think the same way when I was working at the company of Somebody from a vendor came in. Yes, I can do that by myself But we rely on you being able to do your job I mean you wouldn't be in this room if you weren't good at what you are doing people management doesn't send you here to if you are not actually among the top people in your company to do that and What we really are doing or what we really expect and hope for every time we go into the company and every time we Look into the set of faces that sitting in that bottom is that we will have a team People who are all skilled at their jobs and doing what they did what they do best a Few things that we encounter every time or in many times that we are doing cloud project first of all preparation you Your management signed a statement of work with us. There's something Relatively opaque and that says okay, we all build a cloud for this purpose and this is what we what roughly is going to happen But the real decision of what needs to be done is done together with you and this is in the preparation phase oftentimes You know between the statement of work and the actual execution. There's a few weeks and you'll think okay I should be filling in this piece of paper that they sent me or I should be Working on this but in reality People somebody the music comes in I want this somebody comes in I want that and in the end The day sneaks up on you Wow, they're here coming in so Taking a little bit of time and taking the effort to do prep work specifically prep work in terms of How do we work? How are we going to work with these people? How are we going to give them access to our environment? Are they going to be online or are they going to be on site here working with us? communication with us if you have questions say so right away the better the earlier the better and then finally procrastination Everyone has done it if somebody says I've never procrastinated in my life. I'm pretty sure that they're lying but in this case it makes sense to Keep that at least a minimum Except change. Yes cloud is entirely different from a prey from a classic data center infrastructure for instance you have Service you have Traditional storage you have traditional networking and a lot of this is now instead of locking into a router making the iOS changes and saving them You have some software that does something similar but different and you have to adapt to that But on the plus side You are going to be the elite in this field This is going to be bigger and bigger over the years and you are the people who are on the front line of this and You are making yourself more valuable and you're making your company and us more valuable if you are Adapting to what we are doing well and Finally, this is a team sport We Everyone sees, you know, this is my group. This is the other group there's little fires little Tossels, but in reality the better everyone works together the better people communicate with better people are See each other as Cool workers as teammates playing towards the same goal the easiest is for every one of us now Patterns to adapt this is things these are things that we find useful when we are doing a cloud deployment First of all best practices Everyone talks about them. It's one of the buzzwords. Well, I have those best practices and I'm using them but We have a few things that we tell people to do and did they all come from long experience of not doing them and Failing and Or experience experiencing failures and difficulties because we have not been doing them Usually it's cheaper to learn from the mistakes of others Then to make the mistakes yourself become the genie pick and making it You know, you don't want to Chew on the truth and leave of lettuce Let the other guy chew on the leaf of lettuce and I know and find out whether it's really tasty Recycled within reason. This is another thing that I've personally come across a few times lately specifically companies that have that set aside something specific for a specific project and I have to tell them This is unfortunately not going to Provide you with the performance or reliability that you need for this specific project If I say so I'm not doing that because I want to sell you something We don't sell hardware. We don't sell any kind of Infrastructure if I also don't have personal reasons I don't like new and shiny any better than I like something that's classic and proven but if I Come to the conclusion to calculation and through experience that this is not Going to work or that we will have to augment this with some new purchase then I'm saying that because I want to Advance the project and improve the experience that you have from that and finally this is on a trap that I have fallen into myself quite a few times favor stability don't Think that you need the newest version of OpenStack to become to be happy if I deploy Juno OpenStack right now in a production environment. They're probably not going to be very happy about it and neither are you So having tried and true is good Every once in a while you come across a problem where you really need a specific version and In some cases it really makes sense to go to that newest version and experience the pain because there is a way There's no way around the version that For a specific item that you that you need for for something But normally I would recommend do not upgrade every six months and do not get the newest version of the get go I would for instance deploy ice house right now and then in a year upgrade to Whatever is the Experience of the stable version at that point and one thing that you certainly want to avoid. I at least want to avoid it Is this? expensive down times and sleepless nights And I've had enough of both to know that I don't want them If you keep to all that you are going to have happy cloud users, and this is exactly what we are here about Finally, this is the bad part Certain things need to be avoided and one of them the most important of them actually is shooting from the hip Yeah, I'm going to make that change here. I know how to do it. I can make it reliably Although something might go wrong But what does the poor guy do who gets gets woken up? six weeks down the road at night To troubleshoot the problem that my change inadvertently caused he doesn't know anything He doesn't have documentation. He's going to sit there for six hours and swear at me Maybe he doesn't know that it's me, but I don't want to live by that. I don't want to Be the one who just was lucky enough not to be discovered to make a make a bad change. So Even if you're not employing employing CICD I would recommend to at least find a certain modicum of control over your change process. Otherwise, you are going to be in for the sad sleeveless nights and unhappy users Second thing is losing direction Anand and Rickard were both talking about the minimum viable product and the minimum viable product is very important because in this case We are working towards a common goal And if not everyone is aware of what that common goal is and we have this defined minimum viable product Then people are going to diverge and then you are going to get the zigzag Towers the goal that takes Extra hours extra effort extra money and unhappy management And finally and this is another thing that I've seen all too many times and not only in small Small companies or not not even predominantly in small companies because small companies have this way They have a guru hackle oftentimes who knows how to get how to get keep that running more or less I've seen that in great in big companies. I mean 1,400 companies Experimenting in production they have a test environment They have a dev environment and they still make a change in production just to see whether it will work and then figure out Oops, I didn't what do you don't and and this yeah most nothing is more expensive than unhappy cloud users you lose customers you you lose revenue and People are going to be unhappy and this is you lose reputation and this is the important point So and this is what we are all about together. We will build awesome clouds. You can't do it alone I can't do it alone, but all of us can Thank you very much. I think we have time for questions You talked quite a bit about minimum viable product as you as you talk to ranges of companies Is there a prototypical minimum viable product? That lots of people could deploy Yes Yeah, so That's a really good question I think it in general You always want to start with Infrastructure as a service and you may add a few items to that for example some other network functions such as low balancer firewall Some companies will what look at the business layer and they want to be able to enable certain workloads at the push of a button so you will That gives you kind of a template of the first minimum viable product But there's usually minimum viable or an MVP for each major milestone So it evolves, but you start with your basic service. I should be able to Get a server. I should be able to create a little virtual private network. I should be able to deploy a low balancer That's kind of where it starts usually Other questions Hello, I'm very interested in the MVP approach and I was looking for information about tools tools that are are Useful in order to try to make the MVP approach I don't really find them like free mind mind mapping first all of the tools on the MVP approach so the the tools that we have in place like User story tools like rally is one you can You can you can you can look at an MVP from the user's perspective and say these 15 user stories have to be enabled So there it doesn't have to be you know, what you're doing with the MVP is defining scope not so much You're that you know, there's At the end of the day, that's the what you're delivering But the tools for delivery do exist and I believe we've been successfully Reusing like ticketing we use JIRA for example Rally and and for deployment we use The ticketing system and for user stories so to rephrase that for infrastructure, we use the ticketing system and for for the business User use cases we use the user stories and those are work successfully. That's not to say that there aren't other tools Elsewhere on internet you have a website for some somewhere where MVP can be a very explained or detailed We should have your experience and all the experience about MVP. I saw someone which is Eric Ries or something like that in 211 in the had some experiments on that and he says MVP sometimes can't work Yeah, there's some it was for a website. I saw the six so we need to improve. I think MVP or Find what is the experience about MVP? I Do think that's that's correct. Yes, and we are in the early stages, right? Thank you Thank you, it's maybe more remark than the question this is about how to build the cloud But I think then the challenge will start to to maintain it For example, you didn't explain about to give a predictable roadmap for for our company to use the cloud When to go to next generation of the product? Yeah, so you can tell a little bit about that. So Definitely, Rickard did touch upon it on the operations if you can see if we can Get back to that. Yeah, we we told we said that it was very important But we didn't get into we didn't do about it necessarily But it is a day one problem that has to be be addressed and you need to have Team members from the operational side involved Especially, you know in in these more complex projects where a lot of time operations is provided by the customer themselves So you got to have people involved with this already you got to look at logging monitoring and metering primarily those are three things and Yeah, it's yeah, it's a it's a cultural change a lot as well a lot of it is but and then tools Automation etc becomes part and one more thing that a trend that will soon start to emerge is managed services where The other vendors will now be asked to run the cloud On behalf of the customer and then there's a whole set of tooling that you have to do you have to set up processes We do have that it was not in scope in this talk, but thank you for the suggestion We'll we'll definitely maybe next next summit will address that Excuse me in one of the sliders Here In one of the slides we have seen a term CI CD. Yes, what does that stand for that is continuous integration continuous development? So the The idea behind CI CD is that instead of making changes manually and implementing changes manually is That you have a defined process to do that and to use tools to do that specifically tools like Garrett for code review and Jenkins drink Thank you. It's been a long day So and Jenkins Jenkins for the actual implementation these tools have the advantage that if you use those In a controlled fashion, then you will have a lot less risk of somebody who is manually doing something making a mistake and also have a Backlog to see well who did what at what time so you can Determine this is where the problem was introduced and this is how we are going to resolve that next time And this is part of agile as well You have to have an agile model to really get the full benefit of a continue CI CD so what's your recommendations around sort of Versions versus stability you made the point that you know customers more said ice house now It's a stable product, but we've heard this in the summit about boiling upgrades being a key one for some enterprises What are your thoughts around so I I'll let Christian address some of those as a program manager The decisions you have to make are the following right one is features Which features does the customer need and where have aware are the fullest and Versus stability right so you you've got to make that decision Based on what the customer needs the second one is is about Then you might have to make a decision about well Is there a way to we can backport these features where we take advantage of whatever stability we have for this current version? That the customers using Versus, you know going to a completely new one the third one is upgrades upgrades are Definitely a big priority for for our customers a lot of the customers know that open stack is evolving and have Some plan based on that if they don't you have to let the customer know that That in place upgrades that they're used to in regular data centers don't happen yet with open stack So I don't know if that completely answers your questions, but those are some of the concerns that we address right, so there's No real rule of thumb of how to do that what I would suggest is first of all Looking at an existing version Let's say we're looking at ice house and see whether the features that matches what you need out of it Backporting features has its advantages in some cases the problem is that is that you are getting something that is support-wise more difficult to manage than Straight release if you have a straight release and you talk to our technical support they can tell you okay This is a known bug. This is not an own bug. We need to file a bug about this This is something that we have we can fix this is a configuration problem If you have something where you backport for instance a newer version of keystone or something like that Then it's a lot more difficult because then they have to go back our people have to go back and look at the Infrastructure and see whether they can replicate the problem somehow So a backporting I would only do if there is a good reason to have if you have a Features that the largely matches your expectations, and you only have this one piece that has to be different so about versions I would Definitely not use the version that is leading up to an open stack summit that like everything has been Juno right now I would at least not at the beginning of the cycle because there are still so many bugs being found and you are not the What you should not be the one who wants to find all those bugs? I mean if you really are into into a bug chasing certainly is good idea But in general I would for instance use the summit but the kilo summit everything Leading up to it has been Juno now That is probably the time that Juno is gaining the stability way where you might want to implement it and In the end the other thing that I suggest is talking to other open stack users Visiting forums reading blog articles because you can clean a lot of the stability problems for stability Status that you are talking about in a specific release by seeing what other people experience that are using the same release Do we have time for one more question? Any other questions? Okay, one more So did you did you ever have to say no to a customer be it because the customer might be too small or because Every day the case doesn't suit like could you elaborate on every day? Okay, I can give you a concrete example. I'm not going to name the customer, but I A short while ago I wrote an architectural review that concluded with we should not engage in this specific case The reasoning behind it was we had the customer had specific performance and reliability Golds and and parameters that they had to be working within and They did not have or did they simply did not want to commit the necessary resources to reach those The resource that was so short that I have from from my experience I had to say sorry this is not going to work and we do not want to be Or we cannot be part of this because this is going to lead to something that is not going to be sustainable No, it's it was it was money for infrastructure In this case, I think they I know which case you talked about but there are sometimes Misalignments between what they ambition to do with hardware with there are vendors who want to put the hardware solution together And they may want to run particular Kind of Opstack configuration or Components of open stack on it and when we come in and we look at that architecturally we find out that the performance Objectives of that solution will not be met. So if the customer is not willing to change To the recommendation we have it's not much we can do, you know, so Yeah, so so and when you're within a project from the project execution framework There is always pressure for adding another a new feature or or Enabling another user And if you have done a plan before and you know that that's risky And it can't be met then you can't commit to it, right? And you have to say no at that point that doesn't mean that you don't use our ingenuity to try and find a solution But it it definitely means that if you want to deploy something that is Meets the MVP then you can't have additional features At the last moment, but this is also I'm sorry. Also, this is not a flat no in the sense of Okay, I don't the customer doesn't want to do what I want to do This is a no that says okay This is what I see as the minimum that you will have to have to get your stability and performance goals and So can we can we make it a deal there? Can we fix that? This is what Richard was going to say now I was just gonna say that by trying to always focus on the business objectives first Usually there are other solutions a lot of times even the customer tends to focus on the technology too much There are many ways to skin and cat as Chris Christian said All right, I think we're out of time. Yeah. All right. Thank you very much good questions


Good morning, Frank. Want to say good morning to the good people? Good people? It's like a good morning. Just pet me, that's all I want.  So I'm the bacon eater, like I was telling you in yesterday's video. But I'm waiting to start at the perfect time so that they're the perfect temperature. Just done perfectly by the time we're done this perfect breakfast. Let's hope that you and the word perfect today. You're those perfect peppers. Right? Peter Pepper picked a pick of pickled peppers. Nice. I'm a poet. I made that up myself. I can't do that in the morning. Oh no, I'm gonna get sued for copyright, aren't I? Yeah, probably. Oh well. YouTube. That's fine. So we got the hash browns. We got the best part, the main course right here. That's the breakfast. What else do we have around the peppers? Is there a toast or something else I should get ready? You can have toast if you want. I'm not gonna have any. I can have toast if I want to have wife's permission. Do we have bread? No. We're gonna have to make the bread first. You're gonna have to make the bread first? Here we go. You can probably start the bacon up. You sure? Yeah, well, cause I like mine nice and crispy so you're gonna have to put mine in first. Is it bacon time? It's bacon time. It's bacon time. It's bacon time. Bacon. Bacon and hash browns and bacon. Do you smell it? Am I making you hungry yet? Oh yes. Cheesy toast. The main course. And eggs. Coffee. And this is the way she likes her bacon. What is that? I like it to be rid of the bread part. That's the way she likes it, seriously. That's okay. A lot of people like it that way. I just like it to be nice and chewy. Still have some oink in it, right? So we're gonna finish the movie that we were watching yesterday. What movie is it again? City of Bones. It's actually a really good movie. It's just kind of long. So we were watching it in bed yesterday and we fell asleep. So I decided to turn it off. So we finished it today. We finished two and a half whole movies yesterday, guys. That's a record for second half. You're hardcore. It's not a record for me. I like my movies. Excuse me, sir. Did you even see him there? Yeah. He's taking up your whole couch. It's okay. I can squeeze into that little spot. I can kick you out. There you go. Here's your food. Oh, thank you. You're very welcome. We're probably going to need some, some sporks. I had a spork somewhere. Right there. One for me. There you go. You're so kind. You don't want it? Fine, it's mine. So I fixed our garage furnace. There it is. You hear that? The fan just kicked on. The electric motor that spins the blower fan in there. Quit working. It died out. There's a couple old ones there as well that have obviously died out in the past years. I gotta throw those out yet. Those aren't from us. It's from previous owners. But it died out. I bought a new electric motor on Amazon. It was $70 off American Amazon. On Canadian Amazon, it was over 300. Nuts. What's with the exchange rate? It's still nuts. But I'm blowing nice warm air in here again.  So tonight we're going to a painting night. I'm gonna test out my talents. It's a paint night. It's a fundraiser for my cousin Felicia, who's suffering right now from I think seven different strains of Lyme disease. So the whole family has come together and has set up this fundraiser to help her. Because in Canada, treatment for Lyme disease is not covered under healthcare. And in order to get treatment, it's very, very expensive. I know all of you Americans can relate. You can relate even more than most of us can because all of your healthcare is very expensive. From what I've heard, I mean I've never had to get healthcare there. And when I do travel down to the US, I still have health insurance through my work. So wherever I go, I'm still covered. But it's very difficult to watch someone who's suffering with Lyme disease. I don't know if you guys know anyone who is as well. I don't know too much about it right now but I'm gonna learn a little bit more about it tonight and go and try my hand at painting for a fundraiser.  Britt's gonna be there too. We need to take both vehicles though because after paint night, I'm going to the gym and she's gotta go and do her own thing yet. And then we'll come home later on after that. But she's already on the way. We've got a meter there. We're gonna drop off my pickup at the France Motor Inn where fundraisers are gonna take place.  So yeah, grocery shopping. I'm totally not procrastinating. And that's totally not my wife asking me, are you coming? Where are you? Totally not procrastinating. I love grocery shopping. Doesn't everybody? Excuse your elbow. Gotta get out my trusty superstore looney for the carts. So exciting. Grocery shopping. I'm bursting with excitement. Is it sad that I like grocery shopping? Well, at least you have a looney for their carts because superstore is one of those stores that you have to actually put a looney in to get the cart. But that makes everybody bring their carts back so that they're not dinging all the vehicles, as Britt says. Yeah, it's a big positive, I feel. I feel that everybody should do that. I just never carry change with me, so, but. No, he just puts them into peanut butter jars and forgets about them. Yeah, one day I'm gonna have like thousands of dollars saved up. And change.  So we apologize to the bank teller in the future that has to deal with us. Well, let's do it, babe. We're at the real Canadian superstore. Let's do this. This is sort of like Canadian Walmart. We've got about a half hour before we got to get our butts in gear to paint night. Let's do it. I'll meet you guys at paint night. Here we go. We're a little late, but hey, it wouldn't be us if we were on time. Oh, I was driving, so it wouldn't be me. They're expecting us late, I'm sure. So that's supposed to be a moon. We've got a very nice moon. So this is what I've got so far.  We can go up there and show them what it's gonna look like if they have the sample out. Sure, yeah. Yeah, they do. It's over there still. The sample. This is Brits here. She and hers opposite for mine, so they can maybe like hang nearby each other, hang together. So reaching towards each other or reaching away from each other. This is so good. Having fun? Yeah. Let's see yours. Very nice. You see all the ears, but I still love it. There's roses over there. It's gonna get up and go and look at this. This is my sister. It's my sister Cheryl. The baby sister. This is my sister Rose. She's the one who had that accident recently. You're doing great. Yeah? Yep. You're gonna get a good recovery. She got another Corolla just like that one, except there's a blue one this time, right? Yeah, can't be alive. And my mom down there. Sorry, Cheryl. That's okay. She's getting right in your face here. It's for the vlog. Very nice. I don't know what that is. This is my finished product. It's kind of a scruffy trucker out. I'm like so open like you're there. This is... Brits. That looks great. That looks great. Yeah. Mine too. Oh, it's so cold. How cold is it out here? It's only minus 15. It sure feels like it's a lot colder than that. So we just finished. It was a lot of fun. So like I was saying before, this was a fundraiser for my cousin Felicia. I'll leave all the information about it down below in the description of this video. I can't imagine how difficult it must be struggling with a disease like that. And I don't know a lot about it. So I can't really speak out on it and let you guys know everything that's involved with it. But I'll leave the links to it down below in the description of this video. If you guys feel like it, you guys can go check it out. And if you know anybody else who's struggling with Lyme disease, it's no joke. It's some serious stuff. So I'm gonna head to the gym real quick here now that our paint session's done. I don't know if Brit's gonna hang up those pictures. She went home already. I'm gonna quickly go for a quick run and then see where we'll hang those paintings up. It actually turned out pretty well, I think.  This nice little pretty tree she was in. So we're gonna hang it up side by side so I'm her husband and wife. I don't know. All right, I'll talk to you guys when I get home though. Slowly but surely our walls are filling up. This is the first one that Brit did. She painted that herself. And the second one was actually this rooster over here, right? Yep. This is the second one. Brit painted that one next. And then third, she did this gorgeous sunset one that she did just yesterday, right? Yeah, just last night. Wow, it seems like so long and gory. She did this one yesterday. And then tonight, we both did these ones. So there's Brit's on the left and mine. They're sort of looking at each other. Baby owls. Scruffy old guy over here. Hi, hi. I think it looks really good. And Brit got all the colors to match her theme in the house too. All these teal colors. She's really good with colors like that. I'm not. Notice how all those like little things all match? Even to this picture frame over here. Everything, that was all planned out. She thought of all that. Works out great. We're under the blanket here. What's going on over here? There's someone under there. It's moving. Chevy, you're gonna step on him. Will you come down here? No, no. Frank, what are you doing under there? Chevy, don't step on him. You don't even know he's there. You don't even look down. Brit's working into the night here. He's transferring files over, so I don't forget later. Makes it easier for when I'm in the mood to actually edit my vlog. Look away, you can't see the password. Oh yeah. Look away. So anyways, she made a vlog on her channel as well. If you're interested in seeing that, the link to her channel is always in the description of every one of my videos. You can just go down below, click the little arrow down, and you'll see all the links to all my social media and all her social media. Hi. Vlogging here, guys. Come down, rowdies. So thanks for watching today. Tomorrow, I believe we'll be back on the road. I haven't told you yet, have I? I did get in touch with the shop yesterday, or today. That was today, right? Yep. I got in touch with them today, and they figured out the oil leak. That should be fixed. They fixed my bunk heater, so I don't have to idle it so much anymore. I can turn the truck off a lot more often, keep the cab warm. That'll save me a lot of money and fuel. I'll probably pay for this whole repair job in just a few months. And also, what else were they doing? Wind shield. And the windshield. They replaced that windshield for me, so I should be able to pick it up tomorrow. And I have a load waiting for me of lumber that's taking me down to Clara City, Minnesota. Then we're going over to Owatona, picking up a load of glass. We're gonna come home for a day, and then we're gonna continue west out to Surrey, British Columbia, and deliver those next week sometime. I think I gotta be there for Wednesday. Thanks for tagging along with us today on this home time. It's been a lot of fun. I'll see you guys tomorrow.


Alright, so the talks about, called Big Spice and Box, I was doing binary programming in JavaScript. And my intention behind the talk is essentially to promote this idea that we don't deal with binary. So, you know, pretty much all of computer science is essentially abstraction, right? We look at a ball and we say, you know what, it isn't really a ball, it's a wheel. And we just start calling it wheel for the entire step, right? So, everybody else on top thinks it's a wheel, but really it's a ball, right? So, this is kind of fundamental behind software in general and a lot of technology. It is the same fundamental about, behind binary, it's called one signal, one and we call the other signal zero. And then after that, we call this abstraction, we stick with this abstraction and all the software layers on top, just think that they're getting a one and a zero, right? I recently saw an example of a TED talk where somebody was transferring. It's kind of the same principle that you have, you know, the light spectrum and you have two frequencies of light. You send one frequency and the other guy thinks this is zero. You send another frequency and the other guy thinks it's one, right? So, that's kind of the fundamental. But once we have this abstraction in place, what we do is we build other abstraction layers on top. So, the moment we have one and zero in place, we build these software things for data types. And in all our programming languages, we just deal with data types. But what if for a minute, in just a minute, we move below our data types and we start looking at data back in the ones in the most forms? Can we get some advantages from it? So, you know, why think in binary, right? We have a perfectly good abstraction of data types, right? We can think in integers, we can think in strings, we can think in arrays. But why think in binary? Thinking in binary helps because whoever designed the language didn't know your use case, right? So, when you have certain specific cases, it can help thinking in binary. You could get, you know, better data transfer. You could send less data over the network. You could get faster processing of the data. You could do things quickly just because you know what the binary information looks like. And if you didn't, you would spend more time doing it, right? So, that's kind of the basic of why you want to do it. You also might want to do it, you know, to comply with existing standards. You want to implement a client to an existing protocol that is binary, you know, right? And you need to deal with that information. So, these kind of things take you to this level of thinking in binary. And I personally think that we don't do this enough, especially in the web application world. We're stuck with our data types. And even if we're thinking in a different data type, we think in text-based data types. It's a way to bulky and we could think of them differently and we'll get into that in a little bit. So, this is basic math again. I'm going to talk a little bit about the basics because I know that at least I didn't remember my college binary mathematics class. So, I'm going to revise it as quickly as possible in the room so that everybody has those basics afresh so that we can discuss the other stuff, right? But to really understand binary numbers, you need to understand decimal numbers. And we all know decimal numbers really well, right? We've dealt with decimal numbers since forever, since we started learning mathematics. So, basically, decimal numbers have 10 digits, right? And because they have 10 digits, they're called base 10 numbers. So, let's take this number, for example, you know, which is kind of assumed to be the answer to everything. So, we have 42 in decimal, right? We could write 42 in decimal as 2 into 10 to the power 0, right? Which is 1, 2, 4 into 10 to the power 1, which is 14, right? So, this is how we get 40 plus 2 and we get 42. And this is a very generic formula. It works for every decimal number which is essentially that, you know, you take the digit. So, whatever 0 to 9 digits that you have, you take the digit. You multiply it by the number of digits, which is the base, right? In decimal, we have 10 digits, so 10. And the position. So, you start measuring the position from here. This is 0 to 10, this is 1st position, 2nd position, so forth, so forth. You can have an infinitely long number like that. So, if you start thinking about this formula, right? You could, you know, extend it and you could say, okay, this is the 0 to 10, 1st position, 2nd position. As a 2nd position, this becomes, you know, 8 into 10 to the power 2, which gives me 800. So, I can get 842, which is the number by looking at the data like this. And what is the advantage of looking at the data like this? Is because, you know, this will help us thinking of other number systems. So, that's why we, you know, we kind of got the basic. This is the important formula. The digit, the number of digits. So, a particular digit at that position, the number of digits and the position. So, you raise to the power and you get, you know, you can calculate whatever number value. So, binary numbers are kind of similar. They have, instead of 10 digits, they have 2 digits, right? So, because they have 2 digits, they're called base, 2 numbers, right? And a binary digit has either 0 or 1 and it's called a bit. So, it's kind of the same thing. So, now let's say I have this binary number, right? I have 1 and a 0 in binary. So, how will I understand this number? You know, I'll go back to my same formula, which is, okay. So, what is the digit at this location? 0. What is the base? 2, right? And what is the position? 0. In this case. In this case, right? So, if I expand this, it will look something like this, right? You know, 0 is the digit to the base and 0 is the position. Then, to the base, 1 is the position and 1 is the digit, right? So, I could then calculate that, okay, this is 2 plus 0. Which is essentially 2. I could extend this with any number of digits, right? And it doesn't have to... An important thing to remember when you start dealing with binary data, this isn't limited by bytes. It can go on till whatever number of binary numbers, right? The formula still will continue implying. You don't have to think in bytes. You can think in bigger numbers. And that's important to remember. So, we have a binary digit. But we have slightly better ways of thinking of it. You know, slightly higher level abstractions if you will. So, we had binary digits to record bits. We clubbed 4 of them together and started thinking of them as nipples. Generally, we don't use these nipples a lot, but they're important in one place, and I will get to that in a little bit. But basically, what's important to know is you can store 0 to 15 in a nipple, right? And if you know hexadecimal numbers, 0 to 15 should mean something to you. So, a byte is 2 nipples, but 8 bits. And it can store 0 to 255 values. The same formulas apply, you know, if we have bit values filled in, we can apply the same formula to calculate the value. So, similarly, you know, just like we had base 10 numbers, we had base 2 numbers, similarly, we had base 16 numbers. And base 16 numbers have 16 digits. 0 through F, and that's why they're called base 16. But what's really interesting about hexadecimal numbers is that hex digits fit exactly into a binary nipple. And this is important, right? So, 4 bits can be represented by a hex digit. This is important because when you start writing 1s and 0s, right, lots of them, it just becomes hard to read. So, you want a way to compress and read efficiently. And hex is a nice way to read this stuff. So, because I can take... So, let me explain that, right? So, let's say I add this 1 nipple, 1, 1, 1, 1, 1, right? The value of this is 15. 15 and hex is 8. So, I've got to write this nipple as 8, right? And that's kind of key because now I can write a, a, and that will tell me that it is 15 followed by, you know, 1, 1, 1, followed by 1, 1, 1. And that makes binary information readable the moment you start writing in hex. It is so useful that we have a hexadecimal notation in JavaScript, right? A way to write numbers in hex. That's because we don't have a binary notation, sadly. There should be, some languages do. But we have a hexadecimal notation, right? And it, it makes things easy. Sorry? What did I do? Oh, sorry. Yeah, I'm sorry. My mistake. F and F. So, byte order. People are listening. So, another important concept to understand is byte order, right? So, what we've done so far is we've taken we've created the first level of abstraction we extracted a signal out to 1 and 0, right? Two different signals into 1 and 0. The next level of abstraction we created was, you know what, let's take a bunch of these signals together and call them a nibble first, then take eight of them together and call them a byte, right? But once you have bytes, an issue arises, you know? Which is, you know, so I have to form this binary number, right? We have to start from 0 and go up, but in what direction? And that direction is where byte order starts to play, play a role, but not at the bit level. We don't bother too much about the bit level. We do deal with it at the hardware level. But in JavaScript, you know, this is what is important to understand. So, think of it like this, okay? Let's imagine there's a network pipe here, right? So, if there's a network pipe here, the first byte that comes is called B0, the second byte that comes is called B1, the third byte that comes is called B2, the fourth byte that comes is called BZ, right?  But you have to imagine your pipe on the left and remember that your pipe is always on the left. So, if stuff is coming over the network, this is the order. And this is also about digging in, which I know is a very cryptic name that doesn't really convey much. Network byte order is nice. But basically what I'm saying is that the least significant value of a number is at the same, the most significant value is at the same. And so, let's say if I were trying to write, you know, one, the decimal number, I would write one here because it's the least significant position, right? It means that one would mean one. If I would write one at the most significant position, one would start meaning a bigger number. And I don't want that. I want to send one. So, I would write it here, right? In little Indian, it's the reverse. So, if your data is coming from here, you assume the reverse order. And why are we doing this? See, byte orders are important when you're thinking in a next level, higher binary numbers, which is, you know, words. So, I want to combine bytes together and I want to think in words. And in words, I can either store the bytes like this, the way they came from the pipe, or I can store them like this, where, you know, I do this. And this is important because hardware architecture is kind of wary underneath. You know, I would do the opposite. If I wanted to store one, decimal one, in a little Indian notation, I would store one here. So, it just seems wrong, right?  So, all right, so that was kind of the basics, right? I wanted to cover the number system because... So... But numbers in JavaScript... All right, so numbers in JavaScript are this... follow this particular standard called IEEE 7-4 double precision floating point, blah, blah, blah. The basic important thing to note is let's store in 64 bytes, sorry, 64 bits, which is 8 bytes. But it's not stored in our number system that I just saw, right? It's stored in a slightly complicated format. The point of this slide here was that we will deal with JavaScript numbers a lot, but we will not deal with them in this form because they get converted the moment we start dealing with them. So the moment you start using binary operations in JavaScript, most binary operations will just convert this number into something else. And we'll look at what that's something else in a little bit. So binary operators, especially when you're dealing at the bit level, are called bitwise operators in JavaScript. And what's important to note about... this has to do with that numbers in JavaScript thing, if you have a bitwise operator, the value that is sent to that bitwise operator, the operand, the entity that the operator is acting on, is always converted into a signed 32-bit integer, which is stored in BigIndium. This is important to us. And this ignores those complement. Those complement basically means that the signed bit is always on the left side. So you have this one location for plus and minus. But essentially what we need to know is it's 32-bit, which is 4 bytes, and it's BigIndium. So it looks like what we were drawing a little while ago. So now let's look at the basic operators that are available. So we have a bitwise AND. The AND basically says you have two numbers, number one and number two are bits. So these are 32-bit integers, like stuff is in JavaScript. They're 32-bit values. But when you're doing an AND, places where both of them have one become one, everything else becomes zero. And this is a simple bitwise AND operator and should be easy enough to understand. And this OR basically says that if one of them is one, the stuff becomes one, right? The answer becomes one. So if one of the bits is one, the answer becomes one. Exor, a lot of people aren't generally... It's a very useful operator. But basically what it says is Exclusive Org. Only one should be ON. If we are comparing bits, you start from here. See, in this, this number also has one, this number also has one and one. This one only has one and one. So these are exclusively one and only one of the numbers become one. It's hard to explain, sorry. NOT is basically just reverse the bits. So you have zero, put one, you have one, you put zero. Shifts are important to understand. Shifts are important. Shifts are very simple, though. All they're doing is, you know, if you have this number, when I say, so all you want to do is you want to move all the bits this side and insert two here, right? So move all the bits to the left and insert two empty zeros there. Um... It was right... Sign propagating right shift is, you know, the opposite of this is this thing where what happens is here it looks the same, right? What I did was instead of moving in this direction I moved in the right direction, right? These two bits fell off, right? Um... But there's something unexpected happening here which is clearer from a signed example. So nine was an unsigned value. It didn't make a lot of difference. It was minus nine, right? Um... It makes a difference. Makes a difference because when I shift the empty spaces don't get filled with zeros. They get filled with ones. And this is very important. This is very important. If you want them to be filled with zero, you use a different operator with just three arrows. And in that case this will get filled with zero, right? But this is important to understand. So... All right, so... So far what we did was we understood, you know, how binary numbers... To deal with binary numbers. Um... The next thing to think about is how do I organize? So far I've only looked at integers and we've looked at integers also very briefly. So the way you store... The only way we have to store binary reasonably stored binary information so that we can operate on it is the number data type in JavaScript. Okay? But the number data type, um... As we looked at before, has this weird 64-bit format that we don't really care about. But when we need to work on it, it gets converted to a 32-bit format. Right? So once we have these... So let's start thinking of numbers as 32-bit signed integers. And let's just, for a minute, assume even though in JavaScript, you have floating point numbers and you have, you know, longer numbers. Um... But let's for a minute just assume that the numbers available to us for the purpose of binary data are 32-bit signed numbers. Right? And then once you have this unit, um... a 32-bit signed big Indian-ordered number, which is basically saying that there are four bytes in the big Indian order in that number. We can say, you know what? This is not number. I will treat it as something else. I will treat it as my own way of creating new data formats. And this is where encoding starts to come. So most of the time... And what is text? Right? It is in the end in computer science, everything is numbers. Right? And in... if you keep going lower, everything is bits. Right? So it's all bits. Uh... Text is also bits. Right? The only thing is it is in a certain format which says number 65 is 8. Right? So there's a table which says, you know, this number is this character, this number is this character, this number is this character. And a byte can have 0 to 255 uh... numbers in it. So you assign a number to each of these um... values. And you... So you assign a character to each of these values and you can create a text format. Right? This is our old UTF 8 format. Uh... The newer ones have expansion capability and they can deal with two bytes at a time because they need more space. And we can have more characters. Uh... But this is what text formats are. But text formats have a problem. Okay? The problem is if I write the number... If I write the number 10 in text. Right? Uh... Number 10 in text right? Needs one byte to store one. And it needs another byte to store zero. Why? Because one is actually uh... 49 I think. I'm not mistaken. 40? One, huh? Okay. So one in Unicode is uh... 41. Zero in Unicode is, you know, some other number. And I need two bytes to store uh... 10. But we just saw that I can store 0 to 255 in one byte. Right? So there's a problem here. Because I now suddenly need two bytes. Actually I need more strings also store length. So I end up storing like four or five bytes to send 10. Right? I need to send 10 to my server. And instead of sending uh... one byte, which is where 10 can fit in, I send four or five bytes. And this is the problem, right? And this is why you need to look at data at the binary level. Another good example would be that, you know, um... I'll actually get to that example a little bit. But basically text is heavy, right? So JSON is text, which is most commonly used by us. XML is even heavier text because it has its own metadata and text, a lot of it. Um... So text formats are bulky. And we need something else. And... and all I'm doing... I mean, the reason I'm giving this talk is to promote the idea that go look at something else. And there are a lot of options, and I will introduce them a little bit in a little while. Um... And these things we generally tend to call them binary formats. But even text is binary.  Um... Binary formats are basically a set of rules which define data types. Right? So what they essentially say is, if I have an integer, store it like this. Right? If I have a float, store it like this. And typically these formats will look like, okay, you know, um... In case of an integer, put a tag which presents it. So... Um... I have to take this example. Good example. Okay, so... You're trying... So you're getting a stream of bytes on the network. Okay? The length of a byte stream is unknown, let's say. So you don't know how many bytes are going to come. You just... You're getting bytes. So how do I... start reading data from the bytes? Um... And there are several ways. One is... you and I... So you're sending me some data in a byte binary stream. And you and I pre-agree that you know what? The first four bytes that you send me are the length. And then... followed by that length. So the first four... So first four bytes that you send me, one, two, three, and four are length. Right? And followed by that is length bytes of data. Which I will use as a stream. So this will be definition of a string data type. And this is my own custom format. Some format might have this, some other format might not have this. But essentially what I do is send length first and then send length bytes of data. And that is what basically all binary formats do. They send in some information about the length. They may send in a tag here which says, okay, you know what? What is coming is a string. So there might be a number assigned to string. Let's say two... Anything that starts with a two is a string. Anything that starts with a one is an integer. Anything that starts with a one is an integer. Now I could do two things. I could store the length of an integer here like I did with string and then store the integer. So I'd need four bytes to store length and then I need to store the integer. This will make my integer value nine bytes long. That's not very cool. Integers can be stored in 32 bytes or four bytes. So what's going on here? If you and I both agree that integers are always 32 bytes, then we don't need to send this length. And this is what a lot of formats also do is that they have three grids that you know what? Whenever I want to send you an integer, I will send you one and I followed that integer. I will not send you length because we both know integers are always four bytes. So this is what typical binary format should look like. Sorry. So padding could be one of the rules. One of the rules could be okay, you know what? If an integer is only one byte, but what you and I have agreed is that integers are always four bytes. Then I will pad and put zero in the rest of the bytes because I don't want to confuse you. So padding could be one of the rules. But data formats essentially are just these set of rules that define what common data type should look like in a binary form. And I've talked about fixed width and variable width data types. What's interesting and what is relevant to JavaScript? This stuff, everything we've talked so far is mostly common in most languages. What's relevant to JavaScript is how do you store this binary information. And, well, JavaScript traditionally isn't pretty bad. It's been pretty bad because there is no binary data type. There is no binary data type, meaning there is no easy data type to work with binary data. So what you typically do is you stuff the data into a string and then you use these two functions. You know, care code at some location or you use strong care code to create the string. And that's it. It sucks, it's really slow but that's all we have even today in all browsers. It works in all browsers. So if you have to build something that works in binary data in all browsers, string is still probably your best bet. And also, even if I get to the next slide, the next slide will give a different alternative. The problem is that different alternative first needs to use this. Why? Because your data and a web application is coming over HTTP. And when it comes over HTTP, the response that you get from most browsers is text. At least it used to be that's changed now and we'll discuss that. But it used to be just text. So because it is just text, and let's say your server sent you some binary information in text, you need to read that using this care code app. After you've done that, you could copy it into an array of numbers. So you could, instead of using strings all the time, you could use an array of numbers because essentially what is binary information? An array of numbers, right? But you could do two different things. You could store only 0 to 2. So let's say I have a number. There is a, a, so 0x, a, a, b, b. That is my number. And this number I want to send over the wire. So I send this data over the wire in some format. So this value is less than 32 bits. It can fit into one integer. Right? And when you're leading data into an array of numbers, you could store both of these bytes together in one number. Or you could choose to store only one byte at a time. And you might want to do this if you want the flexibility. Right? So array of numbers could be array of numbers that are always less than 255, less than or equal to 255, or array of numbers that are always less than 32 bit numbers. Right? There's like 4 million something, something, the maximum. So you have an option here and different libraries I've seen depending on the data format I've tried to do different things. But this is all really, you know, strings and arrays of numbers are really old things. They still work in all browsers, but they're really slow. Yeah, so that's what I'm going to get out. They're not heavy because memory-wise they're just the same. They're, they're heavy because I don't have good operations to deal with them. I don't have data type-based indices and I didn't use to have it. I now have them, right? I now have them. So stuff is changing. We have new specifications. The first one is block, which is part of the file API spec if you've read that spec. And the file API spec may define something called a binary large object. A binary large object is this in future version of the browser and already I think in Chrome and latest Firefox you have blob. But in future versions of browsers, the intention is that whenever you're exchanging data that is not of known JavaScript data types, you'll always be sending around a blob, right? So for example today, if you read a file using the file API, the result is a blob, right? But this blob on its own isn't very useful because you can't operate too well on it. You need to do other stuff well. Yes, so now XHR 2, new XHR specification, allows you to send blobs. So you read a file, you get a blob. You just take that blob, put it into an XHR and send it over, right? That's all. So you could do that. But you could do that only in new browsers. Well, HTTP was never streamed. HTTP has this header called content type. And content type allows you to send whatever you feel like.  And you couldn't change content type. You could. In an old XHR, you can change the content type. It still doesn't work in most browsers because you have to do, I think in the old XHR, you have to do this override, MIME type, blah, blah thing in Firefox. And in I, you have to do something else. If there are a bunch of hacks that you have to do to pull off a new content type exchange, but HTTP supports it. Yeah, I'll get that. So, I don't stand. You will load into? Is it like the entire problem is actually loaded into the library? The whole file? No, it doesn't work like that. File API, if this blob is coming from file API, it actually can't deal with it. If this blob is in memory, then it's in memory, right? So anyways, if I have, I thought it was 10 minutes. Okay, anyways. So, similarly, you could receive a blob. In XHR 2, you just have to send the response type. And then in our response.response, you'll get the blob. And you can deal with the blob. So how do we deal with the blob? Before we start reading it, we can also build our own. So we don't have to read from a file. We can use this class called blobBuilder and append a bunch of strings to it. And here you can send in a content type. So it has a bunch of supported content types. And then you send it into the blob. At this blob object, you could use in an XHR and send up. Send over the wire, right? But what if? So it is part of the new file API standard. It's, well, you can't really call it standard because it's not in all browsers yet. But yeah, it is part of the proposed file thing standard. It's not in old browsers. So, what if I want to read a blob? So, as such, the blob doesn't really have a lot of operations on it. But it will let you read it, right? So we can use this file leader again part of the file API standard. And you can read it as different things. You can read it as text. And you can read it as a binary string. You can read it as an array buffer. And this array buffer is new. Other stuff is not that interesting. And you'll get that result in this result object. This array buffer is the best thing that's happened for binary data in old browsers for a very long time. So array buffer is your traditional byte array. It's an array of bytes. And typically how you operate on an array buffer is that you create a view. Right? So how did I get an array buffer in the first place? I read, you know, I read a blob as an array buffer. Right? So I could create a blob using blob builder. Then read that blob into an array buffer. Right? So this way I can create binary information. Once I've done that, let's say I want to operate on this array buffer. And the way I operate on it is by creating an array buffer view. So array buffers are just the space in memory. And you don't... that object doesn't give you read-write methods. What gives you read-write methods are these views. And views is typically, you know, just a part. It could be starting from the end, beginning until the end, or it could just be a window in between that you're looking at. Once you've created one type of view that you can create is typed arrays. And typed arrays will give you data type specific arrays. So this is interesting. I think the only way I can explain this is by showing an example. So so here's what I'm doing, right? I create an 8 byte array buffer. Right? 8 byte location that I've gotten in memory. Then I create an 8 32-bit array which so what I'm saying is in those 8 bytes give me an array which is indexed by 32-bit integers. Meaning that when I go to index 1 I will get the first 32 bits of those 8 bytes. When I go to the second index, I will get the next 32 bits. But I could do something different where I could say you and 8. And in this case I would get the first 8 bits not the 32 bits. So here I'll get 32 bits at index 0. Here I'll get 8 bits at index 0. Right? Here I'll get 16 bits at index 0. But you know, sign is kind of important. No, so typed arrays are part of another proposed spec called WebGL. But even browsers that haven't implemented WebGL have started implementing typed arrays because they see the value in it. You don't need you don't need a WebGL context. And because you need to implement a file API which everybody agrees on WebGL nobody, you know people, there's no consensus. But file API everybody agrees on and file API has array buffers which means that you automatically just get all the stuff. Yeah, absolutely. And edited, changed formats all for all. Yes. So the typed arrays right now I'm very fast in most browsers they're almost as I mean they're slightly faster than your traditional array approach. No, if you have a WebGL context then your typed array will get your typed array operations will happen in the GPU. But if you don't have a GPU context which is, you know, if you don't have WebGL then typed arrays running in in your regular CPU. So anyway, so you know what you did this. So, typed arrays are one kind of use remember what I said was you need a view to work with array buffers. Type arrays are one kind of a view that you can create on an array buffer. Data view is another kind of view. And data view gives you your traditional byte array view. It gives you the flexibility. So typed arrays have got a problem. The problem is that they assume that every value will always be 32 bytes or a particular data type, right? Every value will always be 8 bits or every value in that array will always be 32 bits. And that might not be the case if you're dealing with dynamic binary information. So data views, you can use them to, you know, read 8 bits or read 10 bits or 20 bits or whatever. There are built-in functions which lets you read 8 bits, 16 bits and you know, there are a library of these functions will let you read them and also let you set them. So you can use a data view if you need a more flexible approach where your data isn't homogeneous. It doesn't look the same. And this is what you would use if you wanted to create a complex data type. So let's say I wanted to send an object over the wire where, you know, first value in the object is ID and this ID is let's say 1 byte long. The second value is a string. Then let's say this is, you know, 100 bytes. It's a fixed length. And then the third value is some age, right? Of data type number. So now I need to read first a byte. Then I need to read 10 bytes or 100 bytes. Then I need to read 4 bytes. And a data view would give me that flexibility of reading how many bytes I want. So somewhere similar to structures. No. You could create your own but there's nothing that gives you ready-made structures. You could combine the data view API and create a structure like this. But there's nothing that is built into the language. Right? So you could create Okay, then maybe I missed it. That's also possible. But, I mean, right now all I know is that you would use the data view API to create your own custom data formats or structures. Some people also still use, so Canvas has, you know, a way to store images and some people use image data to store that because pixels are also 32-bit values and you can use that information. So this is, people use this. It's getting slower and slower compared to typed arrays. The support is almost just the same. So, you know, this will probably go away. So far we talked about, you know, how do I store data and manipulate binary data in memory? But how do I send it over the network? And this is where, you know, your traditional HTTP question comes in. HTTP has no restriction, right? HTTP will let you send an object stream. HTTP will even let you send a custom header which says, you know, this data is of some other type that I don't know of. For example, you know, Google has created this protocol called protocol buffers. The protocol buffer sends a header which says X protocol Google, X protocol buffers Google. And if that happens, then you can send binary information over HTTP. So HTTP doesn't have that restriction. The restriction was because of the XHR implementation. But people were getting around it using, you know, form data and things like that. So you could do stuff.  The new XHR works just fine. You could also have, you know, web sockets. And if you have a web socket, you basically have the ability to send any binary information. Web socket API. Sorry. Well, you need to serialize it according to your lalins. If you have a data view, right, you could just send that data view over. But what we're talking about really is serialization is an abstract term. Serialize from what to what. And if it's you cannot send a blob on a web socket. Yes, you can't do that. You need to read into a data view and then pass the data view over a web socket. So finally, you know, these are the kind of basics I wanted to only cover the basics of, you know, what you can do with binary data. What I would like to urge people is to consider binary information. Consider that you can gain. So for example, I deal with a I'm building an application that sends a lot of numbers from the server to the client. And if I start sending all those numbers in strings, well, it just becomes really, really big, right? For example, if I want to send 4 million, 4 million as a string is going to take me about 9 or 10 bytes. But 4 million as binary information will take me 2 bytes or 3 bytes. It does, but it doesn't really matter. It just doesn't matter. Almost to the order of, you know, 100 times kind of difference. If you format and deal with a data format properly according to your data, right? And that's exactly what I'm trying to say. What I'm saying is if you have data that looks interesting from a binary angle, just consider that option that you would send it as a different data type, not traditional data type.    There are really old ones like ASM and stuff also. Sorry. Yeah, just last 5 minutes.  One of the advantages that you might want to consider of thinking about data in binary numbers is, you know, the fast speed that you get with just bitwise operators. So let's say you want to, you want to multiply, multiply by 8, right? Multiply by your number n and you want to multiply it by 8. This runs slower than n left shift 3. These things are out there is important. Understanding that bitwise operators can help you do fast calculations is important. So I would encourage you to look at bitwise tricks. They're sometimes less readable but, you know, at critical times, they can get you a lot of advantages. Like the data exchange we've already discussed that you can, you know, if you have new data formats, you can improve your network over it. You can also improve your memory over it. Sometimes if you want to store data in memory but you don't want it typed to, you know, JavaScript objects, you could still keep it in binary blobs. You could of course build already existing. So using WebSockets you could build clients to existing protocols. People who are using Node.js are writing interesting protocol libraries. I'm sure when WebSockets become popular we'll have those libraries in the browser suddenly. And of course you can do file manipulation and that was pretty much all I wanted to talk about. But in browsers in browsers well, I think in my example I can take a lot of numbers and I can just reduce the amount of payment transfer that we do by all the street times just by having minus customers. You could do some definition that's in audio which sits like this. You could do file manipulation. You could read changes in the browser for the way that you want it to. And I think you need to talk to many of your companies about that. I think you can. I think earlier we used to have a bunch of guys and they have better tools. Thank you.