Why learn about sustainability? As far as challenges for society go, sustainability is about as big as they get. We're talking about living, thriving on a finite planet, about how we manage the Earth's resources as our aspirations increase and as the population grows, and how we ensure that current and future generations have opportunities for health, prosperity and a good quality of life. That challenge is not beyond our capabilities, but it does mean some big changes to our current way of thinking, and that won't happen until we better understand the nature of our interdependence with natural systems and how we can do things differently. We are already beginning to see innovations in the way businesses operate, rethinking design, manufacturing, supply chains, access to health care, mobility, the way we produce and use energy, and even questioning some basic assumptions about the purpose of business.  You may see sustainability as being about the ways to achieve the fair and resilient use of natural resources, or about the prosperity of the nation's state and economic growth, or about the future of your business, or simply about ensuring that we leave a positive legacy for future generations. Whatever our personal motivations, we believe it's essential for individuals, and current and future leaders in particular, to develop broad awareness and understanding of the economic, social and environmental changes and challenges that we face, and the options that are open to us. Ultimately, sustainability boils down to the informed choices we make, as individuals, as professionals, and as members of society. What do we mean by sustainability? Your business may have a sustainability policy or strategy in place, and you may have already had training on the subject. You may also have read about sustainability challenges such as climate change, poverty, and inequality and food security in the media. The term sustainability is increasingly being used in all sorts of contexts. Sustainable agriculture, sustainable fish, sustainable cities, sustainable business, sustainable fashion, the list goes on and on. So what does it actually mean? The simple definition of sustainable is a resource or an activity that is able to be maintained at a certain rate or level. In business it has long been used in a financial sense to indicate that the company continues to make money. But it is also used to mean maintaining the earth's natural balance by avoiding depletion of natural resources and disrupting environmental systems such as the earth's climate. Another way of looking at sustainability is to see it as an approach to decision making. Which balances the needs of the current generations with the needs of future generations and the health of the natural environment. For example, achieving a sustainable food system means producing and consuming food in a manner which provides for the health of all societies today while retaining capacity to meet the future needs of a growing population and all the while preserving the natural systems upon which we so fundamentally depend. We hope that this programme will help to build your own insight and enhance your ability to make informed choices both within your personal and your professional life. The programme is designed to take you on a journey. You will start by considering your own perceptions of sustainability and exploring how sustainability relates to your personal values. You'll also be asked to test your insights into the changing global context within which business operates. You will then have the opportunity to explore the way in which sustainability relates to everyday products and to consider the implications for your company. The next step is to examine some of the key issues that pose significant risks and opportunities for business understanding the connections between these issues and reflecting on the implications for your organisation. This will include looking at the importance of engaging with the concerns and expectations of key stakeholders both within and beyond your organisation. Throughout this programme you will have the opportunity to consider the choices that you and your organisation need or want to make in response to sustainability challenges. In some instances the changes that need to be made may be relatively modest, but in others it may lead you to conclude that incremental change or business more or less as usual is insufficient. This could lead you to conclude that what is required is a more radical transformation of your organisation's business model if your organisation is to be both profitable and sustainable. We hope that this will be an enjoyable experience and that this programme will lead you to the realisation that working towards sustainability is a profound challenge for business but it is also an extraordinary opportunity.


