The final item of business is members business debate on motion 13551 in the name of Stuart McMillan on Texas instruments and the debate will be concluded without any questions being put. May I ask those who wish to speak in the debate to press request to speak buttons and I call on Stuart McMillan to open the debate. Thank you very much. First of all, I would like to thank every member who has signed the motion to allow this debate to take place. I would also like to thank the team for allocating me the time. I want to begin with a short history of where we are regarding the Texas instrument situation before exploring other aspects around the business and also inverclyde. In January 2017-16, TI announced that they were to close the ground plant with a loss of over 300 jobs. That came as a blow to my area, one that really hasn't been without its economic challenges over many, many years since the decline of the majority of the shipyards, heavy engineering, sugar and, also in recent times, a huge reduction in the IT sector. The local site manufactures semiconductors but they also had a design centre. The 25 posts in the design centre were made redundant in April and May 2016. The population of Inverclyde is robust and we have had to be as the TI announcement followed a trend of other industries in the past. The vast majority of those TI jobs are technical, highly skilled and the financial contribution to local economy is vast. Those workers deliver results and the Greenock facility is productive. TI took the decision purely for business reasons. The Greenock site is one of the smallest in its portfolio. It therefore wished to consolidate its business by closing the Greenock site and transferring the work to the USA, Japan and also to Germany. TI is the second-biggest manufacturer of semiconductors in the world, so it has that scale and the size to make that type of decision. I am grateful, however, that TI provided a long lead-in time before the closure takes place. TI extended the closure date to 2019, which has provided additional valuable time to try to find a buyer. The Texas Instruments Task Force was established by Inverclyde Council and it consists of councillors, parliamentarians, Scottish Government ministers, Scottish Office representatives, public agency representatives and the site director of Texas Instruments. It is a genuine team-inverclyde approach. The primary goal of the TI Task Force was and still is to find a buyer to maintain the site. If that proved unachievable, the task force would focus its efforts on providing the best possible outcomes for the workforce and the local community. Government agency staff have visited the plant to talk to the workforce to make them aware of the services that are available to them and I would like to thank TI for their co-operation in that regard. TI contracted Atrag to help to sell the site and, despite some companies coming forward, they unfortunately amounted to nothing. Earlier this year, the joint statement by Inverclyde councillor Stephen McCabe and Paul Wealhouse MSP, the then Minister for Business, indicated the past efforts and dialogue with potential buyers and that one was still on the table. We have been informed that discussions are continuing, which I am sure everyone with a stake in the outcome for the workforce and also the local economy welcomes. I believe that the TI Task Force has provided a forum to discuss the challenges and any possible obstacles facing a successful outcome for the plant and also the excellent workforce. I want to put on record two things. Firstly, my thanks to everyone on the task force for the collegiate manner in which everyone has worked. Secondly, but most importantly, to the workforce. With the threat of redundancy hanging over their heads, they continue to perform, deliver and contribute to the highest possible standards. They are the consummate professionals and when TI leave the area, their loss will be the gain of someone else, whether it is in this industry or in some other industry. This summary of hope helps Parliament to appreciate the efforts that have been in their way but also the efforts that continue. As I said at the beginning, the 300-plus workforce and what they contribute to my area is hugely important. They have transferable skills and if that became a necessity but maintaining their quality of life by living and working in Inverclyde, it is important for them but also for our area. I am in absolutely no doubt that anything and everything that can be done is being done and I do not doubt that for one minute. My message to Texas Instruments, to any potential buyer, to the Scottish Government, its agencies and also to Inverclyde Council is very simple. Do not leave any stone unturned to get a deal. The TI will be able to leave the area knowing that a positive legacy is the outcome and the TI will be aware that there has not always been in that case locally, so it can show that it is trying to be irresponsible. Any potential buyer will be getting a first-class, dedicated and highly motivated workforce. The fact that the workforce has done this daily for years and this has continued after the closure announcement proves that they are a credit. If they can still deliver under the stresses that they are feeling, just think of what they can do with job security. The Scottish Government will have an area that has not been hit with a major economic shock and income tax receipts will continue as compared to nothing. Inverclyde Council will not have to worry about an increased number of people leaving the area, adding to the historical population decline and thus the economic aftershock that will bring. It is in everyone's interests that a deal is done. Some of the challenges that we face include a population decline and the claimant count. Our population is down to just under 80,000, when once we had more than 110,000. The recent national records of Scotland population figures and projections highlight that stark message. Between 1997 and 2017, Inverclyde's population has decreased by 8.9 per cent, while Scotland's population increased by 6.7 per cent. During that period, the 25 to 34 age group has decreased by 28.6 per cent, while the 75-plus age group has increased by 20.9 per cent. Between 2016 and 2026, it is projected that Inverclyde's population will decrease by 3.8 per cent, while Scotland's population will increase by 3.2 per cent. Between 2016 and 2026, the 16 to 24 age group will decrease by 13.2 per cent, while the 75-plus group will increase by 20.8 per cent. Our claimant count rate-based on the recent ONS figures stands at 5.4 per cent. That is 2,670 people listed since September 2018. With most of the heavy industries gone, we have our challenges. However, there are many positives too. Shipbuilding remains in Port Glasgow with Fergus and Marine, thanks to the support of the Scottish Government and action that I am immensely proud of. We also have ship repair in Greenock at Dale's Marine services. We are the home of the national ferry company with CalMac and Gurwick. We are the recreation and marine capital of Scotland, with an increase in the level of marine-based activities, including over 60 cruise ships docking in Greenock this year. That number is expected to increase hugely next year, and the new George Welley museum will be incorporated into the new docking area for cruise ships. That will be part of the opening of one of the city deal projects. Those are just some of the many wonderful aspects and examples as to why Inverclyde should be a destination of choice and a location for investment. Inverclyde is my home. I grew up there. I live there, and I am immensely proud of my area. We, just like every other part of Scotland or elsewhere globally, have our challenges, but we also have our opportunities. We are no different from anywhere else. I do not want the workforce of TI to be added to the claimant count figures. I want them to continue to produce the high-quality, high-value products that they are doing. Doing that enhances my community, Inverclyde's economy and Inverclyde's reputation. The TI workforce has consistently delivered. It has perseverance and hope. I genuinely hope that we can give them the best Christmas present that they could ever wish for. That is the deal to secure their jobs for the long term. I move on to the open debate with speeches of around four minutes, please. Jamie Greene, followed by Neil Bibby. First of all, can I open by thanking Stuart McMillan for his impassioned speech and for using parliamentary time to bring this very important issue to the chamber? It is an excellent use of the limited time that Parliament has to discuss this very issue. It is such an important matter because, as Mr McMillan said, it greatly affects not just those who work on site but their families and the wider economy. I, like Stuart McMillan, grew up in Greenock and I am fully aware of the changes that the town has gone through in terms of some of the big employers who have come and gone over the years and the effect that that has on the town is substantial. Sadly, this is another one of those cases. Since the task force was set up in 2016, the concept was to bring together the council, the Government and some of the Government agencies, such as Scottish Enterprise and the site itself, as well as local politicians, to get around the table and have some frank and honest discussions about the situation there. There have been many meetings of the task force that I have tried to attend as many as I can, with the exception of a few diary clashes. I have always found those meetings to be very constructive and very open. I would like to pay tribute to the Texas Instrument task force chair, councillor Stephen McCabe, for the work and effort that he has put into it. I think that acceptance that, unless we were collegiate and sat around the table and worked together as politicians and as agencies, the task force would never achieve anything. I can say honestly that the task force has worked tirelessly to look at and explore all avenues right up until this point. To be fair to the Government, it has done the same. The agencies have participated in these meetings and they have sought to go out to the wider market, both in Scotland and overseas, to see what buyers might be out there. There have been so many instances in these meetings of expressions of interest. Do not get me wrong, some of those companies may have been tire kicking and looking for an opportunity for sight. Many have come and gone and it has been a disappointing thing that we have got to the stage where we are at at the moment. As I said, Grunach and Inverclyde in general has been a resilient and robust part of Scotland. If we look at some of the companies that have come and gone to a great extent, such as IBM and national semiconductors, the members of my family worked for decades right up until the retirement of those iconic industries. When they closed their doors, they left a legacy on the town. This will be another one of those. I share Mr McMillan's values on that. We do not want those people to be simply more statistics or simply to be joining the queue of benefits claimants. I think that we need to look at what is next. I think that there are only a few potential options. I think that this is really the last chance alone, as we call it, to find a buyer. As the motion says, we really should redouble all efforts to do so. I think that for those who want to use this opportunity to retire, they should be helped to do so and not judged for doing that. Many people have their reasons for that and understand those. However, there are many who wish to continue in employment, and that brings me on to another issue. That is that about what we do around retraining and re-employability. Just last Friday, I went to West College Scotland and Paisley. They have a campus in Greenout. It used to be the old James Walk College. Many people will know it. One of the conversations that I had with the new principal who has just recently taken up office was about how we can use further education facilities such as West College Scotland to help with adult retraining and re-employability. It really is an issue when people find themselves made redundant at a certain time of life, but too early to retire and still want to continue in the workplace. We are struggling to adapt after decades and one environment to the new digital industries that seem to be coming forward. We have to have a conversation about how we help many of those people to retrain practically and academically to get some of those new opportunities. I know that Pais is working with many people on site and will continue to do so, so I only hope that that will continue. In the short time that we have here in closing, it is a great site. I have really struggled to understand why no buyer has been forthcoming. I do hope that there is still an opportunity out there, but if there isn't, those people who want to continue in the workplace must be given all the support that every Government and every agency can provide them. As Stuart McMillan said, it is a great place to live and to work. I hope that, if the plant closes, we at least can see those people move forward in their careers and move into the next stage of their careers. I hope that all politicians, both at local level and in this chamber, will do everything that they can to assist them. I welcome tonight's debate, brought forward by Stuart McMillan. I support the motion that we debate tonight on Texas instruments, because it must be a priority for all of us to protect and create quality jobs in our communities. I would agree with Stuart McMillan on the importance of this plant to the Greenock community and to Inverclyde as a whole. It would be difficult to overstate its importance. In an age in which global competition has seen reliable, productive, high-value industrial jobs move elsewhere, the plant has continued to give skilled workers in Inverclyde the opportunity to sustain a valuable and profitable trade. Just as hundreds of people benefit from this highly skilled industrial work directly, still hundreds more are enjoyed in direct employment supported by the presence of Texas instruments. Thousands benefit from the injection of millions of pounds into the Inverclyde and West Scotland economy. In total, as has been estimated, the loss of this factory would mean a loss of 572 direct and indirect jobs and £32.2 million in GVA. As others have said, we cannot allow Texas instruments to withdraw from Inverclyde without a viable alternative coming forward. I also join other members in commending the work of the Texas Instruments Task Force that has worked hard to find such an alternative. By working together to find a way forward, the council-led task force with other agencies and the business community in the west of Scotland have exemplified how the public and private sectors can co-operate to promote economic interests of a community. I would like to commend everyone who is involved, particularly Councillor Stephen McCabe and his council officers, for the leadership that they have shown, but also for the workforce for the commitment and resilience that they have shown in the face of adversity. The truth, Presiding Officers, is that the story of this factory is not just another story of the stark realities of global competition. The potential loss of these highly skilled jobs is not a sign of the times nor a result of modernity. The truth is that the plant was profitable and continues to be in the 2017-18 fiscal year at generated profits of upwards of £3 million. The sharp decline in silicon-glen and the erosion of our electronics industry over the years has been dramatic, but that does not mean that we do not have options now. We do not just have to accept the loss of what remains of our electronics industry in Inverclyde. I would agree with what Stuart McMillan has said about everything that can be done should continue to be done to protect this important asset. Members of the task force and I have said for the past two and a half years that a buyer can be found and a buyer must be found. The plant still can have a long-term future and I hope that this can be confirmed in the near future. In pursuing a viable buyer for the plant who can continue to support these jobs, the industry and electronic innovation in the future, we commit ourselves again to building a bossed economy that we can achieve and which our people deserve. The last of the open debate contributions is from Maurice Corry. Thank you, Deputy Presiding Officer. I, too, express my thanks to Stuart McMillan for bringing this important motion to the chamber and I support the motion accordingly before us this afternoon. I welcome this opportunity to speak about Texas instruments. Semi-deduct conductor plants such as this are an important part of Scottish industry and so it is. The upcoming schedule closure is of a great concerning situation. It has a potential not just to affect Greenock and the Inverclyde area, but the worth of Scotland's nation-wide industry. I also echo the points of my colleague Jamie Greene, which has said earlier this evening. I hope that through this debate we can raise awareness of the issue and strengthen our motivation to keep fighting for the work base of Texas instrument in Greenock. This highly skilled number deserves to have no stone unturned in our aim to ensure that they have continued employment. Also three years ago, it is announced that the Greenock Texas instrument plant, the semiconductor factory, will be scheduled to close in 2019 and has been referred to earlier. We cannot be mistaken that the loss of this plant will be a severe blow to the Inverclyde economy and community and its workers are an asset to the industry. The potential loss of Texas instruments will have a worrying impact. First and foremost, its closure will affect 550 positions. 318 direct jobs are expected to be lost. What does that mean for the area? Without the jobs, families in the area might feel that they must move elsewhere in search of more concrete employment. That will alter the face of the community and reduce options for incoming businesses and industries to Inverclyde. The closure of Texas instrument may also result in the loss of healthy competition across the industries in Scotland and the potential financial loss is high. Our economy could lose over £32 million. To be clear, this is not just a local problem. Texas instrument has been of enormous financial benefit to Scotland's economy. To keep this going, we must safeguard it. I am thankful for the work put in by the Texas Instruments Task Force, which I am pleased to be associated with. This group exists as an on-going collaboration between Inverclyde Council, the UK Government and the Scottish Government, as well as councillors, parliamentarians and multi-public agencies. Our aim since the announcement of closure has been to protect the employees and to ensure a long-lasting and secure future for the future of the plant in Greenock. That has been, as expected, a challenge for such a niche and specialist industry. Finding a buyer for this plant has proved very difficult. Our efforts have so far not received the answer that we would hope for, but with each new possible opportunity, the task force remains hopeful of success, even with on-going tentative negotiations. I am keeping my fingers crossed on that. I hope that the efforts that are made by the task force will continue to be supported from all corners, and only with full support can all avenues be explored in depth. I know that the task force is committed to protecting the skills base that we have on our doorstep and utilising it as much as possible. Ensuring long-term stability will open doors to the next generation of community. For this reason, it is essential that we continue to include the semiconductor science as part of our high school curriculum. That will encourage young people to direct their sites and their skills towards the future of the industry. I hope that our teenagers will have the opportunity to put their skillset, which they gain for practical use in real-life situations. I hope that the Greenock plant is here to provide it. In conclusion, I echo the call to continue an agency-wide co-operation in our efforts to protect the Greenock workforce and also support the Government's efforts. We need to assess our options and every possible solution to keep the momentum going. The semiconductor plant is part of the global industry of much value to the surrounding community as well as our economy. In recognition of that, we must further our efforts and enthusiasm for securing its future, both for the sake of employment and the community. I now call Jamie Hepburn to respond to the debate for around seven minutes. I join with others in thanking Stuart McMillan for having lodged his motion before partner for securing the debate. This evening, as Jamie Greene mentioned, Stuart McMillan spoke with a passion that is something that he always expresses when talking about his home area, particularly in the case of his efforts around the Texas Instruments task force. I also welcome the contributions that others have made this evening. We often have debates, particularly in members' business debates, in which we speak with one voice with great consensus. That, of course, is quite correctly the case. We are all of the same mind here because we want to secure a positive outcome for the future of the Texas Instruments site above all for the workforce there. The points that have been made have been well made. Stuart McMillan reminded us of some of the history of his hometown, his home area, which, in line with most of the west of Scotland, has sadly been one over the past few decades of some industry of the climb. He spoke, of course, of the shipbuilding heritage of his area, the sugar industry that was once the hallmark of Greenock. Of course, in the later wave of industries, we saw that Greenock and Inverclyde established itself as a hub for the IT and technology sector, which, of course, has seen some decline. With Texas Instruments now probably being the last remaining big employer of that sector, and clearly we want to do everything that we can to retain that expertise locally. We are, of course, moving nearer towards the plant's proposed closure in June of next year, so in that sense it is absolutely correct that we have this debate this evening. The loss of over 300 jobs at that site would, of course, be an enormous blow to the economy and Texas Instruments has added a significant contribution to Inverclyde's local labour market, local economy, by providing a large number of high-value jobs. There is no area in Scotland that could afford to lose that number of jobs, but I am acutely aware of the wider socioeconomic context that Inverclyde operates under and its issues of depopulation that Stuart McMillan very ably set out, so it is something that we need to be focused on. Scottish Enterprise has produced a report that assessed the economic impact of the company's closure, and in that regard Neil Bibby was quite correct to say that this is not just about the jobs at that site alone. If you include those supported by the site's supply chain and the included impact of falling household expenditures, the assessment that Scottish Enterprise took forward suggests that there could actually be 570 jobs lost to the local economy. In that sense, the scale of the issue goes far beyond the business itself. Stuart McMillan set out that it was welcome, as it undoubtedly was, that Texas Instruments gave us some leading time to their announcement. That has allowed us time to seek a long-term future for the site and for the workforce. Since taking up my role as Minister for Business, I have been able to attend both meetings of the Texas Instruments taskforce that has been convened in that time. Paul Wheelhouse attended in the past when he occupied the post of business minister. As has been set out, the taskforce was a creation of Inverclyde Council. However, it has been a good approach, because yes, Inverclyde Council established the taskforce and convened it, but the Scottish Government has been critical participants. It has given the development of Scotland at the table, Scottish Enterprise at the table. Critically and crucially, Texas Instruments are at the table because they are best placed to tell us what is precisely happening at the site at that time. MSPs of various political colours are at the table. Since I have been at the Minister for Business, Stuart McMillan has been present, Maurice Corry was at one of the meetings, and councillors of different parties are there. In that sense, we are having that open, frank and necessary dialogue that was spoken of. We as a Government have a strong commitment to work with that taskforce and with efforts to secure that long-term future for the plant and its workers. That is an ambition that I think we all share. We are pursuing the matter, outwith the confines of the Texas Instruments taskforce itself in February this year. The then Cabinet Secretary for Economy, Keith Brown met the Senior Vice President of Texas Instruments to discuss the situation. We have made contact with the company's chief executive to request a further meeting. We have continued to engage with the managing director of the Greenwood Plant officials. Scottish Government officials are now focusing efforts in conjunction with the council's officers through a working group that has started meeting earlier this year. We have maintained that open dialogue with Inverclyde Council to consider interventions to support the wider region that we can take together. Scottish Development International has been working actively and with the utmost determination to find a buyer for the plant, which is at the nub of the issue. As others have set out, it has been very clear from the outset that finding a buyer for the site has been a significant challenge. Stuart McMillan set out several expressions of interest. Unfortunately, I have not come to fruition, but I can say that discussions are still on-going between Texas Instruments and a potential buyer. I believe that it is important that we have to give them the time and space and some confidentiality to find an agreement. That being said, I have been absolutely clear that the Scottish Government remains utterly committed to doing everything that we can to support the purchase, to secure a long-term future for the plant. I thank the minister for taking my intervention and for all those warm words this evening. Perhaps he may have picked us up from being at the meetings. One of the senses of frustration that the task force has had is that when other parts of the country have seen such high-profile potential losses—in the number of hundreds, as he mentioned—that those have seemed to have garnered much more focus from the media and a more of a national conversation. That one largely seems to have gone under the rider. I hope that that does not affect the way that the Government will seek to tackle this or to help the community. To put it simply, to assure Mr Greene and all other members that it will not, just as Mr Greene might be frustrated on occasion, just as I am frustrated, I cannot control what the media output is. However, notwithstanding the validity of the point that he makes, it will not impact on this Government's determination to find and secure a future for the site and the workforce. In that regard, let me say that the engagement right now is more than a tire-kicking exercise. Let me conclude by saying that I think that this debate is important because it does take head on that very issue about giving the matter a degree of prominence. It is right that we debate this as a Parliament. It does reiterate the scale of concern not only for the plant and its workforce but more broadly across the region. We are doing all we can to secure a viable future for the plant. We will continue to work in partnership to seek and obtain a solution that is in the best interest of the employees of Texas Instruments for Inverclyde and for the Scottish economy. Let me assure the student milling and other members that we will leave no stone unturned.


