OK, let's make a start. So next up is day two operations best practices, Janet from SignalFX and Ben from Mesaspear. Cool, thanks. OK, so we're doing day two operations. The main impetus behind this is, so I'm primarily in a customer-facing role. Over the last year or so, we noticed that there's much more emphasis being placed on operations versus deployment and installation. So that's a great thing, right? That means that Mesaspear is finally in a place where doing the generic install is simple enough. And depending on the company size, you could be a small startup. You could be an enterprise. You could be a service rider having a team ranging from one or two individuals to an entire DevOps team. The most common theme that we saw was people want simplified streamlined metrics pipelines. So that's what we're going to be talking about today. So the agenda is we have a brief overview. We're going to talk about all the different categories of metrics in Mesos. And then we're going to take a deeper dive at the Metrics API. We've actually got a live environment. We're going to have a demo where we run a script against the API, pull in that information. But most importantly, we're going to look at the data in a back-end monitoring system. And we're going to interpret the data, look at the different visualizations, to give you guys some ideas on how you can build dashboards around what's meaningful to you. So I've got a couple of marketing slides here. I'll zoom through these pretty quickly. But generally, for most companies, it's all about data, right? So in most cases, what they want is a single platform that runs on top of any infrastructure, cloud, private cloud, you name it. And then this will connect with billions of different users and client devices, as well as, increasingly, like IoT devices. So one example is we were talking to a customer in Singapore. They're actually running a project called Smart City. So things like schedules of buses down to the minute, they want to be able to optimize. And all that requires additional sensors and data. This is largely led by the developers, right? So we're transitioning from a model where we've got traditional enterprise applications. So these are monolithic applications, single code base, very brittle. And then they're persisted into relational databases on the back end. You've got Oracle SQL Server. Into more cloud-inv applications, right? So these are microservices using kind of stateless applications running in containers that are lightweight, flexible, modular, communicating over restful APIs. And then increasingly, companies are adopting all the latest open-source technology. So Spark, Kafka, Cassandra, Flink, TensorFlow, so on and so forth. And then the second thing is, apart from microservices, customers want to build out data pipelines. So this involves ingesting data from all these different sources into something like Kafka. And then persisting that into, say, Cassandra or HDFS, running analytics on it using Spark or Flink, and then writing applications that act on that particular set of data. So the thing to note here is that these are all very complex distributed systems for the most part. And each of these has metrics that operators need to be aware of. So the goal is really to paint a picture, this holistic view of everything that's running in this particular environment. Now, for operators that are looking at applications, we talked to a bunch of customers. These are some of the common challenges that they face. Scalable capacity, dynamic architecture, load balancing. What is scalable capacity? So this refers to when you have an application, the application is elastic, it's ephemeral, it may scale up and down. We need to know, based on the characteristics of the application, when we need to add additional computer or networking infrastructure. So that's identifying what's important relative to the application, and then scaling it up and down. Dynamic architectures, this means that, so now we have this new developer pattern where we've got these modular services that talk to each other. And the nice thing about that is you can swap out services. You can exchange one component of your application, do a blue-green deploy, or whatever. But the idea here is that each application is now a set of constituent services. So instead of just monitoring for a single process that's running on a particular operating system, now we might have tens or hundreds of different applications, each of which has its own tasks. Could be hundreds of tasks per application. So we need to understand what that looks like and how to measure that moving forward. And then load balancing. This is pretty straightforward. All this says is you have an application. It might have one or more instances, typically using either an east-west load balancer or some other load balancer, like an ELB, or maybe an F5 sitting in front. How do you make sure that the load balancing algorithm is performing properly over time? So next, we're going to look at metrics. So metrics are just characteristics measurements that are used to determine the health and performance of the system. How is my cluster doing? How is it performing over time? Do I have any specific issues with my infrastructure? How many masters do I have? Is the leading master changing periodically? And then most importantly, it's really about the application performance. So part of the challenge previously is how do I get the application metrics from the container running in my Mesa's environment? We're primarily going to be covering the first two categories, so infrastructure at CPU memory disk, as well as the application metrics. But you can also capture things like users, things like login and usage for use cases, such as charge back. So increasingly, we're seeing more and more customers wanting multi-tenancy out of their Mesa's environment. So charge back is going to be key for being able to understand these different characteristics as far as how much resources each individual group is consuming. OK, who's seen this diagram before? So this is like the canonical Mesa's architectural diagram. Again, the goal is just to reinforce the fact that there's different sources for all these different metrics. So from ZooKeeper to the Mesa's masters to the agents to the frameworks that are running on top of the Mesa's environment, which are scheduling tasks, and then down to the executors who are running the actual tasks. So the metric sources, so we have the Mesa's metrics. We also have container metrics, so these are more or less OS level metrics that we capture. And then for the application, what's really interesting is things like requests for seconds, latency, active users, response time. So for the masters, the agents, and for Marathon, each of these has their own metrics endpoint. And that's what we use to capture the information and funnel it to our backend system. So I won't go through these in detail. I'm going to actually ask Janet to show off a couple of dashboards that she built to convey the same information. So we're going to take a quick look at this observability metrics page from the Mesa's documentation. It details all the metrics you can get from the different resources, like the master nodes, the agents, frameworks, allocators, et cetera. So lots and lots of data coming in. It also outlines some recommendations for things you want to look out for in your cluster to know if it's performing normally or not. So using that information, we had built a collective plugin that will grab metrics from the master and agent nodes and then send them off to our monitoring app. And then here's one of the dashboards for that. So it's the problem indicators. And as an aside, for the charts, we use digraphs and D3, the JavaScript libraries, to build these charts. So this first chart here on the left, cluster health, it gives us an idea of whether or not the agents are performing normally, taking a look into that chart. We're using the agents connected metric, comparing that with the active one and then seeing what that ratio is. So luckily for us, our percentage is 100%. But if we wanted to know if it's performing less than 100%, we've got these rules set up to notify ourselves if it's within certain ranges, how severe might the problem be. Going back to the dashboard, another example, number of leading active masters. You want that to be one, right? Too many masters, not good, too few, also not good. So we got this one that sums up how many are being reported as being active, as well as master uptime. Something for that, what we look out for is if it's below the recommended value of five minutes, or if it's below, say, a minute for some duration of time, that's indicative that it may be flopping. So we'll notify ourselves if that's a problem. So Jan, I have a question for you. Totally unrehearsed. So when you're actually building these dashboards, can you talk about how you decide what to bubble up based on the requirements or whatever? Like what's important to actually convey on these screens? That's a great question. So from users we've talked to, people are interested in knowing are my tasks running, is my workload being handled? And if not, what is the thing that's causing, preventing that from happening? So we organize information mostly around the infrastructure, so like the CPU, disk memory, as well as what's going on with the task, like what is the throughput of that? So if we want to drill down further, we have a dashboard with the clusters overview. So this shows me all my clusters, what's going on in them, my CPU memory, something maybe interesting is the number of tasks running. So in blue here we have how many are running currently, and then we compare that with this red dotted line of the week over week growth. So looking at past data, comparing it with the current data, if your growth is continually increasing, you may need work capacity to handle your workloads. So going further down we have another dashboard of specific cluster, what are the tasks running in that? What does the CPU memory usage look like? Actually let me go back one to here for the overall clusters view, something we commonly use is comparing percentiles. So in this chart we have the CPU percentiles all over host. So there's something running in here that's taking 100%, that's the max value as well as the P90, whereas the median or P50 is only around 33. So we have this other chart that sorts all the hosts by their CPU usage and we can see that the top two take 100%. So maybe we wanna log into those instances and see what's going on, if that's something we're not expecting to happen with the current expected workload. All right, so cluster detail. Per node we have the master node view, so how many tasks are running on that specific master node, the uptime, frameworks, tasks running. And then similarly for the agent tasks, uptime. Yep, so we're gonna switch it back to slides. Give it back to Ben. Okay, so thanks, Yanan. So I'm not gonna go through all these, but again it's examples where you can look at particular metrics and then based on the current value, understand what's happening with your cluster. So for instance if your uptime for the master is low obviously the master's restarted and then if your number of elected masters is zero, right, then obviously there's some problem with your cluster. Okay, so that's from a Mesa standpoint. Next we're gonna look at container level metrics. So traditionally what do we do for traditional apps? Typically you'll have your application running, you might have a specific agent that pulls metrics from that particular application. But when we move to container as world, sure you can still do this with pods, right? Just have a sidecar container, pull metrics from the primary container. But the problem that we found here was that this approach isn't very scalable, right? And it's kind of unnecessary for print. So what we did is we build this metrics module for Mesa. So the great thing that it does here is you get basically the application metrics for free, right? The metrics module is bundled in with the agent as an isolator and when the Mesa's containerizer brings up the container, it will expose these two environmental variables. StatsDUDP host, StatsDUDP port. So as a developer all I need to do is write to those environmental variables and the metrics module will capture that information and then it's also gonna tag it with context, right? So that's the second thing, is understanding the context surrounding those metrics.  So this is the general architecture. As you see here, we have a set of hosts. Each of these hosts has your Mesa's agent with the metrics module. We have containers one, two, and three, right? And we have applications that are writing to those environmental variables. So those are sent to the metrics module. The metrics module will then forward them to the collector, which is a system D unit that runs on every single host. The collector is also collecting stats from the operating system as well and then we're exposing a metrics API, which you'll see shortly. This allows you to easily pull the API, grab that information, and send it off to whatever backend of your choice. I'll quickly show the environment that we have here. So we spun up an environment on AWS. We have total of eight nodes, so seven private agents, one public agent, and then we've got a variety of different services. So we have Cassandra, Kafka, Kubernetes, and then we have a marathon app. So this app, all it really does is it emits stats D, so you'll see that as part of the demo later on. Okay, so I'm gonna turn over to Janet who's gonna talk about the API. So using the metrics API, we can get information about the cluster. It's like about the host, containers, applications. And this is a collection of basically get requests you can make to pull from information. So here's an example. It's getting metrics from a specific agent using the agent ID and then add some resource path and then takes two headers, the accept header, for the response type, and then an authorization token.  You'll get a list of data points that come back and then an object of dimension properties. So I'm gonna go into detail now about what these data points and dimensions are. So a data point is a single value you'll get for a specific metric from a specific source at a specific point in time. So there's a few attributes that are inside that data point. First three hopefully are self-explanatory metric name, the metric value, and the timestamp at which you were getting that data point. And then there's metric type and dimensions. So the message exposes two types of metric types. There's counters, so like it sounds, it's a count of something happening. It's increasing in value. So like the number of successful tasks, number of failed tasks, number of agent registrations. In comparison, there's gauges, which is a value that could increase or decrease over time and then it's like you're getting a snapshot of the value at a specific point. So it's something like the current memory usage in a cluster, the current disk space being used or a number of connected agents. And dimensions are key value pairs that describe the source of your metrics. So it's a one set of unique set of dimensions will tell you a little bit of information like the host or let's say the region that these values are coming in from. And with these dimensions, you can help correlate your data points. So you don't just have your random values, you can actually link them together into patterns and identify trends over time. And with the dimensions, you can classify your data, helps you aggregate and group them, do some filtering. So it's a way to manage your data so you don't just have like a random collection of numbers. Here's a site comparing the metrics versus dimensions. So examples of metrics are like we've seen like CPU idle, disk operations, load, versus dimensions are descriptions of the sources. So like the data center region I mentioned. And when you combine them, you can make a time series. So the data points and dimensions define pattern or a plot line you can actually put into a chart and look at your data in a more cohesive manner. So like in figure one, we have CPU idle, one plot of that. So that's one set of data points coming from one source versus in figure two, we have two different plots because we have one that's in the data center in the east and then one coming from a data center in the west. So when we plot them together, we can compare them based on their dimensions and do groupings and whatnot. So while using the metrics API, a few things I noted that may be useful if you're using it to know. One thing is you can get an authentication token using this post request. So off login gets you that token, you'll send with every get request you make following that first request. The timestamp of the data points that come back may vary in format. So if you're trying to parse that timestamp out, you wanna look out for longer strings versus shorter strings. Another thing to check is the data point value. So it should be a number typically because that's what you'll plot on charts and compare against each other. But for example, in this data point we got back, the value was not a number. And in general for sending metrics, like if you're making your own metrics and sending custom values, some tips for that, you may wanna structure your names hierarchically, but a way to organize your metrics. And within those names use a consistent dilemma like a period or a dash, which could help with wildcard searches. Also if you're using dimensions on your metrics, you don't need to put that same information in the metric name. It just kind of clutters in, makes it longer than you really need it to be. One thing we see that our users doing that really helps what works against managing their data is using dimensions with high cardinality. So something like timestamps or really long error messages or IDs that are only used for a very brief amount of time. Those kind of things will not, you won't be able to use them to organize, to group and aggregate your data because it's always changing. There's not gonna be a way to link your data together with values that keep varying very frequently. So I just wanna show how we send the data to our app. We send post requests to this URL with the content type token and then lists of the different metrics that we have, the gauges, the counters. So I'm gonna just show that script that we have that gets metrics from our DSOS cluster and then sends them off to our app. So using that cluster that Ben had showed earlier, which is gonna kick off the script, it will do the login and then send all these get requests to the cluster every 10 seconds to get everything about our different nodes, our containers and our apps running in it. So while that is filling in into these charts that I had built before, you can take a quick look at the script. So it just loops over making these requests. We get the host from the master. So master URL here. And then for each host, get metrics about that, get the containers inside that host, get information about the containers and then get all the information about the apps running in those containers. So it's just gathering all this information up and then sending them off into something we can use to take a look at that data a little bit more easily. So it looks like that's still going on. Something I did to help myself find what's being sent in is I added a dimension for the source. So I have the source, the DCOS metrics where I could search for it and then it shows me all the matching ones that I have. And then I built some charts that I thought might be useful for myself to figure out what's going on in the cluster. See stuff coming in yet. Maybe slow, blame network. But let's take a look at some data we had collected in the past. So here's a three hour chunk that we had collecting the metrics. We'll take a little closer look at the container bytes received one. So it has this message here about there being too much data to show within what real estate I have on my screen. So I had mentioned several times we can use dimensions to help us filter out this data. So we can get a closer look maybe by host name. Maybe I only want to know the ones coming from here. So we get a little bit less data that fits more into the chart. You know, zoom in for time span. I can also maybe sum by host name. So then each bar will show me by host what is going on. So let me take off the host filter again there. So we have our two hosts mainly doing most of the work. What's going on in there? And then the different visualization types can help you also see what's happening. So in this, so that one I had used the bar chart for JVMemory with the lines. It's pretty clear there's some to the chart tooth pattern going on. Probably at these points, garbage collecting is happening. But it's very easy to see right that there is definitely a pattern there. CBA user time, heat map, visualization can very easily see what's the outlier, this dark green square. And for disk usage, this bar, sorry, the area chart, it gives us an idea of blocks of time where disk was being used by different resources. And then some other metrics about coffee usage. We had a client Cassandra app running also. So some more metrics about that. Maybe show the one with all the dimensions at the bottom. Which one? Oh, right, so just to see, get a better idea of what the data looks like. That's coming in. Everything to the right of the value column here is all the dimensions we're getting from the different metrics. So you can use that information to help you navigate through your data coming in. Okay, so we've got two minutes left before lunch. Key takeaways, right? So we touched on all three in our presentation, scalable capacity, identify system application metrics that are meaningful, dynamic architecture, right? So your app may be composed of multiple elements. So use dimensions to simplify your overall view of the application. And then for load balancing, again, this is really just keeping track of how each of the instances is doing over time. So if you want more information, we're certainly happy to talk to you, come visit us at our booths. And with that, we'll open up for questions. Nobody? Okay. Yeah, so the question is, do we need DCS? So DCS makes it a lot easier, but no, you could take that and you could roll it yourself. It's open source, the mesos metrics module. So the answer is no, but it's easier if you use DCS. Question? Right, so the question is, I believe it's about like uptime for tasks and jobs and things like that. Okay, so again, that'll be, so typically that's done at the framework level, like whichever scheduler handles that, may expose information. A lot of the new frameworks that are being built off of the SDK, they're all stats decomplying. So they will send metrics automatically and we can pick that up using our metrics module. Okay, any last questions? All right, well thank you guys for coming and we'll let you go for lunch for now.