Welcome to my presentation title Tools I Wish Existed three years ago to create a SaaS platform. My name is Mauricio Salatino and I will be talking about a bunch of open source projects. I'm at Salaway in Twitter and I'm a staff engineer for VMware and I'm working 100% of my time in a project that's called Knative. I'm a Kubernetes addict and I really enjoy open source so I enjoy building frameworks and abstractions that you know helps you to build better applications and faster. I do share my learnings in my blog that it's Salaway.com so feel free to check it out if you're interested. Before I start my presentation I wanted to share that I'm writing a book for Manning that it's titled Continuous Delivery for Kubernetes and it just entered the Early Access program so you can find all the details about the book and the topics that I'm covering here in this link if you're interested in that feel free to join the the program. During today's presentation I will be talking about the Software Access Service platform anatomy from a developer perspective. I do consider myself a developer so I'm looking through this lens and then building and packaging staff pretty quickly. This presentation it's not long so I will just be showing some projects that you know you can use in order to do something related to building and packaging. I will be talking about application infrastructure that's a little bit longer but again it's pretty rushed because the amount of time that I have for this presentation and then I will be talking about making your developers life easier by installing tools like Knative. So let's start by defining what do I think that a software service platform is and why it needs to be self-service and multi-cloud enabled as well. So I when I think about like building a software service platform I do feel that you need a self-service approach right like whatever your customers are you need to provide them a way for them to just go and parameterize your platform and just click a button and then provision some components for applications so they can just go and use them. Customers between quotes because they can be internal or external you can have internal teams of different departments that requires to provision you like some components for them so they can do their work or they can be external being like real customers. If they are internal then sometimes we can decide where we can run the software sometimes we can't but if we can our life is going to be definitely easier. If they are external and they are like paying customers we need to figure out if they can if they are okay for us to choose where we want to run our services for some industries that's okay for some other industries that are more regulated you need to make sure that you are running in cloud providers that they can use and they are allowed to do that by regulations and also you need to figure out how you are going to charge for the service right and that's a completely different topic that I'm not covering here but that's usually a very important question to answer and more advanced topics for software providers that's kind of like where I usually tend to have my experience on is that you need to also allow your customers to run your platform like your software as a service platform in their on-prem cloud services as well that's again because of regulations because of the nature of the software that you are providing for them this is way much more technical but I've seen this happening a lot in the tech industry. So it is very important as you already saw the fact that you can choose different cloud providers and to have a cloud strategy like a multi-cloud strategy in place for building your platforms it's really important but having clear definitions it's even more important and this blog post from HashiCorp CTO defining different dimensions of what multi-cloud means it's pretty spot on right and when I read it I realized that what I'm talking about this during this presentation it's all about these two first categories workload portability and workflow portability and the main reason why I'm a hundred percent sure that what I will be showing you gives you that it's because we are using the Kubernetes APIs as obstructions for different cloud providers and as soon as we rely on these APIs we should be fine by using the same tools across different providers and making sure that you know you can just move your workloads from one provider to the other. I will not be covering data portability or traffic portability I guess that I will just attack those topics when I build more complex examples of the ones that I will be showing you today. So the scenario for this presentation is you know a conference platform that you can create instances and you can just organize your conference on top of it right so you have different sections different services to implement this functionality you have the agenda service you have speakers you have proposals and all these examples can be found in this repository that it's down below it says salavoy from monolith to gates where you will find step-by-step guides tutorials on the examples that I will be showing during this presentation for all the tools that I will be showing but in reality I'm building these these conference instances with different services they all talk to each other using REST calls and of course in real life you will have more and more services and you need to prepare for your cloud native applications to expand and add more services to them so you need to have the right tools for doing that and make sure that you automate as much as possible but what I really want to build here it's something more like this I want to build a self-service conference platform where your customers can go parameterize and then create different instances for different events right so you have a conference in Argentina in the UK and in Denmark you have your customer going and just clicking in some forms just entering some information clicking create and you know a new instance of this platform should be created for them when they don't want to use that anymore they can just shut it down right like after the conference was organized they even happened then you just can't remove that instance because nobody is going to use that anymore so this is what we are aiming to build and all the tools that I will be showing you next are related to that okay now that we know what we're building let's talk a lot about building and packaging stuff with tecton and with helm so now that you know that the application is composed by four services we need a way to automate the creation and building all these artifacts which will include testing and just publishing artifacts to different repositories so for that I usually tend to think that we will need to have a pipeline engine in this case I'm suggesting to take a look at tecton but the concept that I want to share here is the idea of service pipelines for every service that we want to build we should be able to have a pipeline that is automating all the build process for all these artifacts and it's also looking for example into git repositories to see when changes happen if you follow a trunk-based development approach which basically is every time that you merge something into the main branch you are just going to create a release for your artifacts you want all that stuff to be automated for you and this pipeline instance and the pipeline engine that it's running this pipeline needs to be configured in the right way with all the infrastructure required for you to publish these artifacts at the end of the day different kind of pipeline it's having an environment pipeline which basically it's going to sync you know a git repository that has the configuration about the service that you need to be running in a Kubernetes cluster with you know a real Kubernetes cluster this is more commonly known as GitOps but here I'm just calling them environment pipelines because for every environment that we want to have in our you know in our customers for our developers for QA for test customers or different scenarios you will need to have one of these pipelines that basically takes the configuration from a git repository and applies it to a live cluster so you avoid going to the cluster and manually making changes in there which can cause a lot of problems you can implement this with different tools than tecton but in this case I'm just suggesting you tecton because it definitely brings kind of like this declarative approach where we can just define these pipelines using Kubernetes resources and they are going to run inside our Kubernetes cluster as well so let's take a quick look at a demo of how tecton works and how do you define these pipelines using you know Kubernetes resources so when you're using tecton basically you install tecton inside your Kubernetes cluster and you can find here in my repository from only two gates and the tecton the instructions to install tecton and to just also configure it to run the pipelines that I will be showing that are basically defined to build my services in my application and also to sync against environments in live clusters so if you go to these instructions you will see that tecton comes with something that is called tecton dashboard that it's optional that you can install as well and what I have here is I have two pipelines definitions one for a service that it's called api gateway and that basically contains all the steps to build that service and to publish all the artifacts and then the staging environment pipeline which basically is in charge of looking into a git repository that has the configuration for what I want to deploy into the staging environment and sync that to a configured kubernetes cluster so if I want to run these pipelines I can do this by sending a command to kubernetes and that command you can also find in here which is basically creating a new instance of a pipeline with a bunch of parameters I'm creating a new pipeline instance pipeline run in this case it's called and the pipeline of course you can parameterize it with different you know parameters you can define the branch word that you want to build and where is the docker file the user that you want to use to publish docker images and all that stuff the version that you want to generate and as soon as you enter all the parameters you will have a new instance of that pipeline that it's going to be running and you can monitor here in pipeline runs so I have a new instance I have created a pipeline by just defining a kubernetes object that I can show you here so resources service pipeline this is a kubernetes resource that you apply to your cluster and now tecton has this definition available it's can pipeline it comes from tecton and the important part in here besides all the parameters are the tasks which are basically the things that you want this pipeline to run in this case I'm cloning a repository I'm using a bundle from the tecton catalog that it's that's a pretty fine behavior it's pretty common to want to clone git repository so they already include that functionality for you it's pretty common to build the stuff in the java world with maven so they have already a task that will do that for you and it's pretty common to build you know docker images and publishing docker images and you can do with canico so it's pretty straightforward to configure these the main idea here is that you define once a pipeline template and then you just use the same template for different services so after running this pipeline what I would expect is having all the you know artifacts required for me to deploy this service this new service version into an environment and for that then I can trigger the staging environment pipeline that will sync again this repository that I have where I have the new version of my service specified to a live cornerist cluster so I can go and see my service up and running that's pretty much what tecton is it allows you to declaratively define these pipelines using kubernetes resources and then just run these pipelines inside kubernetes clusters so you can automate building and deploying all the services that you are that are required for your application to run when building stuff it's also important to recognize that we need to have some kind of package manager for our kubernetes resources so when I showed you the pipeline before I was generating a docker image and pushing that to registry but I also will need to package and version all the kubernetes manifests that I need in order to deploy these container images into my clusters and helm is one of those projects that you can use to do that helm uses this idea of having a chart that it's easily to version and distribute also so all the teams can install the same thing and usually the recommendation here because I don't want to spend too much time on this to keep the helm chart and the definition of the chart close to your source code so if you have a service it's quite good to have the chart in the same repository for example so you can version all the things together and when you run the pipelines kind of like the last step should be to create that chart and just publish it to a chart repository in helm you can use composition and dependencies but you need to be very careful with that for example you don't want to include too many dependencies in your charts which will make it the chart very difficult to configure and remember that also when you're using helm there is no need to install the kubernetes manifest using helm install you can use helm template to print out all the manifest and then use customize to just change for example some of those yaml files depending on where do you want to apply them so let's take a super quick look at what you can do which is basically installing the application by just running a single command line so I've created a chart with all the services that are required for my application and I can just run this command helm install the name of the release that I want to create and the name of the chart that I want to install that's published in my own helm repository and it's fetching the chart and basically installing that to the configured kubernetes cluster that I have in my terminal so after a bit I should be able to see that the chart was installed and that basically means that now I can list all the services for my application so here I can see the services that are being started I have four services and those four services were created by the definitions that are included in this chart this chart has a version it's 0.1.0 so I know exactly what's in there what versions of my services are in that specific version so I can trace back and figure out what's going wrong when things just go bad so that's pretty much helm I totally recommend you to check it out I'm just sharing this because I do believe that helm is a good project but there are different alternatives as well and as soon as you have some kind of like package manager to deal with versions and to easily distribute your applications you are good to go so once you can build your services and your environments then the next step is to talk about application infrastructure and for that I will be talking about crossplane so for this example some of my services require databases for example the proposal service requires a postgresql database and the agenda service requires a redis database to be provisioned and to be available for the service to work and you might end up needing something like Kafka as well for sending messages or events right or an email server or any other thing that must be configured for your service to work and how do you do that in usually right you can use helm as I mentioned before you can just go to vidnami for example and find the redis and the postgresql and the gafka chart and just install that into your kubernetes cluster but that becomes pretty problematic quite soon because you need to maintain these components inside your clusters and you need to have dba's and people that it's trained in both in kubernetes and into the databases in this case to maintain those components running for longer times right so usually unless you are doing development you tend to not install helm charts into kubernetes clusters for application infrastructure you can also use cloud provider specific tools right like you can go to google cloud for example and create postgresql instance on a redis instance and then connect your services to these you know managed databases inside google cloud right that's kind of like okay the problem is that you need to learn about google cloud specifics you need to use their interfaces and or their apis in order to be able to provision these and if you want to provision tons of these then you just need to automate that in some way you can use tools like terraform for this or you can use crossplane which brings it closer to our kubernetes world so crossplane is basically a multi-cloud application infrastructure made easy and how does it work i usually tend to try to explain how how it will go for you if you want to use it so basically you install crossplane into a kubernetes cluster and then you just configure one or more providers like google cloud azure aws and you give the right permissions to these providers so you can just go and publish provision components in in their infrastructure right and then you just basically create kubernetes resources so for example you can create a cloud SQL instance to create a postgresql database inside google cloud you create the object and crossplane is going to be in charge of going and creating that resource for you and the cool thing about crossplane is that it not only creates the resource it also creates for example a secret with the url and the username and password that your services inside kubernetes will need to use in order to connect to that specific instance and at the same time it will keep monitoring and reconciling the definition that you created in a kubernetes object into the actual you know gcp azure or aws infrastructure making sure that if somebody deletes you know that database it's automatically recreated for you and for your application to keep working so let's take a look at that first so as i mentioned before i've installed a crossplane into my cluster and basically i can go and create now a database here in google cloud in sql cloud sql and i don't have any instance but i can choose between my sql postgres sql and sql server and if i choose postgres basically what i will need to define is the name for the database a password version a region and some other parameters right if i click create an instance here i would just have one of these instances with crossplane installed and the gcp provider configured for me i can just use this more kubernetes way right i can create a kubernetes resource called cloud sql instance that comes from the database package in the gcp provider set some parameters for my database to be created and then just send this object to kubernetes right cloud sql instance and basically what this is going to do is it going to be picked up by crossplane the gcp provider that understand the cloud sql instances and if i go back here to my list of instances i should be able to see that my postgres sql database is being provisioned when this is done basically what i'm also going to get is a secret inside the namespace that will contain all the information about how to connect to that specific instance and the username and password and the url that i need to put into my services that wants to connect to it so that's pretty useful but still we can do better than that let's go back to the presentation so basically what just showed you is we transform a form in google cloud into a type into kubernetes and crossplane is going to be able to provision infrastructure for us by just reading these objects that we we send to the kubernetes apis but we can do much more right because crossplane also comes with the concept of compositions which are basically abstractions that we can build for our own domain and we can build these abstractions based on the users that we have right so i can create an object type and notice that this is my type that it's called postgresql instance when i've already defined which version of postgresql do we want to use and the only thing that i'm asking for the user to enter here is the size of the database right i'm also setting up here the name of the secret where i want to that crossplane will use in order to create all the URLs and username and passwords for connecting to that specific instance so in this case i provide like a higher level abstraction of how to provision a postgresql instance that it's not tied to a cloud provider and i can provide different configuration packages on the back for different providers so this postgresql instance i don't know where it's going to be provisioned it will depend on the provider that i have installed and you know it will not change depending on the cloud provider that you're running on right which is again giving you this abstraction this moving you far away from the actual cloud provider that you're using for running this this infrastructure always providing that interface of you define an object and then you just connect by looking into a secret nothing stops you to go one step higher right and create an abstraction and a composition for what a conference is and this interface in this case is just setting up the details of the infrastructure that you need for that conference but you also can specify some other parameters to configure the services that are going to be composing your application i showed you before how to install a helm chart that contains all the services of the application and in this case i'm doing the same but with crossplane so instead of manually going and installing you know a helm chart i am defining a high level abstraction here of what my conference instance is that also includes the infrastructure that i need to run my services and i'm telling crossplane to go create a new namespace install a helm chart provision the infrastructure that i need create the secrets so my services can connect to them and that's pretty cool because i managed to create a big package that allows me to create new instances on demand by just creating kubernetes objects so let's take a look at that okay so i've just deleted the instance that i've created before so i do not have any post-created instance and we can switch back to the terminal to take a look at this conference jammel file that i've created right so i have this definition again just setting up the sizes for the redis database and the postgresql database and what i'm expecting is that as soon as i send this conference instance to crossplane crossplane is going to just run through this composition that basically install the application provision the infrastructure connects everything together and just keeps me that instance for me to access so let's apply this um conference jammel file to crossplane and crossplane just created it so i now can list conferences right conference instances those are my my abstractions that i can just package and distribute as well and you can see that it's not ready yet because of course infrastructure needs to be provisioned and if i refresh here in google cloud i should be able to see that yes so one instance of postgresql is being created i can just go and check as well here in redis i should have a redis instance being provisioned as well there you go and if i go to get the releases for example from helm i have the helm provider here installed in crossplane it just created a release and it's installed the release and it's already deployed which basically means that i have a new namespace call conference here which has my instance if i get the pods there inside the namespace i can see that my application pods are already up and running which is pretty nice regarding kind of like all the automation of course that this is the pods are going to connect to the databases when the databases are ready and they will just keep looking into it in order to be able to be fully function and again i can just check the status by just listing kind of like the conference instances and wait for everything to be ready so i can give access to my users so in these ways we have just obstructed how to create conference instances and we are now at a point where we can say if we got a call that we have a new customer the only thing that i need to do is to create that conference object and at the end of the day i will end up with the namespace plus all the infrastructure that i need to run my services already wired up and provisioned in the right cloud provider this demo can be extended to create the infrastructure for example in AWS or in Azure there is not much change is required only the specific configurations to define which resources inside the cloud providers needs to be created which is just implementing and defining these compositions for using different resources only so let's go back to the presentation okay so let's talk about making your developers life easier with Knative Knative it's a very difficult project to explain and i think that Kelsey put it in the right way here which says if Kubernetes is the electrical grid then Knative is the light switch which is perfectly aligned with the idea of being a set of obstructions and tools to make your life easier when you are developing cloud native applications Knative comes into two flavors two different components that you can use independently Knative serving that provides advanced traffic management and the auto scalers and Knative eventing that brings the concepts of producers and consumers of events to Kubernetes so let's take a look at Knative serving Knative serving allows you to create Knative services so instead of creating Kubernetes services ingresses and deployments you just create a Knative service and Knative service it's going to create all these kind of like dependencies for you what you can do it's for example here like what the example is showing here is like a header-based routing in this case you have the main revision of your application that's the version that you want to expose to all your users expose there like and your users are accessing that that version of the application but you want to introduce another different version for developers to debug certain scenarios and certain issues that can appear right so and in this case what you can do in a Knative service is to define some traffic rules in this case we are saying 100% of the traffic it's going to go to version one but if we include a specific HTTP header when we create the request we are going to route to this second version which is the debug version so let me show you that in action quickly with just a simple example so I have installed Knative serving here in my cluster and I've installed the same application that I showed you before but now using Knative services instead of you know normal Kubernetes services deployments and and ingresses so if I list my Knative services that I can do with that the first thing that you will notice is that you will have a URL to access the application to access the services straight away without the need of an ingress so I can just copy that into you know my browser and I can access the application that I showed you before as I mentioned one of the features that Knative allows you to implement quite easily is to create this header-based routing so one of the things that you can see here if I list all the pods is that I have two revisions of my application one is the normal version that the users are accessing and the other one is the debug version that it's already running for developers to troubleshoot the application and in order to route traffic to this specific version the debug version I can use something like mod header here which is a chrome extension that allows me to set a specific header when I'm doing and when I'm doing the request in this case I'm setting the bug which is the name of the tag that I'm using in the traffic rules and if I refresh the application I will be able to access this debug enabled version of the application that it's running there in the same cluster this allows me to run different configurations of the same service at the same time and then create these traffic rules in order to direct traffic to different places based on different you know policies here you can see where the services are running the node in the Kubernetes cluster where they are running so you can troubleshoot things right and all the services are green which basically means that the application is working correctly so hopefully that just showed you a simple thing that if you want to do only with Kubernetes resources it is pretty hard to do and you will need to rely on something else to to implement this kind of functionality so I totally recommend you to check Knative serving for that when we talk about Knative eventing that's a little bit different so we are talking about producers and consumer of events so basically what I did in the application is I enabled my services to emit events to a Knative broker that it's this kind of router right like and that broker can be again any uh different implementation it can be Kafka it can be Google pops up depending on where you're running and what implementation do you like you can use that and then basically what you need to do is you need to define Knative triggers which are subscription for your events and here it's kind of like how a Knative trigger looks like it's a simple Kubernetes resource where you set you define which uh broker do you need to look for events in this case my broker it's called default and then I'm saying that I want to send all the events that happen in the broker into this URL which is another here like another application that it's consuming these events you can also add filters here so here you can just create some filters and define those filters here in the specification for just if you're interested in certain kind of events you can do that so let's take a look at how that works uh I configure the application already to emit events as I mentioned I have a broker and I define a trigger that's going to send events to you know an external application in this case sockeye which is just an event monitoring so let's take a look at that okay so if I go to the terminal and for example list all the brokers I can see that I have one broker and the broker it's called default and it also provides this URL which basically means that my applications my services inside the application can send a post request with a cloud event into the broker and the broker will receive that event and forward to all the subscribers basically all the triggers uh and also you can see here that I have this new application that it's called sockeye in this URL and that's where I'm just sending all the events that are happening inside the application so if I go to the application this is sockeye basically it doesn't have any cloud event and in order for me to generate cloud events I need to interact with the application right because different services will send different events so for example if I send a new proposal here to the conference and that's me and that's my mail and this is a test I can just interact with the application one service received this request and basically generated an event here that you can see like the proposal received event from the proposal service that was submitted here right and it has the information that I've just submitted in the form right I can keep interacting with the application for example going to the back office and accepting one uh one proposal here so I should be able to see that more events are generated by the application imagine how you can use these to emit events from your applications connect that to a broker and then define the consumers of these events in a declarative way in Kubernetes you do this on configuration and per cluster and that gives you the flexibility of wiring things up depending on what do you have available and depending on what kind of integrations do you want to implement k-native eventing provide these concepts of consumers and producers of events which is pretty important for integrations and for building event-driven architectures so I totally recommend you to check that out as well of course all these examples that I'm showing are in this repository for monoliths gates under k-native and it's step-by-step guides on how to run these examples in your own clusters if you're interested in doing so so check that out so after all these things that I've shown you what do I want for Christmas so first of all I want the place where I can just build and package my software so that pretty much means that I need a Kubernetes cluster that it's dedicated to these things it will have something like tecton installed and all the infrastructure that I needed in order to build and publish all these artifacts already wired up for me right I don't want to spend time configuring a docker registry or a chart repository I just want that to be configured for me already and I want also like service pipeline templates and environment pipeline templates so every time that I need to add a new service into my applications I don't really need to think about creating a new pipeline I can just start from a template that it's doing most of the things for me right same with environments if I want to create a new testing environment I don't want to be thinking about okay how do I create an environment pipeline for that I need a template that I can just use to get things out quickly and if you haven't checked janking sex that's pretty much what it's doing right like it's installing creating a Kubernetes cluster installing tecton in it in different cloud providers and configuring and wiring up all the infrastructure for you right and at the same time providing this you know service pipeline templates and environment pipeline templates which are pretty pretty handy to get you started you just install this and just start adding services and creating environments so you should check this out on the other hand I want a place where I can just create my platform abstractions and that basically means another Kubernetes cluster with crossplane installed and all the cloud providers that I'm planning to support already configured right like all the right credentials in place so I can provision inf like I can provision components into these clusters uh on the right hand here I'm showing you my compositions and my configurations that my infra team can create based on the cloud providers that we are planning to support and on in yellow here basically my customer instance abstraction right like which represents what my customers are going to be able to parameterize send to crossplane so crossplane can provision all the components required for that specific instance that they they want to to start using if you haven't checked out up on cloud that's the company behind crossplane and they are providing a managed service for crossplane basically which is this right like a specific like their own Kubernetes cluster with crossplane installed where you can just go there and configure your credentials for different cloud providers so they can provision infrastructure for you as well so you should check that out because that's pretty cool and finally what I want for my users is to be able to use this self service approach right so I can create a portal where they can just configure these instances that they want to create and they want to provision they will be sending that to crossplane so crossplane can go and create a dedicated Kubernetes cluster for them with all the projects and tools that are required for the application to run in there right something that I haven't showed you before is basically crossplane creating a dedicated cluster for each customer I was creating a namespace before and also the missing piece in here is to make sure that when we create a new cluster we can install the right tools in there like k native or projects like velero as well that are pretty useful to have in every one of these clusters so at the end of the day it should be like the entire journey from the customer defining what they want for this instance crossplane provisioning a new cluster installing the right tools inside that cluster for running the application all the tools that are installed in there are just to make your developers life easier so when they are developing the application they can rely on certain things like k native and then installing the application that you know our customers customers are going to be able to access that should be kind of like the main goal in here and as you can see this requires a bunch of kubernetes clusters clusters that will be created dynamically but the good thing about this is that this is a hundred percent relying on the kubernetes apis it's multi-cloud enable you can run all these tools across multiple cloud providers without any restrictions it's extensible by design all the projects provide extension hooks where you can just add your own abstractions for your users and it's open source and community backed which is pretty important to guarantee that these projects are going to move forward and make things easier for us so that's pretty much it thank you very much for joining my session i recommend you to check out my continuous delivery for kubernetes book that i'm writing just join the early access program there if you have any other questions please feel free to reach out be a twitter at salavoy that's my twitter handle and thank you very much see you next time


