We have seen that one of the relatively easy way of showing that a function is integrable either Riemann integrable or Riemann Stilder integrable is the one criteria which we discussed last time and that is the following that let me write that is we have shown that f is integrable that is r a b alpha if and only if for every epsilon bigger than 0 there exists a partition p in this script p such that for this particular partition u p f alpha minus l p f alpha is less than epsilon and using this we have shown that every continuous function is Riemann integrable and also with a slight modification of same proof we have observed that every continuous whenever alpha is any monotonically increasing function every continuous function is also Riemann Stilder integrable and the main tool used there was if you remember that every continuous function defined on such a closed and border interval is uniformly continuous and using that we subdivided the partition in a particular way for continuous functions we can also notice one more thing in fact we have noticed that whatever be the partition this part is always true that is l p f alpha this is always less than or equal to u p f alpha then we have also observed let me keep this is less than or equal to any Riemann Stilder sum and this is less than or equal to upper sum and this upper sum is less than or equal to big m into alpha b minus alpha a and this lower sum is always bigger than or equal to small m into alpha b minus alpha a where as usual the small m and big m have the same meaning which we have discussed earlier namely that big m is the supremum of f x over the interval and small m is the infimum. What we also know is that whenever the function is integrable the upper and lower integrals coincide and upper integral is the infimum of the upper sums and so it will be always less than or equal to any upper sum similarly lower integral is the supremum of the lower sums so it is bigger than or equal to any lower sum so both these numbers lower integral as well as the upper integral they lie between any of the lower sum and the upper sum and in particular when the function is integrable the number integral is nothing but the common value because we say that the function is integral is same as saying that the upper integral is same as the lower integral so that common number will also lie between these two always common no not these two this and this this and so what we can observe here is that okay let me write it once again here if f is integrable that is if f is this or a b alpha then then we can say this that is this is less than or equal to integral a to b f d alpha and this is less than or equal to integral no this is less than or equal to up f alpha and we already seen that this is less than or equal to big m into alpha b minus alpha a and this is bigger than or equal to small m into alpha b minus alpha a okay and usually this function alpha will be a strictly monotonically increasing function so alpha b minus alpha a will be strictly bigger than 0 in most cases unless in some very trivial examples so what one can say further is the following okay that is I can say that this small m is less than or equal to 1 by alpha b minus alpha a into integral a to b f d alpha and this is less than or equal to big m okay this much is true for any integrable function right this if the function is continuous we can say something more okay and what is that this big m is a supremum okay and we know that if the function is so continuous on this interval then this value is attained that means there is some point let us say the point x 1 such that f at x 1 is equal to m right similarly there is some point let us say x 2 such that f at x 2 is m okay that means these values small m and big m are taken actually taken by the function and if the function is continuous we know that if it takes any two values it will take all the values which lie in between those two the famous intermediate value theorem so that means what that means there should be some point at which the function takes this value also right that will happen if a function is continuous okay so let us let us just see what is the consequence of that so if f is also continuous on a b then there exists a point c in this interval a b such that such that what should happen that is 1 by alpha b minus alpha a into this this is same as c that is 1 by alpha b minus alpha a into integral a to b f d alpha this is equal to c not c this is equal to f at c because there is some point c at which the function f takes the value given by this that is f of c is equal to this number or what is same as same that suppose we rewrite the same thing in a different manner that is integral a to b f d alpha that is same as f at c multiplied by alpha b minus alpha a and this statement that whenever f is continuous there exists c in a b satisfying this last okay that is called the first mean value theorem of integral calculus that is called the first mean value theorem of integral what is the theorem that if f is continuous see once it is continuous it is automatically integrable that is what we have already already shown then there exists c such that integral a to b f d alpha is equal to f c into alpha b minus alpha a that is called first mean value theorem okay we will use the standard short form for mean first mean value theorem of integral calculus by mean value theorem because it looks very similar to mean value theorems of differential calculus it talks about some point c inside the interval a b such that something happens at that point and why first obviously it means something is going to follow something some more theorems are going to follow that is why but anyway it will not happen immediately after some time alright so that is about this continuous functions there is one more class of functions in case of which we can prove in a straight forward manner that those functions are integrable and those are monotonic functions okay so that is another theorem that we want to say let us as usual just as we have done in case of continuous functions we shall first prove for Riemann integrals and then we will go to this arbitrary Riemann Stelios integral so if f is monotonic monotonic on a b then f is of course we are always assuming that this function alpha is okay for the time being I am not talking about alpha then f is Riemann integrable okay let me write in words then f is Riemann integrable okay now what happens if f is monotonic okay f is monotonic means what it is either monotonyically increasing or monotonyically decreasing let us prove in one of the cases prove in the other case will be similar okay so assume f is monotonyically increasing in order to know what is happening in this case see the first thing that we can observe here is that what we have defined let us recall the definitions of this big mi and small mi that is this big what was this big mi big mi was nothing but supremum of fx where x belongs to this ith sub interval xi minus 1 to xi okay but we know that f is monotonyically increasing so what can we say about this big mi for an increasing function on an interval what will be the maximum value that it takes at the right hand end point okay so this is nothing but f of xi right similarly small mi that is nothing but infimum of the same and that will be nothing but f at xi minus 1 right f at xi minus 1 right okay now for any such partition suppose we look at the difference between the upper sum and lower sum since we are talking about the Riemann sums let us just look at u pf minus l pf okay so this will be the thing but sigma i going from 1 to n sigma i going from 1 to n it will be nothing but f xi minus f xi minus 1 multiplied by delta xi okay right and delta xi is nothing but xi minus xi minus 1 okay alright now suppose I choose a partition in such a way that this delta xi is constant okay suppose I choose a partition in such a way that this delta xi is constant if the delta xi is constant then there is only one possible if there are n sub intervals each must be of length 1 by n okay so choose a partition in such a way okay that n we shall choose later okay but first we will say that if there are so choose p such that choose p such that delta xi is see there are n sub intervals and if each interval is has to be of the same length and the total length is b minus a so each of the delta xi must be b minus a by n okay so each of the delta xi must be b minus a by n okay and so what will be the partition that is also easy to say we know that a is x naught then x 1 will be nothing but a plus a plus b minus a by n that is x 1 x 2 will be a plus 2 times b minus a by n etcetera etcetera okay so in general one can say that xi is equal to a plus i times b minus a by n choose this partition okay so for this partition what will happen to this up f minus l p f this delta xi is b minus a by n so that will come outside the summation sign okay that will come outside the summation sign so this is nothing but b minus a by n and multiplied by this sigma i going from 1 to n f xi minus f xi minus 1 okay so once that once that the delta xi has come outside what will remain suppose you take this sum for example first element will be f x 1 minus f x 0 second will be f x 2 minus f x 1 etcetera okay so it will be simply f of x n minus nothing but f b minus f a nothing but f b minus f a okay so you can put that here f b minus f a so suppose you do that simplification so what we get this this up f minus l p f this is nothing but this b minus a divided by n and multiplied by f b minus okay you can say then okay now come come back this criteria what we said that f is integrable if and only for every epsilon there exists a partition p such that up in our case this alpha is just x okay so up f minus l p f is less than epsilon okay all right now in our case what is up f minus l p f it is b minus a f b etcetera okay there is only one thing that depends on the partition and that is this number n everything else is fixed okay so the only question is this given epsilon can we choose n such that this whole thing becomes less than epsilon that is obvious right because we can make n sufficiently large so that this b minus a into this number is suppose this number is fixed suppose you call that number k okay this whole thing is k by n okay then choose n such that n is bigger than epsilon by k okay m is bigger than epsilon by k then this difference will be less than epsilon okay and that means that that means that f is Riemann integrable right f is Riemann integrable okay all right is this clear now coming back to Riemann's Tildes integrable Riemann's Tildes integrable see one can do all these calculations up to this okay this will be replaced by up f alpha minus l p f alpha okay let me let me carry on here okay suppose instead of Riemann integrability suppose I look at Riemann's Tildes integrable then this will not change okay b mi and small mi those numbers depend only on f okay so if I look at this difference p f alpha minus l p f alpha this will be sigma i going from 1 to n then multiplied by f sorry f xi minus f xi minus 1 and this is multiplied by instead of delta xi it will be delta alpha i okay it will be delta alpha i okay and what is delta alpha i recall delta alpha is a thing but alpha xi minus alpha xi minus 1 okay so instead of delta xi there we have delta alpha i here we have delta alpha i here and what was our next argument we have said that we can choose a partition in such a way such that that delta xi is constant the delta xi and that the delta xi turned out to be if it has to be constant it has to be b minus a by n so what will be the change here we will want is delta alpha i to be alpha b minus alpha a divided by n okay delta alpha delta alpha i should be alpha b minus alpha a divided by n now the whole question is whether okay that is if we want to imitate that we want this okay we want delta alpha i is equal to alpha b minus alpha a divided by n okay for example suppose I suppose I want let us say suppose I look at say delta alpha 1 what is delta alpha 1 that is alpha 1 is nothing but alpha at x 1 minus alpha at x naught this should be same as delta alpha b minus alpha a alpha b minus alpha a divided by n okay or what is the meaning it means alpha x 1 should be same as alpha x naught plus alpha b minus alpha a by n okay now if you compare this situation here here it was easy to say that you just choose x 1 such that x 1 is a plus b minus a by n okay choose choose x 1 x 1 is same but a plus b minus a by n but here what is the case we want to choose x 1 such that alpha x 1 is equal to alpha x naught plus alpha b minus alpha a by n okay so the question is whether such an x 1 exists or not okay whether the function alpha takes this value or not okay right that is the question okay and in general we only thing that we know about the function alpha is that it is monotonically increasing okay only thing that we know is it is monotonically increasing right but we know nothing further but if we impose some additional condition see is it is it clear to you that alpha x 1 that is anyway bigger than or equal to alpha see this is this alpha is monotone this is a non negative number okay so so this alpha x naught is less than this alpha x 1 and this is obviously less than or equal to alpha b minus alpha a okay or not alpha b minus a this is I can say less than or equal to alpha b okay that is clear all right because alpha I can say that alpha b alpha x naught is nothing but alpha a alpha x naught is nothing but this is nothing but alpha a alpha a plus alpha b minus alpha a divided by n okay and one can say that for any positive n this will be less than or equal to alpha b minus alpha a and then hence this whole thing will be less than or equal to alpha b okay right so if we knew that alpha is continuous if we knew that alpha is continuous then we can say that it takes this value it takes this value so it will take all the intermediate values so I can find x 1 such that alpha at x 1 is equal to this otherwise we cannot say this otherwise so if we add the hypothesis of continuity to alpha then I can say I can choose alpha x 1 in this fashion having chosen alpha x 1 use the same technique I can choose alpha x 2 also in the same fashion so if alpha is continuous then we can choose the partition x naught x 1 in such a way that each delta alpha satisfies this condition okay otherwise you may or may not be able to do this okay so what it means is that this will work if you assume that f is monotonic that alpha should be not only monotonic but also continuous and that is remember that is true for rebar integration this because in in case of rebar integrals alpha x is a thing but x that is a continuous function okay so that is automatically satisfied here okay so we can say that if f is monotonic on a b then f is rebar integrable also if alpha is continuous then that means all this is assumed f is monotonic alpha is also monotonic increasing and continue continuous then f belongs to this r a b alpha now we go to the another task just so just as in case of differentiability we have done if we know that a function is differentiable then what can be for example suppose we know that f1 and f2 are differentiable then f1 plus f2 is differentiable etc a similar thing we want to do in case of integration okay that is suppose we know that some functions are integrable then constructing functions using those functions and whether those new functions are also integrable or not that is the question that we are going to deal with now right so let me start with this okay so suppose this is a theorem okay suppose f and g are that is this means inverse f and g are rebar integrable with respect to some monotonic increasing function alpha okay then okay there are several statements we want to make okay I shall write one by one and then we shall discuss the corresponding proofs also all these proofs depend basically on the definition of integrability okay so first thing that we want to say is this f and g are also sorry f plus g f plus g is also integrable f plus g is also integrable and we can say something more integral a to b f plus g d alpha this is same as integral a to b f d alpha plus integral a to b g d second thing is okay f or g it is suppose we take any k for every real number k in r okay for every real number k k times f is also rebar still integrable integral a to b k f d alpha this is same as k times integral a to b f d alpha okay what what does it mean in words that if you take two functions in this if f and g are rebar integrable rebar still just integrable then there are some as well as product with a constant is also integrable okay in other words since you are also doing a course in linear algebra simultaneously it is basically same as saying that this is a real vector space set of all ribbons still just integrable suppose alpha is kept fixed then set of all ribbons still just integrable functions is a vector space over real numbers if you take all functions on a b that is also vector space you can say this is a subspace of that and what can we say about can we also describe this part in terms of linear algebra using terminology of linear algebra have you studied what is meant by a linear functional yes have you studied what is meant by a linear functional so what does this say that integral a to b f plus g d alpha is same as integral f d alpha plus integral g d alpha and second thing says that integral k f d alpha is same as k times integral a to b f d alpha right so in other words if you take this map f going to integral a to b f d alpha or suppose you define phi f is equal to integral a to b f d alpha then phi is a linear functional on this vector space so basically proving these properties of this integral is basically showing that integration is a linear functional on this vector space of all integrable functions now since there are three functions involved here f g and f plus g and whenever we want to talk about the integration obviously upper sums lower sums are going to come into picture and so we have to discuss the upper sums lower sums of three different functions so we need some notations for this big m i small m i etcetera so let us start with this let us say that suppose we i will call this function h let h be equal to f plus g then we will have to talk about the upper sums corresponding to the function h corresponding to the function f and corresponding to the function g all right suppose let us say that we will have suppose I call this m i as the supremum of let us say hx hx from x in hx for x in xi minus 1 to xi I will get similar numbers for corresponding to f and corresponding to g right so let us say suppose I denote this by m i star as supremum of f x same thing x is in xi minus 1 to xi and m i double star as supremum of f x in not f x or g x for same thing x varying with the interval xi minus 1 to xi okay can we see obvious relationship between this m i m i star and m i double star what is that m i must be less than or equal to m i star plus m i double star okay that is so we can say that this m i must be less than or equal to m i star plus m i double star what does it say about the upper sums we can say that from this it follows that upper sum of h must be less than or equal to upper sum of f because all that you are doing is that multiplying each of this number by delta alpha and taking the sum so we can say that this implies that up h alpha is less than or equal to up f alpha plus up g remember we are going to use that same method to prove that h is integrable what is the method that given epsilon will produce a partition p such that up h alpha minus l p h alpha is less than epsilon that is the idea okay so what we can what we can do now is that okay now now this is true for every partition whatever be the partition that upper sum of h is less than or equal to upper sum of f plus upper sum of g that is true for every partition okay but we know that f and g are integrable okay we know that f and g are integrable so what we can say is that given any epsilon given any epsilon i can find a partition suppose i call it partition p okay let us let us start with epsilon okay let us let us start with an epsilon bigger than 0 what is the m our aim is to produce a partition p okay such that for that particular partition u of h up h alpha minus l p h alpha that should be less than epsilon okay that is the that is the aim okay but we know that such a thing can be done for f and g such partitions can be found for f and g so we shall use we shall use that fact first okay let us first stick to the upper sums one can say that there exists partition suppose i call it partition p1 okay there exist partition okay see here we are going to have the several partitions and we are going to use the thing that we have shown earlier that whenever you take a refinement the upper sums decrease and lower sums increase okay so we will find a partition corresponding to f corresponding to g and then take something which is common refinement of both okay so we can say there exist a partition p1 such that okay we know that f and g are integrable so integral is nothing but the infimum of the upper sums okay in fact that is what we had called upper integral but when the function is integrable those two things are same so i can say that i can find some partition such that the difference between the integral and the upper sum is less than epsilon or epsilon by 2 or epsilon by 4 whatever we want okay that is that is what we can do okay so i can say there exist a partition p1 such that so see u p p1 f alpha u p1 f alpha minus integral a to b f d alpha this is less than okay i do not remember okay let us start with epsilon by 4 okay if we require we shall change that epsilon by 4 to epsilon by 3 or 6 or whatever we require okay this can be done okay then one can say that similarly there exists a partition p2 such that upper sum u p1 g alpha is less than integral i can i can rewrite this inequality i can bring this integral to the other side okay that is convenient okay instead of writing like this i shall say that this this upper sum is less than this integral plus epsilon by 4 okay and similarly this upper sum is less than integral g d alpha plus epsilon by 4 okay now this was p2 right now consider the partition p1 union p2 okay consider the partition p1 union p2 for that partition both of this is inequality should satisfy should be satisfied okay right so okay suppose i call that partition now p3 okay let p3 be equal to p1 union p2 okay then what what we want to say is that then u p3 f alpha this is less than or equal to u p1 f alpha and that is less than integral a to b f d alpha plus epsilon by 4 similarly also u p3 g alpha this is less than or equal to since p3 is also a refinement of p2 okay this is less than or equal to u p3 g alpha and that is less than integral a to b g d alpha plus epsilon by 4 okay all right now you look at u p3 h alpha we have seen earlier that for any partition u p h alpha is less than or equal to u p f alpha plus u p g alpha okay so u p3 h alpha that should be less than or equal to u p3 f alpha plus u p3 g alpha that is this should be less than or equal to u p3 f alpha plus u p3 g alpha okay and this is less than integral a to b f d alpha plus epsilon by 4 and this is less than integral a to b g d alpha plus epsilon by 4. So, there are some should be less than this plus this plus epsilon by 2.  So, do you agree up to this? Now, whatever we have done for the upper sums is it clear that we can do a similar thing for the lower sums. What is the obvious changes? Here you will take small m i small m i star and small m i double star and inequalities will be reversed. Small m i will be bigger than or equal to small m i star plus that is in other words lower sum of h alpha will be bigger than or equal to lower sum of f alpha plus lower sum of g alpha. So, everything that you have done in a similar way you can do everywhere inequalities will be reversed.  So, one can say that following a similar method you can find a partition. You can find a partition such that for that partition lower sum is bigger than this number minus epsilon by 2. So, I shall skip those details do that on your own to convince yourself. I will say that in a similar way we can find a partition. We can find a partition.  So, again we go is this clear. So, then again we go back to the same degree. Here we have partition p 3 for which u p 3 is less than this number plus epsilon by 2 and here we have partition p 4 such that this is bigger than this number minus epsilon. If this were the same partition we could immediately say that this minus this is less than epsilon, but that is not the case because. So, but we know that how to deal with such things. Just take the union of the two that will be a common partition for both common refinement and so that both the inequalities are satisfied. So, I will just this statement I require. So, I will go back here. So, let p be equal to whatever partition we have p 3 and p 4 p 3 union p 4 and we want to show that this p is the required partition p is a refinement of both p 3 and p 4 and we know that for the refinements upper sums decrease and lower sums increase. So, let me just write it here. So, I can say that this u p h alpha u p h alpha is less than or equal to this and hence less than or equal to less than this plus epsilon by 2. Sorry, this should have been everywhere this should have been that is correct. Yes sir third line this line third line here p 2 common sir second in the middle u p 2 g alpha is same. That is right because we have used the fact that p 3 is a refinement of p then where we are using that p is p 3 union p 4.  So, lower sum with respect to p should be bigger than or equal to lower sum with respect to p 4. So, we can also say that l p h alpha is bigger than or equal to l p 4 h alpha and so that is bigger than all these things.  So, when you subtract these two numbers will get cancelled. So, this will be epsilon by 2 minus. So, this is less than epsilon. So, what we have. So, this shows that this implies that h is Riemann Stilder's integrable. It shows this first thing and though it does not show immediately this you can observe that we have done whatever is required for showing this we have done whatever is required for showing this. Once we show that h is Riemann Stilder's integrable it means that integral h d alpha exists. It means that integral h d alpha exists and that is less than or equal to any upper sum that is less than or equal to any upper sum and also bigger than or equal to any lower sum. So, but we already have one partition for which we we not only proved this. In fact, we have proved many much more than this. We are in fact proved that u p h alpha is less than or equal to this number plus epsilon by 2. So, let us just recall that. So, once we know that h is Riemann Stilder's integrable it means that this number exists integral a to b h d alpha exists. That is something we already proved and moreover this number must be less than or equal to any upper sum. This number must be less than or equal to any upper sum. So, that means in particular this is less than or equal to this u p h alpha. This must be less than or equal to u p h alpha.  That is something that we know.  What is more? We also know that this is the integral must be bigger than or equal to any lower sum must be bigger than or equal to any lower sum. So, this must be in particular bigger than or equal to l p h alpha and we know that l p h alpha is bigger than or equal to again let us write this is bigger than or equal to l continue here.  What does it mean? That is this number integral a to b h d alpha this lies between whatever is the sum of this 2 number plus epsilon by 2 and this minus epsilon by 2. So, what can we say about the difference between this and the sum of these 2?  Suppose I want to look at difference between this difference. In fact, we have shown that this difference is less than epsilon by 2 because this shows that this minus this number is less than epsilon by 2 and bigger than minus epsilon by 2. So, this difference is less than epsilon by 2, but epsilon was arbitrary remember that we started with any arbitrary epsilon and for that epsilon we have shown that the if you take this number and whatever is there on that is difference between left hand side and right hand side is less than epsilon by 2 for any arbitrary epsilon. So, the only way in which this can happen is that those numbers must coincide those numbers must coincide and that gives this result. That is if the 2 functions are remastered as integrable their sum is also remastered as integrable and integral of f plus g same as integral of f plus integral of g. Then what I would say is that the proof of this is also exactly similar. There are no new ideas involved here. In fact it is even simpler because see here what was the whole idea relating to the upper sum of this f plus g with upper sum of f and upper sum of g and similarly for the lower sums. Here you have to do only for the function k times f and that is very easy because you can say that upper sum of that is you can easily show this that for any partition p u p f alpha is say we want k times f we want k times f of course you will have to make a slight slight you have to be little bit careful here. You have to make the cases when k bigger than or equal to 0 k less than or equal to 0 etcetera. If k is equal to 0 there is nothing to be proved k is equal to 0 there is nothing to be proved because it is a constant function 0 and 0 that is integral. If k is bigger than 0 then we can say this if k is bigger than 0 then then upper sum of k times this is same as k times u p f alpha. And similarly one can say about the lower sums and so you can prove this at least when k is positive you can prove this at least when k is positive. If k is negative what will happen is that this will be k times the lower sum of this if k is negative upper sum of p k f alpha is nothing but k times lower sum with this and similarly for the lower sum and again you can basically use the same technique. So, no new ideas are involved to prove this so that is why I will skip this proof basically all that you need to do is given epsilon you have to produce a partition p such that for that partition difference between upper sum and lower sum is less than epsilon. And then this part you can prove in the similar way using this we will stop with that. There are many other properties of this type and those we shall see in the next class.