As a matter of fact, carbon dioxide is portrayed as harmful, but there isn't even one study that can be produced that shows that carbon dioxide is a harmful gas. There isn't one such study because carbon dioxide is not a harmful gas. It is a harmless gas. Carbon dioxide is natural. It is not harmful. It is a part of Earth's life cycle, and yet we're being told that we have to reduce this natural substance and reduce the American standard of living.


The 1397 deployment and distribution support battalion completes a port operation, loading the vessel arc independence with over 500 pieces of equipment in a 28 hour time span. Today, we're loading up the arc independence, estimated at about 575 pieces, including some helos for a couple units back in the states. Port operations are a major way the U.S. Army can logistically move equipment and vehicles and being able to move it efficiently allows soldiers to stay ready to fight. Well it doesn't put stress on the forces because this port and then also our unit we operate 24-7 where we're ready to load up at any moment notice. The 1397 believes their missions be efficient and effective keeping soldiers ready for action. It's just being prepared to if anything should happen anywhere in the world and at each installation we have a timeline of where we should be in the world or where we can be in the world at certain times and I think these guys here this team here will be able to move us there at a faster pace. With so much equipment on the move, the 1397 is keeping the U.S. Army sailing toward success. Sergeant Ian Valley, U.S. Army Central.


Hello, and welcome to the Eric Camineca show presented by Buffalo Wildlings. I'm Greg Royce joined with Stevenson Track and Field head coach, Eric Camineca. Coach, first of all, congratulations. Great, great weekend for your program. The men take home their first ever Mac championship, and the women finish second. So just talking about how it feels to be successful on both sides.  So that's really, really exciting.  The men's side, obviously, the coach's poll that came out before said it was going to nail biter, and it was. You guys won by two points over Widener. It came down to the last event. Talk about that last event and the emotions that you and I'm sure the whole team were going through. Yeah, it was rough. At that point, we knew the women finished second, and that was really exciting. We weren't expecting that. And the men's competition was a lot closer than we anticipated. We knew it was going to be close, but a couple things happened throughout the meet. We got de-queued in the Heptathlon in the last event, and that cost us six points there. And that was tough. And then there was about three more events going on in the track. Pull vote wrapped up. We didn't score any points there. The shot put didn't go the way we did, and so they got a lot more points than we anticipated. And then it did. It came down to that high jump. And the way things were going, Widener had two guys left at that point, and we were only up by nine. I was like, man, this is going to be tough. We're sitting there thinking about we battled really hard. This was close. And thinking that we didn't have a chance anymore. And then it winds up that Coach Roger comes up to me, and he's like, I think we got this thing by a point or two. And it just happened that Clement was able to take a six-place finish, get those three points, and put us up by two, and walk away with the championship. Yeah, obviously very exciting. Like you said, just kind of comes down to the wire. And there are other events, like the 60-meter dash where you had six guys in the final. And that had to be impressive, watching that meet with six guys all with your uniform on. I mean, that was really impressive to have that. We put six guys in that event, and all six guys made the finals, which is just really impressive, and it's exciting. But it's not fair for us, or for me, to really single out any event group or anything, because this was a total team effort. I wouldn't have to name every single guy in the team, because everyone put it all out there on the line. Yeah. Then the women's side, obviously second-place finish. And kind of talk about that, kind of the progress the women's program has made. Yeah, you know, last year, in the past couple years, the women's throwers have always been carrying us. And they did it once again, coming out with like 40-some points between the shot put and the weight throw. Alice and Bishop had a great meet, especially in that weight through. She went from someone who didn't even make the finals last year, and then wait to end up winning it and setting a school record.  And then Kimberly Ham, you know, I didn't even realize where all these points came from, us finishing second. Kimberly Ham and had a fantastic meet. She was responsible for over 30-some points, winning the 60, one to 200 out of the slow heat. She wasn't even in the fast heat. I was able to sneak through there and did a really good job. And then finishing second place in the long jump. And then, you know, Dion Hicks had a ton of points, and Rachel Panick finishing as the rookie of the year really carried that woman's team through. Yeah, certainly an impressive performance, and you set a lot of athletes to be back, you know, obviously for outdoor, and then obviously, you know, for next year. So, you know, certainly the future very, very bright. Absolutely. Now you kind of shift gears this week. You go to ECACs up at the Armory. Kind of what are your goals going into that meet? You know, we're trying to get someone out to nationals. We have a lot of people who are on the verge. You know, Derek Davis now put himself in conversation. Kendall Belzer put himself in conversation, along with Matt Riggins, Aaron Holliday. You know, all those 60-meter guys are there. On the women's side, I think Kimberly Hammond has a really good shot. Maybe Rachel, Richie, in the multi may have a shot. You know, that's kind of where we're going right now. You know, we're going to end this indoor season possibly this weekend or continue on, depending on what happens. Yeah, not as much pressure in terms of trying to win the team championship, so individuals can kind of concentrate a little bit more on getting their mark to get out to nationals. Exactly, and we're not going to really worry about the team's score this weekend. You know, we're going to hold some people back from a lot of the events that they did qualify, and just to let them focus on their main event, to try to see where they can get to the next level, or at least hit that personal best mark. Yeah, absolutely. All right, coach, we wish you and your athletes the best of luck this weekend, and we'll talk to you next week. Great, thank you very much. All right, for Eric Camadeca, I'm Greg Royce. This has been the Eric Camadeca Show.