Do not let AI write your cover letter. We can tell, I promise. For starters, they're nearly all identical. And what many job seekers forget is that the people who wrote the job descriptions are often the ones reading the cover letter. So when chat GPT regurgitates my exact phrasing back to me in your cover letter, I'm good to notice, especially when your resume doesn't back it up. And with both entry level and highly competitive jobs, cover letters are sometimes the only things that can set you apart from other applicants with very similar qualifications. AI should be a source of inspiration for cover letters, not a one-stop shop.


Hello, folks, we'll get started at about five after. Hey, Oliver. Welcome, Kusher. Good morning. Good morning. We'll get started about two minutes after. You can add your name and any agenda items to the meeting notes, which are posted into the zoom chat. Hello greetings, everyone. Let's see. We'll get started here in just a moment. You can add your name. And any agenda items, or if you have an agenda item, you can say it out loud. I'll just add that into the zoom chat. Welcome. Michelle and Ben. Hey, Frederick. And Ian. Hey. All right, Ian. All right, I'm just opening the agenda to give me a moment. No problem. And then I could. Help you, but I'll let you, I'll turn it over to you late. Good morning, everybody. I'm used to being fraction late. Let me try and share this, but it looks like I can't share today. I'm afraid. Right. So if it's not a problem for you. Taylor, could you do the sharing while I do? Yeah, I'll share the screen. Yeah, sorry. New laptop. It's forgotten all of its sharing permissions. Right. So. The first item is simply the upcoming events as usual. We've got KubeCon imminently. So yeah, KubeCon at the end of the week. That's the China version. So for those of you who are a little bit more in a civilized time zone and who have signed up to it, I hope you'll go to that. I don't know if anyone's got any. I don't know if anyone's got any specific sessions they want to raise while they're here. I see we have one listed in the minutes there if anyone's interested. Nope, fair enough. And then for a second round of everything happening in Asia, then it looks like we have the open source summit in Japan as well, which looks like it's going to be next week. Then beyond that, we've got a round of things coming up next year. You can read as well as I can. So you're good. Other than that, apparently we have zero agenda items. So what I'm going to do is have a look and see if we've got anything on the pull requests. Does anyone have anything that they just want to speak out loud and we can add. Well, got very quiet meeting today then. This is going to be very quick if we don't think of something soon. Is my audio coming through? Yes. All right. Yeah. So if anyone has any topic, just anything you want to talk about regarding CNS cloud native, we can just add that or look into something. If you had questions about something, we can put it on the agenda. Good morning. Yeah, I think I wanted to check with you on the proposal thing. I think we had a brief conversation over the email. Can you share more details about that? Is there any link or something that I can go through regarding contributions? I think there's a couple of topics though. Talk contributions to the working group or the blogging. I don't know. We had a couple of things going. Can you hear me? Yes. So what was the specific question or topic on that? And just add it in and we'll dive into it. Yeah, I wanted to basically know the topics for the proposal. Right. Yeah, let me add. Best practice ideas. Yeah. Just make sure we're covering the right. The right one. Okay. So just what is the, how would this. How do you do it? What's the process and what's involved? Is that, is that kind of the question how to do it? How to contribute best practice? Okay. Is that the question? How to contribute best practices. Yeah, so. Yeah, so best practice. Yeah. Yeah. So the topic. So what I am currently working on, right? I think I was discussing our previous meetings. I was basically. Working on. Integrating our. Into CNCF. And also we have a bunch of best practice. Policies. That that can, you know, be used to. You know, I think that's one way of contributing. I think. But maybe I can come up with a write up. You know, and share it with you. And then. You can decide on that. All right. So it might be good to, I guess, for folks on this call that haven't. Same. Give a little bit of background. So. Kyverno. Is a project that. Can it's a policy. I guess a policy agent for. Kubernetes. And you can set different policies. There's different. I guess projects out there like OPA and other things that can do it in a different way. And Kyverno is one of them. And there's been some interaction with Kyverno and the. The CNF test suite. Around testing. And checking things. So. With regards to the working group. I think what we'd be looking at is. Not the test specifically, but what, why are you testing something like, what is the best practice behind it? That. That we would want to. Capture and tell people that you should. Try to cover this, whether they. End up using Kyverno or. Directly. The idea would be if there's a practice like, this is the wrong one. All of that one's good too. There's a practice that. Recommended. That we all recommend. So this is. The one that's been published. We can point out. So. Non-root. So there could be many different ways to test. For the use of root users and containers. That a process is being. Run as root versus. A non-root user. Or potentially. A related thing would be users above. UID 1000. And there's many different ways that you could test this with different, there's different projects that try to test this, including. Cubescape, which we got been on the coffin. Okay. Falco does some testing around that. There's a lot of different ways. So the best practice, we're not recommending. In the working group, we're not recommending. The use of. Specific projects. That's up to implementation. It's the best practice in general. So we'll say, don't run. Not. Your processes. Well, user may say, we're using this project that does rootless containers. Or they say, oh, we've. Refactored and broken things up and we do it. We handle it in some other way. So whatever the best practices, someone could implement in multiple ways. And then, of course, we'd like to be able to test in different ways so that. We're catching all the different, maybe edge cases and different ways that something may. Be seen. But this is kind of be the goal. And I can stop there. We can kind of dive into process that. Many of us know, I guess, from the working group side. I think the least privilege, probably the session notes and that we worked on this. I've been giving this as a reference. For many people, I keep. Opening this wrong one. Get rid of that. Yeah, I mean, I'm just looking at the Kiverno website and list of policies that it's got, which effectively says, you know, these are things. You could be doing to a container as hard as it starts. And. The question would be the open question between those policies and what we're talking here would be, what is the need for doing that in the first place? What helps with that? And, you know, why does using one of those policies improve matters? Why would you want to make that decision? And, you know, why does using one of those policies improve matters? Why would you want to make it a default of the cluster? So you've kind of got to join the dots between, well, you know, we strongly recommend you do X. And the reason we recommend you do X is this reason. Can you give an example of a policy and we can take a look at it? I guess they have a best practice category. Why not that one? That is one example. We can take a look here is dropping all capabilities. Yeah, if you go down, I think there must be, yeah, drop all capabilities. All right. So this would be, I mean, it's literally labeled in your category best practices. So if we said this was a. A best practice that we think the CNF working group should promote. It's a recommendation for service providers to adopt and say, we want everyone that's creating these, and it's a best practice for people creating these network and applications to adopt when they're building them. So we're saying, we think you should drop all capabilities. Then what we're going to want to do is go through and communicate that. So this is kind of the quick summary, which would be related to what you're going for here. Capabilities right here. So all of these should be a drop. That's kind of the summary. And then you go in and talk about the motivation. Here's our goals. So how is this going to help? So we're wanting to communicate to the end user. Why do, why are we proposing that you drop all capabilities. And then you can kind of go in here and talk, talk about it. One of the important areas is going to be a user story or use case. So for the non root, there's a whole bunch of reasons to do it. We have a set of user stories. Under this area called supply chain attacks. So then this, these also could be applied to other best practices. But the non root is referencing them because we're saying, if you have a compromised update, you have some type of security bug in the, the application. Then if, if you're running non root, then it's going to have less effect. Probably just by thinking about this, these drop all capabilities would be able to also reference that same set of user stories.  So potentially this whole section here on non root would be usable for a lot of people. So that would be a good practice of drop all capabilities. Yeah, I think the question that's coming up. The question that's coming up in my mind, if you were to use Falko, is what you're doing is effectively of changing defaults. Well, you're changing default behavior of Kubernetes in as much as a container that would run on a foot Kubernetes without Falko will not run in the way you expect. Sorry, not Falko. The question is how do we fold, fold kind of enforced policy information like this that would either modify or prevent a pod from running with an application. If a container requires capabilities, then you know, thinks it requires capabilities, expects capabilities, then Kivano will either prevent it from running or make it run in a way that it's not expecting. So the question is how do we follow fold. Is there an application that does not expect that to be working. Are we saying, for instance, that we insist that Kivano is installed with a set of policies on any pod that you use for network functions. Yeah, so this one. Yes. So basically, this policy that drop all. That's going to initially drop all the capabilities and only add the capabilities based on your application requirements. That way, you know, the way we are explicitly mentioning the capabilities that we only need but before that we need to drop all the capabilities. I mean another example of a similar thing that Kivano seems to want to offer is for instance, preventing anything from accessing the host name space, which to my mind is a very good idea. Because if I allow a pod to access the host name space, I'm basically giving it a power to destroy the cluster or alternatively escalate its privilege in the sense of, you know, find out what else is going on the cluster modify the cluster, change the cluster's behavior in a way that means that the infrastructure is not independent of that application. It might break because of this application. So policies like that potentially a good idea. And however, if you are going to say that you should use Kivano on every cluster to ensure this happens or even, you know, Kivano is an option to use on a cluster, then it comes with consequences because an application may, you know, there are three actors here. There's the people providing the infrastructure, the people providing the application and the operators. If the infrastructure prevents things that the application delivers did not expect, then, you know, the operator is going to find when they bring the two things together, the application doesn't work. So you might argue that another way of phrasing this would be to say, you shall not use this and then a best practice would be use Kivano to enforce that. So the Kivano part should be separated. So that there's, if you're, we can have a suggestion recommended, you should drop all capabilities. And then we were checking for that. And as far as someone that says, hey, we want to have as much as these as possible, then we could say, oh, you did great. And then for those who say, no, you must it's required. We will not let you similar to non root. So on some platforms, they don't allow root. SC Linux platforms, you can't run as root. So a service provider could say, no, we will not allow it. And we're going to have denied by default. And for those, they could require that. But I would say the requirement to drop all capabilities. It could be, it could be a completely separate like requirement from, I guess it's a, it's a, it's a different decision to say it's a must versus a recommended. And a different one again to basically modify the containers that think they're going to get privileges to enforce that they're not as well. You know, checking that they do drop privileges one thing, adding the drop command is a separate thing. So there's, there's also a, or reject them. You just don't allow it to deploy. There's also another thing to consider as well. So the drop all capabilities, even if you don't end up enforcing it and saying it's a must, you are able to say that if, if drop all capabilities fails, as in you decide that you don't want to run the drop all capabilities, but you still see that the test itself that determines whether capabilities are present fails, then that could trigger and not it.  And you may have exceptions as to why you don't end up dropping all capabilities. And some of those exceptions may never be resolved, but at the very minimum, it gives you an abley of where you're, of where some of your, your risk is at. So it's not just everything like, don't run it if it doesn't fail or if it doesn't pass, it could be just audited if it doesn't pass. Right. I think. So these, all these policies, right, they can be run in two modes, either enforce or audit mode. So you can, let's say you don't want to run it again. So workloads, you can basically run it in audit mode. That way it will just generate a policy report saying that, hey, this particular resource violated this policy and here are the details, but that workload will still be able to run it. So that should not really block you from running your applications. Hmm. Yeah. Can we, can we go back to maybe start building some potential ideas based on this? Like we, we put out best practices. Yeah. I think that we have to differentiate between best practices and what is enforced. These are two completely different things. And I asked, and I agree with the iron that in that, that, that there are, that we can break applications, but, and it's not a good idea. We have to, but as a best practice, it is the best practice to drop all capabilities. It is, it is, but it is the best thing to do, but you have application, which must have those capabilities. So with either. Yeah, I think all I would say is that. What we're doing here right now is probably rules which are defined by their exceptions. So the auditing possibility here that this is fishy and you need to understand why this is happening is probably more useful to us than you ain't going to do this. And we're going to stop you. I would love one day for there to be a platform where in fact you can't have capabilities. It's simply not possible, but the problem with a platform like that right now is given there aren't very many options for running CNFs, then I don't think you get a CNF to run on it because they're all going to want to privilege for some reason. So the auditing possibility seems like the more useful one. Yeah, the in general, when you model trust in this area, the entire goal for this type of an auditing path is to determine do I trust this thing and per and how do I trust it. And so generally you want to, we don't have enough information here to be able to tell what the context is, whether I'm given things should or should not have privileges. So instead we have to enable the operators to be able to tell whether to have the conversations as to whether they should trust something or not. The second part of on it is time based because things change over time. So how long do I want to trust? Do I want to trust something for? There's a there's a third aspect of trust, which is whether it's symmetrical or what stress is not symmetrical, but that's we'll leave that part out. So just based on the first two, what generally from an audit perspective, what we want to be able to say is this thing will run and we'll give it an exception for a period of time. It's best practice to re-review the, the capabilities on a regular basis. And you continue to understand your, your infrastructure. And you could also make different decisions where maybe there's an update and you don't need these privileges anymore than you can drop them. So, so I would add a time based component to any, to any audit in this particular path if, or to any exception to this path. Well, the other thing that I was thinking, and also regarding what Fred said, is where are the, well, Taylor mentioned about different implementations. So if those implementation can allow us to treat those exception as, as Fred mentioned, or they need to modify the way to handle those exceptions or. So I think that we have to be also connected with the current implementation. You talk about Q and no Falco. So can we do those things there? Or we have to request changes or. Where would the changes be? Well, I would just think. Are you saying in the projects? No, yeah, in the projects. Absolutely. I mean, if ideally we have a two way conversation going between. Or multi way. So between projects and the working group between projects and the test suite, which is trying to test those practices. We want to have a two way conversation and, and improve the projects. As well as improve the best practices and the test happening. And then of course we, we also want the same with people creating. C&S or consuming them, the service providers. It sounded like there was a proposal for a. For something around. Using having policies of some type and there's different policy engines. So having policies. And creating. And having them run and do checks on a regular basis. And I don't know exactly what we would say on that. Because you could say they run. Policy checks run on every deployment policy checks run. But you know, what happens is someone pulls in updates. And it doesn't end. Inline updates. So do you want to check every hour? Do you want to check every day. And have alerts or are you just running a report and sending a report once a week? So there's a lot of different ways to do it. But it seems like we could potentially write something up. I don't even know if this is would become a best practice. It might become like more of a. Just another document, a white paper document that we could. So we don't just have to create. We can create these best practices that we're doing. Like this. We have user stories that we're doing. And we could also have other documents where we talk about. You should do audits and regular checks and policy stuff. We could have a paper written up just about policies. Are there any other practices that we want to write out? And we can take them straight out of this or someone has some other ideas. Taylor, you remember I had to, I had. We discussed to shortly to ideas regarding the network. Best practices around the protection of the. Kubernetes control plane. I don't know if we should talk. Discuss this. Here or what are they? Let's just add them in. Yeah. So, um, There were, or you can put them in this. You can drop them right here in the. Yeah. So I will try to do it in parallel, but, but to, you know, to put you into the discussion. The idea was, well, we have two basic network. Protection concepts, wherever basic concepts around the, the control plane of Kubernetes. One is the API server protection. Making sure that the API servers only. I'm answering authenticated users. And the doesn't enable insecure port and stuff like that. What is the control? There is no. There is not one yet. I have to insecure. Wait a second. I have to look at it later. We'll go ahead. I'll just type it in. Whatever just the words, just use English words and we'll do it. Okay. So first of all, API server protection, making sure that. Authent only authenticated users get answers from the API server. This is one thing. Which, which also in which we all usually include also. The enforcement of our, our back. Which we can discuss whether it is really how deep it is related or not. But from what from our perspective, it is important to enforce that the greatest cluster uses our back. And anonymous user is that it doesn't have any access rights. And the second is actually is not is, is, you know, I'm using public internet text less from, from, from API server. So, you know, from the public internet, you cannot access. The API server itself. Which are with the same thing that this is our two bay very, very basic. The Kubernetes API server. Yeah. So, again, this is in the sense of telcos it isn't a, I think that it's less on issue. Okay. But still, I think that this is something as a best practice. It's something that, you know, should be there and should be clear to everyone. And also, okay, we, we, we suggested also to make sure that every one of us is, you know, where it is control playing components, like, you know, cubelets and, and scheduler and control manager and stuff like each talking to each other in TLS with, with bilateral authentication. Which authentication TLS with what? Mutual TLS. Oh. So that these are really the, the one on one of the network security around the Kubernetes components. And these should be enforced. I will, I will follow up and I will add, okay, the controls. We are adding right now also to make sure that these are covered in our test kit, but this is as again, this is the best practice. So, for example, a public access to, to cover this API server is not necessarily something okay that can be easily tested. Since, you know, how do you prove that you don't have public access. You cannot cover, cover this, you know, 100%. Yeah, these were the things which, which I thought would be, you know, good things to, to best for best practices. I actually think that some of those might be related to stuff that we had listed for lease privilege. Yeah. Select the API access. That's similar. It's not exact, but that's similar. So that's good. Continue on that. Security controls. Yeah. I feel like there was something about our back. I'm not seeing it now, but maybe it was in the actual notes. Yeah. Here we go. Look at this. So we have been, we have this whole section here in these working notes on our back roles and authentication and a pretty, pretty decent right up in several sections about this. So this would be content that could be pulled for something like around our back. We get, there's a lot of things on our back. So we can, the more specific we get on something, you know, potentially the easier it is, but whatever, whatever it is, I think we got a lot of content on our back. And likewise. So we have, I think on these like drop all capabilities.  These will number one, we have like exceptions and stuff, which Ian was talking about. Like when, what do we do with all the applications that need it right now? This no privilege or capabilities granted. So this is kind of related to that, what you're suggesting. It's pretty much the same, but it's definitely something we've thought would be good. And I think there's probably other content here besides the supply chain attacks. So if you can, you probably take this non-route as a good example. There's also. Like, literally like, here's, here's the template that anyone can use that explains what it's about. Actually, here's the template. And this says, what's the process? What do we want? But here's the template. And, and this. Yeah, I'm sorry. I was saying, if you could share that link for the template. Yeah, sure. I'll just drop these all in here. So. Example are creating. Creating a new best practice proposal. So example, non-route. So we have a template. Yeah, let me grab that. So probably. User story. Example. Supply chain attacks. The, all of these can be adjusted to. As needed when we created this, it was without before having an example. So. We have this section, user stories, use cases, it can be whatever makes sense. The, the main point here is. I'm not seeing it. There we go. To give context to the end user. Okay. Why is this relevant? This best practice relevancy. But if, if you are giving relevance in another way, that's okay. It's not relevant. It's not relevant. It's not relevant. It's not relevant. These are just. To help guide us, but it's not. Strictly required. There's some of the things that we've marked as required. And if you feel like it's not relevant, then come back. Same thing, Ben, on anything that you all come up with here. It's not relevant and then just come back. It's we're trying to, we're trying to give recommendations with enough content that it's not relevant. So let me adopt that. Across, across our company. We think it's a great idea. Yeah. All right. Is there any other ideas for potential practices that anyone wants to, and it doesn't have to be, or some of these are, I would say more security oriented. So we don't have to just do that. But any, any ideas, whether it's more security or other stuff. I think it's a really good one. For people. There was one more. Which, which requires read only root file system. I don't know if that's already part of the CNCF. Yes. We require that potentially. I don't know on the test suite side, there's a lot of different things there, but what is it if we're talking about it from a best practice standpoint? Yeah. This policy ensures that, you know, there is only, you only have a read only root file system. All right. Yeah, this is, I think there's agreement between many different projects. And it's probably a good indication that it's a best practice. Use read only root file systems. Right. The others as well, but. I think you'll have something about read only. FACA has read only there. So if we have, you know, a lot of different projects that are focused on Kubernetes and cloud native and everyone is saying you should have, you know, you know, you know, you should have read those as well, but. Let me pull those one second. So Taylor, can you go back to that? No. Website. In the best practice. Yeah. These are. Checking the deprecated API is one of them. Ben, would you. Add a link under this. Cubescape area to. Set. Yep. And you could put it right here and then people can go check those out. Sure. Okay. I will do. Thanks. So. Check for deprecated APIs. I know that there's several. Projects for this too. There's been. There's one project that's actually used. With the SIG testing for checking. Test coverage for all Kubernetes APIs. And it can tell you whether it's. Alpha beta or production. I'm not sure if it checks for. Deprecated APIs, but that's great that. Kaverna can do that. So check for deprecated APIs. I think that would definitely be one from an audit standpoint for service providers. They'd get noted if an application is using that. So that they'd be warned from an ops team perspective. Before they upgrade their platform. What applications are going to break. And what may have more bugs potentially, I guess. Yeah, so. So Taylor, I, I think one more thing was I was working on. Integrating those policies, right? I have made some progress on that. Especially, you know, formatting the output. I think with the help of a caution. Now it's more formatted. So I'll update my policies accordingly. And probably. Show like a demo sometime this Thursday. Okay. Does anyone have anything else. So even if you're dropping capabilities, it's still a good idea to, to not use root. There's other issues besides capabilities that come in. Yeah, that's all we're going to keep it separate best practice. Drop capabilities. Don't set your container privilege to true. Don't use root. We just keep piling them on. So the more you use the safer you're going to be. Perfect. And someone may decide to only use a sub set. That's fine. As long as we can tell. What are you, what are you doing? Any other best practices. That in the mention. In the fourth one, not just often only authenticated users, but also and, and services, because not every, not everything that connects to Kubernetes API is a user. So I guess we can map them to the user. So we may not make too much sense, but.  Sorry, can you say that again? The strict image registries. Let me bring you the link on second. That you can get this from, which is a perfectly good way of ensuring supply chain security. So, or assisting on it. Yeah, I just think in the chat. Yeah, the point is to limit from rich image registry. You can pull to the pods. Probably argue against this one. I want public and secure. But that has to do with signing and other stuff. Yeah, it depends on Taylor. It certainly depends on how you play this game. But on the other hand, if we put it forward though. Yeah. Yeah. Signing, signing may not be enough in some, in some use cases. Absolutely. And so, for example, I may, we may end up with a, with a signed. Root image or let's say like, you pick a database and I won't give a specific database name, but let's say you have like some database that you use and that database sort of be compromised and an image uploaded, then you start pulling from that specific one rather than the ones that you bet. So generally, what is it happening is that the, the, the, the, the, the, the, the, the, the, the, the, the, the, the, the, the additional scans that are put onto the private repo and the organization may want to ensure that those scans are performed before they deploy anything. So they won't want to pull from public for, for that specific reason, even if they're not modifying the images themselves. Yeah. I think it's questionable how well it's any more secure than basically signing things as trusted because you've done the scan. You've done the scan. You've done the scan. Having a trusted testing place that signs after testing, scanning and testing. But anyways, we're getting into how would you design all of this and restrict image registries is definitely a, a way of helping to secure. Different paths. So any others. That someone was put forward. And if you think of something later, you can feel free to come in and add it to the notes. Or go into another good place to add it later. Would be put a discussion item. If it's related to something here, feel free to add it or just create a new discussion area. And then we can talk about it, you know, a following week. If you really think this is a really good one, we definitely should do this. Then please go add an issue. So we have, we actually have one about privilege flag. The Ian added quite a while ago. Don't use privilege. So this is one that we could, the privilege flag specifically. So that, that capabilities one, the very first one. Might be something that we already agree. You should drop capabilities. So go ahead and create an issue that we should propose as a best practice. And then you can start iterating on it with a draft. That you can share and we can all work towards creating. And then we create a pull request. We'll be good to go. So with that, Ian, why don't you go ahead and open the pull request. We'll move on. We're nearly at the top tower. Open what pull request exactly. Oh, review the open pull request. Yes. Okay. Well, there is in fact, only one, which is the one that we've had open for a while to create air gap environments. Oh, well, sorry. The pull request is called create a cat environment. But yes, to, to discuss the best practice of using an air gap environment and the implications that it has. I don't think there's much worth discussing on this meeting. And in any case, I don't think in six minutes, we would get very far. But, and it looks like we've got a few open bits of commentary that haven't been addressed in the pull request at this point in time. But I think I would just simply suggest that people have a read of it if they didn't know it existed, or if they haven't looked already to get a sense of where it's going and just so that they can add their own comments on it. So this is user stories, which potentially could be referenced by any of the best practices that we've been talking about or other best practices later. Yeah, I mean, I think what Jeff, I'm not, I'm just skimming this, I have to admit, I'm a bit lax on this, I haven't done my own review, but I'm just skimming this. And I think his, his storytelling needs a bit of work. But the idea is that we know in many, if not all service providers that when they're doing network functions of whatever kind of software, they don't just pull it from the internet. And they certainly don't pull it on the internet from the end device. They basically distribute it within their network, which is a closed system that they only allow new software images to enter under limited circumstances. And that was the point that Jeff was trying to get across. But yes, anyway, this one's open. It's up for review as we speak. So anyone who's got the time to basically read through it and see whether it makes any sense to them, that would be useful. And we, again, are right at the top of the hour, give or take. So unless there's anything particularly urgent that people want to talk to, talk about for three minutes, then I think we might be done for the morning. Spelling, grammar, any type of updates are appreciated. If it makes it more readable, if you say a word that you think needs a definition, put it in, whatever, any of that will help. Yeah, absolutely. Don't feel that you can propose a change in GitHub. And I strongly suggest you do. If you are doing comments, then, you know, simply putting the change you would like to see is often for small changes a lot easier than basically telling someone else that they've got work to do. So, you know, do make sure you do that. Can you demonstrate, Taylor? Yeah, that's it. We'll do so. Yeah. So this little insert suggestion, and then I can say air gap places. And then if I put that as my suggestion, it shows up like this and then someone can click commit suggestions if they like it. It makes it really easy for folks to move along and quickly take stuff that's been put in there. We can have fast iterations of changes. So please use those. And if you're not using them in your own, then I suggest you do so with your pull request. And if you mess up, you can always delete and try again. Like I just did. All right. I think we're at the end. Unless anyone that's muted needs something has anything else. All right, and I think we did it. Okay. Thank you, everybody. And we will see you all next week. Okay, guys. Thanks everyone. See you. Take care.