This study compares the efficacy of three psychological interventions, short-term psychodynamic supportive psychotherapy, SPSP, affect phobia therapy, APT, and schema therapy, ST, for individuals diagnosed with cluster C personality disorder, PD. The study will assess the effectiveness of each intervention by measuring changes in ADPIV scores over time. Additionally, the study will examine potential mediators such as personality functioning, psychiatric symptoms, and quality of life.


Hi, everyone. Hi, I'm really loud and excited to talk about Terraform today. So how many people have heard of Terraform before three minutes ago? How many people have heard of Terraform before they read it on the Meetup Group? OK, roughly the same people. Good. So my name's Seth Vargo. I'm at Seth Vargo on Twitter. I work at Hashicorp. I wear a couple of different hats. So you might see me responding to support tickets. You might see me working on open source projects like Terraform, for example. And I also work on some internal tools and some of our commercial products. So depending on what day of the week it is, I'm usually touching a different part of the ecosystem. So if you haven't heard of Terraform, perhaps you've heard of some of the other tools that we work on. Probably the most notable and oldest tool is Vagrant. How many people have used or heard of Vagrant before? Cool. So the last talk talked about VirtualBox for a couple sentences. Vagrant is a command line driver for virtual machines. So VirtualBox, VMware, their support for AWS. Pretty much any virtualized instance, you can control and create a isolated development environment, quickly create and destroy them. Packer, how many people know about Packer? It's like all the same people, this half of the room. Packer was the first Go project. So Vagrant was in Ruby. Packer's in Go. That is a way to build replicated virtual machines. You can build VMware boxes, like ISOs. You can build cloud-based images, kind of the whole stack. So the idea was you could build a Packer image and then throw that into Vagrant and then use that same Packer image to run your production infrastructure. Surf is gossip-based protocols. It's what Console is built on top of, which is service discovery, key value stores are first-class citizen. And then our most recent product to hit the market is Terraform. And I say product, which is a very heavy word because all five of these tools are open source and they have many different contributors, some of whom work at HashiCorp, some of whom work at a variety of different companies from a bunch of different backgrounds. They're all in Go except Vagrant, which is in Ruby. Obviously today we're talking about Terraform. But if you have questions about any of the other tools, feel free to hit me up afterwards. We can talk offline or whatever. So the biggest question is why write Terraform? Why does Terraform exist? What problem is it solving? So anytime you set out to solve some software engineering problem, you have to have a problem to solve.  What problems base are we filling? What gap are we trying to make easier for our consumers? So one of the questions that we had a lot were how do I provision resources? So we have tools like Puppet, Chef, Ansible, Salt, and they can be configured, they can be managed, but it's kind of a one-to-one relationship. So I have this one server, maybe physical, maybe virtual, maybe a container, and I'm gonna apply Chef to it. I'm gonna apply Puppet to it. But I want something higher than that. I wanna be able to extract that. I wanna be able to describe compute resources the same way that I describe my DNS resources. The same way that I describe my storage resources, my network resources. So it's not just what does this one isolated system look like. I wanna be able to describe my entire infrastructure topology in a shareable way. So furthermore, I described it, I can spin it up, like let's assume that works. I have this hypothetical file that describes my entire infrastructure. How do I manage the life cycle? What does it mean whenever the instance is down? How do I add more instances, remove more instances? How can I associate the relationships between the database and the web application, for example, or between the database and the backend RESTful API? Furthermore, how do I balance all the existing technologies I'm using? So how many people work in some type of hybrid environment? Where you have some cloud-based things, maybe you kind of work in a data center, maybe some of your stuff's on AWS, some of it's in digital ocean, some of it runs in like what I call Closet Cloud, which is like that one server in the corner of the room that you don't touch, cause your boss told you not to. We work in very, very hybrid environments. How can I manage it where half my infrastructure is in digital ocean, half of it's in AWS and the other half is in Closet Cloud and that adds up to three halves. This is how computers work. Furthermore, let's talk about security. How can I enforce policy across all of these machines? So not only can I make sure that only required users, required ports, or required permissions are there, but how can I make sure that this particular machine has this set of services, this set of packages, this set of responsibility and how can I separate those concerns? And finally, very rarely are we in isolated, tiny little boxes. We work in teams. Software engineering is a very collaborative effort. So how can I share these, whatever this mythical file is? How can I share it? How can I version it? How can I store it in something like Git or SVN? How can I collaborate on it, get feedback from my peers, all while realizing that this file is really the description of our production infrastructure, which is kind of a big deal if you think about it. I'm encapsulating the thing that makes me money in one file and a Git diff is gonna tell me whether or not it's okay. So we need something that's incredibly gross, incredibly descriptive and powerful, but why did, like, how did we get here in the first place? So let's talk about the rising data center complexity. 15 to 20 years ago, we had a data center, and the data center was kind of like this one server. Might have been a mainframe, might have been just this really powerful server, and it was kind of run by this one dude, and I don't say that to be sexist, I say that because they were all dudes at the time. And it was kind of a, you know, you pick up the phone and you're like, hey, we need this package installed, and then like six to eight months later, you got your package installed, and I'm not gonna like blame IBM since I'm standing in their office right now, but they may or may not have been one of the companies that provided such a service, but very quickly we realized that we needed more compute resources. One server was no longer cutting it. We needed four servers. We needed our primary database slave and our secondary database slave.  We needed the ability to scale and handle more and more traffic. And then we entered kind of like the last five years where technology is rapidly advanced. So the era of virtualization where no longer does one application run on a single physical server, but we have a physical server that may run like anywhere from two to 200 virtual machines, depending on the physical capacity of the machine and the requirements that it has. And then we extrapolated that even further, and now we run containers in our VMs that run in our physical machines that run in our data center. So as you can see, the complexity increases drastically. No longer are we concerned about one physical server that has a very, you know, cute name that we can refer to when talking to our colleagues, but we're talking about highly ephemeral infrastructure, service-oriented infrastructure, microservices, and high fault tolerance, where no longer do we care about whether the server is down. We care about whether 90% of the nodes are functioning. And if 10% is an acceptable loss, then our ELBs can handle that. It can automatically route traffic. So we're no longer in an era where we can think about infrastructure in a way that is binary. And it gets even more complex when we add third-party service providers. We're adding our DNS provider, whether that's something like Simple DNS, or you're using something like Dyn.  Maybe you have a database as a service or a caching layer as a service. You're not running your own Redis. You're using Redis Cloud. All of these things add extra complexity. And to communicate with, let's say, Dyn, for example, you can't really use Puppet or Chef to do that. You're making API calls to their service with some authentication tokens. It's not really the place of a configuration management tool to be doing that. And since it's infrastructure-wide, not on a per-system basis, it doesn't make sense for 10 nodes to make API calls to Dyn, just to update a DNS entry. So, furthermore, as I kind of hinted at before, is all of my slides so far have assumed that we have a single data center, but in reality, we have hybrid data centers. So, not only do you have more than one data center, so maybe you're balancing availability across the East Coast, the United States, the West Coast, and Asia, but you may have two physical data centers and a cloud-based virtual data center. So maybe you have one data center sitting in AWS, behind a VPC. You have one sitting in a proprietary data center that you rent space and a rack and bandwidth, and maybe you have another closet cloud somewhere. And it gets even more complex if we realize that these environments are not homogenous. So they're actually a mixture of everything we've talked about so far. So maybe you're an infrastructure provider and you need physical machines because you're providing infrastructure, but maybe you're like a cloud provider and you need virtual machines because you don't really care about providing physical machines. Nobody's running QEMQ on your stuff, so you can provide virtual machines, you can allocate resources, or maybe you're someone that's providing containers as a service, or maybe you're doing all three of them. Your apps run in containers, but you still need a physical machine to perform some really big data number crunching or something that's very IO-intensive. And then maybe you have a whole other data center that's just cloud-based storage, and how do you aggregate all that information and how do you describe that this container here has access to a particular networking resource that this machine should not and that that cloud should have those ports open with that VPC rule and only this container here can talk to this cloud. It's very complicated. It's very complicated for me to even explain to you, let alone try to describe in some type of state file. So this was the problem. Given all of this information, how can you possibly solve the problem of I wanna describe my entire infrastructure in a single file? And we have our asses, the IS, the PS, the CS. And one thing that I didn't talk about was, holy crap, there's these things called Windows and Linux and Mac and Linux, and we have different operating systems and this thing doesn't operate at all like this thing. And this thing here kind of operates like this thing, except this is based on Darwin, which is actually based on BSD, which kind of works like that thing, but doesn't work like Ubuntu and other things. And it's just a total mess working in not only in an environment where you may be working between containers, virtual machines and physical machines, but you're working with different operating systems, different versions of those operating systems, which have different packages available, all of which make it exponentially complicated for the user to configure these things. Ultimately, it's a nightmare. I don't think anyone in this room or anybody who has ever worked in a large infrastructure capacity would say they enjoyed researching different package names across different releases of different operating systems just so they could get something to deploy. Taking all of this, we took a step back and we said, what problem are we trying to solve? What is the goal here? Came up, Terraform kind of has this mission statement, which is to effectively deliver and maintain applications. So at the end of the day, your business unit as a technology company is some type of application. That may be a web app, that may be an iPhone or an Android application, that may be a service that supports some other monetary device. But at the end of the day, you're deploying some type of application or series of applications that are your monetary stream. So we need a way to effectively deliver and maintain the life cycle of those applications. So whether it's the first deployment or the 10,000th deployment, it should be just as easy in the same process. If you break down the application lifestyle, you have develop, deploy, and maintain, right? So the initial development, this happens usually on your personal laptop. Maybe it's a company laptop, but this is kind of like your personal workstation. Maybe you're working in isolation, maybe you're pair programming. But what's important about that environment is that it's consistent, not only among your developers, but it's shareable among your developers, readily available. So I don't wanna wait three days for my development instance to provision, just so I can write one line of code, as close of a parody to production as possible. If we have a production infrastructure that has 50 microservices, obviously we're not gonna run all 50 microservices on our local development machine. But getting as high as a parody to production as possible, making sure we're running the same version of Redis, the same version of MySQL, the same version of Postgres, that we are in production, so that the cost of fixing a bug is drastically reduced in development, compared to once the bug hits production. The next stage is obviously deploying that, and that's the more of the configuration managed side of things. So this is where Puppet, Chef, Ansible, Salt, or just homegrown bash grips really shine, which is I need to start this thing and install this thing and then run this thing. So AppDash get install, pseudo service start and service, I don't know, status to make sure it's running. Fail if it doesn't return a zero. And then the maintenance is where things get a little more difficult is, what does the nth deploy look like? How do data migrations look? What if I need to reconfigure something, turn on feature flags? How do I monitor the service? Or how do I react to particular monitors? So if disk space is high, what do I do? And finally orchestrating really complex changes. So an example of a non-complex change is adding another database server. An example of a complex change is migrating from like MySQL to Postgres and changing the number of database nodes and the way you do replication, perhaps your whole sharding mechanism. So how do you orchestrate all of that? And this is kind of like the big picture. So the idea behind all of these open source tools is that with Vagrant, you have this like awesome development environment. It works as close to production as possible. And then Packer and Terraform work together to build your production infrastructure. And Packer can output Vagrant boxes. So effectively you describe your infrastructure using Packer and Terraform to produce Vagrant boxes. So you produce the Rails front end Vagrant box that you can then distribute to your developers, whether it's like on your internal wiki or just download it from Dropbox and say, hey, this is the Rails front end. And you can ship nightlies of that in your CI by just simply running Packer and Terraform, jettering it a dev box. And every morning your dev comes in, downloads the newest box and they're good to go. It's as simple as running Vagrant up and they're able to hack on your code. As opposed to the typical developer bootstrap process which takes usually like a couple of weeks. You have to install your Ruby's and your Go's and then, no, we don't use RBM, we use RBM. And then you have to implode all of that. And then somehow you got stuff in your system Ruby and it's just always a nightmare. With Vagrant, you have highly ephemeral environments.  And it's pretty awesome. Then on the maintenance side, which is something that I'm not gonna talk about too much today, we have console and surf. So console's built on top of surf, which is like service discovery. And we have a lot of tools on top of console, like console template, which can automatically write out ELBs, configuration files based off of service help. So in the event that you deploy something with Terraform and it starts to fail, you can automatically adjust your load balancer and Nginx, for example, to stop sending traffic to that node. When it reports itself as healthy again, it can start receiving traffic. So it's very much leaning towards Skynet and it's pretty cool. So Terraform's biggest goal was to provide a single workflow. So whether you're a developer or an operations person, a single workflow with a unified view, using infrastructure as code, so something that's highly versionable and shareable that can be iterated and changed safely, capable of complex and tier applications. And then the thing that I always add onto here is, but simpler enough for a single tier application. So something that a huge organization, you know, like Netflix, for example, could use to scale out their entire production infrastructure, something that's so, so verbose, so flexible that a company is large with the needs of something like Netflix could use, but also something with an API that's so simple that a tiny startup that has like one to two web nodes and a database server could easily use and gain just as much productivity, just as much use as a huge enterprise organization. So this is Terraform. I guess the short answer to that is we did it. And I'm not gonna go super in-depth into the internals of Terraform today because it's a lot of code and there's also a lot of like computer science and some graph theory that goes into there. And I wanted to showcase Terraform, not showcase graph theory. So we're just gonna look at some Terraform examples now. So this is one of the few slides that actually has code. This is a digital ocean droplet with its DNS configured using DNS symbol. This is using a configuration language that we created called HCL. It's HashiCorp config language. It is JSON compatible but human readable. So we looked at existing things like YAML and JSON and said, you know, JSON is not really human friendly. It's very machine friendly. It's not human friendly. YAML is really painful to write. We wanted something kind of in between. If you see this, it looks a lot like an NGINX configuration. We were inspired a lot by the NGINX configuration. It's very readable, but it also looks like computer code, not, you know, like Nagio's checks and or sent to checks which are kind of like written in English and just didn't feel right. So the idea here is the Terraform configuration is expressed in HCL. It can also be expressed in JSON. So if you have a machine that generates your Terraform files, they can just export them as JSON. And HCL can embed JSON and output JSON as well as HCL. So the first block here is defining a resource. So resource is a keyword just like, you know, if or for, you know, do and other languages. And it's taking two arguments here. The first is the type of resource. So digital ocean underscore droplet is the type of resource. You know, this could be like AWS underscore instance, for example. And then the second thing is the tag or the name of it. So this is going to be like a tagged web. We're naming this particular instance Terraform dash web or TF dash web. And then all of these things are provider specific. So digital ocean droplet is part of the digital ocean provider, which exposes the digital ocean resource. So things like size, image and region are all dependent on digital ocean. So obviously there is no SF01 in AWS. It's, you know, US West dash two. So these are dependent on whatever the provider's implementation is. The next section is the DNS entry. So basically what we're doing is we're saying, spin up this digital ocean droplet. And then once it's done, so this is side to side, you know, in order serial. Once it's done, create a DNS simple record. And we're just going to call the record hello for example.com. And then the value is this crazy thing here, which is this digital ocean underscore droplet dot web dot IPv4 underscore address. So what is that actually doing? So this is Terraform interpolation syntax. And this is where like the true power of Terraform shines. So this is essentially saying the DNS simple record depends, this is an implicit dependency on the digital ocean droplet. So basically we're telling Terraform, I cannot execute this resource until the digital ocean resource successfully returns its data. So when Terraform creates the digital ocean resource in memory, it's going to get back more than name, size, image and region. It's going to get the IPv4 address, any SSH keys, all of the data that digital ocean sends back from the API. And that then becomes available on the web instance. So we named this instance web. This is the internal reference. And then we access it by saying resource type dot name. And from there, we can get whatever property is exposed by that particular provider. It's now safe to execute this DNS simple record. And this is going to be interpolated to something like <IP_ADDRESS>. And then this resource is going to execute. And it's going to create a record using your DNS simple credentials in their API to <IP_ADDRESS>.4 to example.com. So all of the dependencies and the internal dependency mapping are all handled by Terraform Core. So whereas if you were an operator and you were doing this manually, you would log into the digital ocean GUI. You would enter these things, these values. You would click launch. You would wait for the progress bar to go across. You would copy and paste the IP address. You would log on to dnssimple.com. You would create the new record and the dropdown, create all of this. That's all automated. And the dependencies are automatically set up for you. We'll look at a more complex example in a second of kind of why that's important. So you can imagine this is a very simple application, but what if we had 50 web nodes and we needed to create 50 DNS records? Well, we don't really want to create those in serial. As these return, we want to create the records. So Terraform is capable. It's highly parallelized, but it builds a dependency graph for you. So you don't have to worry about any of that. Just state what you need. As I said before, it's a human-friendly config, but it's JSON-compatible for non-humans, like dogs and computers. And it's in a VCS-friendly format. So I'll say this and then I'll go back to the previous slide. Support for trailing commas, something JSON doesn't have. This is a very nice, difficult thing. If someone comes in here and changes image and then submits a patch on GitHub, for example, you're gonna very clearly see this as a red line followed by a green line. We created the language with the notion that people, humans, are gonna have to look at this and understand what's changing. But more importantly, it's your entire infrastructure specified in a single text file, which was the biggest goal, is I want a reproducible way to configure my entire infrastructure using a single text file. I want to be able to share that with my team and I want it diffable. So let's talk about the Terraform Graph. So Terraform Graph is an internal construct and also a command. So if you run Terraform Graph on the example we just had, you'll get this nice output, which is basically showing you the kind of, it's like the inverse of the dependencies. So DNS Simple depends on the DNS Simple provider. It also depends on the DigitalOcean web droplet, which depends on the DigitalOcean provider. So if we take the providers, it's basically saying the DNS Simple record depends on the DigitalOcean record. If you have a more complex infrastructure, this chart can be huge or this graph can be huge. And you can also see which pieces are gonna be able to be run in parallel versus which pieces need to happen one after the other. So let's talk about providers for a second. I talked about the DNS Simple provider and the DigitalOcean provider, but providers are kind of this abstraction from core. So you can think of Terraform providers as basically a plugin. The same way Vigrant has plugins and Packer has plugins, Terraform has plugins. We call them providers. They provide a single integration point. They expose, quote unquote, providing a resource. And some of those are like AWS Instance, DNS Simple record, et cetera. They follow a CRUD-based API. So you can create a resource, update a resource, delete, et cetera. Some of the resources expose CRUD and another thing. So if there's a restart on AWS Instance, for example, that does not create, read, update, and delete, but sometimes you wanna reboot your AWS Instance. They're super pluggable for integration so you can write your own. So if you're using some type of internal cloud that isn't part of Terraform core, you can easily write your own provider. You just have to expose all the APIs and it'll just work. So it's a super high level abstraction.  It's kind of like layer cake where you have a different provider per layer, but it's all a unified configuration. So whether you're a physical, something like physical servers, infrastructure as a service, we talked about open stack already, something like cloud foundry perhaps could throw in there. Whether you're at the VM layer or the container layer, like Terraform has it all. So it's kind of like juju we were talking about before. It can integrate with any layer of the stack. And this all happens with Terraform apply. So if you remember one of the very early goals was a single command, a single workflow. So regardless of whether you're an operations person or a developer or an engineer or a manager, we wanted to provide a single way for you to deploy infrastructure and that's Terraform apply. When you run Terraform apply, it's going to essentially go out and reach into the arms of the internet and report back any errors that happened. We'll talk about Terraform plan, which is essentially like a dry run that Terraform says this is what I'm going to do and then you can approve it or reject the changes. As far as built-in providers in core, we have console, digital, ocean, DNS simple, Google, Heroku, Milgun, AWS, CloudFront and Atlas. There are more planned and we're growing the coverage for Google and AWS. Basically every day we add new features. For those of you that don't know, AWS has like 50 billion possible things that you could configure and we've only been able to configure 49 billion. So we're getting there. But they're all open source. They're all in Terraform core. So if you work on a project and you want Terraform to be able to configure and manage those resources, you can submit a pull request and we'll review it. And if it looks good, Terraform can have support for whatever particular cloud or service or whatever you're offering. So I mentioned Terraform plan. This is really the power of Terraform. This is my favorite part of Terraform. How many times have you wanted to apply Puppet to a system or Chef to a system and you want to know what it's going to do beforehand?  And then you run it and it doesn't do the thing that it told you it was going to do. It happened to me all the time and it's because of the nature of configuration management. But we're at a level above that. So Terraform plan is actually proven to work. Like mathematically proven and the result that it provides is really, really cool. So we've kind of invented this Diffing style language. So you can see the plus sign at the top there, right there, which says that we're going to add a new digital ocean droplet resource called web. And you can see if the resource already existed but certain values changed, it would be a little tilde. And if we were deleting it, it would be a minus sign. The values that we specify are in there. So if you remember before, this is the same Terraform config that I showed earlier, the image name, the name of the machine, the region and the size were all specified. So those kind of show up as hard-coded values. But you also see these computed values. So those are things that Terraform doesn't know right now. We haven't spun up the digital ocean instance. So we can't possibly know what its IP for private networking is. Or if we enable private networking, we may not know what the internal versus the external IP addresses. So these are computed. If we were changing this resource, Terraform has a state file. It would query the API and get the status, but it would know the IPv4, private networking, backups, et cetera, it knows all of that information so it can intelligently diff its state file from what the API returns. If we scroll down a little bit further, you can see this interpolation thing that we had before. So the first time this record is going to get created, it's going to say, this is basically a reference to whatever the digital ocean droplet returns. But after this is created, this will actually be the IP address of the instance. So Terraform plan was going to show you what will happen. My general rule of thumb is you should never run Terraform apply before you ran Terraform plan. It's one, it's a great way to kind of like sanity check yourself. The parallel I always use is you would never run like get add dot before you ran get status. It's the same approach, like show me what's going to change before I commit those changes. Any actions that it's taking that Terraform is able to explain, it will explain to you. So I didn't have time to create an example for this, but let's say for example, AWS forced your instance to shut down, as it does sometimes, or they had an outage. Terraform will actually explain to you that it needs to start that instance because the underlying provider reported that it was stopped. So you have a more intelligent view of your infrastructure, and you can go on to the AWS status dashboard, which is always up to date and accurate, and see exactly what's going on. Previously before this, it was very, very difficult for operators to manage these types of things. One thing that I haven't discussed here is Terraform has the ability to say, instead of giving me one server or two servers, you can allocate like a pool of resources. So give me a range of these servers, or for every web server give me two database servers, or for every ELB give me five front-end servers sitting behind it. So these complex relationships can all be modeled in that Terraform file. So let's talk a little less technical. So DevOps is cool. It's this really cool buzzword. How does Terraform fit into this DevOps cycle? Or does it divide it? Does this make it like dev versus ops? Are we working backwards? Because it seems like we're taking power away from operators and nobody really needs to tune the Linux kernel anymore. It actually doesn't. So let me explain why. Developers have certain responsibilities that they care about. These obviously aren't the only things developers care about, but these are the primary things. They wanna deploy their application to production, and they want to have their development environment as close to production as possible. Operators on the other hand, they want to define core infrastructure once, so they don't wanna do the same thing over and over and over again. They want it to be secure and they want it to be scalable. So at a high level, taking apart, whether you're a tech company or a product company, that's what developers and operations people care about. Those are their high level concerns. Can I write code and can I run code? And when you break that down, the developers can treat Terraform configurations as a black box. They don't need to understand the production infrastructure. They just need to understand that there's a web node, and they don't need to concern themselves with what version of what package, of what software it's running. They don't need to be concerned with how much memory it has, or how much disk space it has, because all of that's defined in the Terraform configuration file. If they care, they can go look. If they don't care, they can either use Terraform to spin up a cloud instance and use that as their development environment, which is an exact parity of production, or they could use Terraform with Packer and spin up a vagrant box and run that locally on their machine. For operators, all they have to do is modify Terraform configurations. So no longer do you have to SSH instances and manually install packages, et cetera. Obviously, when things go boo-boo, you still have to SSH in an instance, which is why sysadmins are super, super important, but Terraform is extracting a lot of that to the point where you could easily move from one cloud provider to another without any of your developers ever knowing, because it's all extracted into that Terraform configuration. So in a way, the operators become self-servers. They provide Terraform configs, and the developers become self-servees. They consume those configs. So far less responsibility is placed on the developer to understand production. They're just given production effectively, or they're given a copy of production in the form of a development environment. And the operators can work independently from the developers, realizing that the developers are writing code that's targeted to their production systems. So the probability for code not working in production is significantly lower in this scenario. If we look at the same picture from before, the important piece to remember here, the developers are probably working at maybe this level, but the operators might be working at this level, or in this example, I said Dev is working on VM to container, Ops is working on physical to IOS, but your developers might actually have credentials on your OpenStack cluster. Who knows? These arrows can kind of fluctuate, but what's important is the ability to decompose, delegate, and deploy. So Terraform modules are a little bit like Charms, which we heard about in the last talk, which are these isolated components that you can then share. So Terraform doesn't have like a cool charm store like JuJu does, because they're ultimately just text files that you can pass around. So this, for example, is a Terraform module that installs console, and a Terraform module that installs console. It's obviously called console. And then it's saying, pull the module from HashiCorp slash console slash Terraform, and this particular one is gonna use AWS. Give me five servers and run version 0.4.0, which is the latest as of now. And when I shove this in my Terraform config, it's gonna give me console. So applications have the ability to write Terraform configurations, and I can pull them in just the same way you can pull in a Chef community cookbook or a puppet module from Puppet Forge, et cetera. And then in my DNS record, so this is DNS simple, for example, I can say for console, set my domain to whatever the module's IP address is, which is something that the module exposes. I'm not gonna go into how to write a module because it's kind of like an advanced Terraform topic, but all of the docs are online. This is just an example of using it. So this is gonna give you five AWS nodes, each running a console service that work together in a cluster, and then set the IP address for DNS simple for those particular records. So modules provide an easy way for component abstraction.  They're actually less than plug and play. They're actually copy and paste, which is something that I think is actually a lot easier than downloading some tar ball or installing some software. It's just literally copying text into a file and it works. So abstracting all of that out makes it a lot easier to test as well for unit testing purposes. It provides higher level reasoning, so instead of having 20 lines of configuration that say I need console, it has this, this, this and this, you can extract that into a Terraform module and then your higher level abstraction just says, give me console with five servers. And the person writing that Terraform configuration doesn't need to know all of the implementation details of how console is deployed or what it's listening on or what ports it's listening on. Those are all configurable, but they have sane defaults that just work. They're highly reusable. So across your entire infrastructure, shareable is another point of that. And kind of I already touched on maintenance delegation. If you work in a large organization or if you have a particular group of people who specialize in software. So if you have the MongoDB people who are really good at MongoDB, like they can write their MongoDB Terraform files and, you know, write the API on top of it and just give that to people. So the whole organization, the whole operations organization or the whole development organization doesn't need to know all of the internals of MongoDB. They can just look at this API, realize this is how I set up MongoDB. This is the company standard and run with it. So it's much easier to hit the ground running. It's much easier to deploy not only an entire infrastructure, but just a simple little application with really just one command, Terraform apply.


