Okay, so I'm going to talk about the confusion of things. I'm going to rant for a couple of minutes to start with and then we're going to talk a bit about What a platform is what an IOT platform is and what are the constraints you can use to cut through the marketing nonsense and Pick a platform. So I look like this on the internet and Everything is actually pretty awesome If you cut out the horrible marketing materials, etc that we have on the IOT domain and the other thing We're doing a terrible job of as engineers again, sadly You know driven by marketing as well We're really coming up with terrible applications for IOT. So this is where I start ranting So this is a very good example of why, you know, IOT is getting the bad rep that it's getting If only we could find a way to make notes stick to a fridge like we don't actually need a, you know, twitter connected And I'm not kidding. There's actually a twitter app and this is a door of a fridge. You know, this is unnecessary or I mean This I'm not a dentist So I don't know like if this is a real problem But like we I think we don't really need toothbrushes with bluetooth enabled, you know So this provides some, you know, real-time brushing guidance and personalized dental care journeys everyone Again, not a dentist, but somehow I think this is a terrible, you know example Or like we don't need engineers explaining how to, you know, ipv6 enable your coffee brewer, you know, it's just You know, if you look at if you search for IOT on google images, you get this thing, which is, you know It's a bubble it's it's it's literally a bubble if you think about it. It's just this Generic notion of a cloud now speaking of the cloud the cloud has been or have been having this problem for a long time You know, you end up with these cloud applications that are just a mishmash of, you know, different technologies, you know Why do you even use mongo db? So it's just it's just things are terrible things are very bad But then you get applications like the radiation monitoring that safecast guys did and this is actually an amazing application of iot Um, if you don't know about this they distributed some guide a geiger counter kits around the fukushima district and around japan and around the world now as well and um, you know, they allowed, you know impartial and honest monitoring for disaster relief And there are loads of other environmental applications like this, you know, uh water monitoring Air pollution detection and that kind of stuff. So I I somehow feel these are not getting the attention that they need and you know, all the consumer goods Because they happen to have bigger marketing budgets are getting, you know, a lot of attention and that's actually giving iot a very bad name um and healthcare is another area where iot can help really really well and um Again, I kind of feel that we're not really getting Or we're not really giving them enough attention. So That's my rant over. Let's talk about hardware um now an iot application as you can appreciate consists of many different components Um starting with the lowest level Like a bottom-of-approach you have these nodes or you know devices that are deployed around the field These could simply be your cell phone. They could be sensor nodes. They could have a variety of different processing devices on them Different sensors different inputs different outputs and then um, generally you have these central nodes that The little nodes connect to and you know relay information to if they're not directly connected to the internet um generally referred to as hubs and um Going Like further you could also include all the data processing that you do and servers to be part of the iot devices as well um with many devices and different architectures you have the You know responsibility to manage them. Uh, this includes the registration. How do they actually get associated with user accounts? You need to monitor them if they go offline. What do you do? Do you panic? um and the general orchestration of things So and data is everything these days. So you do have data services which collect and you know Do rather perform some analytics on the data And so that they can be sold for money. Um, and then You have mobile apps. You have web pages. There needs to be some communication endpoints that these things can connect to as well So overall an iot platform is actually quite a complex bit of um architecture and If you look at um vendor websites, they all claim to offer the full stack solution to everything, of course but the problem is um It's a tie-in to a particular vendor and most of these ecosystems don't actually play well together or connect well together Um, it's a bit it's a case of oh, there are 20 competing standards Let's create, you know, yet another one and let's you know, raise some money whatever and the problem is now You have 21 different competing standards So Choosing an iot platform is actually quite a complex device today I'm going to focus mostly on the hardware side of things choosing which hardware platform to use And I've broken that down into several categories. So the first one is connectivity Um, this is very simple. Uh, depending on the application you may want to have I don't know gsm connectivity or wi-fi connectivity or some form of connectivity to get the data out of the device The first characteristic of an iot device is that it's somehow interconnected with everything else um internet of things so Yeah, the the the questions you have to ask yourself is how does the communication happen? Does the device have direct connection to the internet or does it have to go through a hub? And Other things you need to keep in mind is like you get this Radio device, how do you actually get it to talk to other things? What's the setup process going to look like and I feel this is an area that we're failing as engineers To like make simple, of course, there's limitations around this You're not going to get a random rf device talking to your iphone or whatever But this is an area that you need to keep in mind as well. And the other thing is the application dependent Uh, processing requirements. So do you have I don't know high high definition cameras that you need to process frames out of Um, how much local processing do you have to do? This is very important in choosing a device that will run your system because I mean realistically, you're not going to hook up an hd camera to an arduino. So That's one of the key constraints as well And everything is getting mobile and you know portable So is this device going to be battery powered because if that's the case you probably cannot afford to put a You know 64 core processing device on a you know single tiny cell battery So, uh, physical size is a is a factor. Uh, is this thing going to be pocketable? Is it going to be mounted on a wall somewhere and ultimately cost? So this is both the cost of the device that you're putting together and the operational cost Keep in mind these things are connected. So you need to provide some back-end services to them And that needs to stay up for these devices to be functional um, and a very good example to this, uh connectivity and operational cost is What happens when the vendor you choose for your connectivity and data analytics and stuff like that goes down You have devices in the field You know trying to reach this back-end server, but that company has gone out of business Because they pivoted they decided to I don't know write a messaging app for an iphone or something So, um, this is actually quite an important thing both from a cost standpoint and from your app for your application standpoint as well That's outside of the scope of this talk. So I'm not going to go into that now This is a question that comes up very often.  So, um What follows is Mainly focusing on going into production and actually designing something custom as as opposed to these I'm going to be talking about what kind of processing devices that reside on these boards And focus mainly on the on the architectures and the platforms in general as opposed to brand names So this is a very informal categorization of these devices. You have small embedded devices And these are 8 16 bit micros general purpose, they don't really have I mean, they might have a particular application, but they're general purpose in that they support multiple protocols. Um They have larger embedded devices. These are arm cortex series slightly larger And faster they have, you know dma's different channel dma's they have a lot more complexity And then you have linux capable so c's So to give you an example small embedded would be arduino large embedded Would be say the disco stm f7 board or Some I think there's a board called maple which runs on a cortex m3 Like an arduino linux capable so c's are things you would find on raspberry pies or beagle bones and stuff like that These things just run linux effectively and then you can repurpose pc class devices Into you know your little iot device or a hub or Something along the lines of that. So it's 10 a.m. So let's look at some architectural diagrams So this is this is i'm not going to go into very much detail I just wanted to show you the differences between these these different devices So this is an 8 bit cpu and it's architecturally. It's super simple There's this cpu core and then you have some peripherals These peripherals are very low level. I'm talking u.r. It's high square c spi that kind of stuff no usp Although you can get usp on some micros now But an application for this would be a low power wireless sensor node now this By itself does not support wireless But this architecture in specific specifically but the idea would be you know This device would be sleeping most of the time. It's really not doing much It's just grabbing a couple of sensor data and pushing it to a central hub or something An example Of a wireless, you know embedded would be the esp 8266 not going to go into too much detail Matt is going to talk about this at I think in about 14 minutes or so But this is uh, this is a small cpu core with wi-fi bundled onto it in a single package Which in quantity you can get for silly little prices So, you know the first example I gave gave is probably more suited to run on this But as you can see the peripherals are still very simple. They're just spig pio There is no pc i express. There is no usp So the applications are quite limited into again small sensor nodes or that kind of applications and then you have you know beasts like The bcm 2835 In you actually have different devices on the same chip So you have the gpu and then you have the cpu and you have all the peripherals that are on the on the cpu itself An example application to this and in fact if I remember correctly The main reason this chip was designed was this was meant to go into setup boxes where you have an htmi out And the cpu just grabs stuff from the internet and then pushes it to the gpu to be decoded as h264 So this I mean you could Do you know little sensor applications with this but this would be more suited for Something that's connected to the internet and runs any generic software package because it's running linux So yeah, and on the same way in as this Um This is coming more and more becoming more and more common repurposing so system on chip devices That are designed to run access points and routers home routers These devices generally have a linux capable soc or a processing core and then what they have is quite spectacular in that You know Alongside the low level interfaces such as gpio's you are at etc. They have usb's they have pcie express cards and stuff like that and One thing that's great about these things is that they're super cheap for what you're getting and Now the only problem is you're not going to go to media tech or athero or qualcom atheros or whatever and say can I buy 10 chips so Actually designing with these things becomes more complex The general idea is that you get a router board and then repurpose it to your You know application And if you're going into production you talk to oems and odm's to actually customize an existing design but They have wi-fi integrated into them and they have all these high level interfaces. So an example application to this would be if you had say You know a custom, you know fpga application that required really high throughputs to the Core system and you used pca express to connect to it and so on again You're not going to If you really wanted to you could do sensor applications with this But that's better suited for the small embedded and somewhat large embedded devices And this is yet another example of an soc for a router And you can see that it's Generally they're all the same. They have some form of wi-fi and they have pcae and usp and so on One thing again, these are great for applications that need to run some form of i don't know linux demon or When you don't really want to program things very low level and you need connectivity and so on So you can of course do connectivity to the outside world with with small micros But this is running linux. So you could you could reuse any existing Package very easily for that kind of stuff. So let's have a quick look at the key constraints that we talked about So we have connectivity how do these things connect to each other and the internet and the users effectively What kind of processing we need do we need to do hardcore, you know image processing on the device some dsp To do signal processing Or can we just use the device just as a data acquisition device and then push it to the cloud For some server to do processing on Is this thing going to be battery powered? Or are you plugged into the wall? Do you have the luxury of burning watts and actually not caring about it? What kind of size this thing is going to run on and ultimately what the cost of this whole operation is going to be So once you've You know come up with a short list of devices Comes the next phase because the hardware platform you choose Is effectively going to dictate how you're going to develop your application or your system so If you choose to go for Say an 8-bit processor, you're not going to be able to run a high level virtual machine with concurrency and I mean you can but you really There's no point in doing that And likewise if you go up to the level of a linux sock You know programming that in asm probably is not the best way to go about it So it's going to dictate what kind of language you're going to be using and what kind of frameworks you will have at your disposal So if you if you go for one of the solutions from an iot and that's full stack, they probably will give you Effectively an ide that you use probably on the cloud something that runs on the device That takes care of deployment and stuff You know that's entirely up to you Do you want to rely on a vendor or do you want to do your own cloud? But ultimately how you program this device is entirely, you know down to what device What system or what device you're going to choose? And another important thing is the data model that you'll be using so Again on a small 8-bit micro You're not going to do protocol buffers or you know something heavy like that So you know it it all depends on what combination of devices you have in your system To determine how communication is going to be architecting the nose Another very important thing on iot is security and firmware updates so Again, let's go with 8-bit micros doing ssl and that kind of stuff on that Kind of devices is very difficult You may choose a device that has a crypto co-processor that will take care of that for you But again, that's something to keep in mind And how do you get firmware updates to the devices safely and securely? You know is another thing Most iot companies i'm not going to say most some iot companies say Oh, we'll just you know ship this very old version of linux and you know Actually, they don't care about patching it and then you have cases where you know Oh, you know hundred thousands of routers got compromised because they were running an old version of open ssl or something like that So firmware update management in iot is a very very important thing And I just wish people paid more attention to it And ultimately the entire characteristic of the system is going to be a sum of all the devices that you put together And you know how you're going to present that data or what you're going to do with that data This gets into the business domain. So i'm not going to go into that So with all that said If you're interested in playing with some iot devices or iot systems and stuff I'm running a workshop on sunday i.e. tomorrow We have We have nine boards So we have eight nine Spaces available if you're interested come and find me when we're grabbing a cup of tea or coffee And um, that's me done. Thank you very much. If you have any questions


