So who am I? I'm Steve Wong. I'm an open-source software engineer I work for a team that we call the code team and it's funded by Dell Technologies We're software engineers who are assigned to work on community open-source projects in the past two years I personally have been working a lot on DC OS and Kubernetes Mezos I added the Storage interface for external volume mounts to a patch the Apache Mezos project that would be the dvdi Isolator and I've been active on the Kubernetes storage SIG for about two years My group code also maintains an Apache licensed open-source project called rex ray It's designed to support Docker volume driver mounts on multiple container run times as well as multiple container orchestrators and We're also off active in the container storage interface initiative that is underway What I'm going to talk about today is just a brief intro to the history of the containers and the 12 factors Then moving on I'm going to cover container orchestrators and past platforms platform as a service I'm going to cover orchestrator support for stateful services and then finally I'm going to wrap up with Basically the first three are going to cover the state of running stateful inside containers and I'll wrap up with Call to action on what you can do to get involved with stateful now We'll start with a history lesson on containers Some of these dates vary I went and tried to research this and some of these came out to be plus or minus a year I think the difference is maybe when somebody wrote the first commit in a repository to when it became available to the general public but You know don't throw stones if You know more than I do and I'm off by a year here They should be pretty close and the point here is that Containers aren't really new you can get traces of them all the way back to 1979 and the old AT&T UNIX v7 Containers moved on into the first decade of the year 2000 Google released process containers and these later became packaged into the Linux kernel as control groups or Also known as C groups After these initial containers a movement evolved To support what was called platform as a service and this was a movement that was designed to simplify the effort to deploy build run and manage Applications by giving you a foundation of ready-to-run components so that you didn't worry about networks operating systems middleware servers storage and Backing services such as databases These were fundamentally based on containers whether they you know Drilled down and explained it to you or not and the advantage of these platform as a service Offerings were that you could reduce complexity and thus effort because much of that infrastructure Comes pre-configured and abstracted behind something with automated management The disadvantage of these past platforms is that you have reduced flexibility to support to select the exact tools that you want You know in many cases these platform as a service Offerings are opinionated and they picked the tool the tool solution. So once it's picked you live with it Some of these past platforms also face charges of having single vendor lock-in Finally About a year after this cluster of past platforms come came out This set of patterns and antipanards called the 12 factors was published by and Adam Wiggins He was a co-founder of a Roku which One could say I think is the pioneering past platform Although when I did a Google search it turned out that there may be where as many as ten of these It's just some of them Parished and are no longer with us so I Don't really know what it looked like at the time because I wasn't dealing with past but this is this is what my research told me and that the 12 factors We're designed to abstract out the platform your app ran on and they use containers and they supported Horizontal scale out of apps using container technology What were the 12 factors or what are the 12 factors that the the website hosting this is still alive And well They were a collection of patterns intended really to guide deployment of apps on the Hiroku platform But they applied I would contend equally well on the other past platforms such as cloud foundry Where did this come about In terms of modern containers Docker well, it turns out that the 12 factors were published in 2011 and Docker didn't come out until 2013 it in fact was a spin-off of The 2011 dot cloud you see on that diagram The container orchestrators depends on which one the masos container orchestrator actually predates The 12 factors although it wasn't running at the time on Docker containers it had it had its own masos containerizer Based on Linux containers, and they added support for Docker later Swarm in Kubernetes clearly came after the 12 factors Now what is the difference I mean we've got masos Kubernetes swarm as container orchestrators and These past platforms and really I would use this analogy of Comparing them to pizza as a service you've got there in the two columns Delivery pizza and frozen pizza now if you get the delivery pizza That I would contend is the equivalent of pass where more of the choices are made for you, you know you deal with The vendor takes care of the cheese the toppings the pizza sauce the pizza dough the oven the electric and gas and Shows up at your door, and you're done you don't get to pick the oven that that's taken care of when you go to the Frozen pizza it's using your oven and gas and you maybe have a little more choice if you liked it extra crispy You're in control of your own oven if you wanted to throw a few Extra veggies on top of that frozen pizza have at it now This isn't the whole continuum of this you know to do this right in this talk I'm really talking about the the 12 factors relating to pass and Container orchestrators relating to containers, but the fact is parallel to this you could draw even more cops covering infrastructure as a service virtualization even running on bare metal and the more you know in this continuum horizontally you'd Deal with a less opinionated provider of service all the way down to potentially the equivalent of pizza of growing your own wheat you know threshing it growing your own tomatoes and Really, I would contend in it. You have all of these choices, but the the modern trend Seems to be that in many organizations you're trying to eliminate this complexity which eliminates your operational expense Now it isn't to say you have to choose one or the other there are many organizations where One division might have things going on that makes sense to run on infrastructure as a service another one on Container orchestrator and a third on pass But that's how I would compare these two you're you're basically You're basically in an arena where the past platforms make more choices for you But because of that they remove options from you What are the 12 factors say well the one I'm going to talk about today is factor number six it says Execute the app as one or more stateless platform Processes why would they say that well? It's pretty easy if you if you have a stateless process Whether it's in a container or on a pass in a container. They're easy to replace an upgrade You just shoot them in the head and bring up another one It's easy to automate scale up and scale down because there's nothing you care about inside these things if you've Maintained statelessness now on the other hand I love this I love this quote that somebody tweeted out there and it says there's Stateless as a hoax.  It it's just Declaring that the state part the difficult part is someone else's problem It doesn't make the problem go away now in this picture if you can see it in the background They used an ostrich with a head in its in the head in the sand I'd suggest that maybe a more appropriate Animal analogy would be to use the elephant, you know that there's still state there on these past platforms Heroku for example or cloud foundry. They don't really eliminate it They just declare that and I've got it here that any data that needs to persist Must be stored in a stateful backing service. Well, that's where your state is You've just declared it out of scope the other guy's problem But the elephant in the room is that it's still there and you're pretending you don't see it What exactly is one of these stateful backing services well in the era when the 12 factors were originally written 2011 it was typically a database and The 12 factors goes on to advise that this database or this stateful backing service should be consumed behind an API such as an HTTP network service now What exactly would that be well if you're running in AWS in the Amazon cloud? It would be something like Amazon's Dynamo DB if you're on-prem it would be something like an Oracle database Something basically maintained by either your service provider or if you're dealing with the Oracle example a team of Oracle DBAs, you know high-priced experts that maintain this stateful backing service What's That changes a little bit in modern times. I would contend that since 2011 Some of these it isn't just databases. It's moved on to various forms of No sequel things like Cassandra, Mongo, Kafka, Redis keeping state other than simply in memory elastic Hadoop and What if you want to run these kinds of stateful services? But you're the guy responsible for your whole IT organization in other words suddenly it isn't the other guy's problem You're the guy room maintaining that stateful backing Service There are perfectly valid reasons why you'd want to maintain your own too Maybe you want to pick the version of your own tool and or database Maybe you want to customize it. Maybe you want to stay portable across clouds in other words I want to put together an app that I could run on Amazon AWS but also run it on the Google cloud and also run it in Certain geographic reason regions in an on-prem data center You know in order to maintain that portability you can't go use something like Dynamo DB you might want to pick an open-source solution and Take management responsibility for it Another good reason for doing this yourself is to main to avoid database monoliths The fact is in a lot of those platform as a service solutions the platform would stand up a database and Every app using it on that platform would be connected to that behind the the API but ultimately that results in a Monolith where all of this information is in in the one big basket. Well, what's the problem with monoliths? Well Monoliths are bad for a number of reasons If you let a database get large, how are you safely going to move it? You know moving it to another location or a different version or a different technology can be as Complex as rebuilding a 40-story high-rise in a dense urban area where you're going to have to orchestrate an Implosion with other buildings filled with people that you care about right next to it The bottom line is in my observation and you know, I work for a technology vendor. That's pretty big in storage My observation is that once a database gets large Sufficiently large nobody ever moves it nobody wants to bet their career on the risk involved with moving that You know, why is Oracle still here? Well, because there's a lot of really big ones and nobody wants to bet their career on taking the risk of moving it I mean once these get large that problem can be not just the risk of collateral damage and the The time it will take and the outage where your services are off the air But really these things can sometimes get so big that the problem is like moving all the water out of the Atlantic Ocean Into the Pacific is just not doable with the technology you're likely to get at hand Get on hand or with the budget that you're likely to have so Just like people advise against monoliths when you're building You know unrelated Apps whether they're related or not, you know the whole principle of separation of concerns I would contend that when it comes to data storage It's a good idea to avoid these monoliths that if two apps are not related They shouldn't be saving their things in the same database that gives you the flexibility to Do things like pick different technologies when they make sense and it keeps them from getting bigger so you can do things like Change versions independently. I mean consider the logistics if you had a hundred different apps all in one Database and then you want to update it You're going to have to have a hundred different teams responsible for those apps coordinate this effort to Assertain whether they're comfortable and compatible with this version change Whereas if you kept these as separate instances of that data store you could do the common things like canary testing where you have one team maybe one that Has a relatively low cost should it fail go out there and do the testing for it first and then and only that Only if you have a satisfactory experience let that ripple through to the rest of your organization You could also do things if you avoid monoliths of having a team with a key value store That discovers a newer open-source key value store that's likely to work better for them have the freedom to upgrade Without impacting others. I mean and let's face it in in this field things change all the time The only constant is that things change so avoiding these monoliths in your data store make a lot of sense so if If we agree that we want to give people the flexibilities offered in containers and container orchestrators things like Dev teams engaging in kind of their own self-service of picking their own tools Taking advantage of container Attributes like consistency no matter where you run, you know looks the same whether you're on the Amazon cloud the Google cloud or on-prem You want to have these things packaged with dependency management? You want to take advantage of an orchestration platform that can do health monitoring automatic rollouts and rollbacks declarative configuration Putting these things in containers if you can do it makes a lot of sense. There's a lot of value here so My wrap-up on the 12 factors is that I'm I'm not I'm not challenging the whole thing. I'm actually in full agreement that with the 12 factor principle That publishing any any data store behind an interface is a good idea having a controlled abstraction layer But I want one that's I want to enable one that's hosted on a container orchestration platform That gets to cheat on that rule that all processes must be stateless, you know, they're they're Maybe in 2011 that wasn't doable, but on a modern container orchestrator platform Stateless running in containers is supported and I'll I'll go on a further slides to back that up if you have doubts but by by accepting the fact that maybe the 12 factors should be a little bit flexible we can preserve its usefulness and I mean there are a lot of documents You know in this technology field that should have a sell-by date of six months or a year The fact is the 12 factors have survived from 2011 to 2017 pretty pretty well and a six-year life in any document in this field is pretty decent I'm not saying tear down the whole thing. I'm just saying We need to treat these 12 factors not like some religious code of sale or treat them like a law book and You'll just you'll make yourself miserable doing that. They they should be respected and considered when it makes sense Now if you're skeptical unfortunately, it looks like that's pretty hard to read But what that is just to point out that? stateful in containers Isn't new and isn't just crazy talk This is a snapshot of Docker hub and it turns out that if you go to Docker hub You can actually sort these by popularity in other words the number of downloads. Well on the day. I got this this is a top 12 list of Images off of Docker hub and it turns out that seven of the top 12 on the day I looked we're stateful applications. So pretty clearly people are doing this This isn't crazy talk If we move on to container orchestrators We've got this is a chart showing the features in an assortment of container orchestrators related to running stateful in Stateful apps inside containers So on the far left you can see DC OS supports external volume External persistent volume mounts. In fact Kubernetes mazos and swarm do as well DC OS and mazos support frameworks in other words This is a two-level scheduler if you're not if you're not familiar with it and they have frameworks that Have been published specifically to support stateful applications being managed on the platform and Scheduled out onto cluster notes DC OS has packages to support stateful apps Running in containers Kubernetes has something pretty similar called helm charts Kubernetes also as operators and stateful sets and I'm going to go into these in detail Now you on some forms of these stateful backing stores It is possible to use local storage for state, but there's a downside to this, you know my What I would compare this to is I'd say that You know you could you could be really crazy and run something like postgres or my sequel Direct attached storage in a cluster node But if you do that and the container is killed or that cluster node catches fire and burns Your data is gone like forever There are other things like Cassandra that do involve some forms of replication So maybe you feel some pain when it goes down, but it it might be recoverable But I would use the analogy to using local storage to be like smoking a cigarette You take that first drag it tastes good at first. Maybe you see other nodes doing it But in the long run it's going to learn lead to shorter data life expectancy and reduce your capacity your lung capacity The the alternative of this is something called external volume mounts where you use some sort of data communication Network communication to attach a storage volume that is provided off your cluster node and These external volume mounts. How do they work? Well, they're If you're a techie geek like me, you're probably familiar with the sci-fi TV series Star Trek and I would say that a persistent volume of Persistent app using an external mount is just like that familiar episode of Star Trek your database binary Can be like that guy in the red shirt in other words the expendable guy who you know if you watched Many episodes isn't going to ever be seen again by the by the by the end of that one-hour episode that red shirt guy is dead The the state full app binary can be the guy in the red shirt So long as you use an external volume mount, which is the guy in the yellow shirt when trouble arises the guy in the yellow shirt picks up the communicator and says beam me up Scotty and He flees the safety the red the red shirt guys are dead But the state the stuff you cared about in your database it got beamed up You can beam it back down to another planet pick some other red shirt guys and you're back in business If you're running things like Postgres my sequel the traditional relational databases that is really how you're going to do it here There might be an alternative with some of them of sharding them, but you know the baseline single node database That's how you do it Cassandra could take the red shirt guy getting knocked off, but in fact In some instances there might be benefits to using an external volume out even if even with cluster aware storage Like Cassandra this all depends and I guess this is getting into a second talk that takes more than an hour But I'd invite you to come and see me if you're curious about that either after the talk or I'm hanging out in a booth We're sponsoring downstairs, but Bottom line is External persistent volume mounts are like the Star Trek it untethers your data from a particular cluster node and lets the container orchestrator do things like upgrade the database binary with a very short-term hit on on your downtime and It allows you to migrate things across these nodes So you could do things like a plan maintenance activity on it on a compute node Moving on to frameworks like I said all of the container orchestrators now support those external volume outs They're they're They've just become universal the frameworks are found in Apache mesos and DCOS now these frameworks can support both stateful and stateless applications, but Stateful app management is a primary use case and mesos frameworks exist for Pretty much all of those Stateful services I showed in that prior one and at the end of my talk I'll have a diagram that you can take with you that actually links to where you can find these The DCOS container orchestrator also has a concept of packages and On the stateful side packages exist for Cassandra elastic HDFS Kafka MongoDB MySQL Postgres Redis and even more and this provides an app store like experience complete with a UI plus a CLI For deploying these stateful apps. So they're basically moving this into the realm of the easy button for deploying stateful Kubernetes like DCOS has helm charts and it's a similar thing An app store experience it supports update and rollback of these stateful apps Helm charts are available for Cassandra elastic HDFS Kafka Mongo MySQL Postgres Redis and more and it's growing Kubernetes also has a Recent edition called stateful sets now it turns out with many of these cluster aware scale-out things like I don't know zookeeper for example They're based on a horizontally scalable set of nodes That have unique network identifiers in other words They know that this guy is node one this other guy is node two and this other guy with this host name is node three The stateful sets take care of separating out the configuration of these things And it and keeping these running Using stateful persistent storage the kubernetes stateful set also manages and this is very important in some of these cluster aware replicating stateful Solutions it supports ordered start-up and shutdown Including a graceful shutdown where you might be able to drain transactions in progress Rather than have this be the equivalent of randomly pulling the plug on a bunch of servers some of these can recover in the unordered Scenario, but it just takes a lot longer and if you can have this scenario where you can shut them down gracefully If you're engaging in a plan maintenance activity and upgrade something like that. It's just a much more pleasant reduced downtime experience Finally kubernetes supports something called operators and an operator We're getting into kubernetes design here, but I'm going to go for it an operator is based on the kubernetes controller concept And in kubernetes a controller is something like the you know the thermostat that controls your furnace a rare conditioner where you start by Setting or declaring a desired state say 72 degrees Fahrenheit and the controllers this continuous process that Looks at what your desired state has been declared to be goes out and takes a measurement of the current state and does what is necessary to maintain that condition so This these controllers can take a declaration that I want X number of nodes of my horizontally scaled out Stateful solution and simply make it happen health monitoring the health monitor this well it runs and Engage in self-healing when things should things go wrong and Operators free to be layered upon other kubernetes concepts like stateful sets external persistent volume mounts etc And they often are But the bottom line is that kubernetes has an inventory that is out there now and growing of operators specifically built to support stateful apps If you want a demo of this, I've got two suggestions here, so tomorrow at 1055 there's a session which is a tutorial of running stateful applications on kubernetes and During this tutorial, which is going to involve Sodaly of Google and Chris Duchain of the code group that I work in You're going to see a demo Deploying stateful on kubernetes and it's an end-tier app using stateful and they're going to demonstrate first deploying it to the Google public cloud and then deploying the same app unchanged to an on-prem hardware scenario and There's that there's actually user participation in this so bring your laptop Finally if you're sticking around for mazos con there is a workshop on building your first stateful service on DCOS so if this is a subject that interests you and you're potentially interested in either of these Container orchestrators. I'd recommend these sessions Getting back to the 12 factors I'm not the first one to recognize the fact that as Good as the 12 factors was it perhaps is in need of some embellishment It turns out that there's an O'Reilly book That is excellent in fact some of the ideas for my presentation Came from this book as well as a presentation that I sat in at a meet-up by Randall Schwartz who is the emcee of the Foss weekly show and At the end of my deck here I'll show a link to that will allow you to you'll have to give up your email but you can download a free copy a PDF of this O'Reilly book and It basically I'm making the point that the The specific 12 factor line item that relates to stateful Maybe needs an update but this book goes into more detail on other things of the 12 factors and if you're deploying things on either a pass or a Container orchestrator system. I recommend this book Kylie So is stateful perfect on these container orchestrators no I'm gonna give you a warning up front that This is an active area, but there are there are parts of this story of stateful on In containers on container orchestrators that are ripe for improvement The first one is backup, you know to do backup right you need solutions like Kessing of these applications and I mean the applications themselves things like postgres typically have a CLI you can call to drain Transaction in progress and get them to flush Caches in memory down to the storage level so that the storage can be utilized in a backup But what you typically want to do in there is trigger a snapshot I mean in the old days in virtualization That storage was evolved to the point where with popular storage solutions They had built-in snapshot solutions where you just call an API saying snapshot this volume like that The snapshot is retained maybe in a copy on a right scenario or something but then the database can go back immediately into production and the the outage Related to a backup was typically minuscule and perhaps undetectable, you know that that snapshot made that instantaneous I am working in With storage sags in both mezos and kubernetes and I can tell you that These groups are working on support for snapshot now, but it isn't there today. So it's something That's something that's still in the air The second item is that Storage plug-in drivers are not standardized against across these platforms now if you're a big organization that maybe is Running multiple container orchestrators and they're non-uniform There are people out there who run one department in mezos in a different one in kubernetes Or one on a past platform like cloud foundry and another on a patching mezos It'd be a great thing if this interface to the backing External volumes that you keep to store the persistent information was standardized, but they're not There is an effort underway called the container storage interface that is a group of both Orchestrator suppliers like kubernetes mezos docker cloud foundry and storage providers like del net app A long list who is working on this, but it isn't out there yet. So we're we're having meetings We're designing it my code group actually had the first release today of A provider for this container storage interface, but it's written Against what is really a draft standard at this point? It hasn't been universally agreed to by this group But we felt we had to go first. So we had a press release today announcing the fact that we came out there with a Call it a validation suite for this principle of the container storage interface And I would compare this contort container storage interface to the efforts like the container network interface that That have evolved in the container space to make things portable and that work is underway There are also some rough edges related to replication volume resizing etc. Things that you've typically had available For years in the virtualization space We're still working on those on containers now Don't let that scare you You know I went there and told you the honest truth that some of these things aren't really comparable to what you might find With virtualization, maybe with some past platforms that run on top of virtualization But I would contend that even though there are still some rough edges if you're somebody who can make serious use of this The time to get involved is not to wait till it's done, but get involved now You know the whole model of open source isn't like commercial software I used to work in commercial software and the way that worked is a product would typically have a Product manager or guy a guy with that product manager title who would try to deduce a feature list Maybe he talks to the biggest customers kind of ask them what he wants goes off and builds things And then comes down from the mountain with the product already carved out If that isn't to your liking or if you want features later, it's typically You know a long cycle to get what you really want in if you get involved in an open source project like this today Well, it's still forming You're going to be in a position to actually contribute and basically get what you want If you get a seat at that table and participate as an end user to represent your use cases And I'm kind of sitting on the other side building, you know the implementation of this But I can tell you from the meetings that we've got and things like the kubernetes Storage saying that we'd love to have more user involvement Representing your use cases so that we can build the things that people are actually likely to use The other benefit you get of participating on that level before it's fully bank Is that the bottom line is here that if you're really a big organization at scale? Let's face it you're going to need to have your staff or at least some members of your staff Trained in this right to be able to troubleshoot this when things go wrong. Nothing is ever flawless Well, I'll tell you the one of the best ways to get training would be to get there with a seat at the table As this thing is being architected in design because your anybody who does that is truly going to understand this from top to bottom And if you do run into bugs, you're likely to build up contacts with the actual developers You know if some of these meetings are face-to-faces some of them are on Google Hangouts or Zoom video calls But you would get to know the actual developers and I suspect that the net result of that is that if your organization uses this in mission-critical things that you'd have You'd have a Contact list to where you could call these people you'd know who they were and and they'd return your call So I'd invite you to get involved if this is something that your organization is Potentially Could could benefit up from and I'd invite you to get involved like now before it's done I Want to get back, you know to I'm going to suggest to you that The gestation of containers, you know, I showed you I opened this talk with kind of the history of containers showing that containers go all the way back to 1979 and They they took a while to actually get adopted. I I think that Containers really didn't hit the mainstream until docker came out myself And I would compare this to the adoption of the automobile. It turns out that the first gasoline engine Thing like an automobile. It was an engine attached to the push cart came out in 1870 it wasn't till 1885 that Carl Bands made the first gas automobile for sale that guy in 1870 just made that push cart for himself and this was handmade, but you could order it It was hand produced finally in 1903 Henry Ford Put together a factory to mass produce the Model T Now Let's see the effects of that in 1900 before the Model T This is New York City Fifth Avenue. Believe it or not. Those are all horses, but somewhere in there In fact, it's right here. There's one automobile So that's that's that's 1900 New York City Just 13 years later There's one horse in that picture and it's all gone automobile. So a span of 13 years You know I would contend that This span Took 34 years from that guy first Building the hand push cart to when it got popularized and this is very comparable to the development of CH route in 1979 taking all the way till about now for containers to get mainstream but when things move they actually move pretty darn quickly and This field of containers is moving quickly and stateful in containers is moving quickly as well so I Think that this We're only a few years out before containers are universal for both stateless and stateful and once again to my point This this is why I think you should get involved now Even if it doesn't quite have things like the volume snapshots yet That's the end of my talk I'm going to just show you a few things here because I'm going to leave you with a link to this deck But this is the uber chart Kind of I raced through this but this shows you the support for all the stateful apps on the various container Arcus Raiders and if you get this deck, this is actually a hyperlink that actually takes you to the Repository and the documentation for what's going on there so you can learn how to deploy these on the various container orchestrators If you want to take a picture of this one, I've already published this deck Up on slide share so this will get you to this deck That top link is the free O'Reilly book The 12 factors revisited I'll just leave that up for another second so you can get pictures of this And I I did release this to the Linux foundation who should publish it in my experience They'll get it in a couple weeks But they generally publish them as PDFs and I can't promise you that it will have working hyperlinks So going here might be better Finally should you want to contact me you can get me on Twitter at that handle I Unfortunately see now that these maybe aren't super readable, but this is the group I work for we've got a booth Down in the expo hall so come and see us That said I guess I have room for some questions here if anybody's got any yeah Yeah, right. Oh, that's what they do they Well, I Okay He's asking if people are actually using kubernetes stateful sets to run stateful apps in production Well, I I think that there are people running in in production, but there's varying levels of tolerance Right. I mean some people have more tolerance for failure than others. I You know It's so new that in some fields like financial transactions My gut feel is that those guys tend to be the last adopters of technology and some others are Much more aggressive At each other Yeah, not really a technology now on some of these I think that it almost is required that they run in containers So if you look at something like a big data fast data solution like a Kafka I think the reference platform for that is in fact running it on Apache Mezos or DC OS that You'd be really out of the mainstream if you were to stand those things out off of a platform like that. So I Think a lot of this depends specifically on what the stateful app is and A lot of that is your tolerance for pain, you know, the stuff isn't perfect yet Some of these stateful solutions actually are cluster aware So some of these could even be used without the external volume mounts using Das But you would you know the downside of that is that if you get sufficiently big like let's say you scale out horizontally to a Thousand nodes once you get to that size.  I mean the the probabilities just creep up the bigger the size gets and the logistics of that Yeah So well, it isn't perfect, let's put it that way and but There are early adopters who are already going there and a lot of it depends on what your stateful app is and a lot of it Like I say depends on your tolerance for pain What it will cost you if there's a glitch if I have to do a recovery from a backup if things go wrong There's no universal. Yes. No Even in virtualization, which has been here. I don't know how many decades I think if somebody told you it would never fail ever they're a liar I mean this this stuff maybe isn't as good as some of those other solutions, but it has other benefits I mean if you really want portability across clouds You know, I don't know if you've ever tried to take a virtual machine running on-prem in one hypervisor and then move it in into the Amazon cloud and then move it back because My own experience with that is a conclusion that they're really not portable at all So, you know, this maybe isn't as good as some solutions at some things But it's way better at others that and you have to decide on your own which of these attributes is important to you and I can see with all of the R&D effort and human manpower being invested in these open-source projects. I mean all of those things on that chart have Dozens if not hundreds of people behind them and there's a lot of effort going into this stuff to To build it up and the world is going there Well, I think that depends on the app, too I mean there are some of these stateful apps people build the stateful app for something like I Know there's a guy Josh Berkes who's like a guru of Postgres who's speaking here and he's the If you're curious about running Postgres, it's what would be a sharded Postgres database server on stateful set He's the guy writing it. So I think I'd suggest that maybe You have to ask that question in the context of the specific stateful app You're trying to run because the answer is different for all of them and some of them are in a more advanced condition than others Oh, I even I just noticed sod is here. So he's somewhat of an authority on Kubernetes, too Do you have anything that I hate to put the spot but maybe you can contribute to my answer there We're very new Kubernetes has been around for two years that said there are fairly large deployments out there It's a lot like what Steve said depends on what your tolerance for failure is if you need to be very very very highly available Trying brand new cutting edge technology probably isn't But at this point, I think at least we're in the Kubernetes side of things. We're fairly stable It's far better than it was when we started about a year and a half ago. So people are trying it out. We do have customers Deploying stateful applications using Kubernetes So it's definitely possible. Thank you anybody else. Okay. Well, thank you for coming