With that, I'm going to bring up our first user. Jack Wu from IGE, engineering manager, is going to tell us what they're doing with OpenStack. This is one of the largest video sites in China, similar to Hulu or YouTube, massive, massive infrastructure. So come on up, Jack Wu. Tell us what you're doing with OpenStack. Thank you very much. OK, good morning, everyone. I'm Jack from IGE. I will take several minutes to share OpenStack in IGE. Before that, let me talk a little bit about IGE. So IGE is China's online video companies, which were founded by Du. And the website launched in 2010. And it's focused on the four licensed high-definition video contents, like Hulu and YouTube in American. So we also have strong in-house content teams to produce the different ancient contents and the entertainment news. The graph sheet here is our website. And the data on the left side is monthly unique visitors. It's an important criteria as to evaluating the online video company. So currently, the data is about $360 million. It's about one-third of the YouTube's. OK, one year ago, we are evaluating the computing service. So why OpenStack? I list several highlights here. The first one is the control and the flexibility. It helps us to easily integrating the legal code and a third-party technologies. So the next one is the community support. The third one is the flexible technologies. It's important for us to integrating the different virtualizations to serve the different problems. So the last one is the cost effectiveness. Since we are startup companies, cost is really important for us. So after one year's operation and development on OpenStack, OpenStack has provided, sustained almost all the infrastructures of the IT with the scalable IT capabilities. Currently, we have several data centers. And in each data center, we set up one or two OpenStack clusters. And we set up a unified dashboard to control all the virtual machines across the different database and different clusters. So currently, OpenStack managed 100 servers and sold them to all the virtual machines. OpenStack in IT provided the two parts of the service. One is the computing resources. The other is the operating storage. So based on the OpenStack, we set up a service cloud. And the service cloud supported the distributed database and the message queues and all the computing frameworks such as Hadoop. And above the service cloud is our key business applications such as the search engines, recommendation systems, et cetera. So across data centers, computing resources and the distributed object storage keep our application much more robust. OK, so in order to minimize our operational efforts, so we set up several systems to co-work with OpenStack. The first one is the management systems. It provides a unified entries to manage the virtual machines, life cycles, and check the OpenStack functionalities. And although we can review the computing results statistic, the next one is ticket assistance, to review the customer requirements. And the third one is the audit systems. And it helps our management to identify the area where to cut and achieve the profit. The first one is the monitor. We are based on the Zebix, it's an open source project. So the last one is deploy systems. And we extend the puppet to support the authority control process. OK, this is our OpenStack unit models in IGE. It's our mixing architectures. What I call this mixing is virtualization divided the servers into the different virtual machines. And OpenStack hiding the virtual machines management and provided the results to the results framework. We are using the MISOS. And MISOS provided a computing results to a different high-level computing framework, such as Hadoop, Spark, and some self-defined architect framework, such as transcoding. So two months ago, we set up this framework. And it leveraged all the CPU results from our code storage clusters. And here now, it's about 8 million task. Transcoding task has been finished on this mixing architecture. So it's important for us to set up this elastic computing force, since we can provide our resource to a different computing framework, different applications, business priorities. And although this computing force is really flexible to scale, since it's operation of the integrations versus supported virtual machines and the server seamlessly. OK, at the end of this speech, I will share a demo video. It's about my screen interactions. OK. OK. OK, so that's all. Thank you for your time. Great. Thank you for that presentation. So that's pretty incredible to me. If you think about hundreds of millions of people every month watching this premium video content throughout China, and they're relying on OpenStack to do it. And I think we heard yesterday that if you're into modern family or today, I believe they were showing two broke girls. So whatever your taste is in TV, it's probably powered by OpenStack, which is pretty incredible.