meeting of the 2014-2015 Common Council. Would the clerk please read the quote for the evening? Thank you, Mayor. Nobody will ever deprive the American people of the right to vote, except the American people themselves. And the only way they could do this is by not voting. Thank you very much. Very apropos. Next is the roll call. Would the clerk call the roll? We have 16 present. Thank you. Next is the Pledge of Allegiance. Please stand and join me. Pledge of Allegiance to the flag of the United States of America and the duty of the republic for which it stands, one nation, under God, indivisible, with liberty and justice for all. Next, we'll go on to the approval of the minutes from our last meeting, Alderman Hammond. Thank you, Mr. Mayor. I move to approve. Second. Thank you for that motion and support. Is there any discussion on the minutes? Seeing none. All those in favor, please signify by saying aye. Aye. Opposed? Motion passes. There are no resignations. And we have one council appointment, city attorney. Thank you, Your Honor. Honorable members of the Common Council, I hereby submit the following appointments for your consideration. To the mayor's neighborhood leadership cabinet, Rosemarie Trester from the North Flats Neighborhood Association, be appointed 11, 3, 14. And the term would expire 4, 30, 2015. And Ken Van Orden, North Flats Neighborhood Association Alternate, for those same dates, signed by the mayor. That appointment, well, or those appointments will lie over. We haven't approved their formal association status yet. That's on the agenda for today. Next, we have a program. John Dole is here, the executive director of the Sheboygan County United Way. And he's here to make a brief presentation on their campaign for this year. John, please join us in front. Want me to go here? Yeah. Thanks for having me here today. I'll just try to take a few minutes, but not too long. United Way's campaign kicked off, and it really keeps going all year long, for the most part. It's really biggest, most important part of the time. It is in the fall season, obviously. That's when our biggest campaigns go. But I wanted to let you know, just really, if you can remember, four things when you're done with what I'm done speaking tonight. First off, we continue to fund about 22 different agencies, roughly 50 programs within those agencies. And we'll continue to do that. We'll continue to look at the best programs in the county and in the community to fund. However, there's four areas that we're really taking a really hard look at the last couple of years. And we want to focus on and really begin to take to scale some of the key things that these four programs are going to be focusing on. The first one is the idea of early learning and birth, basically birth to four, birth to five-year-old learning. There's a really good program that's out of the Family Resource Center in Plymouth called the Parents' Teachers Program. It's a home visitation program that's been around for many, many years in the county itself, I think somewhere around 15 or 16 years. And United Way has been supporting that all along to one small degree. There are about 1,200 kids that are born every year in Sheboygan County, and many of those to first-time parents. So right now, the Family Resource Center is able to handle about 100 of those families. And basically, the idea is that a child is born learning. As a child is born, the minute they are out of the womb, basically, they start to learn. And I tell the story of my daughter, Becca. I was in the birthing room when she was born. And within five minutes of her being born, the nurse handed her to me in a small blanket. And I looked down at her, and she looked up at me. And I could think of nothing more mature to do, so I stuck out my tongue.  She was emulating me. She was mimicking her father the moment she was born, pretty much, within about three or four days of that. My wife said, here, read her this book, Good Night Moon. And I looked at my wife and said, she's not going to understand what I'm talking about. How can she possibly know what I'm saying? Sit down, read her the book. So I did. And within a couple more sessions of that, I would say Moon, and she would point to the Moon. And I would say Bunny, and she'd point to the Bunny, and to the cat, and everything else. So it really sent it home to me that children, or the parents, have to be the child's first teacher. And all too often, we don't see that happening in our families. And it's a universal challenge. A person could be an isolated family, immigrant family, just moving to the country. That's kind of in a tough economic situation. Or it can be two vice presidents at Kohler that are having a child, and they don't know what to do. Kind of like me, I was a vice president when my daughter was born. And I didn't know that much about parenting. So this idea of trying to take this one particular program that's in Plymouth and begin to bring it to scale, and to begin to make that kind of a social norm in the county. And we're going to look to try to do that over the next number of years. That's one big program. The other one, we had a summit. We convened a group of us, convened a community conversation at Blue Harbor last March. And we had over 320 people from all different walks of life, people like you, people from the health care system, people from the schools, law enforcement, any number of people that came. I remember one person, and we talked about mental health. And the whole subject was to discuss mental health and the crisis that we're having as not only this community, but across the country, beginning to realize that mental illness drives so many of our other chronic diseases. So I remember one person that was sitting at my table was a woman, and she had a son that was addicted to heroin. And she was at wit's end as to what to do. How can we keep this, how can this happen in our community? And what do I do with my son? Where do I go? So at the end of the day, it was about a five-hour session, and a lot of conversation was had. And at the end of the day, three subjects came to mind, came to the top, that floated to the top. One was access to mental health. The next one was coordination of mental health services. And the last one I think is the most important.  So from that, we continue to go forward. One of the missions that we have at United Way is to try to make people more aware of mental illness and it's important and it's relationship to chronic disease. So that's one thing that you'll hear more and more from us. The third thing is the area of food, of healthy food distribution in the county. We have many, many pantries, we have a food bank, and oftentimes a lot of them aren't necessarily talking together or working for the betterment of the community to be able to get it to the point where everybody who needs healthy food can get it. So we're working on that. We're trying to knit together a network. One of our success stories over the summertime was the summer lunch program for free and reduced lunch. Kids who qualify for free and reduced lunch, and it's a higher, higher number now, don't have access to a free or reduced lunch in the summertime. So we work together with the Boys and Girls Club and the school, Sheboygan County School District, and we pulled together a network that we were able to provide 750 kids a day with lunch, and so we'll continue to do that. The last thing is the Volunteer Center. Up until June, the Volunteer Center was housed in an agency and the agency decided they didn't wanna deal with the Volunteer Center any longer, so it was either the Volunteer Center and the Day of Caring and all of that was gonna go away, or United Way was gonna have to take it on. So we stepped up to the plate and we brought it in-house and we've hired a director and you'll hear more and more about volunteerism as the time goes by. Our mission is really to connect those people who wanna volunteer with non-profit agencies that have programs and projects that need to be done in the community. So that's it for me. Anybody have any questions? John, thanks so much for your presentation. I hope that's a great campaign this year. The city handed all the pledge sheets out to their employees about two weeks ago and we're trying to wrap everything up by the 21st of November and appreciate it. And all the aldermen have some pledge sheets on their desk if they'd like to participate as well. Have a good evening. Next we'll go on to the public forum. So you're clear? Yes, we have one person this evening. Joe Lam, if you could come on up to the front podium. Joe, can I have your home address please? My name is Joe Lam, I live at 4010 North 30th Street, Shebaugin, Wisconsin. Okay, and you will have five minutes. I'm here to represent Midlake Softball Organization. Back in March, the Common Council approved us to run the softball program at Wailudette Valley Park. I'm just here to give you a brief update as to what happened last, this past season. The short term we had 92 teams that had registered for the program, 91 finished the season. We had over a thousand player cards issued to members. We ran two tournaments, one for the Pediatric Brain Tumor Foundation and one for Toys for Toss. Those were both benefit tournaments. We had planned on, we expect to give about $9,000 out to those organizations. The entry fees, anything from concessions is staying with the Midlake Softball Organization. The donations to them were extra cash that we had collected from the players to get to those organizations. I gave out a list to all the aldermen. We had park improvements in the range of $12,000. Some of those are donated, some were cashed and some were items. Items were donated to us and they were put into the park. We have, Community Bank has given another $5,000 for a total of $17,000. And on behalf of the players and the board of directors, I'm honored to hand the mayor of the city a check for another $7,500 for park improvements down at Wildwood Park. Any questions? I'd just like to thank Joe and all the volunteers for the Midlake Softball Association for all the work they've done, mostly helping us keep the park up, keep it as a premier facility for all the softball players here in Sheboygan. Great job. Thank you. Thank you much. Next we'll move on to Mayor's announcements. I had the pleasure of issuing a proclamation last Friday. It was Mike Kinzel's last day of working for WHBL, so I went down to the studios at eight o'clock in the morning and presented him with a proclamation and made it Mike Kinzel Day all day last Friday. So he was ecstatic and it was somebody that we really appreciated working with for the last 13 years. And tomorrow, if you don't know it is election day, please exercise that right to vote. And new for this election, the city results from all the city wards will be posted on the city website and they'll also be forward to the Sheboygan County clerk's office at the same time. So if you go to a banner headline on our website, you'll be able to see those and then after we get all the results in, the clerk's office will put a tabulation up as well. Next we'll move on to the consent agenda and include items 2.2 through 2.14, Alderman Hammond. Thank you, Mr. Mayor. I move to accept and file all reports of officers, accept and adopt all our season, put all resolutions and ordinances upon their passage. Zagat. Thank you for that motion and support. Is there any discussion on the motion? Seeing none, will the clerk please call the roll for passage. I'm sorry. My computer's on. Okay. Mark, okay. 16 ayes. Motion passes. Next we'll be going on to reports of officers that include items 3.1 through 3.10, Alderman Hammond. Oh, I'm sorry. All these documents are meant to be referred to various committees. Alderman Van Akron. Thank you, Mr. Mayor. I'd like to, I guess send item 3.4 along with items 6.1, 6.3 and 8.1 and have them all referred to the Committee of the Whole. I do see that we are having a Committee of the Whole where item 6.5 is also being referred to the Committee of the Whole. I just think if we're gonna have a discussion in reference to these items, the chief administrative position going forward and possibly changes in duties and so on, I think we should have that discussion at the Committee of the Whole. That way everybody gets the opportunity to have the same information, the opportunity to ask some questions and then I guess make a decision before going to council. So I would like to send all of those items to the Committee of the Whole and we can have a meeting and have an open and honest discussion about moving forward. Thank you for that motion. Alderman Hammond? I second it. Okay, we have a second. Under discussion, Alderman Hammond. Thank you, Mr. Mayor. I move to divide the question. I'd like to take 3.4 or 6.1 for a separate vote. Second. Okay, the first motion then will be on 6.1. Okay, hold on just a second. Just hold a second. David, who seconded your motion? Alderman Born? And that was to refer to the four? Yes. Well, under discussion, Alderman Born. This is on 6.1. Yes, thank you. What was your reason for dividing the question, Alderman Hammond? Go ahead, Alderman Hammond. Thank you, Mr. Mayor. This was taken up in salaries and grievances and was discussed there. I completely have no problem with 6.3 by Alderman Coth wanting to double the salary of the older persons, the job description, and going to the reduction of the council, all going to committee of the whole. Those are committee of the whole kinds of discussions. But the extension of a contract, in my opinion, is kind of mutually exclusive. If we change the job description, and Chief Amorio is in that position, that just has to deal with the change of the job description. The committee agreed 4-1, that they wanted to extend the contract. And so again, I think these two things are mutually exclusive. And unless somebody can give me a compelling reason from a job performance standpoint, that we should take that up in closed session at the committee of the whole, I don't know why we would not approve the contract as the committee recommended. Thank you. Thank you, Alderman Born. Thank you, Mayor. That was kind of my thinking. If this was going to go to the committee of the whole, I brought up, and I would agree, probably it should be in closed session. But one of the reasons why I thought that this document 6.1 should have had further discussion had nothing to do with the person that's in the job. My idea was to find out from the council, and that's why I think it's a good idea to go to the committee of the whole, whether the position that was created four years ago has met the expectations of the council. And that was another reason why I came up with some suggestions for the job description. And if this was going to go to the committee of the whole, I would agree it probably should go into closed session so that the council can be made privy to any evaluations of the current Chief Administrative Officer so that the council could be made privy to that. Anything that we could be made aware of as far as the performance evaluations that I take it for granted that those have taken place the last three or four years. So I just think that five people voting on this at the committee level, when this is something that's very, very important for the city, basically there was very little discussion at the Salary and Grievance Committee other than Mr. Amodio saying he was interested in staying another year. This is probably the most important reappointment or new appointment that we're gonna be making. And I agree with Alderman Van Ackerman is that I think the full council should be privy to any performance evaluations in closed session and any suggestions that we should have that the council may have before we go in carte blanche, give another year extension. Thank you. Thanks for those comments. Alderman Hammond. Thank you, Mr. Mayor. And first off, as I mentioned to people quite often is that our committee meetings are certainly open to everybody this has been on the agenda. It lied over on the agenda. People could have came to the Salaries and Grievances committee meeting and expressed their opinion or had the conversation. As far as whether or not the position's going to change, unless there's a document in here I haven't seen about removing the position of the Chief Administrative Officer, all I've seen is changing the job descriptions and the preliminary scene was more so things like who does the evaluations and a few tweaks around the edges of input and various things like that. So I haven't seen a wholesale change in how this position, whether it's going to exist or not. So again, I don't know that these things are attached to each other. Whether or not Director Amodio or Chief Amodio stays is more of a performance issue than whether or not we're going to keep. Now if there's a document in here that I'm not aware of that says, hey, we're looking at getting rid of the Chief Administrator Officer's position. Then yeah, we should maybe table that and go to Committee of the Whole and have that conversation. But there's nothing in here that indicates that. So again, I think these two things are mutually exclusive. The Salaries and Agreements Committee discussed it and voted for one. So I won't be supporting. Thank you for those comments. And then Alderman, then Akron. Thank you, Mr. Mayor. I guess my motives are simply that the current term is set to explainer in 2015. That's how it was originally set up. I think it's a good time if we're gonna be talking about the Chief Administrator position anyways, impossible amendments. I do agree that with Alderman Hammond that I think those things are exclusive. However, if we are gonna have a conversation about it at the Committee of the Whole, then we should talk about the position itself, not any one individual, not a personality, but the position itself, what we expect out of it, where we want to go from here. So I do think it's a good opportunity. We've had a Chief Administrator for four years. I think we should have a discussion as to, again, where we've been and where we should be going. Thank you for those comments. Alderman Carlson. Thank you, Mayor. I guess I'll just take what you said in regards to keeping the personality out of it. That's exactly why this document should not go to Committee of the Whole. At Committee of the Whole, we can talk about the position going forward. However, right now all we're doing is simply voting on extending his contract for a year. It was voted on four to one. They could have had that, or they could have had any conversation they wanted to have in salaries and grievances. But for some reason, that didn't happen. For whatever reason, however, once again, this document should not go to Committee of the Whole because, as it's already been said, it's mutually exclusive. It's simply a one-year extension to the current contract that's in place. If we happen to make any changes in the job description in the Committee of the Whole meeting, then the person sitting in that chair is just gonna have to accept it. Thank you for those comments. Seeing no other discussion, would the clerk please call the roll on the motion to approve item 6.1 going to the Committee of the Whole? No, first of all, we have to vote on division of the question. I'm just accepting that we're dividing it. I don't think we need a vote on it. And the discussion has all been on 6.1. So if there's no other discussion, I'd just like to call for a vote on 6.1 going to the original Committee, which would be rather to lie over. And so if you wanna send 6.1 to the Committee of the Whole, you'd vote yes. And if you wanted to continue to lie over, you'd vote no. Is there any other discussion? Okay, then the clerk will call the roll. Docks is asking you to roll. Do you want yes or no? No. Six sides, 10 noes, the motion fails. Okay, so 6.1 will continue to go to rather to lie over. And then we have the original motion is to refer 3.4, 6.3, and 8.1 to the Committee of the Whole. That motion is before us. Is there any further discussion? Yes, Alderman Hammond? Thank you. Just a point of clarification. 8.1 is the motion to adjourn. Oh, I'm sorry. And we can defer that to Committee of the Whole. I'm okay with that, but. No, I'm sorry, but 9.1 is the motion to adjourn. 8.1 is the NRC for salary and grievances. I have the wrong one then. Thanks, Sue. My apologies, we're on the wrong agenda. Okay, is there any discussion on the remaining referrals? Okay, will the clerk please call the roll on the referrals? If you wanted to go to the Committee of the Whole, you'd vote yes. And if you wanted to stay to the original designations, you'd vote no. That's not the right question. That's not the right question. The JCs. Oh, no, this is JCs. Oh, is that the wrong one? Yes, we did. What's that? What was it? Yeah, but I thought it was referred to. Yeah, it's another box. Referred to three documents, 3.4, 6.3, 8.1. Mike, do you have yours? Got it. 12 ayes, two noes. Okay, those three documents then will be referred to the Committee of the Whole. So now we're back to reports of officers and the remaining items that we didn't talk about will be referred to the various committees. Under section four resolutions, 4.1 will lie over and 4.2 through 4.6 will again be referred to various committees under reports of officers. 5.1 is an RC by law and licensing to whom was referred, RO number 126 of 1415, submitting various licenses and recommends that beverage operators license application number 6733 be denied based on her failure to accurate reveal all relevant convictions on her application, her record of violations related to the license activity and her record as a repeat law offender and her failure to cooperate with the committee. Alderman Vanderweel. Thank you, I move that the RC be accepted and adopted. Second. Under discussion. This is Diana Ramminger here this evening. She is not, we invited her two different occasions and she did not appear. Thank you, is there any other discussion? Will the clerk please call the roll for passage? It worked. This is really hearing no, so it worked. Get in power. 16 ayes. Motion passes. Item 5.2 is an RC by law and licensing to whom was referred, RO number 163 of 1415, submitting various licenses and recommends that beverage operator license number 0537 be denied based upon her failure to accurate reveal all relevant convictions on her application, her record of violations related to the license activity and her failure to cooperate with the committee. Alderman Vanderweel. Thank you, I move that the RC be accepted and adopted. Thank you for that motion and support. Under discussion. Is Amanda Drews here? She is not, we invited her back to her committee after we held this matter and she did not show up. Thank you. Any other discussion? If not, will the clerk please call the roll for passage? 16 ayes. Motion passes. Item 5.3 is an RC by law and licensing to whom was referred, RO number 138 of 1415, submitting various license applications and recommends that beverage operator license application number 8464 be denied based on her failure to accurate reveal all relevant convictions on her application, her record of violations related to the license activity and her record as a repeat law offender. Alderman Vanderweel. Thank you, I move that the RC be accepted and adopted. Second. Under discussion. Is Tracy Hickard here this evening? She's not, the committee voted 4-0 with one abstention to deny the license. Thank you. Any other discussion? Seeing none, will the clerk please call the roll for passage? 16 ayes. Motion passes. 6.1 will lie over. 6.2 through 6.5 will be referred to various committees with the exception of 6.3, which is going to the committee of the hall. Under matters laid over. Item 7.1 is general ordinance number 32 of 1415 by Alderman Donahue, Dastler, Boren, Hammond and Vanderweel amending the municipal code as to add a part-time clerk in the building inspection divisions slash city planning department. Alderman Donahue. Thank you, Mayor, I would move approval. Is there a second? Second. We have motion and support. Is there any discussion on the motion? Seeing none, will the clerk please call the roll for passage? 16 ayes. Motion passes. Number eight, other matters. That's going to be referred to the committee of the whole and under 9.1, Alderman Hammond. The same agenda I did. Under other matters, city attorney. Thank you, your honor. RO, by the city clerk, this is document 9.1, submitting various license applications for the period ending December 31, 2014, December 31, 2015 and June 30, 2016. She had to be referred to law and licensing. 9.2 is an RO by the city clerk submitting communication from Alexis Torres requesting a waiver from the sex offender residency restrictions in order to live at 1127 North 8th Street. Referred to public protection and safety. 9.3 is an RO by the city clerk submitting a communication from Alexis Torres requesting a waiver from the sex offender residency restrictions in order to live at 930A Michigan Avenue or 1123, 1125 North 14th Street, depending upon availability. That would be referred to public protection and safety. 9.4 is a claim from Renee Gallegos for alleged damages to his vehicle when a tree in Evergreen Park fell on his SUV. That'll be referred to the finance committee. Now, Alderman Hammond. Thank you, Mr. Mayor. I move to adjourn. Second. Thank you for that motion. The clerk calls all those in favor. Signify by saying aye. Aye. Opposed? We stand adjourned. Thank you very much.