Hello everybody. Thank you for coming to the session Which will be a round table. We have different panelists that will introduce themselves. So the question we want to ask to the panelists and We hope that you will love their answers Is around containers and all their representing future of infrastructure as a service And how does it position themselves with regard to other technologies? And so for this round table we have Maybe maybe maybe it will come we have four three panelists Simona on the left hand side Jerome in the middle and David on the right hand side For me. So it's a reverse for you, of course And they will introduce themselves coming from different angles working on different technologies So they will introduce themselves and then we will ask questions and if you want to make the Discussion interactive feel free also to raise your hand and ask questions And I will repeat them so that you can be recorded and the panelists will will give you answers to those questions Simona, can you stop? Yeah, sure. It's working. Okay So hi, everyone. I'm actually really excited to be here and I want to take Bruno as well for the invitation I work as a product manager for Suze and I will just take one minute to introduce Suze I would love that everyone knows or let me first ask. Do you know what Suze is? Okay So I work at Suze as a product manager I have been doing product management in different areas from the maintenance side of the classical operating system moving into Developing a service pack so a version of the operating system and now building a platform for containers And that's the primary reason why why I'm here to talk about containers in our vision for containers Hi, so I'm Jerome Pittazzoni and I work for Docker I do mostly evangelism these days So you might I've seen me in how to get your microservices working on containers without blowing up everything Things that I'm not doing anymore But Brett and Laura that were here in the room are doing a workshop about that So I recommend you to check it out if that's the kind of thing you want to do But before doing that I was doing Ops at dot cloud the company that became darker and before that I was doing mostly development And I feel like this kind of Discussion for me is a kind of back to the future because almost 12 years ago I was trying to build infrastructure as a service back in France in the small companies They had and we are also looking at that thing Everything like UML and not the the thing to build your diagram But user mode Linux, which was a kind of ancestor of containers So I feel like we might have a shift for circular here David hello, I am David Flanders of the OpenStack foundation So I primarily work on the container and platform as a services that get connected to the OpenStack API So I work a lot with SDKs and different developer communities from lots of different programming languages trying to understand how they want to connect this plethora of Container choice that we have with all the different Stateless features and tools out there last I saw there's about 70 Gartner's tracking about 70 different Container and platform different services and modules and things like that. So it's a very confusing space And yet I think that we're obviously going to see a lot of Filters going on where we're going to need to make some choices I'm a big believer in the fact that I think we need to move towards a kind of lamp stack for the cloud And so I'm I'm genuinely excited to be chatting with Simone and Jerome on how we do integrate all of these Technologies and how we start to build this new lamp stack for the cloud So we have the true open source that we want to be able to build the things that that we love building with the computer in the web Okay, so my first first question for for you would be around the Solvable tools that you need to build that stack. So We have bare metal systems. We have virtual machines and we have containers now How do you position them? How do you see the useful mess with regards to each other? Where are the key points for you around those technologies and maybe David you can Sure, so I think the most important thing to remember here is that we do work in a space that does change a lot So compute modalities We'll we have very old compute modellies. You heard Linus talk about and and Alan head of Seuss talk about mainframes, you know So I worked in universities for a long time and you know, there are mainframes still kicking around Likewise, we still have virtual machines and a lot of you know enterprise Legacy applications running on those Bare metal especially as it relates to things like GPUs and being able to use new compute modalities are coming into play more and more to Experiment with and of course containers And a lot of people, you know, think open stack doesn't love containers We love containers and containers live open stack. We we are building open stack better with containers from just a point of view of being able to update it to keep it Modular and being able to allow more people to use it and likewise. We're putting caner containers on top And I'll talk a little bit more about that later But I also and I just came from a conference on edge computing where we are starting to talk about all the new compute modalities coming down the line, you know things like Why not array computing and being able to do that smaller compute modalities things like serverless and functional computing and then also that looking kind of in the far future I think we we've got quantum computing IBM's just launched, you know a cloud that you can actually go and start using Cubits right now and start playing with quantum. So quantum's here So I think we're going to continue to see these new compute modalities for all the use cases that we see and we're just getting More and more use cases, you know, it is getting bigger and bigger So for me, I'm I'm actually genuinely excited these past five years have been a lot of just making virtualization work and making containers work and making bare metals work And we're starting to see a whole new set of compute modalities open up. So I'm I'm genuinely excited about that I think that generally everyone is really excited about this now What we are seeing with now on our customer base is that everything is going to be a journey So we should not expect that even if the technology is extremely cool And it's proven to be working and bringing all the benefits like improving Productivity bringing the innovation back to the organization and so on for some organization It will take a while to get and build their container ecosystem and container architecture and You know, we started we are talking about infrastructure as a service And I would like to maybe do a little bit of detour to talk about how we ended up with containers and everything So I think that all of you in the room already know that You know managing an infrastructure It's usually a very risky task and it brings a lot of responsibility to assist admin New concept like continuous integration. They sounded really cool But those can be really dangerous when you use them on mission critical infrastructure And the reason for that is because your infrastructure, which is critical for your business might not be available Once you do a patch and you cannot have the mechanism ready to roll to roll back easier That's why and we are seeing that on the operating system We know we are always exciting about new versions of the operating system But large organization and enter pricing running Thousands of servers are not going to roll out our New York's version that in the immediate next day after a release They will usually do it gradually with a lot of testing making sure that the critical infrastructure It's still up and running now historically application have been linked with the infrastructure and historically at the application level we have Inherit all those rules on the infrastructure And I I bet to say that in the last 20 years We tried to decouple the application and they allow the application to be more rapid and develop itself Embrace the agility the continuous integration and everything while the infrastructure on the infrastructure level We continue to keep it stable and reliable. That's why we still have this usually at Susan when I talk about DevOps We try to explain to everyone why this is usually a fight between Operation and developers and why we want to embrace them as a as a core concept Now when we look at what's happening now in the market and this is what do it open stack and so on what happened Is the innovation needed to hit the infrastructure and we needed to find a way to automate and to bring all this Application innovation that we had build around with agility and so on on the infrastructure level Allow the CIS admin to have tools and automation and stable solution They can rely on so that they can get the same agility as the developers have on the other hand and You know when we talk about cloud and application in the cloud everything that could be an easy fruit Everything that could be easily put into the cloud as an either as a container or the virtual machine I bet to say it's already there if you have a small website your marketing campaign stuff like this are already in the cloud But what we are seeing now is that organizations? They they want to continue this this journey and they are looking at the what we call more enterprises or their mission critical Application and today is not easy to put legacy building system in a in a cloud and not even talk about containers Some find the easy solution of just checking a box saying here is my container strategy I take my legacy Oracle system. I put it into a container I put this to the container in a VMware. I running on top of open stack and I have the task done Yes, it's true. It is a way of doing it But you don't yet gain the full agility that micro services Approach or a modular approach will bring you so that's what we are seeing today that customers are struggling on defining their architecture of how to embrace containers on top of infrastructure as a service So for us at Susie infrastructure as a services core to the future of the software defined data center Allen has shown the the slide. We usually have it on all our presentation We have at the as the first pillow the operating system everything We still need an operating system to run everything but the second pillow It's an infrastructure as a service and then we go up the stack with containers with Kubernetes with Cloud Foundry And then you get a solution or you get different solutions depending on your needs So that will be in a couple of words our vision So as you can see we kind of all agree that the future of containers and IAS are deeply intertwined So the I feel like the the good question would be more about how like how how do we get there? And what are the things we can do? to to to get some interesting results and I think one one observe interesting observation is to think about the fact that the biggest and most successful Public IAS infrastructures are built on top of containers if you take Google Cloud It's when you when you start a VM on Google Cloud It's starting on on top of something that looks like a container that is using C Groups and other mechanisms that are the same mechanisms used by Containers to make sure that this container only has access to a specific amount of resources there is an orchestrator which is Borg which is the kind of Ancestor of Kubernetes So Google Cloud is built on top is running on top of containers, which is kind of The reverse of what we could think at first is like oh, I'm going to run my containers in VMs Obviously, but these people are running VMs in containers. That's interesting And if we look at another huge successful public cloud Amazon It's it's not running on top of containers per se, but when you start a VM You indicate a machine image which is really close to a container image And whenever you want to start a VM you always have to specify that image and those images can be made from Running VMs so you you create them the same way that you create container images kind of so the the lifecycle of those VMs Is really close to the lifecycle of containers, especially if you want to do it right and by do it right I mean in the like DevOps ways immutable infrastructure, etc. etc. So Ias and containers that I think at some point will become almost impossible to distinguish in some way Because that the perfect Scenario if I if I wanted to deploy something tomorrow I wouldn't I don't want to choose between containers and Ias I want both because I have some legacy work workloads that run in VM and Sure, I could put them in containers But that would just be lipstick on the pig that thing is still a VM And I also have new workflows that are containers and I would like to address both workflows from the single control plane and and see them in a kind of homogeneous way And the last thing that will Probably at least some reaction from my neighbor will be about as an open stack For instance as this reputation of being complicated to operate Kubernetes is getting there as well And so it would be interesting to see if we can take some really simple Container primitives for instance Swarm as the reputation of being really simple to to deploy and now see okay. Can we layer? Something like open stack or some kind of Ias on top of that. Can we get either a simple way to? Deploy and operate open stack thanks to those low-level container orchestration mechanisms Or can we get an even simpler Ias thing? That will let me start VMs as easily as I start container by doing like talker run blah blah and then 10 seconds later. I have a VM up and running on my infrastructure So it I actually really agree with this We're playing with all of this right now at open stack and what's really getting excited What's happened with kubernetes and with docker and with those 70 other companies out there who are now doing container solutions Is that we're getting a lot of experimentation? It's kind of like the the Cretaceous period of speciation inside of the way you build your applications So things I've just seen already and drums actually had a great example Borg Still using VMs with containers Amazon still using VM containers We're mixing and matching and there is that kind of blending going where you almost can't tell the difference right because there are things in VMs which are really brilliant some of the old security layer stuff that goes inside of there and all the rest of that And there are brilliant things for the statelessness and what you want to achieve with containers So I think actually Simone you hit you hit the nail on the head as well Is it's about walking people through that journey as we get there now? If you want to check out some cool stuff that is starting to happen with this blending I've seen for example open stack cinder, which is our project for being able to do a database back ends or sorry Not database, but storage back ends Cinder has been working for seven years now And they've been working on actually creating over 80 different driver profiles so that when vendors come up with new compute You want to sell it? You can just grab cinder put swarm on top off you go And that's incredible for me to be just be able to do that kind of lightweight experimentation All of a sudden you're seeing web companies again who are able to build their own little clouds Just by using a couple of modules and things like that They don't want to just use utility computing They actually want to still have their own things so that they can touch and work with it So we are getting to an arrow now and again I go back to this kind of lamp stack example where you know Linux doing all the work Linus. What is he doing day on and day out? He's making sure that drivers plug in so that we can have more computers utilizing this stuff broadening the scope Enabling more people that's exactly what open stack is doing you look at cinder Swift Nova glance all of those are trying to work with hardware vendors to make sure we can plug the hardware stuff in so that You can use these things and then as we get into you know the Apache You know back in the day It was the Apache web server Docker and Kubernetes and core OS and tectonic and all of these companies They're starting to provide that interoperable Apache web service thing. We still got a ways to go You know like what does scripting on the web look like you know I've been trying to keep my own serverless and functional Maybe that'll kind of fulfill the P in the lamp stack You know when will we get to a place where databases will be you know truly serverless you there's some brilliant Cockroach DB I think is doing some really cool stuff now around this. I'm sure Docker has got some things as well so My advice to anyone on on about this kind of thinking about I ask versus containers is it's not an or It's an and just like the lamp stack.  They're not gonna be consumed by one company We don't want them to be consumed by one company or just one foundation We want them all working together in correspondence. So just remember that when you're kind of going out there and people saying are you using Kubernetes? Or are you using? Docker or are you using open stack? No, it's an and it's an and we're using bits and pieces from all of this And most importantly like good engineers. We're letting the best technologies actually prove themselves So so what will make the customer choose one technology versus another is it typically is a type of applications are developing So general mentions a lipstick effect on on on traditional application used in container mode So do you think that you really need to tie containers to cloud native type of applications and that? Legacification will never benefit from containers or I mean you have a Docker You have the MTA program that you introduced so so some people at least a doctor think to them seem to think that it's possible to Build legacy application with containers. So So the the MTA program is super interesting at first when I was speech to program I was like what what is this this that doesn't make sense to me and and then I remembered a very important moment when I was neutralizing stuff for customers maybe ten years ago and One day I was tasked with virtualizing some I think an anti-server or something like that The hardware was ten years old and it was about to explode and I'm like, okay, this machine dies We lose. I don't know if it was Accounting or time off or so something important for the company I'm like, okay we need to virtualize that just to save that machine because it's in it's impossible to to get that running on a new hardware and I'm not really a Windows kind of person Okay, I mean for the whole weekend and then one of my friends told me oh, you just should try this software I can't remember the name. It was a p2v thing. And oh, what what is that? Oh, that's a physical to virtual you just run that on your server And it's going to work for a few hours Maybe days if it's really slow and then it will just like speed out a nice VMDK or whatever The VM image that you can run on your thing. I'm like that seems like science fiction to me And I don't think that will work But for now, this is my best bet to get that anti stuff running on Xen I had I think and It worked and I I was like well I I'm glad I didn't say anything stupid like I will eat my own shoes if that thing works And and so I think The what we're trying to do with the MTA program is something similar So at first it's like wait a minute when I'm counter-rising an application. I should carefully write a docker file and Like optimize the way I lay out the instructions, etc. Right, etc. Yes That's when you do it the cloud native way But you can also take an existing VM and you can like get that VM in a container image And of course you won't get like this super nice docker file that rebuilds everything in an optimized way, etc But it's getting there. The first step is just get that container and put it in the VM And oh, sorry do it the way around take the VM and cram it in the container and then little by little We improve the tooling so that in in the process we can get either a docker file of the equivalent recipe to be closer and closer to What a good professional artisan would do if they were docker rising in the first place so I I'm glad that I had this experience almost educated go about virtualizing physical machines because it gives me trust in the fact that Trust and faith in the fact that yes, we are going to take those VMs And we are going to put them in containers and some of them We will just like it's a kind of fire and forget thing now The VM is in a container and we will never touch it again because it's been running for years and years and We have no reason to rebuild that thing ever and sometimes we're like, okay, we need to like make this application like to Maintain and improve it over time and so we will progressively transform that VM into a proper Container, but so yeah, I think that's the one one possible path in this journey And I think what's important is to define what is a legacy application and this is what you mentioned So sometimes for me for some organization It is much cheaper to just continue to support legacy pay a vendor Than to look at this legacy and touch it touching it means I need to rebuild the knowledge I need to check the documentation. I need to realize ops It wasn't documented for the last 14 years So it's much easier to say, okay This is the amount I'm paying for this application to this vendor and it's going to be supported that day I can decommissioned and in my experience that's also this is the happy case If you are in the setup where you can say I will support this application for the next seven years And then it's naturally decommissioned because we only have a couple of customers or something like this What do you see more and more and more often is you do have a legacy application that it's actually one of your mission Critical application like a building system like something that is core to the business and there even if we call it legacy It still requires enhancements It still requires work on and one of the things that you are looking at at the moment is how do I Balance those two has or how do I maintain this application up and running because they cannot just you know shut it down The business is going to go down the next day And how do I move this into a more? You know cloud-native friendly setup and this is the I will say the new type of legacy Where containers can help and where I agree with Jeremy that it's a nice way to use containers as the first step So and look I think it I couldn't agree more with this, you know Developers we naturally get in this debate about what's better the VM or the container or you know functional or serverless and we get We get obsessed with these things because it does affect us and it emotionally hurts us when you know the thing breaks and all the rest of it, but really smart smart organizations have smart smart product managers like Samona Who actually understand that journey and the cost and that's that's one of the real things that I think we We can't forget about the most is that What is containers really pushing out there as a value proposition and for me it's portability of application and So having someone who understands okay We do you know this this is just an enterprise thing and it's used internally inside the organization and People access it via the one way and we're not too concerned about it It's when we actually start to think about containers from the point of view of in the future I want our organization to be cost ready to be able to jump around to the different clouds that we'll need and How we'll want them and that that's what we should all really care about if you're here at the open source conference And you kind of feel in the the economics of open source the economics says that we should actually be able to take our Applications and move them around and not just be stuck in one platform So more than anything else. I feel like we should be When you come to the decision points of should I be just throw it in the VM and use some use some magic to be Just get it in the VM and use it versus put in the additional cost and time and developer time to make sure that you're you're moving towards us a Stateless application which containers can provide if you get all the components in though. It's very difficult. It's time It takes a lot of time it takes very smart to developers to do it But if you can get it into that container portability Then all of a sudden you're starting to make your organization cost-proof you're able to say oh well today We're using Amazon and now we're gonna add Azure as another infrastructure provider and yeah We we actually do want to have open stack also as a private cloud there because it holds a bunch of sensitive secret financial data And we we really cannot allow that to be to be Put out in any other organization Maybe because of data sovereignty inside of a country or because of security reasons So let's not forget about the the actual economics of containers and the fact that it's about portability And enabling us all to have a better economic open-source future So I had one question back for you see my night So at Susie you had all the offering you had you have an open stack based solution You have your cast solution you have your past solution How do you advise customers with regards to all those different options? What do you where you tell them you should choose that type of product rather than that type of product based on the technology On the application on the life cycle of the application Well usually talk about their project and their life and their ultimate goals and it's all a matter of choice So they are customers who really want to start a journey and they are even satisfied today with only the container engine And we have that offering as well. So they only say I want to give it a try I'm just going to put a couple of containers here And that is the operating system plus the container engine then we have customers who are looking into the transformation That's why I was talking about this infrastructure transformation and then they are evaluating open stack And we are really proud to be one of the first open stack distribution and contributing to the open stack solution But nowadays we have customers who are coming back and saying, you know, everything is really complex And I used to get an operating a stable reliable enterprise operating system from you guys And now I actually have to deal with all okay What exactly do I want and so on those are usually the customers who are looking for a full platform as a service We're already the the log management. It's set up the monitoring tool It's embedded and you know the the task that it's on the sysadmin or that the task list for the sysadmin is really reduced Because this all comes as embedded full Solution provided by Susan that's the value of a platform as a service or how we call it nowadays It's a cloud native application platform. This will embrace this will Embrace the latest technology this will help customers run on Different solutions so they can run it on the public cloud or they can decide it to build it together with yes On their own private cloud and it all depends on the cut the ultimate customer needs and how they want to get there We are aware that more than 50% of containers today are running in public clouds So it's still a journey of you know transitioning from A standard for legacy usually application and set up to the new cloud native solution And one thing that we realized and that's why we have probably we have a unique set up Where we have a cost in the past and we don't want to play around in the terms and saying that the cost is the past and so on We have identified the need in the market to have Automation for containers and this is where we build it the container as a service platform and on top of this We are going to have the platform as a service the main difference is a container as a service is really focusing only on containers And it comes with very minimal that you need in order to run your containers where a platform as a service is focusing on your Developers and comes with all the tools that your developers need in order to run their application And you no longer have to worry about what is happening underneath. That's something that the vendor like Susie will do for you Okay Show me any feedback on that any So there is one thing like when you said it's pretty important to know what applications we want to Put in containers and that's that's one thing that We're also trying to do within this MTA program like modernized traditional applications And this is more for people who have lots of applications. So For for many of us we have maybe just like one big website or maybe a dozen of applications So that's that's not us, but for the organizations that have hundreds or thousands of applications Finding out which ones are good candidates to be put in containers can be just by itself a daunting task So we we worked on tools for that to can do some kind of audit on on this Application landscape so to speak and say okay with a bunch of pretty straightforward heuristics We can kind of score these applications and then you can Start working on the ones that are on top. It won't tell you exactly. Yes. No, you can containerize that or not That's not exactly the point. It's more to know immediately. Okay. I'm going to Get a good overall and leverage benefits and etc etc on this something on this pool of applications So I can start working there and then walk my way slowly To the applications that will be less good candidates, but eventually we'll get there as well so so in European there is no Restriction to put any workload inside a container environment You don't you don't feel that there is room anymore for virtual machines or I think there is no restriction But it doesn't mean there is no room for virtual machine The container has to run somewhere anyway. So sometimes it will be in a VM. Sometimes it will be on bare metal Sometimes it at some point it might be in some abstraction that is even different so I mean it for now it's it's still a kind of In the sidelines, but For training purposes, we have a lot of things that run darker in darker So we have containers that run on top of containers and I think those containers then run on top of VMs That if you run them on Google, then they will run in containers So that doesn't mean that we should encapsulate thing like all the way down But I think at the end of the day everything can be in containers There is no doubt about it. Now, should it be that the answer kind of depends on how you want to look at things Like if you have a hammer, it's better if everything is a nail So if you want to manage a large number of containers, it's great if you pick something that is very well suited for that and The last few things that don't look like quite containers, then we will make them look like containers So that but but it doesn't mean that you have to put everything in containers Yeah, and one just one quick comment We have noticed that some customers prefer to put containers in VMs for Isolation and for security reasons they have already existing security policies in place that it will take a while to change them because usually comes with Regulation changes and we all know how long this discussion can take and for the time being because they want to embrace containers for Their development of their application they prefer to isolate them within VMs and fulfill all their regulations Just as a comment. That's that sometimes is mandatory So what one thing and Simone I actually want to kind of ask you a question a little bit here as well because it's interesting To talk about the difference between CAS and pass and I think you kind of talked about it and correct me Please but pass or more for I guess the DevOps and and being able to manage that and CAS or more for your Your people who just are specifically working on container applications or let's let's have a little bit of a talk about that because I think this is what really interests me is the groups of people who are going to use these different layers Right, so as we start to build layers on top of the I ask It is about trying to bring together your DevOps and your app dev and your usability experts and your users and your Product managers and your communications people and all the rest of it So I'm interested to see if you're seeing anything from your customers in regards to those kind of different Modalities right so the way we implemented and that's probably specific to suicide. It's our cas solution It's relatively quite simple. So you have an operating system the container engine and our orchestration for that everything on top of this It's something where we work with partners and the custom then customer can choose between the variety of partners that are already out There while the past solution comes already with CICD included with log management with monitoring already included Whereas a customer you can not necessarily Choose any other solution. Excellent. We've got some we've got some audience questions.  I Just want to ask the panel about how do you think about complexity in the in the With the introduction of containers and the virtual machines and so on because obviously complexity increases with With having several layers, but also it kind of seems it decreases in some sense portability is obviously a Keyword here, but in my ideal world It would be better if we didn't have to to do all that portability stuff if we could make the applications portable And have just one OS and everything would run like that But yeah, that's not you ever seen the xkcd cartoon where it's like, oh, you know all we need is another standard So there's 12 standards and now there's 13 standards. So we're already into that with containers We had that with VMs and we have all of our different, you know Distros, but I think one of the to address the complexity question. So this is my two pence The the thing that we really right now I feel like we are in a phase where we look at VMs and we say can this VM go into this container and That's a very one-to-one pattern ratio And that's not the way you want to actually build serverless applications or 12 factor applications And we're in a phase now where? Everybody's starting to have this debate and just conversation around what are the additional features you need built around the container You know whether it's it Whether it's you know a heavyweight orchestration system like Kubernetes or something a lot more lightweight like nomad or swarm Whether or not you want to be able to do the stuff like Netflix is doing with CI CD You know so you have 20 applications out to all your different sets of users so you can be collecting data I think that's the place where over the next five years We've got to figure out what do serverless applications look like and all the rest of that and that's a much more That is where it gets complex, but just in terms of you know customers moving over into containers I don't think that's too big of a deal then there's a whole other level Above the pass and cast and this this is kind of why I'm asking this question right now It's because I don't know what are the things we're gonna build on top And I'm not I'm not sure if you guys have seen anything or any use cases yet or So before we move to another question I do have an answer What we have seen so far is that the complexity is already there and it started from developers trying to push into getting root access to the infrastructure and They could usually they don't get that and then they found lots of workarounds for that So what we are trying to talk about here to it you it's actually Standards that that will help the CIS admin and organization the infrastructure layer to put some rules in place And still let the developers have the freedom of innovation that they are looking for Complexity it's already there in my view. I'm not sure we will have enough time to take all the questions But the panelists will stay after sure So for me the specific question about Caz versus Paz Paz when I think of all the passes that came out I mean first of all cloud is a nis standard and nis define what infrastructure services and what platform is the services and When all the different people who created different solutions around those credit them They were following those standards Containers as a service kind of came about and said well We're going to ignore all that stuff But it doesn't have feature parity as a result to infrastructure as a service and platform as a service for things like self-service for example their metered service, so That's kind of what I wanted to address from the panel is like how do you how do you go from infrastructure as a service to something like container as a service when most containers of service does don't have all of like the basic Features of infrastructure as a service because it doesn't follow a standard In our case you pile them up So we have our container as a service solution running on top of an Infrastructure as a service and then you get all the benefits and all the goodies from you know storage network management on that layer And then in our case we use Magnum and put Kubernetes and build it on top And one of the things I think is really important to draw out here is again that who uses it, right? So in that is layer you got sys admins network engineers dev ops You know and all the rest of it up in the cast and pass layer you're seeing those usability app dev Community manager people and stuff like that. So one of the things I think we're really trying to do is actually break down all the barriers You know so actually trying to get your application developers to talk to your dev ops So that they can understand each other on each side of their their layered fence because right now that I think that's where a Lot of organizational break down is occurring is that they don't actually know how to how to participate with one another on that So more more concrete questions or Kubernetes or swarm both both and nomad and Do you think there are messos? Yes, thank you Do you think I'm sorry, let me just do you think there are comparable products or they're like things of their own and we cannot really say Formulate the question like this one versus another. I think that they're comparable just like EVM and Xen are comparable They they have differences. They have strengths. They have weaknesses. I believe both swarm and Kubernetes communities are kind of looking at each other and converging to this central position where They they have the upsides of both So my answer would be both like they depending on what you need to do or yeah I think also what you want to do is look at who their customers are going to be so messos because it is got that apache Hadoop background they've got a bunch of customers are doing a lot of big data stuff, right? So that's what's going to happen is that people are going to come around these things and their use cases are actually going to Form the product and we need that because we we need more diversity in this space We're not we're not having less and less things. We're having more and more use cases. That's the biggest problem Yeah, so we need these different Cases slash passes to be able to have vertical markets inside of this space and understand what those customers need inside those vertical markets So getting again all of these what's really cool is every single one of them has a community You know, we are finally in the era of community where go and hang out with that community and see who's there And if you know birds of a feather, you know flock together, so that's the place to go David you said, you know, it's not about either or it's not IES or VM Ies or containers, but it's it's actually and you know, I think that's reasonable But you know if that were to happen you really need to have a single Orchestration layer which can actually orchestrate, you know that kind of mixed payload environment right now You know, there's one of the challenges we're dealing in our company is you know We have cuban it is we have open stack if you have some payloads running on open stack some running on cuban it is You end up building another higher-level Orchestration layer which would talk to cuban it is an open stack and maybe another one later on. How do you think? That evolution would happen would open stack end up You know orchestrating containers as well or would cuban it is also support VMs in future Look, I think all of those are a possibility right now I don't know which way it'll do to go Yeah, no orchestration absolutely essential and you know you look at Nova and what they're doing They have such rich history in the way that they have managed You know VMs and bare metal and all the rest of it the way they're ingrained in containers But at the same time there are very definitive use cases for you know More heavyweight solution like kubernetes to be able to do the full-blown pipeline stuff versus just more simple Orchestration tools like heat like salt like ansible so I don't think we're gonna Converge in on a single you know It's not actually gonna be the board Borg is an interesting work that kubernetes came from Borg because we're not gonna have a single orchestration language People have their favorite orchestration and configuration languages and you're not gonna give those up Just like you're not gonna give up your favorite programming language, right? You know, it's it's something you have in your your arsenal of tools. I think we're out of time Okay, thank you very much for panelists