Hi, everybody. I just want to show you how I quickly process Facebook notifications. So let's go ahead. I'm going to go to Facebook. And I'm using the dark theme on Facebook, so it might look differently than yours. It's the same thing, though, just for reversed colors. And so to process notifications, click on the bell icon on the top right. And you'll notice that they now have the ability for you to click on the unread, which then filters only by the ones that you haven't yet clicked on in terms of the notifications. So what I usually like to do is click on see all first. And then I just basically scroll down. And I just keep scrolling down until they load all the recent notifications. They only give you notifications, I think, up to like two days ago. So usually not that many. But then I scroll all the way back up. And you can see the ones that have the blue dots are the ones that I haven't yet cleared yet. The ones that don't. I've already cleared. Let me explain soon what it means to clear notifications. So most notifications are really nothing you need to respond to because they're just people who heart something you commented or wrote or they had other reactions or they liked it or whatever. So most of them you don't have to respond to. The ones that you might need to respond to are the ones in green, which people commented on your post or replied to your post or replied to your comment, or they may have posted in the group that you're interested in, which is the blue icon with the three little people, people in the center. So those are really the only ones that I look at. The rest are just very nice, but I don't have to respond or really do anything. So what I do is I click on the unread button. And then once I'm in the unread button, now I'm only seeing the ones I haven't yet cleared. Okay. So I scroll to the bottom again just to make sure I see everything. So I really go from the bottom up just because that way I'm guaranteeing I'm seeing everything. So I've already scrolled to the very bottom. I can't go any further. And then again, I just ignore why I don't ignore, but I don't have to do anything with the ones except unless they are no friend requests, you know, might want to process that. And then the green ones and the ones with a person that those are the only ones that I really care about. So for example, if I click here, then it will open up to me what the notification is. So I'll just give it give it a heart care there. And then basically again, I click on unread on the top right because sometimes it's toggles back to all. So unread and again, there's nothing else. I've already looked at all these other ones. So let's say I'm all done with everything. Then I click on the three dots on the top right and then click on mark all as read again. Click on the three dots top right, click mark all as read. And now voila, they've all been cleared. They've all been well processed. I guess they've all been cleared. I just haven't, I haven't clicked on these yet, but I will in a moment. So I hope this is helpful and hope this helps you to be more efficient with your Facebook notifications.