This is the animation minute as always I start with jobs here Well, this animation is recruiting for a junior animator what effects in Vancouver is looking for animators Super suit studios has a bunch of positions They're right there and super spline studios is looking for animators and technical animation at every level Rockstar games is looking for a senior gameplay animator switch over to news is a new chapter in the world of Warcraft called Dragon flight and if you're interested in dragons check out the rest of this cinematic because it's pretty cool If you are interested in dinosaurs, then check out prehistoric planet on Apple plus because it looks absolutely fantastic Come on. This looks super super cool. Speaking of super cool I unfortunately haven't seen bad guys yet, but you can Google and check out the first six minutes on YouTube Here is the ending of those set six minutes and it's so super cool Check it out. Adam school is saying here that it got five million views on their animation showcase Make sure you check it out because it's really nicely done really cool animation working there And you know, I like industry stories in every with yet another fantastic thread. Go check it out. It's almost every week It's fantastic. Justin T Lee talks about how he made his 70s inspired star trek next generation animated short That's what it says here. That's what it is. It is really cool. Check it out. This is pretty cool. Jesse You're tweeting out. There's a collection of walk cycles that she assembled here And if you check out sketchfab here, it's right there. There's a bunch of stuff You can have turnarounds and everything you can check them out. Very interesting. Check out Harvey's new cliff This is all about salary negotiation. Let's switch over to art this time. It's about Lake. These are really cool Then we have here the collection of cities. These are super cute She always does awesome work. Then static designs as it says here that he's done so far These are also super cool designs. I love them new art and concept work for light-year also super cool Then look at this one. Love it Love it. Look at those colors and then black and white art also fantastic. There's more below So cool. Then we have these and you know if you watch my animation minute You know, I love these little snippets of landscapes and how's everyone lots of detail in there. So cute I love it. Then we have a tip for composition. This also works for animation. Then super cool effects Watches at the end. I love that face in there at the end. Then we have this here I'm gonna spoil it because it's awesome. Very the thing inspired Cracked me up. It's great. 2D effects this time. I love seeing these Love it. Talked about Legos before. Here we have a closer look This is a full run through of the set. Can't wait to get this and then of course pixel art These are nice and chunky. Love that. Love this anything Zelda link related and pixel art come on That is cool. Isometric. That's my childhood. Come on. This looks super cool Zelda one mock-up. I would also play this. Let's go straight into my nostalgia heart This is pretty cool. This is animation. That's pixel art, but also 3d. Love that style Very neat game trailer also with nice and chunky pixel art in there with some modern effects thrown in there as well Very cool though. Definitely wish listed and then that's about at least here. Street Fighter 2 nostalgic edition So we check this out here clicking link after link But here it is and if you go forward you can see what it would look like on the NES and that is so cool And I'll put on the music as well Yep, that is absolute for me and that is also that animation minute you can find it every Monday at 10 a.m on my channel