In order to achieve climate stabilization, governments must invest in research and development, R&D, for low-carbon technologies. This paper links two integrated assessment models to study R&D investment pathways consistent with climate stabilization and suggests a consistent financing scheme. The authors found that timely R&D investment in five low-carbon technologies and energy efficiency measures reduces mitigation costs and generates positive employment effects. Additionally, they showed that carbon revenues are sufficient to both finance the additional R&D investment requirements and reduce distortionary taxation, thus enhancing job creation. This article was authored by Lara Alleluia-Race, Tui Frantisi, Elena Verdellini, and others.


Some members of the family of Zambia's late president, Kenneth Coundey, are now in a row with the government over his burial site. The relatives have gone to court to try to stop his burial at the Embassy Park National Site in the capital, Osaka. The burial plan for tomorrow is now in doubt, as the family wants the court to allow them to bury Coundey next to his wife, Betty, who died in 2012 to fulfill his wishes. Coundey was Zambia's first president, who was in office from 1964 to 1991. He died on June 17 at the age of 97. Hello, hope you enjoyed the news. Please do subscribe to our YouTube channel. And don't forget to hit the notification button so you get notified about fresh news updates.


Anilkinthal, the anilkinthal is the terminal part of the large intestine. It is situated between the rectum and anus, below the level of the pelvic diaphragm. In humans it is approximately 2.5 to 4 cm 0.98 to 1.58 in long. It lies in the anal triangle of perineum in between the right and left ischioanalphosphate. The anilkinthal is divided into three parts. The zoonocolumnaris is the upper half of the kinthal and is lined by simple columnar epithelium. The lower half of the anilkinthal, below the petanate line, is divided into zones separated by Hilton's white line. The two parts are the zona hemorrhagica and zona cutaneous, lined by stratified squamous non-charitonized and stratified squamous-charitonized epithelium, respectively. In humans it is approximately 2.5 to 4 cm long, extending from the anorectal junction to the anus. It is directed downwards and backwards. It is surrounded by inner involuntary and outer voluntary sphincters which keep the lumen closed in the form of an anteroposterior slit. Behind this lies the anal gland which secretes lymphal discharge and built-up fetal matter from the colon binding. Lumen expungement is done routinely every 24-36 months to prevent infection and fistula formation. It is differentiated from the rectum by the transition of the internal surface from endodermal to skin-like ectodermal tissue.