So today I'm talking briefly about the metaphors we use when we talk about data, and some of this is coming out of my research from the last year at the Oxford Internet Institute. So when we do Google image search for data, we see that data is really taking literally here. It's all ones and zeros. It's cool electric blue that evokes the computer that the data is related to, but it's still really intangible. So we have to use physical metaphors to make this understandable, embodied, tangible, legible. And to do that, we use metaphors. We are borrowing from Lackoff and Johnson's concept of the way we talk about metaphors in our language and that govern our thoughts. And so all of these sentences here illustrate how we metaphorically think of time as money. We equate time with money. But it also illustrates how that analogy enters into our thought and filters into our language and frames the way we see the world even if we're not kind of conscious of that relationship. So I wanted to look at how the tech industry talks about the metaphors we use to talk about data. So when we describe data as the new oil, it suggests that there's great value in the natural resource to be mined and refined, but it also suggests that it has to be handled by experts and by large-scale industrial processes. When we talk about data as an exhaust, we're talking about it as a byproduct of our digital transactions, but it's also suggestive that it's wasteful and pollutive and it might not be interesting. When we talk about data as a deluge, we talk about it in liquid fluid terms, but we're also talking about its overwhelming scale in disastrous terms, something that we can't control the flow of. When we talk about data as a shadow, we talk about the fact that it's attached to us that might be tied to us, gives an indication of the shape of who we are, but it's incomplete and possibly not necessarily representative. So these metaphors all get at the intangibility and obscurity of data, but they're really impersonal and dehumanizing, and they don't address the individuals to which the data refers. So I wanted to look at more personal, human-centered ways of relating to data, and so to do that, I looked at the quantified self-community, who are using apps and wearable sensors to create data about themselves and their bodies and to understand their lives. In some ways they're an early adopter group, but some of these tools are becoming much more commonplace in the consumer world, but their concerns and challenges reveal some of the pressure points that we all might start to be concerned with as more of our data and more of our lives turn into data. So I looked at how the quantified self-community talks about data and their personal relationship to it. So in the quantified self-community, when we talk about data as a mirror, we suggest that it's something to reflect on. It shows us, it is a tool for reflecting on ourselves and how others in the world see us, but it still might be a distorted view. When we talk about data as a self-portrait, we're talking about the artistic, interpretive, creative potential of data and constructing a sense of self, but it still might be granular and bitty and not yet photorealistic. When we talk about managing what we measure with data, we're introducing a very mechanistic objective view of the self inspired by Taylorism and scientific management. And when we talk about data as a practice, we might think of self-tracking as being associated with navel-dazing and narcissistic tendencies, but in talking about it as a practice, we're also getting at the fact that using data as a mode of introspection or practice towards self-knowledge. So why does it matter how we talk about data? The introduction of new technologies into our everyday lives, we need ways of familiarizing ourselves with those technologies, and metaphors have always helped with that. So when the television entered the living room in the 1950s, we framed the cathode ray tube with wood, literally domesticating it as furniture in our homes. And we see this when we use visual metaphors in the physical world that bring the physical into the digital to familiarize ourselves when we have new computers in our pockets. We call this skeuomorphism in design, and these visual metaphors teach us how to use technology by relating it to old technologies that we're familiar with, but they begin to also fall away as the technology becomes more familiar. So remember, maybe some of you students don't remember, but remember when we talked about the internet as an information superhighway? We wanted to talk about ideas spreading through space and time, and the highway system was our best analogy to understand that kind of interconnectedness and scale. So my provocation to all the digital problem solvers in the room is to be conscious of the ways that these metaphors influence how we approach our problems. To take a second look at the way it frames, the way we think about technology, is the way we use them, the way we design them, and the way we flip them.