I'll put this one behind her. Keep them there. You should be good, like that. Anyone? What? Or is it gonna lock in? It's gonna be tight. Tight. Rads are gonna have to be tight. That's good. Yes, okay. All right, just so you check. We're gonna take some. Once you move out of here, we'll start the tube.


In this presentation we will take a look at multiple choice questions related to payroll. First question, which is used by the Internal Revenue Service to keep track of employers? A. W. 2. B. E. S. 4. C. E. I. N. D. W. 4. So let's go through this one more time or again maybe not the last time and see if we can go through the process of elimination which is used by the Internal Revenue Service to keep track of employers. So A. W. 2. Now it's key that when we read this when we read through this these key little terms here employee errs we got to see the errs at the end and it's very easy for us to to possibly have a preconceived notion about what the question might say especially if we first see a W2 down here and misread it as employees or something like that so note that's the first thing to keep in mind here the Internal Revenue Service is trying to track in this case the employer information and so how can they how can they do that obviously when we process anything to the irs they don't really care about our names we're all just a number so which one of these is going to give us that number that's going to basically track who we are as an employer W2 then is an employee type document so typically the employer will send it but it's really there to track the employees and make sure that they can go after them for any unpaid taxes and then B says the ES4 like I'll keep that for now I'm not quite sure what what we're talking about there we possibly might not be on that one C says the EIN number EIN I put number in it but that might sound familiar to us so we'll keep that for now and then D says the W4 which once again that's like an employee form that's the one that employee fills out to track the employees not really the employer so we can probably eliminate A and D and look then at B and C which is the ES4 and the EIN so let's read through it one more time or once or another time which is used by the Internal Revenue Service to keep track of employers is that the EIN or the ES4 and of those two it's actually the EIN number and that's called the employer identification number the EIN number so for the for the IRS to track the employer just like our social security number we're just a number we're a social security number to the IRS the employer has their number for their corporation which if they're sort or their business which is if it's a sole proprietor their social security number or if it's a corporation or a partnership then they're going to have another number and to keep track of the payroll and and so everybody kind of has the same type of number for their payroll processing then there's an EIN number so if we're a sole proprietor we're not going to use our social security number when processing payroll we'll use the EIN number so anybody who has employees needs an EIN employer identification number in order to process the payroll information including the 941s the 940s and then all the W2s and whatnot so correct answer C one more time which is used by the Internal Revenue Service to keep track of employers C EIN number next question which has 26 pay periods in a year A weekly B bi-weekly C semi-monthly or D semi-weekly so let's read through this again and see if we can go through the process of elimination which has 26 pay periods in a year so if we just think about that 26 pay periods in a year well we should kind of know like weekly how many weeks are in a year and this is basically how many pay periods we're gonna have if we're if we're weekly bi-weekly semi-monthly uh we know that there's there's more than 26 weeks in a year there's and we should just know that number if we're doing payroll and it's 50 it's about 52 so so it's not weeks it's gonna be a lot higher on weeks and and semi and B says bi-weekly maybe C says semi-monthly maybe those two are very similar who pro those are probably where the issue lies and D says semi-weekly which isn't even a pay period who gets paid in the middle of the week no one gets paid on Wednesday and Friday really that doesn't happen so we're gonna say that's not it uh you might get paid daily possibly but in some certain but in case the question is between B and C bi-weekly or semi-monthly and this is really really confusion lies most of the time and the way I would think about this is um semi-monthly would be twice a month because we get paid on like the 15th and the 30th or the 31st or whatever and so that's gonna be 12 months in a year times two which is 24 pay periods whereas if we get paid bi-weekly that means every two weeks not necessarily on the 15th or the 30th not necessarily only having two pay periods in a particular month so that's I would think of more of 52 weeks divided by two and that's going to be our 26th so there's actually more pay periods when we get paid every other week bi-weekly than there are when we get paid semi-monthly so B is the correct answer which has 26 pay periods in a year B bi-weekly accounting I don't know anyone in accounting