All right, thanks. And I really should say it's Kubernetes. It's not Google Kubernetes at this point. No, that's not a correct answer. I want to make it clear that we're an open source project. We have actually contributed at this point the project to a foundation under the auspices of the Linux foundation. So it's really out there for everyone. There's a hosted Google version called Google Container Engine that we like to think is a great option for a lot of people out there, but it's really an independent project. So I am Brendan. I've been an engineer at Google for, it'll be eight years at the end of June. So it's been a long time. I started in search infrastructure and spent a long time building the back ends for search. So if you've got something out of Google that's under about 12 hours old, it came out of software that I wrote. And then I transitioned to the Google Cloud Platform. And what I really got excited about there was bringing a lot of the tools and techniques and approaches that we use to make search so reliable that for many people, Google is a test of whether the internet is working to everyone. And so I'm going to try to talk about how our philosophy about that and how I think that systems like Kubernetes change operations. All right. So this is my motivation slide. I've used this a lot. So if you've been to another talk I've given, I apologize. You've seen this slide before. But I find that it's really emblematic in my respects about why the job of operations can be really hard. Because almost no one pushes bad software, right? I don't think anybody knowingly goes, you know what, this is just not going to work. I'm going to push that out anyway. So what happens is actually that it's the coupling that's the problem. There's unintended consequences of whatever it is that you thought you did. I mean, sometimes you just make a flat out mistake and it's a typo, but hopefully you have automation that catches that kind of stuff. More often it's some sort of like, oh, we didn't realize that making that operation twice as slow is going to crash this other system over there. And so this is the point. Most outages are self-inflicted, but most outages are also accidental. And if you think about why this is, it gets back to that tractor trailer, right? It's this coupled system where the thing that is providing the force is on this hinge point to the thing that's trying to move, which is the trailer. And it's kind of unintuitive, right? I actually just spent the weekend trying to help someone, not all of the weekend, that would be really extreme, but trying to help someone back down a boat ramp. And we actually ended up stopping and just hand-trailering the trailer, disconnecting the trailer and hand-trailering the trailer down, right? It's hard. This coupling makes things really, really hard and there's unintended consequences about what happens. And so I think if there's one theme that I like to put out there, and this will sort of hit on in a few places elsewhere about how physical isolation, this morning, physical isolation of teams can actually build barriers and stuff like that, I wanna talk about how we can build systems so that we can decouple our operations into a bunch of one-dimensional problems instead of these coupled two-dimensional problems. And as a result, make our lives easier, right? Job is just too hard. All right, so we're gonna try and break that coupling. And I think that this is the breakdown that we have internally at Google. And I think this is the breakdown that I think that we're trying to put forth to the world in general. And I wanna say each of these layers is essentially decoupled from one another, right? We have hardware SRE who are basically responsible for the physical machines, imaging machines, things like that. They're the people who are in the data center. If you're using an IAS provider like Google Compute Engine or any of the other or some sort of virtualization provider, you may have actually already opted out of this, right? Your hardware SRE already may be someone who is totally decoupled from you because you're using an infrastructure as a service company. And then the next level above that is Kernel or OS SRE. And I think that one of the things that containers have really, well, one of the things that containers did for Google a long time ago and are doing for people now is enabling us to break the dependency between the operating system and the application, right? I can now suddenly say, I don't need the OS people to install Debian or Ubuntu or Fedora or whatever the OS is that I need for this particular binary package. Suddenly, there can be one operating system across and one Kernel across the entire fleet. Thousands and thousands and thousands of machines can have one operating system managed by one team, right? That's a huge decoupling and a huge improvement in process for a lot of people. The next level up is cluster SRE. And this is basically the people who are responsible for running a system like Kubernetes or Borg or Mesos or whatever it happens to be, right? They are the people who sort of provide this abstract API that then applications live on top of. And then of course on top, there's application SRE. Sorry, I should say SRE. Is that a familiar term for everyone at this point? Yeah, okay, sorry. That's kind of a Google, I guess it's a Google-ism. So it sounds for site reliability engineer. It's like DevOps before DevOps, I guess. I don't know. There's a book now in O'Reilly though called the SRE book from Google, so you can go and read about some of the ideas there. And so application SRE, there are people who are actually, I think this is actually the first place in some places where DevOps actually occurs. I mean, honestly, I don't necessarily even know what the word means, but I think that what it means is that the people doing operations have deep knowledge of the applications that they're operating or that the developers themselves actually are doing operations. And I think that that's what this decoupling allows you to do, right, because if you can focus on an application and you don't even think about kernels and you don't even think about hardware and you don't even think about really the cluster API, suddenly you have time and cycles to really focus on the application that you're running and the application that you're responsible for. And it turns out actually, so that's what we say here, like I think this is DevOps. I should remember to move my slides forward. And it turns out actually cluster SRE is DevOps too because the cluster is an application, it's just this special application that everybody else in your infrastructure uses. But it's just an application at some level at the end of the day. All right, and so yes, I really did talk through my slides before I showed them. And yeah, all right, I'm just gonna skip ahead to catch myself back up. All right, so what I think this is the thing that cluster managers like Kubernetes enable you to do is that basically everything below that cluster layer, it just vanishes, right? Just like with IAS, you got to make hardware disappear. With containers and a container cluster API where developers are saying things like, I wanna run this image with two cores and 10 gigs of RAM and the cluster itself is responsible for figuring out where to place it, on what machine, keeping it alive and all this kinds of thing. They can forget about operating system. They can forget about kernel. They can forget about everything below the application that they're managing, right? And that's really the power of this higher level API, this higher level abstraction that is container oriented instead of being machine oriented.  And it becomes actually this just giant C of compute because you have a scheduler that is responsible for figuring out where to run things. And so I no longer need specific machines. I no longer need to tell my application to run on specific machines. I just express the general requirements of my application and I trust that this API, this container oriented API is going to be able to schedule it out. So this is the stuff below this line. It's the not my monkey, not my circus line, right? So this is like application owners don't actually have to care about what's going on with the operating system. They expect that you'll make the operating, the people who are operating who are responsible for the operating system, they expect that they'll do a good job and they'll do the right thing and it'll work. But they have no other expectations, right? They have no other dependencies. This is the decoupling that we're talking about. And it turns out that it works both ways. And so it turns out that for the people who are running the operating system, the line protects them from the application, right? I don't have to care what you're running on my system. I provide everything up to this line and it's your responsibility to provide a working application on top of that, right? So again, we're decoupling these systems so that we can move independently so that we don't break each other, right? So that people who roll out a new kernel don't have to worry that they're going to be breaking some or more often rolling out a new operating system with new LibCs and new Python maybe that those people don't have to worry that they're gonna break some application because that application is no longer dependent on the things that those people are rolling out. This decoupling is really important for reliability. All right, so applications are gonna use resources, not machines, right? Every application just says what it needs. We scale in terms of resources. We don't scale in terms of machines. We just ask for more. Also important is the fact that this is an API, right? And so suddenly you can introspect via an API, you can automate via an API, things that are applications, right? If you're going in and you are running, heaven forbid, you're running manual commands via SSH, but even if you're running scripts inside that machine, even if you're running some of these automation services, it's very, very difficult to get an application-oriented view from automation, right? It's very difficult to write an audit log that can go across and figure out what versions of what software are running where. And that's because the APIs just don't exist, right? The APIs, even if you're in the cloud, if you're not in the cloud, then there aren't even APIs for your machines. If you're in the cloud, there's APIs for the machine, but not for the application. But with containers and with container management APIs like Kubernetes, there is actually an API for the application, and I can go and walk up to the API and I can say how much memory is that my SQL instance using? How much CPU is my PHP script running, right? That's hugely powerful in terms of the kinds of systems that you can build on top, right? Suddenly, I can build a system that goes across my entire infrastructure, and for every team in every group, aggregates the amount of CPU that their particular applications are using. And by the way, I can difference it against the amount of CPU that they're requesting, and I can go up to teams and say like, you know what? You asked for three times as much CPU as you ever use, even at peak, that's probably not okay, right? This is a huge step above what normally you can achieve. Everything effectively that you're doing becomes application oriented. I said this to someone yesterday, but one of the really important transitions that I think that containers and container management APIs are doing and are going to have, one of the reasons why I think they effectively are taking over the world is that the primary key for every single thing in your data center, which used to be the machine, is now the application. Logs are keyed in terms of application. Monitoring information is keyed in application. Your API is in terms of your application, right? That's what you were thinking about anyway. You were thinking about your application, and so why should you have to think about what machine, start with a machine and go find logs on that machine? Why should you have to think about health in terms of machine health? It's just not something that is relevant to your life rolling out software, which is in the end what the job is about. All right, and so this is the real transition that I think is going on right now out there in the world, and the real reason why people are getting excited around container oriented infrastructure is that the primary key of the data center is just shifting, and it's better for everyone. Because if I'm owning a machine, I can focus on machines and not even think about applications. There I want the primary key to be the machine because that's the thing that I manage. If I'm managing the machine hardware or the operating system, I want it to be. Then I decouple myself from those details when I start rolling out applications and for everything else, above that line of decoupling, the primary key is the application, which is the thing that you cared about anyway. And trust me, you don't want me rolling out kernels, right? And I don't particularly want kernel people touching my application. All right, so your data center is now application oriented. And now, hopefully that sounds a little bit cool, but it's a little bit vague. I sort of skimmed along the top and told you how the world was awesome, and I didn't really talk about why this was actually something that could make your life easier. And so I wanted to start with some of those sort of practical, actual things that these application oriented cluster APIs do for you. As an operator of an application. And the very first thing that they do is they keep your application alive, right? So we all, if we've been out there and we've done reliable software for a while, we know that there is, you need something to watch the system that you're running. You need something that software crashes, right? Software crashes all the time. There's lots of daemons out there that will restart your software after it crashes. But they are not really very well integrated. You tend to have to make decisions. Am I gonna do system D? Am I gonna use supervisor D? Am I gonna, like, what is the way that I'm gonna do this? And they tend not to have APIs, right? So I can't walk up to something and say like, give me the place where there's 20 restarts. Give me the application that has had 20 restarts in the last hour, right? Or in another way, is there a difference between how many tasks are restarting on this machine versus tasks that are restarting on this other machine? Maybe that machine is sick because everything that's on that machine is restarting constantly. And so what Kubernetes and what other systems do for you, other systems like this do for you is they allow you to put into the API application-oriented health checks, right? So I can actually, when I deploy something into this cluster, when I deploy a container into this cluster, I can say, you know what? I want you to hit this URL. Just go and hit this URL. If it returns a 200, then the application's healthy and it's good. If it returns anything else, restart it. Right? And so instead of me worrying about installing and figuring out how to configure system D, instead of me worrying about what particular supervisor and how I'm gonna get the information back, just the act of deploying into this cluster manager provides me with this attribute. And I think that's one of the themes you'll see. Not only does it decouple systems from one another, but it actually has this sort of generic set of primitives that you get for free just by deploying into this API. Just like with infrastructure, you expect that if your machine fails, you know, sorry, infrastructure as a service, cloud infrastructure as a service, if that machine fails, your machine should come back someplace else, right? It's taken over health-checking your machine. Now by moving up to this application-oriented layer, the API is taking care of health-checking and maintaining your application. So the other thing that it allows you to do is it's actually health-checking your machine too. Sorry, that's not actually coming through very well. There's a really light gray box around each of those. So this is three machines in a Kubernetes cluster, right? I have my yellow and green jobs running on one machine and two red jobs running on these other two machines. All right, so bad things happen in data centers or infrastructure as a service and machines can fail, all right? So what happens normally when machines fail? Well, if you're lucky, you page, right?  But if you've been decoupled in this way, if you've stopped caring about machines and all you care about is applications and you have a piece of infrastructure that's responsible for scheduling your application, what you will find is that the infrastructure itself actually notices that that machine has failed and it actually moves your jobs away from that machine. Because you're decoupled from the machine, you don't actually care. You just said, I want three CPUs. There's three CPUs available on that machine and it gets scheduled there, right? So you don't get woken up just because some machine failed. And it turns out, kernel or hardware or any kind of machine-oriented upgrade, that's just a special case of a machine failure, right? From the perspective of your application and you can do things like, if you want to be a little bit more proactive, you can drain a machine out.  But it doesn't really matter from the perspective of the application, right? From the perspective of the application, whether you restarted that machine because you wanted to upgrade the kernel or whether that machine simply disappeared because the hard drive died, the system reacts in the same way and your application continues to run. And so what this means is that if I'm a kernel operator or I'm an operating system operator, I don't have to talk to any of my application owners before I run an operating system upgrade. I just run it. I just go through one machine at a time and I have an SLA, right? Like any other good decoupling layer, like any other good API. I have an SLA and I say things like, when I run a kernel upgrade, I'm not gonna restart a machine more than once every 20 minutes, something like that, right? I have a policy around how I do these machine upgrades, but I don't talk to anybody. I don't tell anybody like, hey, we're gonna come through and upgrade the kernels. I just do it, right? And what this means is my fleet is almost entirely homogenous, which is a huge improvement in terms of maintainability and also in terms of, frankly, team size, right? And specialization, right? I can have a team of eight that is specialized on one particular operating system that doesn't even know anything about any other operating system that runs fleet of machines that is hundreds of thousands of machines, right? That's a huge win. All right. So there's something else that this does if you're thinking about machines and the thing else that it does is that if you've ever planned machine resources or any resource really, network, machines, CPU, whatever it happens to be, you know this problem, which is you go to the teams that are responsible and using your hardware and you say to them, so what are you gonna do? What's gonna happen in the next six months? What's gonna happen in the next year? And they say, team one says, we're gonna double our users. It's gonna be awesome, right? And team two says, we're gonna double our users. And team three says, totally gonna double our users.  But if you're in a world where applications are tied to machines, where applications aren't decoupled from machines, you really have no choice but to say, great, we're gonna 3x our machines, right? Because we have no ability, like team two, they want Fedora and team one, well, they want Ubuntu and team three, maybe they're on Windows. I don't know. Hopefully not. But we have no choice, right? We have no choice but to do this because we just don't know, right? But if we decouple and we abstract and we say like, well, the things that these teams ask for, they don't actually ask for machines. They ask for a container with a bunch of resources. We can actually look back historically and aggregate that information and say, you know what? Historically, every single team says they're gonna double their users. And historically, only one team out of three ever actually doubles their users. And so we're actually only gonna increase our machines by a third. And we're not gonna care whether it's team one that doubled or team two that doubled or team three that doubled because in the end, all they cared about was CPU and so we have the CPU necessary for whoever happens or maybe nobody doubles. Maybe everybody goes up by 10%. It just doesn't matter, right? Because I've decoupled my application from the machines, my planning process, I get to aggregate all your usage together. And I get to buy machines without having to worry in an image machines. And I can just basically look at my usage day to day, week to week, and say like, oh, you know what? I'm at 80% of my machine fleet capacity. I should probably add some more machines. And I don't have to say, well, are they gonna be Fedora machines or Ubuntu machines? It's like, no, they're just machines because everybody just consumes machines, right? So that ability to aggregate usage across all of your teams also is really, really important. All right. So what about application ops? I've talked a lot about hardware and I've talked a lot about sort of the system itself and how it makes managing machines easier. I wanted to talk a little bit and give some demonstrations of how this actually makes it easier for people who are running applications as well. And so that's where I'm gonna jump over for the moment. I'm gonna cross my fingers. I have some backup slides that go through in slideware terms, but hopefully the live demo will work. It is Friday the 13th, someone pointed out to me, which I hadn't, is that really true? Yeah, it hadn't occurred to me, so, you know. So I have right here, hopefully everybody can at least somewhat see it. I have a little Kubernetes cluster here that's running on a stack of Raspberry Pis. It was kind of fun to build. There's a couple of blog posts out there.  It's kind of become the hello world of distributed computing. So if you're interested, you should try it out. And so hopefully we will be able to see a demo with that. I guess I'll hold it here with one screen as I move things across. This whole splits. I'm also very used to having video mirroring when I do my demo. I get to type. Wow, this is gonna be really super exciting. I get to type while looking at the screen. All right, so I'm gonna move this. Actually, maybe I'll just turn on this. Yeah, I blame, I really, I'm blaming people who are not me. Um. Okay, so what we have here is a visualization of our cluster. What you can see here is I have the master with Kubernetes. I'm gonna hit reload affairs. I have the master, which is the node says Kubernetes, and then I have node one, node two, node three. I have this thing called a service, which is basically a load balancer. I have this replication controller, which is an object that's responsible for making sure that there are two of any one thing. And then I have two instances of my HTTP application that are running there. So that's all happening right there. And so now, I'll give you the same view. I can say cube, control, get nodes. Is that visible? Can people sort of see that, is there any to zoom in? If I can do that actually with this SSH client. Oh, that's probably true. I'm hitting control shift plus, but there we go. I'm too used to the OS X terminal where it's control shift plus, not control plus. All right, so there's the same picture. I've got my nodes there already. And I can actually say get pods. And there's my two services running. Now, the first thing I'm gonna do is I'm actually just gonna delete one of those. Actually, I'm gonna say dash O wide. And you can actually see, okay, one's running on node three and one's running on node two.  So I can say cube, control, pods. Can you briefly explain what a node is? Sorry, sure, yes, yes, sorry. A node is a machine. A pod is an application. A pod is actually one or more containers running, but you can just think of it as an app, as a particular instance of an application. Yes, I apologize for that. So, yeah, a node is one of the, one of these boards is a node. Okay, so I'm gonna kill one of these things. If I could actually. Anyone who learned how to touch type, that's not me. H, D, T, U, W, W, T, three. Okay, so let's go back over to the visualization. All right, there we go. All right, so what you'll see here is we have a pod that is actually, the one that is in gray is terminating because I've actually asked the system to kill it. It's not entirely like a failure because a failure, it would just go down. Since I actually asked the system to delete it, there's actually a graceful termination period. So it actually waits 30 seconds.  And then it waits 30 seconds by default, configurable, to allow you to drain network connections. So the load balancer drains out the network connections. Your application runs for another 30 seconds to allow you to finish whatever it is you're doing. In the meantime, it's in the midst of starting up something. That's the red one there. And eventually, we'll get back to a situation where we have two things running. And so if I go back over to, you can see that I have two instances running. Again, the same HTTP that was running on node two is there. The one that was running on node three is now actually running on node one. So again, I'm decoupled from application from machine and I just don't care. And when I restarted this thing, it just happened to land on node one. Now, that's a little bit interesting, but we are going to do something a little bit, which is we're actually gonna simulate a network failure. We're not gonna simulate it. We're gonna have a real network failure. And so at this point, all of the nodes are health checking with one another, health checking with the master to make sure that they're actually in existence. And so whether it's because the machine failed or there was just a network partition, for whatever reason, the system has noticed that the node... And you can see there that node two has now disappeared. So it now knows that node two is sick. And what's gonna actually happen is not only does it know that node two is sick, it's actually gonna note that that pod that was on node two, well, it's probably not working anymore either. And so eventually it's gonna be just like I deleted that machine. You'll see now, sorry. You'll see now that there's a gray one there. That's the pod that's been set to terminating. And it's actually created in another instance of the pod. So if we go back over to the terminal, there is that the thing that was on node two, well, because the machine failed, it's in the middle of terminating. It's not actually terminated because it actually can't get the signal, right? The master has actually said, hey, you're supposed to die, but because there's a node part, there's a network partition, it actually has no idea. But it will once it comes back online. And then it's moved and created a new instance. In this case, it's actually running on the master. And that's another interesting point, which is that from the perspective of these applications, the thing that is the master that is in charge of the cluster is actually just another source of compute resources. It's not something special. It's just the place that happens to be where the components that make up the API for the cluster are running. And so your jobs, as long as there's enough CPU, your jobs can schedule there as well. So we'll connect the network back in and we'll go back over to our visualization over here. And we're back and we have two things running, right? So I think this really shows that by decoupling the application from the machine, we're enabling the system to have enough flexibility that it really can react very reactively and responsively to a large number of different kinds of failures. I have one minute 17 left. I can end now or I can go through one more example, I don't know, do we wanna run over? All right, maybe we'll go back and run over. All right, so I'm gonna come back over to you. I don't know, is it better to do things like close the presentation and have the demo work or is it better to? Just wanna go through one quick, this is the review in case you missed the beginning. So then, so briefly, there's this concept in Kubernetes called labels. And basically a label allows you to mark different things that are running in your system, front end in production, beaver ends in testing, allows you to query things and say, I want everything that is production. This turns out to be a really powerful feature for operations, and the reason it's a powerful feature for operations is that I can actually do things like quarantine a server. So if I've said I wanna have three things running, I say, the way that I say I want three things running is I say I want three of front end comma production. Now let's suppose in the middle of the night I get paged because some server is deadlocked and it can't be restarted, right? What can I do in this situation? Well, normally what I would do in this situation is I would, if the system itself hasn't already restarted the machine or the task, I'm gonna go in and I'm gonna actually kill that thing myself because we need to get back to our production service, right? We need three of these things. But in Kubernetes what we can do instead is we can actually remove this label. So we can actually say, actually, we're gonna pull off that production label. This has the net effect of moving the container out of that replicated set of things. A new one will be brought back in its place, but what's important is that the old one is still out there in the cluster running. It's just not serving production traffic. And so this means that when I come in the next day or when a developer comes in the next day, they have a quarantine task that they can go in and debug that's live, that's no longer debugging from logs. It's debugging from a live server that they can poke at and hit with requests and everything else like this. It's a way, way more useful thing to have. And yet I'm still able to restore my system to full capacity without having to, without having to terminate applications, right? And so again, I think this is the labels and I don't have time to really go in and do justice to it. But again, what we've done here is we've decoupled the notion of the load balancer from specific machines, from specific applications even. We've tied the load balancer to just this abstract notion of having a set of labels. And by doing that, we enable behaviors that you otherwise couldn't do that enable your operations to become easier. So I will be around later for questions and everything else like that. Please don't hesitate to come up and thank you very much for listening.