So, we promised a period of half hour or so of open comments on what we've seen over the last day and a half, so I want to start there. I know Larry Magged got cut off last time, so he'll get the first question. I do want to encourage those who are not members of the task force in particular to use this as a time to put questions or comments on the record. At 12, we will close sharply and excuse everyone who's not on the task force. We're going to spend the afternoon from 12 to 3 in a closed-door session. But from now till 12, I'd love to have comments or questions, particularly on the technologies we've been talking about, and comments most welcome as well as questions. So Larry, you get the mic first, which I think I might have here. And then again, to task force members, I'm going to get tried of place to those non-members for this half hour if that's okay. Well, I'm glad that you talked for a minute because it's really hard to follow those three very smart young people, and I'm really glad they were with us today. Is the question I was going to ask of Hamu, but actually it's a question that I think anybody in this room can think about. And it has to do with the unintended consequences of if we were to more successfully lock down services like MySpace and Facebook and Bebo and all the other social networks. If we were, for example, to empower parents to keep their kids off of these sites or to make it easier to keep their kids off from these sites, if we were to restrict access to 16 or possibly even 18, what might happen? Hamu mentioned the suicide prevention hotline. There are children alive today who would not be alive if it weren't for social networking sites. You also talked a little bit about the high-risk kids. No doubt about it. I think you're absolutely correct. And we've seen that with the researchers here at the task force. There are children who do risky things offline, that do risky things online. Often they do not have the parental support. Often their parents wouldn't be available or willing or able to validate them through some kind of a permission process. So we worry about a lot of things, gay and lesbian teens who might be prevented from understanding their sexuality. We worry about kids who are suicidal. We worry about kids who might want to find out information about STDs. There's a lot of stuff out there. And Anne and I did a little memo on this. But I'm wondering, should we be worrying about these unintended consequences? And might we have more harm than good if we were to successfully lock down these services? I'm happy to have responses to that. But I'm also happy just to go to other comments. Professor Harry Lewis, back here in the- Jump in and follow that, because I asked this question yesterday about the developmental consequences if we move to a state of sort of blanket surveillance of children. And I'd just like to question the philosophical premise from which that world seems to be emerging, that as parents we have a fundamental responsibility to keep our children safe. Obviously, none of us wants our children to be endangered. But it's kind of our responsibility to make sure they're safe. And that so measures like the ones that have been talked about yesterday, which would call me on the cell phone as soon as my son or daughter types certain words into their internet browser are things which I would almost be negligent if I didn't embrace and make sure that my neighbor's embraced as well. And this is a question that I would just like to put is whether there is a moral or even potentially legal flip side consideration of the rights of young people, certainly 17 year olds. And you take it down, I don't know where the age cutoff would be to free expression and the right to seek out information on their own without supervision by any adult, including even their parents. If I kind of think there is some such right in there, I don't know what age it would start at. Just from where I philosophically said, I would tend to think younger rather than older, but whatever it is. But if we go to the extreme on parental responsibility for supervising the words and what the word spoken and heard by young people, then you have to deny the right of children for some kind of, as Larry said, seeking out knowledge or expressing themselves to other people. I just philosophically and legally I don't know where that balance has to be struck. Thanks. Thank you. And I commended yesterday to you Blown to Bits, which is a book written by Professor Lewis and two others, but he's also blogging on this topic on Blown to Bits.com, is it? Bitsbook.com. And he's got a blog post on yesterday and is, I think, a helpful guide fly to this conversation among others around here. Please. Hi. I'm Rod Zias. I'm the CEO of EGuardian, but I'm going to answer this question as a parent of three teenagers rather than as a CEO of a company that does age identification. I don't think, first of all, I think the parent is the best arbiter for their children of what's going to be appropriate or not appropriate. And as children get older, they do get more rights, and that's a healthy part of our society. But parents are ultimately responsible for who their children are from the moment they're born until they become adults. So I don't want to take away the authority of the parent. I think what we need to offer is more choices, and choices inherently mean less censorship. Before movies had ratings, there was a whole list of things you couldn't do in a movie. You couldn't kiss for more than three seconds, and you couldn't do certain things in violence or whatever the case may be. Movie ratings allowed parents to have a tool that said, OK, do I find it appropriate for my child to go to a PG-13 film or to a G film or to an R film? And I sometimes make those. There are a lot of things I'll let my children watch with me that I probably wouldn't let them watch on their own. There are some things that I find very objectionable, like violence, where sex in context, I think, is a normal thing for them to be able to see. That's my right as a parent to do. What I think is objectionable for most parents today is that, number one, they're not been given tools. They're not giving options or visibility into what's going on there, and many of them don't have the time or the tools to do that. So I think whether you're a social networking site like Facebook, which I think has been doing an excellent job of trying to bring some transparency there, or you're a site like Myspace, which I hope can work on this a little bit further, we need to be able to give parents a way of tools to be part of the conversation and not lock them out of what's going on. Thank you, Sahara. My name's Sahara Burr and I'm an assistant professor at Cornell and Department of Communication. And what I just would like to say really quick speaks to these two comments. I study the way children resist messages that are supposed to help them and why they do that and all the different reasons, and especially messages that are supposed to protect them from negative effects of the media. So I've learned a lot in this meeting. I've just been given some funding to conduct a national sample survey that looks at parents' responses to different technologies and different strategies, not just technologies, but also media literacy interventions and rating systems and all kinds of other strategies that I've been looking at in other contexts, but in the context of internet safety. And I'm putting out a call to talk to me if you have something. I've learned a lot about what to put on there today in terms of what the major concerns are, what the different strategies are from a technology perspective. But if there's something that you think needs to be known about this topic, I would love to hear from you. So please email me at Cornell or talk to me afterwards. Sahara, thank you. We're very excited to see the results of your work. And I want to make a special researcher's plea to those who are running social networks to be friendly to researchers. This is an area in which you are now public spaces, effectively in my view. And I really think those who have been cooperating closely with researchers have been aiding the public dialogue. Those who have been more close to that, I would urge you to open up some more. That's a special little plea. Can you please pass it to Wendy Seltzer here and then? Thanks, that's a great comment for me to follow up. Wendy Seltzer, I'm a fellow with the Berkman Center and a law professor. And I'm impressed with what I heard this morning about the voluntary steps that companies are taking and the effect that that has had in creating safe spaces. And I'm more impressed by that than by the rush into find the technological solution that will save us all. What I think this space needs is really good social science research into how kids are interacting online, how parents can help them to understand the technology. It was great to hear from young people who are using the technology and who are going out to talk to their peers about how to use the technology safely.  Obviously, none of us will disagree that every harm is serious and even one child hurt online is something to be taken seriously. But I worry that we all hear about the one child who has been hurt and exaggerate the problem when we hear less about the flip side of all of the children who have been helped by having places where they can talk with their peers and with others who are in cohorts slightly older than they are who can help to educate them about safety issues that they may not necessarily get from their parents or from their local community. Wendy, thank you. And thank you very much for your personal leadership in this field to be sure. Go to the gentleman from Netanyi, but one just notes for those who are not on the test force. One of the things we're doing this afternoon is having a first peek at the literature review which Dana and Andrew have put together. That's something that will become a public document. It's not there yet. It's in a very early first not for distribution draft. But what it's doing is looking at what good social science research has happened, has occurred, trying to catalog all of that and to identify frankly the gaps. We know that there are many gaps in our understanding about that. And I think that's also where this partnership between academics and social networks and others in this space can bear fruit. Please, sir. Just speaking to Wendy for a second, I think the Pew Internet. Can you just tell people there? I'm Peter Fairley from Netanyi. And speaking to what you just mentioned, I think the Pew Internet Life and Research Group does a great job and they have a lot of great stats around some of the things you mentioned. My question goes out actually to the Teen Angels. I want to talk about it in the gentleman in the back who talked about privacy for children. It seems from the stats in the Teen Angels what you guys have done that 70% of people's friends are cyberbullying them. And I've seen ads in the ad council that talk about how kids will step outside of their personas and say and do things that they wouldn't do to their friends in real life, let's say. So there's been a lot of talk about the place of being anonymous online and how that is the place. It seems that when kids are not educated properly that everything that they do online is put somewhere and everybody can see it at some point and they do step into that persona of being anonymous that these issues then happen. So when it comes down to what they spoke about about identity verification and not age verification, that seems to be the real ticket or the real way to cut through a lot of the cyberbullying and a lot of the sense of when these tweens and teens step out of their personas and take on these things and say these things that are harmful and derogatory to their friends or other kids that if they had those abilities to have the ID verification at some level that that would cut a lot of that out. And I just wanted to say that I have kids and I do talk to high schoolers and middle schoolers and I tell them to expect no privacy online at all. And if they can have that expectation and understand everything they do is being logged and put somewhere they'll have a better understanding of the long term.  And that seems to be another big issue that hasn't been brought up. But anyway, I just wanted to talk to you. Professor Lewis, do you want to respond? Well, the question is the data that said that 70% of their friends are doing things and that what the ad council is doing, when you're doing your research, do kids step outside of who they really are when they're doing things online? Okay, so do you mind just talking to Mike? Sure, sometimes they do step out into that anonymity factor, but a lot of the times kids are able to figure out that it's their friends cyberbullying them. Maybe they gave a certain piece of information to only one friend and so when that gets passed around they know how it happens. And a lot of times kids are smarter than their friends realize and they're able, just like people are able to do a little research, they can figure out how things started and kids are also very into gossip and a lot of times they get sped around who started certain rumors or started instances of cyberbullying. So we did find across the board in our research that friends, cyberbullying friends was a significant problem. And I'd like to pass the mic to Dana Boyd just for one sort of data intervention from her end as well and then we'll swing back on this side where data gluttons around here. The thing we also know just generally about when people go on to be anonymous and to be sort of stepping outside of their identity is there's sort of two kinds of clusters of practices that go on in these spaces. They can best be understood as interest driven and friendship driven. Friendship driven means going online with your friends, going on there to hang out with your peers and your schoolmates and in many ways including the bullying of your peers and your schoolmates. That is primarily identity sort of localized which means I may say that I'm 95 years old but I'm still Dana and my friends still know how old I am and we have this sort of circle going on. Then there's a set of interest driven practices. Now the interesting thing historically is that the early internet and the early web was almost all interest driven. This means that you go on and you go because you're really interested in anime and you find all of the other kids that are really interested in anime with you and there's that sort of motivation to be there and in many ways that core group, especially in the early days was stepping outside of identity because they didn't like their everyday lives. This was hardcore marginalized, ostracized, socially outcast kids of which I was one of. I grew up online desperate to escape the hellish identity that I had to deal with every day at school. What's happened as we've seen the online environment go is that as things have gotten more and more friendship driven the vast majority of behavior is very much identity local. There are still the marginalized kids out there desperate to escape identity and in some ways they are at a totally different kind of risk than what we're talking about mainstream. The most noticeable of this group of the marginalized kids are queer kids and all of the research is looking at GLBT kids, gay, lesbian, bisexual, transsexual kids. They are in much greater risk because they're stepping outside of their identity and they're doing so with a sexuality intention practice and interest which puts them into a totally different dynamic. So in terms of figuring out this sort of topology you have to think about what kinds of practices people are going into and why they're going and when they would step out of identity or not. But the majority of kids, they're going on to hang out with the people they already know. Thanks, Dana. Thank you, Nancy. Thank you for a voice of reason. Is it okay if I defer to the non-task force members and then come back or is that okay? Hi, I'm Braden Cox and I'm with the Net Choice Coalition and I'm not a task force member and I appreciate being able to be here at this open meeting and thank you, John, for hosting this and understanding what the process has kind of been all about. Well, you mentioned the Socratic method earlier. I got me thinking we're here at Harvard Law School. What would Professor Charles Kingfield do at the paper chase? So if you're in the audience, I think you'd have three questions of the task force here for the task force to consider later on and I think the first one would be, what are the problems? Let's identify what the problems are and is it something like turn to your left, turn to your right, one of you are gonna be molested online or is it something that's a little more nuanced than that? The second one I think would be, what technologies can help solve these problems and are they gonna be effective at that? And then the third one, and I think the book that was put together has actually tried to address those first two, but I didn't hear it today that much was actually, it's not whether the technology works, it's whether the technology works to make children safer and I think it's that third point that is gonna be the primary directive of this task force and that's something I look forward to hearing about. Thank you. Very helpful, thank you. I want to acknowledge that both Mike and Anne of the task force would love to get in and I will let them in but I do wanna, to the extent there are others now in the task force, give them a voice. Why don't we go to Mike since we're here and Anne next and then others can think of their questions. Okay, this is, wow, there's a voice activated microphone and it's actually on. Mike McCann from Verizon, I'm on the task force and I wanted to ask this question now since it's fresh, we didn't get a chance to talk to the Teen Angels, ask questions of the Teen Angels directly. So 70% of kids are sharing and this is directed right at you guys, 70% of kids are sharing their passwords with their friends, it seems like then 70% are getting cyber bullied, not pay me not the same 70%, but it seems like sharing password, sharing their passwords can lead to more bad things than good things. Is there something, is there a downside if industry was to develop a tool that would prevent people, kids from sharing their passwords? I mean, or maybe saying it another way, is there a good reason why we should let kids share passwords? It's a great question, thank you. Casey, reaching for the mic again. Passwords should be shared with the kids' parents and only the parents. So the kids should know it and the parents should know it and there's no reason for anyone else to know it. So I don't think there'd be any downside to that because as long as the parents know it and the kids know it, no one else needs to know it, no one else should be going into that kids' account. It's very often that the kids share it online, they, you know, with the IMing and the social networking, it's very easy to pass on information and that opens up an entirely new danger because once something is online, it is so accessible and a lot of kids don't realize that. So they think that just because they send something out and they think it's private, they don't understand that it could be copied, it could be forwarded. There's so many other ways to get that password to different people. All right. Well, that's not very common, but what is very common is, hey, I can't get to my email right now, can you check something for me? Or hey, I left this book at school, can you log on to my email and just, you know, write something, leave me a message, write something for me so I can get it later or get it from a different location. It's not outright. Here's my password. Have fun. Helpful. So I just want to turn to Dana and see if she's got a further note on the score from the data bank. Sorry, I actually interviewed tons of kids about why they change, share their passwords. So I actually have a pretty good topology of some of the different dynamics of it. There's a variety of different reasons. You have one, which is just sharing it, you know, like they said, for getting access to, you know, I can't get to my email right now. I think that's actually much broader than that and I think that this is actually where class comes into play in an extreme way. The more that schools and libraries and other places have banned access to Facebook and MySpace, the more a variety of kids cannot get online through the places that they are able to get online. So a lot of the kids, especially in working class communities who have no access to it in those public spaces know which friends have access at home, give the passwords to those friends who have access at home and will have them call up to check their information all the time. That's a really interesting side effect and cost of all of the banning that we've been doing. This also happens in the home environment. When kids are in trouble and they've been banned or their parents don't like the technology, they ban it there, they give it out to all their friends to check in them and then call when there's a new message. So the kids are supposed to check all of the friends that they can't check. Another cost of this sort of banning attempt. Mobile phones are another funny one. Kids can't actually do certain things on their mobile phones so the kids who only have access on their mobile phones will give out their friends passwords to do other things. Kids also give out their passwords to have their friends make more complex profiles. This is particularly common in my spaces because they don't have the technological fluency. They're like, hey, you know how to do this. Here's my password. Will you figure this out and set it up and just give it back to me? Right, which is another dynamic of it. Another thing that I find really interesting and probably a little bit more disturbing is the ways in which in dating relationships, when boys or girls are dating, they give each other passwords as a form of trust, a symbol of trust, and that that's a way of proving that they're not cheating on each other, right? That they can check each other's messages to make sure they're not cheating. So what are the dynamics there? And of course, there's a friend component to this as well. Now, I think that understanding why, as much as I agree that passwords probably shouldn't be given out to anybody other than parents, I think that understanding why is really critical because there's a whole set of dynamics here that are at play, that are motivating reasonable thought processing.  They're doing this for a very logical set of steps, but the thing is that these same tools that are being given for this sort of logical step can again be turned around for some of the worst of bullying. And so that's where you get these dynamics at play. And they're also totally right. Kids can guess each other's passwords like nobody's business. And one of the things I'm surprised that they didn't point out is that the worst of it tends to come from siblings where you don't even have to guess the password. All you have to do is get onto each other's computer and then play those games. So there's also that component in all of this. And then that gets getting out. The other thing is as more and more computers which allow you, which you never remember your password, you save them on your computer. Siblings also give each other siblings passwords out. Which is another component of that that plays in. Thanks, Dennis. So Ann and Blair have their hands up. Maybe if you guys can just keep them tight, that'd be awesome in case someone else wants to. Is it too hot? Thank you. And now just talk. Okay, now I'll talk briefly. I really, I appreciated what Hamu said earlier about online safety being a journey, not a destination. And one thing I think we need to be mindful of is that this is a transitional problem in a way. John and hers talk about the digital natives and very, very soon, a lot. The vast majority of these digital natives are gonna be parents. And so we're really dealing with a moving target. These digital natives are getting smarter by the day. But parents are too. And I think we need to, not only do we need to be reality based and research based and we aren't yet, we really need to get there. But we also need to observe this great experiment called the social web as it goes and learn from it collectively, actively. And see where it goes because the actual practices on the social web are changing as people learn how to navigate it and negotiate it. Great, thanks, and there. Hi, this sort of goes to the comment. Do you mind just saying? Blair Richardson from Aristotle of identifying the problem. And one of the things that there's sort of a dearth of, and I make this comment in the open session because there are researchers here that are not gonna be in the closed session. There really seems to be a dearth of information about what the behavior of online predators is when they're in these social networks. What are they doing? Where are they going? When they get identified and kicked off, where do they go? Do they try to come back in? Are there interviews? Are there studies? Is there research of what these people are actually doing? They're really the most dangerous members of society to kids. And if there is anybody that is aware of studies, research, interviews, anecdotes, anything, I think it would be really helpful to the whole task force to address that exact question of what's the problem. And certainly the task here of the Research Advisory Board is to roll up what's good there, to be sure. Very brief is that there's almost none because it's methodologically how? Honestly, the numbers are so low that the people that have been arrested for these kinds of things that even doing post-FBI interviewing is very difficult. The other thing is that the DOJ does not release a lot of what they do in terms of the interviewing around this. So it's not that people don't want to do this. There's only one research project out there that actually investigates people post-FBI interviewing. And other than that, it's really difficult. They're coming up with the second one soon. But this is where you get tracings, which is only a certain amount of information. You don't actually, understanding the logic requires interviewing. So it's a question of what you want to understand. There's a lot more understood through the tracings. There's a lot less understood through the logic of why and why is an interview question. Then we'll come back to this when you talk a little about the literature review in a moment. We're almost at time, but is there anyone not a member of the task force who wants to get on the record at the moment? Please. Can we get a mic over here? Thanks, Anne. Please tell us who you are. Hi, Kate Schroeth from iCouldBe.org. I just wanted to remind the task force that, while I'm thrilled that 100% of all the parents attending the conference are very responsible with their children's online lives, there are millions of children out there who do not have that in their homes. And that it's a very vulnerable population that we have to think about as well. As well put, I think that is the note on which we should end this public session. A wonderful, wonderful comment. And thanks to everyone for participating. All right, so we're gonna take a break for the next hour. So I think we have just kind of a lunch period. Jess, we'll return here at one for the actual discussion. Okay, task force now, we would love to welcome you over at the Berkman Center, 23 Everett Street. There's gonna be a resetting of tables and so forth. Then task force members and the select number of the TAB are gonna come back to here at one, right? Great, see you back.