Genetics and imaging are both very exciting fields. I mean, they're both brand new and there's a lot of information in both types of data. But it's very difficult to see what genetic changes do to the brain. So we all have millions and millions of base pairs in our genome. And you can imagine asking, well, how am I different from other people? How are these genetic changes affecting my brain and my behavior? One of the ways that we've done it with this enigma project is we've collected 20,000 images and 20,000 genomes. And it's amazing. You can actually see the effects on the brain of single letter changes in your genome. And that's very exciting. Your engineers and mathematicians can mind through the data and try and understand what makes a brain healthy and what makes the brain at risk for Alzheimer's disease and other disorders. And so often what we do is we find correlations with genes that might cause disease. And very often we use other databases to find out what the genes do. So if a gene causes migration of axons, you can begin to build a story about what that gene actually does in the brain. In translation experiments like knockout mice, you can look at removing the gene and see if the function is lost. And so often the imaging establishes the correlation. It just finds a pattern of connections. But then you go to more translational experiments and wet lab work to really delete the gene and see if that made any difference. There is a gene that was discovered recently that one percent of us have. And it's called Trem2 variant of this gene. And it doubles your risk of Alzheimer's disease. And this was only discovered very recently. It's very important. So, you know, if you think in the U.S. that's three million people that carry this very dangerous gene. So one of the things we're able to do with images is figure out how this gene affects the brain. And what actually happens is it speeds up the rate of tissue loss in the brain. So we may not notice this. And in fact, while we're healthy, this is going all the time. Now there is a positive message in all this. So if you could find these people that have that gene, you very easily genotype them and find them, you could preferentially enroll them in a drug trial. And they could have all of the Alzheimer's medications available today. And you have much more power in finding the effects of the drug in these people than if you did a study of regular normal people. The reason is most normal people aren't losing brain tissue very fast. So it's really hard to see whether the drug's working because there's not a lot happening in the brain. So one of the positive messages with genomics is you can find people at risk and do something pretty much straight away. And so it gives you a really a leg up into drug trials where normally they'd be very expensive. And you could really scan the people that are declining the fastest. The Europeans are involved in very large scale genomics projects. The Australians we work with are very busy collecting data from twins, which is very informative from a genetic point of view. So I think it keeps giving us a lot of new insights, a lot of new information about what's happening at the brain in research worldwide. I think one of the benefits with imaging is that so many people have collected data already that a grad student can come into the lab and just explore images and look at the diseases they care about. And they don't have to scan thousands of people themselves. So it's a little bit like we're standing on the shoulders of other people's work and it's much more efficient.


Meanwhile, Mahmoud Yakubu, Chairman of the Independent National Electoral Commission, INEC, says the Commission has nothing to hide from the Labour Party LP. Speaking during a meeting with the legal team of the LP on Monday, the INEC Chairman said the Commission would make available any document the party requests. The LP legal team of the party was having a meeting with officials of INEC over the request to inspect materials used for the February 25 presidential poll. Yakubu told the legal team that materials are the Commission's headquarters would be provided. I want to assure you that the Commission will not hide any document from anybody and will make any document that they have requested. There are two categories of documents. Those that are in possession of the headquarters of INEC will easily make these documents available to you, specifically the EC8Ds from the States and the ECDA, which is the National Collision Centre by the Commission itself, the EC8E, the Declaration. So meaning a total of, I think, 39 documents. This we can easily certify and give you almost immediately. As for other documents that we are asking for, so we need to work out the schedule so that we know when your team is going to which state and on which date so that we can easily facilitate not just certification of documents, but also the inspection that you requested for. Get notified about fresh news updates.