So I'll just get started. Like Colin said, they started the architecture group. And some of my friends who were starting that group reached out and said, hey, would you like to do a talk? And I said, no. And then I thought, well, I always say that. So maybe I'll do it this time. And here I am. So this talk is about, like Colin said, taking the solid principles. It is not about object-oriented design. That's what solid is about. That's what there are many, many great lectures from really smart people online. Dr. Bob Martin is the founder of that ideology. This is about cloud architectures. And as I was going through the slides last night, I thought this really isn't even an architecture talk. This is a DevOps talk. But the good news is one way to have solid architecture is to have a solid understanding of how all the pieces are coming together. That's in large part, at least in my opinion, what DevOps is about. So you're wondering about the pony. When I googled solid clouds to see if anybody else was talking about this, this was the only hit in Google. So that's what it's really about. Just a quick disclaimer, my opinions are mine. Not my employers. My employer has lots of great opinions. I work at Petuam. We're hiring. On most of the slides, you will see a QR code.  There's something interesting there, Easter eggs. This one is the link to get a job at Petuam. Then you can ask McGresh. It's a great place to work. So I'm going to go through a couple of background slides just to cover the basics. This slide is from a talk by Sam Newman about microservice architecture. Again, a great read if you click through to that. These slides will be posted later. I'll link it in the architecture group on the Slack channel. So the general idea, there are a lot of different principles that Sam talks about going into the design of a good microservice architecture. But one of the things that I noticed in here that is very similar to what I'm going to be talking about is the idea of isolation, the idea of independence, the idea of keeping things simple. Another thing to keep in mind, at least what I'm talking about cloud architectures is Kubernetes, because that's the box that I live in most days. Kubernetes is a fabric for deploying microservices, really for deploying things in containers on a cloud, sorry, on a cloud architecture, on a cloud. So Heroku put together these 12 factors as best practices for building applications on their platform. And since the talk is really about building solid cloud applications, why isn't it a 12 factor talk? Because there's a lot of 12 factor talks. Because I'm lazy and remembering five things is a lot easier than remembering 12. And most of all, because talking about solid clouds gives me an excuse to use the ponygif. And the last background slide is what we're here to talk about, except not object-oriented design. Just quickly buzz through them, and then we're going to go through a lot more detail in the next 30 or 40 slides. So the first one, single responsibility principle is, I think of it as the rule of one. It's about keeping it simple, keeping it isolated. The open-closed principle is, the tagline for that is change is bad. Lisk-off substitution is really just a reasonable expectation of types. Interface segregation principle is the rule of small. And dependency inversion is about decoupling, which some concepts to keep in mind as we're going through this. So the first responsibility is, like I said, it's the rule of one, the idea being that it should only change when the requirements change. And if you have, if your thing only has one reason for being, one concept, if it's isolated, then the reasons for which you may have to change it, the reasons for which it will break, the reasons for which were bugs will be introduced, becomes a lot smaller. And with a smaller bucket, you have fewer bugs. You have a single point of truth. When you package your thing together, it's in a single package, whether it's a tarball or a helm package or a dead file. But there is a way to package it that gets all the miscellaneous parts, where they belong, the way that they belong. You don't want to check out a Git repo and try and build it on your production servers. That will work a bunch of times, and then it won't in a really bad way. So taking a look at the single responsibility principle as it applies to DevOps, just some ideas to take away. When we talk about it in object-oriented design, we're thinking about one class. That function has one purpose. There's a single path of execution. But when we expand these concepts out and we start talking about how they apply to our cloud design or to our DevOps principles, some of the things you can think about is, I'm going to have one Git repo for a thing, whether it's a DLL or a jar file or it's the content side of your website. But you've got these things isolated in a single code base that builds into a single releaseable thing, one package. And each one of those things has an explicit version or tag per release so that you always know which one of that thing isn't. One action per build job. So you've got your build script, and it's very easy to understand. Where did this fail? You can see which balloon turned red, which line has the big fatal on it. It's much easier to trace in and figure out where you made your mistake and turn it around. And that's a big part of keeping that idea of single responsibility is, if there's only a single responsibility, if there's only a single behavior for the thing, then there's only ideally one way that it's going to break. And it becomes much simpler to diagnose, fix, and move on so you don't get locked up. And then just keep going, one source for trusted artifacts, a single configuration template. But maybe that configuration template breaks out into multiple value sets, one for dev, one for production, one for my desktop, one for yours. Another way that you can look at single responsibility applying to beyond just the code base, single testability. So each thing should be testable. Each of those tests should have a single path of execution for a single assertion to the test. And just the simple quality of is it testable? Is there something that I can identify about this thing I built that I can describe in terms of a test? So moving on to the O of solid, open for extension, closed for modification, there's, when I stumble across this notion of it, this is the definition right there. It's a LEGO brick. They are infinitely composable, but you're not going to take it apart. This is only going to have eight bumps on the top. It's only going to have eight sockets on the bottom with those three little holes if you're feeling kind of crazy. But it doesn't change. But you can do myriad things with it. The take away from the tagline for OCP principle of extension closed for modification is that you want to resist change. So this LEGO brick is not going to change. And by the way, that's not a LEGO brick. It's somebody's CAD drawing that was in free images online. Because all the LEGO stuff is copyrighted. But it's not going to change. You're not going to mutate it. You're not going to modify its behavior. But how you use it, it's a brick. It's a car. It's a leg. It's a foot. It's a hat. It's all about context. So when we take that open, closed principle out to the cloud, one of the ways that really seems pretty clear to me when I think about it is how my code behaves depending on the configuration set that I give it. So when I build my code into containers, 12th Factor talks about storing the config in the environment as one of the 12 factors. And so when I think about that in Kubernetes, I'm isolating my secrets. So my secrets are deployed as a thing in my Kubernetes environment in a particular namespace or generally across all the namespaces. And they are separate from the code itself, which means, so that's the way that OCP begins to affect the overall security of my platform. I don't know if any of you have ever looked in a Git repo or in other source control and seen passwords or certificates. So it's not where you want to be. So in the environment, it's not in the source code? Not in the source code. Well, so 12th Factor means specifically, they stay specifically in the environment. But I would generalize it a lot more to just say, it's in its own place. It's separate from. So there are secrets, and you have a way to get secrets in. And it's only about getting back to single responsibility. Because all of these principles, no one of them is terribly useful if you try to religiously follow a particular one. It might make your code better, but it might also, you end up kind of lost. They all go together. They all feed into one another to build a more solid application architecture. So in Kubernetes, I'll take those secrets out of the code, but I'll also inherit a lot of environment from my namespace, from the cloud room deploying. If I'm in AWS, there are certain variables that are going to be injected into my runtime. There are, and then within my Kubernetes deployment, there are additional environment variables that will be set, and all of those will filter in. And if I build my containers so that they're reading in a lot of that information just from the environment, then there's those nested contexts begin to change the behavior of what I'm deploying. How many replicas do I get? What subdomain are they looking up other services on? Permissions, storage, backends, et cetera. So then an additional, so then you can, so one of the things I get with Kubernetes is, so I've packaged my code in one thing and I've got configuration and I've got my container and now I need a way to pull all that together. Helm is a tool that I use to pull all those things together. It gives me a way to, I can still very explicitly declare this is the value set for this particular installation. I can also have another value set that's built into the Helm package and then yet another value set that's built into the spec for that pod, for that Kubernetes app. And just each of those abstractions, each of those layers is defining just that single behavior, but then as they all fold together, they begin to affect the behavior of the overall system. So a little rant that I've been playing on my head against lately is, is anybody familiar with Docker latest?  Yeah, that's because it's a tag. And this thing is it. So a lot of what I'm trying to talk about is the right way to do it, but this is a case where Docker kind of blew it. They've got another thing called labels. Labels on the other hand are immutable. When I create a new container, when I do Docker build, I can specify label, get hash, I can specify a label for the architecture, I can specify a label for my birthday, just in case you guys wanna keep track of it, I can specify a label for anything. And those are fixed in the container image. Unfortunately, the only way I can see them is by running Docker Inspect and parsing that JSON out and extracting those values. So they've got the feature that you need to be able to get the thing that you need, except it's hidden behind tags, which everybody changes tags and the Docker pull mechanism doesn't really quite work. In Kubernetes, they addressed it somewhat with pull policies. So I can have a pull policy on my pod, which is my collection of one or more Docker containers that says always pull, sometimes pull, pull weekly, but that's a case of a leaky abstraction. So we've got the responsibility for which instance of this thing, is this container, is really on the container, it's on the Docker framework. The fact that Kubernetes had to build something into the pod spec to kind of force that override that broken behavior. It's just a demonstration of how it kept broken. And now that that's a normal thing in Kubernetes, it makes it even more confusing when I try to run my containers in a CI test, because it works great in the Kubernetes cluster, but now it doesn't work great when I run it in a Docker compose or a swarm. Barbara Liskov, she's the one that gave us Liskov substitution, all of the other letters in this are actual descriptive names, acronyms are hard, naming stuff is hard, finding something that started with L that fit in this that made sense, it was apparently also hard, but Barbara Liskov wrote a very complicated explanation of is a versus has a relationships. And Liskov substitution is talking about is a relationship, meaning that if there is a thing and it exhibits an interface, that all things that exhibit that interface will behave the same way. So in a cloud or Microsoft architecture, it points to I've got containers that are no JS servers. So I can reasonably expect that they're all going to have a service port that's going to serve up some form of HTTP interface. But it also extends to how a team or an organization or an industry segment will converge on certain expectations, like logging to standard out. So we assume that all of our things now in the cloud are logging to standard out, so that all we need to do is scrape standard out most of our frameworks do that and pipe it off to a place where we can aggregate our logs and have some clue about what went wrong, when things go wrong. Pull metrics versus trying to push them out, abstracting security and permissions away from the actual implementations of the things. So another one way to look at how Liskov substitution applies in some of the 12 factors, these are the two 12 factor definitions port binding that like I said with the no JS server that I can always expect that there's going to be a port and that even though outside the container it's bound to port 8080 inside the container or vice versa inside the container it's bound to 8080 outside the container it's bound to anything. That means it makes it very easy for me to scale out 30 of those and all of those ports whether they're on one host or many hosts will map to a reasonable port within the container. They have prod parity meaning that as a developer I have a reasonable, when I push things into my development environment I have a reasonable expectation that it behaved well there it's going to behave well in production. Obviously I'm not going to be running to the scale or the load that I do in production but I should have similar deployment mechanisms. I should have, if I'm deploying to Kubernetes in production I shouldn't be running it in mesos on my desktop. But really, that was all kind of boring. I recently ran across a tweet which is this code about garage doors in HTTP. Has anybody still come across that story? This guy, actually I'm going to click on it. So this guy. So HTTP get, right? You get this page, you keep getting this page. I've gotten this page several times today. And it always comes up the same way and nothing else happens. Yeah, so this guy, it's a relay. It's hooked up to a push button on the garage door because it doesn't work. So he hooked up this thing so that he could open and close a garage door from his laptop except it's a get request. So every time he hit that URL, this garage door opens, this garage door closes. So that's an example of Liskoff not done right. And that's what happens. You get a garage door that's going to be here. So the I in a solid, obviously nervous as I'm racing through these. So if you guys have questions, comments, catch me making something up, feel free to give a shout. The, so the I in interface segregation is, like I said, it's the rule of the small. The idea being that each one of these things can stand alone. But even more so to abstract it out a little bit away from just that object already, that code mentality. So thinking about it in terms of what is the minimum useful bit of functionality that can be defined in that particular context. And this is where the interface comes in. Where does that context overlap with something else? So my interface isn't what my thing does. My interface is where it touches something else. It's how am I implementing HTTP handlers? How, how do my routes map in my app? How, how am I accessing back end storage? How am I getting my code to the different environments? Those are all the interfaces, the places where the things intersect. And when you start thinking about how are those isolated? And again, so interface segregation couples very, very well, at least in my mind, with that single responsibility principle in that I don't want my interfaces to overlap. If there is a way to do something from here to get from here to there, I want there to be one path. I want it to be a clear path. Now you can stick in, then you apply something on this golf and that one path, there are many ways to actually get there but they're all taking the same path through that same interface. They all exhibit that same behavior. Again, making it easier to understand your system, easier to compose your system. And even more, I skipped past it on the open close slide but one of the big things that I've seen that makes a lot of products, architecture solutions wildly successful, is when people figure out how to do things that you didn't anticipate and that's composability. If you give them the ability to make something that you never imagined with what you built, they're going to do that eventually. And that's often an ingredient in wild success referencing back to that Lego brick. So thinking about interface segregation in terms of 12 factor, a couple of the things they talk about, administrative processes that every one of your administrative tasks is an isolated one off thing. It's separate from your application code. It's outside of your deployment logic. Similarly, your processes. They're also isolated, excuse the app, is one of more stateless processes. That also is an important thing to think about when you're building your Docker containers. A popular Docker anti-pattern is the container as a virtual machine where you've got startup scripts that are triggered from an ITD and they're starting some background processes and you've got some other things going on. You want one PID per container, one process. A container is literally a wrapper around a Linux process. So this guy, why is he here? In Kubernetes, a lot of teams deploy what I've read called a bastion node, which is it's outside the cluster. And this is a way that you can separate some of those administrative processes. So one of the things that I've seen those bastion nodes used for is an SSH proxy, is as an SSH proxy. So I've got my Kubernetes cluster out there in AWS and I don't want to make any public routes available to that control plane because if you get that vulnerability and you start mining Bitcoin on there, my AWS fees are gonna go through the roof. So one of the things to do is don't open anything. You can't SSH to my master, you can't SSH to my nodes. There's a box out there that if you know the credentials for the next hop that you can SSH proxy through, but then you've gotta get two different vulnerabilities. So that's a purposeful isolation for security. Another way that those bastion nodes are used is setting up some kind of a gateway server and that's doing your authentication. That's pushing users to come in, they hit that really quickly. That box is tuned very well to do the credential auth or whatever auth you're using and to authenticate the users and then it passes them on in your application, gets into, okay, I know that this person is who they say they are. Now you can start to do the authorization to see what they're allowed to do and you use the tools that are built into your platform and the Kubernetes to authorize that role. Another huge way that interface segregation has personally saved me a great deal of time and I think it's a really important thing to think about when you're designing your applications is observability. So if each of this, my request comes in, it hits one container that parses it out, determines what the intended action is, then it gets routed to another container that decorates something or triggers a side job, jumps it into a queue, another thing starts a worker. It bounces through all of these things in a matter of a couple seconds. I got a couple thousand of those hitting my cluster every minute. It becomes very difficult to understand where did it go wrong if when I'm logging I'm not expressing an identity for each one of those interfaces that's being hit. I'm not the correlation ID. So there's an ID for the request, there's an ID for each of the nodes, there's an ID for the version, there's an ID for the host where it's running, all of that information gets logged and then suddenly your logs become a really valuable tool and a really powerful tool for diagnosing what happened. And it gets into, so on one hand it's about separating those interfaces, those isolating them, on another hand it's about making sure that each thing has a distinct responsibility so that I know when I see container food got hit. I know that somebody was trying to get some food. Moving on. So the D, made all the way through. Fendancy inversion principle. And I just copied the, I was getting tired when I put this one together and I got to the last slide. So I just copied the definition. High-level modules should not depend on low-level modules. Both should depend on abstractions. Abstractions need not depend on details. Details should depend on abstractions. And that's what I hope that I've touched on this a little bit as we've gotten to get this far. But it's about separating those things but it's what happens when we separate those things. So when I take that configuration data out of my container. So let's say I've got an init container and that, or I've got a container. And it knows how to get things from Amazon S3 and copy them over to storage. When I configure that, when I test that out on my desktop, I run that Docker. I mount the volume to a local directory. I set some credentials in the environment. It goes out, gets stuff, ooh, that worked. I push it up to CI, it does the same thing except it pipes that off to another filter that makes sure that the file content is correctly. It runs through a hash, it checks the SHA awesome. Okay, great, I actually got the file that I expected to get, moves on. I deploy that in my cluster. Now it gets configured with a map to a persistent volume from Kubernetes that's either mapped to that node host or maybe it's mapped to some kind of a shared file system that all of these nodes are using and I configure it to be an init container. So it comes up and dies before the actual application starts. So now this thing comes up, but I deployed seven of them. They come up and I also told them to communicate, to broadcast over a local channel what they were getting to make sure that if somebody else is getting that, they don't duplicate it. Now all five of my clusters come up, they'll go out, they grab different channels on all that data, they pull it down really fast, they start up, it always comes up. If only three of them start up immediately and two of them are lagging because they couldn't get resources, that's okay. Those two will come up and they'll say, oh, the files are there, I don't do anything. Exit, everybody comes up, the data's still there. So you change the behavior by getting those details out of the implementation. The implementation still stays really simple. Copy stuff. But then as you apply those layers, those configuration details, and you extract them out into, through the different, I talked about how the Helm modules give me some control over it. And the Kubernetes spec gives me some control over it. And my cloud provider gives me some control over it. All of those things. Just check my notes and see if I actually talk about what I said. And one last rant.   These people databases do not belong in the cloud. They are the antithesis of stateless. Their whole reason for purpose is to store state. Except sometimes you need them and sometimes they're really easy. So you build abstractions around them to make them work. Use a stateful set to make sure that when that thing goes down, it always comes back up on the same host. So that where your database still has quick access to a local drive, it's not trying to read and write from over NFS and struggling. Yeah, so think simple. Right, so one of the other challenges you have with databases is it's not as simple as bumping your replication number from two to three because all of your clients are not necessarily gonna map to the right thing. But you can build abstractions around that to make it work. So then suddenly you've got six copies of Postgres running in your cloud.  You're staying reasonably in sync, but you didn't have to do a monolithic replication back end behind it. Simply by building those abstractions around it. In my opinion, the better answer is, don't use a SQL database. Use something else, abstract out your storage. So the frequency with which you actually need to have all of your data in a single table is not very high. Occasionally you'll need that. Maybe you're doing some kind of analytics. But even then, most frameworks that you're gonna be using don't want it as a cursor. They want it as a CSV, as a text file, as a bunch of objects in a queue. So you're gonna end up abstracting it anyway to get it into the analytics framework that you're gonna be using. Right, so some of the mitigations that you'll end up applying if you do wanna use that relational database in your cloud application. So another way to think about it, getting back to the DevOps cycle, is when I build my thing, I'm gonna have dependencies. And I want to explicitly declare that I know this works for that version and that version and that version of my dependencies. Getting back to the latest tag. I don't want to say that I'm using whatever the newest thing is. In your gem file, you generally wanna say that you're gonna bound it at version one, but not greater than one. Or you might say 109 if you know that this is the only one that works and I'm not trusting anything else. So dependency version across configuration management and quality, if the API is able to express and abstract the relationship with its dependencies specifically, then deploying that thing with confidence becomes more reasonable because you know exactly what you're gonna be deploying with. And then you're gonna want the abstractions around that. That's what Docker gives you. That's what your cloud is gonna give you by segmenting your cloud and having those dependencies where you expect them to be in the underlying layers in the base containers as you build the new versions and build on top of those building blocks, you inherit the behavior that you expect. So that's the end. I copied a lot of images from the internet. This is where I got them from. That's the end. So be the pony. So any questions, comments, suggestions? I would love to hear them. Rdms, I guess, where do you prefer to store it? NoSQL is some variation of NoSQL depending on what the application is and what the usage is. Sometimes don't store the state. Sometimes the state is, it comes in, it goes through transitions, it comes back out. There might be static content. There might be dynamic content that's delivered. And maybe behind that content is an Rdms. Maybe there's just a traditional web app that's serving up that content. But when I think about applications where I've got a lot of microservices that are working together, I want that storage. I want that unit to be well abstracted away from the rest of my cloud. So wrapping the database of service, is that more in your... That's a mitigation that you... But it's pushing it up to kind of a blockier level of interaction, chunkier, chunking-sized data. Rather than, you know, do this right to the street, do this right to the street. You're like, I'm gonna work with this thing that data sets. Right, so it's, yeah. Here's my updates should be met. And the more abstractions you can put around that, the better off you are. And then one of the things that you'll find after you start building out those abstractions is, oh wow, I don't need the database. I can just drop these messages in a durable queue. Because I don't need them to be around forever. Or maybe I do need them to be around forever. In which case, I'm gonna have something pulling on that durable queue and serializing them off to a no SQL storage or something. Replicates. It's designed. Left or a lot better. It's designed for cloud applications. Databases grew up in an era of big client-server computing where it was reasonable for me to order another $40,000 computer when I needed to expand. Yeah, but it's just that generally for a microservice architecture, it's you can get that. Right, and that's what I was saying is, as you build the abstractions around, you're already gonna ask to make it work well in a cloud solution, in a microservice solution. You're gonna find, oh wow, instead of an already been asked behind this, I could just use something that's a lot simpler and cheaper to deploy. What about like the hosted options, the one we got like with the RDS or something, basically they manage it for you and they handle all of that. They've built an API around it and they deal with all the headaches for you. There are ceiling ones. That works, yeah. And I've seen it work well and I've seen it hurt. And that's true for any of these things. I mean, there's no perfect answers. There's no right and wrong. These are just concepts to think about. And that's really what I wanted to get across with this, is as you're designing, as you're building, ask these questions.  I need to get this out the door this week. It's going out this way. I'm breaking the rules and sending it because you need to get it done and it's good enough. So yeah, it's basically it's about fostering your different patterns a less fine grade approach to the data and persistence. In this particular, yeah, on that slide, yeah. Oh, yeah, I'm doing better on this slide. Yeah. I've heard of Helm, but I don't know anything really about it. Could you maybe just talk it maybe at a high level what Helm is and for what it does for you? Sure. Helm uses Go template. So do you know how you deploy? So the way you deploy a Kubernetes application or pod is you write out this YAML file. And Helm uses Go templates. It's a templating library built into the Go language to mock those out. So you can rough out your YAML file for your deployment as a template and stick into little variables. You've got looping up operations and you've got different mutations that you can apply to the strings that are, and you feed it a dictionary of values. I don't know, it's not my code. I can't make sure. And so what Helm gives you the ability to do is I can then describe the container, the actual Docker instances that I want to use, and I can describe the configuration for my deployment, how big the replication set is. And then within that dictionary, I can have fields for, I could say replicas, colon, and then underneath of that instead of just four, I can have dev staging production developer and four, two, eight, 36, depending on what environment I'm deploying to. And then when I say Helm install, I say dash ENV equals whatever, and Helm uses my Kubernetes credentials to push that out. It reads some information from the Kube config, it reads some information when it starts talking to its counterpart, Tiller, in the Kubernetes cluster, and actually fills out the rest of those templates and then applies those specs to the cluster to create whatever you're trying to create. It's a great tool. It's like a Mica later in about two minutes. It's an installer package, really. It's just a way to describe how to install something and then bundle it together neatly into a tar ball. And it has reasonable install semantics, install, remove, scale, anybody else? Well, thank you all very much for coming out. I hope it was useful. If it wasn't, like I said, there's some great Easter eggs in there. You can hear more intelligent people talk about these topics.


Leaders, the United States Marine Corps was formed in 1775. Two centuries later, Ronald Reagan said, some people spend an entire lifetime wondering if they made a difference in the world, but the Marines don't have that problem. More recently, author and executive Nate Fick wrote that hardness was the supreme virtue among recon Marines. The greatest compliment one could pay to one other was to say he was hard. Hardness wasn't toughness, nor was it courage, although both were part of it. Hardness was the ability to face an overwhelming situation with aplomb, smile calmly at it, and then triumph through sheer professional pride. For 244 years, Marine hardness ensured and continues to ensure that each and every Marine knowingly makes a difference in the world. Happy birthday Marines. Lead well this week.