Pancreatic cancers are a group of various type of cancers which can affect various parts of the pancreas. If we talk of the symptoms of pancreatic cancer, patients most commonly have pain in the upper part of the abdomen, they have loss of appetite, they have jaundice. A very typical symptom of pancreatic cancer is a pain which goes, which travels from the front part of their abdomen to the back, which is known as a radiating type of pain. How do we diagnose pancreatic cancer? We can diagnose pancreatic cancer by doing a CT scan of the chest and the abdomen, which is done with a contrast. However, we can also do a PET scan to diagnose whether the cancer is localized or it has gone spread. How do we treat pancreatic cancer? Pancreatic cancer is usually treated by a multi-modality treatment, which includes surgery, chemotherapy and radiation. However, surgery is the mainstay of the treatment, which is followed by chemotherapy or radiation depending upon the stage of the disease. We at Sanaa Hospital, we perform pancreatic cancer surgeries by laparoscopic means, which means that the whole surgery can be done without a single cut or a large cut in the abdomen. Only by making very small centimetric size, one centimeter, half-centimetric size incisions, we can do a surgery with a great precision, with great results where the blood loss, the pain, the post-operative outcome and the recovery is much faster. What we need to understand is that pancreatic cancers are quite an aggressive kind of cancer where patients' life can get shortened if the disease is diagnosed later on. So it is important that whenever the patient or any person has got a pain, which is not relieving for a long time, is radiating to the back, patient is having jaundice associated with it, then you should urgently see a physician or a surgeon where you can get evaluated at an early stage and get rid of a very aggressive disease, which is likely fatal in the later stage of the course.