So, what I wanted to do today was I wanted to, the way that this talk was originally positioned was it was kind of, it was in sort of the product track or something like that and I think it might have, our product manager might have originally wanted to kind of do like a product walkthrough but I don't know about you guys but that's kind of boring to me. If you can find it on our website then who, then you know, why should I present it to you here? It doesn't really make sense. So, I kind of morphed this a little bit into kind of talking about kind of our design philosophies as we were building our product and so we're talking about more kind of big picture items which I hope will still be of interest to you. And I was kind of hoping we could figure that out and you could ask me some good questions at the end. There's a few pieces I might go through quickly because they're not super interesting. But the important thing is to talk about why cloud scaling out of so many open stack companies cares about making open stack look a lot like Amazon Web Services. So just real quick for a background on me, I'm on the OpenStack Foundation Board of Directors have been since the foundation was formed. I'm used to building fairly large projects, the largest of which were three 100,000 square foot data centers in Hong Kong, Taipei, and Seoul in 2001 which were fairly cutting edge at the time. Cloud scaling was part of the original open stack launch in summer of 2010 and we got a number of the first including the first public compute cloud, the first public storage cloud outside of Rackspace and the first public storage cloud in Korea. So sometimes people give me a little bit of hard time because we don't contribute as much code back although we contribute more code back than any of the startups that are our size that we compete with. But part of the reason is that we are very focused on building and deploying clouds and you'll see more of that in a second. And just one thing that I think is really important for people who are new to OpenStack is I was working on and building clouds before OpenStack existed and kind of OpenStack became a vehicle for what we believed a cloud need to look like and hence the focus on Amazon Web Services. So if I'm really honest, our first wave of customers didn't go so well. I'm not going to get into history on that. Over the past year, we've kind of had the second wave of customers kind of on the 2.0 product and it's gone fairly well as you can see. We've been very focused on production deployments and I don't really want to do kind of a comparison against other people. I don't know how other people are doing but when I say that we're actually deploying and managing and supporting large production clouds, you can see here that we're doing at a pretty reasonable scale for a small 30-person startup. I've got three, three and a half support people supporting 600 servers with 8,000 cores and roughly eight and a half petabytes with over 10 production clouds. So I think it's going pretty well and two of those are Fortune 15 companies. As far as I know, I'm the only startup this size who's able to capture and hold on to a Fortune 15 company for better or worse. So today, we're going to talk about why Amazon, why Amazon-like, why an elastic cloud is what I call it. I have to talk about hybrid cloud interoperability to really bring that home and then I'm going to sort of talk about the pieces that make OpenStack be more flavored like Amazon Web Services. Pretty much anybody can do it. It's not just us and I don't necessarily want to hold any of the secrets close to my chest. I just kind of want to highlight what it takes to get there. So people have probably noticed this, but the majority of the big public clouds are not running OpenStack and probably will never be running OpenStack. And yes, I might get some pushback from some of the folks who are, but I think it's kind of like when's the last time you saw a company that was growing as fast as Amazon suddenly plateau and then lose all of their market share. I mean, that just doesn't really happen. So we have to be realistic about the fact that Amazon is the market leader in public cloud and that has implications for any kind of hybrid cloud scenario that any enterprise is thinking about. So digging in a little bit more, what is an elastic cloud? Well, it's something that's designed along the lines of Amazon Web Services or Google Compute Engine. It's got kind of a scale-out model. It's designed for smaller failure domains. It's the cattle clouds, not the pets clouds. It's a foundation for cloud-native applications. People have probably seen sort of the Netflix use case and how they've been designing a three, four, five, nine app that runs on a two-and-a-half, nine Amazon Web Services infrastructure. And that's because those apps are out around failure. And that's the lesson learned from Google. If you look at how Google runs their normal business, 10 to 15% of their capacity is down at any given time. And they still run a four, nine business because their applications are designed to expect failures in the system and then to run around those failures to do their own data replication and so on. And then finally, I think it's a side effect of making these decisions when you move responsibility for uptime into the application. The infrastructure can be less expensive. And what that means is that most elastic clouds are very inexpensive. So this pets versus cattle meme that some people have... Who's heard of that? Excellent. So I stole that originally from Bill Baker, who was using it to talk about scale-out versus scale-up. And I was the first one to apply it to using it to talk about cloud. And then it took off. And the reason that it really worked out for me is that I struggled and struggled to explain to IT staff and CIOs why you wanted a cloud that looked like Amazon. And the problem was is that every time I walked into a meeting with folks, they were all on the pet side and they didn't understand why you would want sort of a cattle-style cloud. And we would always get into sort of like, well, what do you mean I don't have nick bonding to the switches? What do you mean I only have one top of rec switch? So it was always kind of like going back to the like pure technical aspects of how you build one of these things. And so I found this to be the best analogy and it basically goes like this. We're moving from the era where we treated servers like pets to the era where we treat them like cattle. And in the era where we treated them like pets, we gave them cutesy names like Bob the male server. And then when it got sick, it was all hands on deck to nurse it back, to nurse it back to health. And in the new era, we treat servers as disposable. We treat them like cattle. We number them, you know, WWW001 to 100. And then when one gets sick, we take it up back to the woodshed and then we replace it on the line. And that's the key change in mentality that has to happen when you're thinking about an elastic cloud. Your servers are disposable. They can go away at any time.  It can go away at any time. Your data can be lost. You've got to take care of it. It's your responsibility at the application layer. And that's this thing that I think people don't get. When you take the responsibility and you shift it from the infrastructure, when you take a two or three nine application and you basically move it to being more of three, four, five nine application because it's taken responsibility for itself, then the underlying infrastructure no longer needs to be gold plated. So in 2010, before OpenStack existed, I spent most of 2010 in Korea in Seoul, where we were doing one of the largest three cloud stack appointments of the time for Korea Telecom. And when I first walked in to start talking to Korea Telecom, they said, we need a five nine cloud. And I said, do you have any idea what a five nine cloud will cost? I mean, I can build you a five nine cloud, but that is going to be really, really, really expensive. And they didn't. And so we tried to walk through it and they still didn't get it. So I said, OK, what are the applications that you have that have five nine requirements? And they said, well, our billing system. I said, OK, great. What was the uptime of your billing system last year? Three nines. Year before that? Three nines. Year before that? Three nines. So I said, so you want to take a three nine app and put it on a five nine infrastructure? And they were like, yeah. And I said, well, it's still going to be a three nine app. So Joe Tucci, CEO of EMC, recently did some presentations. And he noted this very interesting shift, which is that if you look at the applications that are going on Amazon web services, if you look at where the enterprise is spending money developing applications, it's all around net new cloud native applications. And you can see there's a 10x difference in growth between sort of the legacy traditional apps that can't router on failure and those that can. And this is the key that I think that most enterprises start to wake up to, which is that cloud is not about cost savings or server consolidation or virtual machines on demand or any of that kind of stuff. It's really about driving business agility into the enterprise and the way to get that agility is via cloud native applications. So you have an application that routes around failures. It needs to use up a lot of resources to do that. You've got 100 servers, 10 disappear. Once you spin up 10 more, maybe you need 100 servers of capacity for your application. And you always run it 110 or 120 so that you have as much as you need to meet the demand.  And you're managing that all dynamically. Well, if the unit of cost of each of those servers is very expensive, then you're going to be highly incentivized to not use additional resources. So what's funny is that there's this thing called Jeven's Paradox. It's this law that we've learned over time where if you've got a resource that drives towards zero in terms of per unit cost that becomes more of a commodity, oil and gas, electricity, minutes, bytes on the wire, as you approach zero, you actually see the usage take off. So part of Elasti Cloud's being less expensive is less about cost savings. It's more that you can do something fundamentally different, right? If you go to your developers today and you say, look, I can give you 10,000 servers for an hour, for 100 bucks. Can you do anything with that? It turns out that there's all kinds of stuff that they can do. So we should care because enterprises are in this tough spot that's emerging, which is that they are starting to die out as they are unable to adapt to change. As the internet and cloud forces us to move faster and faster and faster, the only way to remain competitive is to be one of those businesses that as you grow larger as a business, you get faster, not slower. And that's something we haven't seen. But you look at businesses like Amazon, Facebook, Google, Twitter, even Microsoft's in the midst of making this change, Apple. And you compare them to sort of a classic general electric or something like that. And as the old style of enterprise, basically, as the business gets larger, the communication overhead gets very high, projects get very costly, very expensive, take a very long time to basically lead to success. But the way that the new enterprise will have to be to be competitive is one that moves much, much faster and that is leveraging cloud to get that agility, both in elastic infrastructure and cloud native applications that run on top of it. So OpenStack is a platform. It's a framework that you can use to build a lot of things. Think of it like the Linux kernel, right? Linux kernel, you can run an Android handset. Android itself is an operating system that uses the Linux kernel but has none of the normal Linux tool chain or user land. You can run a Linux kernel on a Cray supercomputer. Those are two different things. It's the same code base, completely different reference architectures. They don't look anything like each other. Therein lies both the strength and weakness of OpenStack. It can be used for anything, any kind of cloud, any kind of cloud service. But if it's like that, then what that means is every single deployment of OpenStack looks different. It looks like a snowflake. So given all that, we still think that OpenStack's best fit is as an elastic cloud. So for those who don't know, the very first two projects, Nova and Swift, Nova was built originally as the clone of Amazon's Elastic Compute Cloud and had the Elastic Compute Cloud APIs in it from the very beginning inception, and the later OpenStack APIs were only added after the fact. And Swift was built by Rackspace as a competitor to Amazon Web Services S3. So both of those services were basically designed from that sort of Elastic Cloud reference architecture model from the very beginning. So we think OpenStack is the best fit for that, even though it can be used for many different purposes. So one of the key things about getting agility for a business is that you want to be able to have maximum flexibility and use the right tool for the job. And the reality of the situation is that there are going to be use cases where you want to be on private cloud, and there's going to be use cases where you want to be on public cloud, and there's going to be use cases where you want to mix them or burst from one to the other. I've seen people doing it every single way that I can imagine. And that has really shown me that pretty much everybody is looking at hybrid cloud as sort of a key enabler to get this new business agility. Why would you use up your infrastructure inside your business if you've got a launch that's going to happen for three days? Like go put that on Amazon. I can give you a dozen other examples. So as we see enterprises adopting DevOps, building these cloud native applications, we really see that hybrid cloud is sort of the go forward solution. So people like to talk about interoperability in OpenStack Land, but they don't like to talk about what interoperability means. And that's a part of what this talk is about, although not the whole of it. So I think when people are talking about interoperability, what they really mean is they want application portability. They want to know that they can design the application in one place and move it to another place or replicate it. Maybe they're running, like I've seen all the financial services guys, they all want to run QA Dev and test outside the firewall. So they don't have to pay for that capacity. But they're never going to run their production workloads outside the firewall. So they want hybrid clouds so that they can actually do that kind of exercise. But they don't want their application to look or smell differently between their QA Dev and test environments than their production environments. That's not a good idea. So most of the time what people want is application portability because they want independence and they basically want to be able to have maximum flexibility. Portability requires interoperability. And I think that's where people get a little bit tied up. And they also get tied up in thinking that if you've got the same API in two locations, that that gives you compatibility or interoperability. Excuse me, and it does not. So again, why this matters is that we want OpenStack, or at least I want OpenStack to be as interoperable with the major public clouds as possible. Because I believe that OpenStack will win on the private cloud side of the equation and will only get partial penetration to the public cloud. It will never be dominant in the public cloud. And if that's the case, then it's very important to me that there are flavors of OpenStack that are able to hybridize and interoperate with some of the major public cloud winners. In fact, I think that if we don't do that, it could actually impinge on OpenStack's ability to win in private cloud given that pretty much every enterprise that I've talked to so far, no matter how big, how little, how security conscious, whatever, is all talking about hybrid cloud. And so the problem with API compatibility is a focus. Oh, we've got the EC2 APIs in OpenStack already is that it sort of misses the force for the trees. You can have two systems that have the same API and don't behave anything like each other. These are the same API. You've got a steering column. You've got gas. You've got brakes. You've got clutch. You've got all of that. You've got transmission. You've got mostly the same bits, but you have two fundamentally different systems. They behave differently. They have different performance characteristics. They have different service level agreements. I mean, they're just different systems with the same API. Look, an API is easy to code. I can get an intern straight out of a CompSci degree to come in and basically rewrite the Amazon Web Services API to talk to something over a weekend. That is a trivial task. An API is an interface to the system. The system is what creates interoperability. Who here used IPsec VPNs like in the mid to late 90s? Excellent. So the thing about IPsec VPNs is that in the early days everybody implemented IPsec to the standard, except there was so much looseness in the standard that they all interpreted differently, and none of their shit worked together. You couldn't do IPsec VPNs between vendors. There was no interop, same standard, same protocol, no interop. So it's about the system. It's not about the APIs. So these are the six requirements, I think, that you need in order to get interoperability. If anybody comes up with any more that I missed, that would be absolutely fantastic. I'm looking to continue to update this. And I think we're going to talk about these in painful detail, or well, maybe not too painful detail. So matching SLAs and availability guarantees. So you want two clouds to basically provide the same basic guarantees around availability of the API endpoints and of the virtual machines and so on. Because a lot of the frameworks that talk to a given cloud or API-like Bodo that talks to the Amazon web service and so on, they have timers and other things in them that are related to the behavioral compatibility at the end, which I'll talk about. And so you really want basically the same SLAs and availability guarantees, particularly around the API endpoint availability. Second is you want performance.  Or even if it's the same, the performance has got awfully horrible because there's a huge amount of oversubscription on the back end that you're not aware of, that's a problem, right? You pick up an application that requires 10 VMs here, and it thinks that that's its key scaling multiple, and then you stick it in another cloud, and it needs 20 or 30 at a time. And that's really an issue. You don't want surprises, right? Application portability, pick up the app, run it here, have it basically look and act the same. The next thing there is you want to have roughly the same set of services, right? I mean, you want the sort of lower end services, just the core infrastructure services, but you want to have the same services in both clouds, right? I mean, they don't have to be called the same thing. As long as they behave mostly the same way, then you're good to go. Block storage, object storage, virtual machines on demand, whatever the bits are that you're using. You need to have similar costs, right? I mean, you have to have a similar TCO, right? If you're running a private cloud that's 10x the cost of Amazon Web Services, and you're trying to hybridize that, people who are inside the business who are going to pay for that are going to gravitate towards the other cloud. And what you're really looking for is you're looking to get within half the cost of public cloud or private cloud or 2X, somewhere kind of in that range. You don't want to be too much above or below it because it makes too large a disparity between those systems. You need the basic API compatibility. It's table stakes because the tooling around the different ecosystems, Amazon, OpenStack, Google, is all a little different, and you want to be able to support all of that different tooling. And then the last, this is the thing that I think that people forget all the time when they get hung up on API compatibility, it's that behavioral compatibility component. If I move from cloud A to cloud B, and on cloud A a VM spins up in five minutes, and on cloud B it spins up in 60 minutes, the way the application is going to manage auto scaling is going to be really, really different, right? Drew Smith, who I don't know if he's in here, but he's on my team, he's giving a presentation tomorrow talking about hybrid cloud landmines, and he made this great point to me as we were doing run-throughs of the decks. He basically said, the thing is that a developer goes into an environment and they basically build their application in that environment, and they make all their assumptions based off the way that that environment operates. So the problem is that if you want application portability for that, if you're going to try to move that app to another cloud, it's got to have a very similar environment, it's got to behave really similarly. If it doesn't, then you're going to run into all kinds of surprises. One example I love to give there that I think helps, too, besides the VMs is that last one, which is that if you go to Amazon Web Services and you spin up a VM, every VM by default gets a public IP address. On OpenStack, it doesn't. And that's OK, it's just a difference, but it's fundamentally a different behavior, even though both have access to the EC2 API. Also one last thing I'll say there about the behavioral compatibility is that behavioral compatibility typically isn't modeled in the API. That's the big difference, right? There's no way to talk to most of these APIs and say, spin up this VM and if it doesn't spin up in five minutes, kill it and start a new one. That's actually not modeled in the API. And the reason is that systems are gigantic and complex and APIs are these little teeny windows into them. They can't model the whole thing. That's part of the problem I have with Neutron, but that's a different story. So when we're talking to customers, we like to point out that they need to move to a hybrid first cloud strategy. And the reason is that whether you're building a hybrid cloud now or later, you want to make sure that you're thinking about it first thing and you're thinking about those six elements there. So how do we get Amazon Web Services flavored open stack? We need these six elements. Let's walk through them really quickly because I want to make sure I can take some questions. First is that we need to match SLAs and availability guarantees. I can't give examples for every single thing you should do here, so this is just one example of what you could do. You have a 2.5.9 infrastructure like Amazon. That's your guarantee. OK, great, perfect. However, you want your application to be more than a 2.5.9 application, which means that the API can't be a 2.5.9 availability API. It needs to be 3, 4, 5.9s because when your application detects a failure of a server or something like that and needs to spin a new one up, it needs to talk to the API. I mean, that's the whole benefit here. So you need to make sure that those API end points are highly available. So one of the things that I see happening a lot in open stack land is a lot of focus on things like HA failover. The problem is most HA failover takes 45 to 60 seconds for a failover. Master elections take 45 to 60 seconds. It depends on your environment. But that's kind of like a lot of suckage if you're trying to get close to like 3, 4, 5.9s because in a minute only six of those failovers and you're already down from 5.9s to 4.9s in a year. So it doesn't take much. What's funny is that we actually have this other pattern that we use in our version of open stack called load balancing.  And so this is a much, much better pattern if you want high up time for the API end points. And the thing is unlike websites, APIs are very transactional. You make a call, you get a response. Boom, done. There's no need to have sticky session tracking or cookies or any of that complicated stuff that you would normally have to use with the load balancing service. Second is performance and quality of service. So right now, you see, it's funny is when I was working at GoGrid, the way that the scheduling system worked, it was just so obvious. And the reason is that if you look at a public cloud provider, if your scheduler just goes and sprays VMs like wherever there's availability, you run into a problem because you're like, fill up boxes partially. You'll have a box that's running out of CPU and it still got RAM left. And for a public cloud provider, that's just unacceptable. You have to sell every plot of land. I mean, when we've done the modeling, the most extreme example is you could only get 50% of your capacity sold if your scheduling is really bad and you've chosen bad instance sizes. So what Amazon and Google do is they, in pretty much every public cloud provider that I'm aware of that knows what they're doing, has a bin packing scheduler. They treat every hypervisor node as really a single plot of land and they subdivide it into acres or hectares depending on where you're from. And so a given virtual machine is one, two, four, eight of those plots of land. And there are even multiples of each other, one core, two core, four cores, eight cores. And if you go and look at Amazon Web Services, M1 instances, M2, M3, you'll see all this. If you look at Google, you'll see the same. And so what that allows you do is you can assign a class of instances to specific hardware designed for it. You can evenly bin pack in all the virtual machines and that gives you fixed proportions of resources which allows you to manage over subscription rates and know exactly what the performance will be for those systems if they're all banging full out. And you can do this today in OpenSec fairly easily with host aggregates or a custom filter, right? It's really, and it's not a lot of logic either. I'm giving away secret sauce now. So third is we need to have the set of services that these elastic clouds have. And this is, I meant to get the Amazon Web Services logo up here, I apologize. But this is the set of Amazon Web Services. You can see the Amazon does a lot of stuff. But really all we care about is that box at the top, right?   I mean, you're locked into Amazon. And the worst thing in the world is to be locked into a big public cloud provider with all your data and something like DynamoDB. I mean, how are you ever going to get out of that? So all of the stuff there, the core infrastructure services are mostly already an open stack, right? I mean, we don't always have all of the Amazon Web Services APIs, but we have quite a few of them. EC2, S3, CloudWatch, CloudFormation. I'm probably forgetting some. We're working on adding virtual private cloud to the EC2 API. So there's a bunch of good stuff there. So most of what we need is already in there. So that's awesome. Meaning total cost of ownership, what I find really humorous about this is I see this problem continuing to happen everywhere I go, which is that people don't quite get what the costs of running a cloud look like. These numbers are from Amazon Web Services.  So for a big, gigantic, public, elastic cloud who buys and bulk, who drives all their costs through the floor, who has no gold-plated infrastructure, has minimal redundancy in every element of the system, servers are still 57% of the overall cost. So if you go and you say, well, I'm going to put OpenStack running on my super high-end blade servers, that's great. But that pie chart starts to look a lot different. That blue is like 80% or 90%.   There is a customer that I've talked to that is in the financial services business on the East Coast. And they're running their Hadoop cluster on Cisco UCS B-series blades attached to a fiber channel sand. That is the wrong way to think about solving cloud problems. So when we've modeled out our price, for example, total cost of ownership, power, cooling, space, labor, software, hardware, Amazon Web Services direct connect, cost of being with any and everything, what we've seen is we can build a cloud that's basically half the price of Amazon Web Services wholesale costs. One-year reserved instances. So there's this mythology that they have more buying power than the average enterprise. And the reality is that you can get most major hardware vendors to get down to very low margins if you've got just moderate buying power, a few million dollars. So OpenStack's already got all of these APIs. We worked on the Google Compute Engine APIs. AWS APIs have been in there for a while. Google Compute Engine APIs are in Stackforge. Thank you, Alex. And we welcome anybody participating with us there. So this is the last and most important thing is the behavioral compatibility testing. So this is the only way to figure out whether two clouds are interoperable or not. It's testing, testing, testing. That's the way the IPsec problem was solved. They got into these big, huge IPsec VPN bake-offs between vendors. And they just basically get all the vendors in the room and figure out what the heck wasn't working. And then they would hammer through it and figure out what needed to happen. So it turns out that we've already been modeling and testing for behavioral compatibility with Tempest. And we've started to create some more Tempest tests that we're going to upstream push back.  So you've got a checklist. And you can run that same set of tests against Amazon. You can run against your cloud. You can run it against vanilla OpenStack, whatever that is. I still don't know what that is. If anybody can ever figure out what vanilla OpenStack is, please let me know. These are the Tempest tests that are in there today for Amazon Web Services behavior. You see that pretty much it's lit up green everywhere. Just some minor differences. OCS being our product there in the middle, just for comparison. This is the new set of tests that we're in process of cleaning up. And we're going to work to upstream them.  But at least they'll be in there so that people can turn them on as they need to. But you can see that there's a whole bunch of behaviors that we can test on an OpenStack installation that's configured to look and smell and taste like Amazon Web Services that effectively tell us whether we've gotten more of the AWS behavior or not. And I think that what I would really love to see happen with OpenStack is that there are many different flavors of it. Some of them are like this. Some of them are not. But that we can test these flavors hopefully with the ref stack work that Josh McKenzie and others have been working on. I'd love to see there sort of being like this is OpenStack for Enterprise. This is OpenStack for AWS. This is OpenStack for HPC. And you've got reference for how that gets turned on. And then you've got a reference for how you test and guarantee that it's the flavor that you want. So this is pretty easy. How do you know you're done? Same availability, same performance, similar services, equivalent TCO, same APIs, and it behaves identically. With that sixth one being kind of the unifying principle. This is a new architecture diagram, which is not on our website for our system. I'm not going to talk about it because we're running out of time. But it is sort of like in the product track, so I got to show my product here. You can see that we've got a bunch of these pieces in here. It's not perfect. No product's perfect. I'm pretty proud of what we've done, though. We worked on solving certain hard problems. And the response yesterday when we were talking about our Layer 3 networking plug-in in this room actually was pretty astounding. I didn't know that people were jonesing so bad for a functional network stack, but I did get the message to get that upstream sooner rather than later, and I will work on that.  If they don't have that, they're not going to survive. The path to that is through cloud native applications, which require moving to that DevOps model. And the elastic cloud type architecture, no matter what the software is behind it, whether it's Amazon, Google, OpenStack, is a foundational component to make yourself successful there. And largely I think that's because we want to hybridize the private installations to the large public clouds. And so my main takeaway for you would be we'd love more people to be interested in sort of this effort, and there's a lot more people in the room than I expected, so that's great. I don't want to be the lone voice in the wild. I'm used to that, but I don't want to be that crazy old hermit talking about this when nobody else is. So I think that's my last slide. Why is this not advancing? So I'm happy to take questions, and could you please come to the center mic so that they're picked up on the video. Hi. I have a question. What's your view on pass with respect to this question of hybrid cloud and pass? Well, the way that we look at the world is that we're going to solve the infrastructure problem, and then there's an ecosystem of people that run pass on top of Amazon, OpenStack, and so on, and that we'd rather have those people come and work on top of our system. So it makes more sense to use Cloud Foundry unified across those three different systems or something like that than it does to bind to Amazon's pass or for me to deliver a pass. And I'm an infrastructure guy, not an application developer guy. There was a recent court ruling where Oracle. Yes. And Google, where Google's found responsible for re-implementing the job APIs. How does that affect your thoughts here about embracing a proprietary public cloud API? So that's a good question. And essentially my stance before after talking to Google was that this would not be overturned and that we would be in the land where you could copy APIs. In talking to Google further, their position is that the battle's not over. I don't know whether it is or not. But what I do know is that, and I hope everybody takes this in the best way possible, but Amazon is totally ambivalent about OpenStack. I mean, they just don't care. And I don't think that it's going to become a big enough threat that they will care. And so there is some need to try to clean that up from a legal perspective. And maybe over time they'll care enough that we can get them in the fold. One of these Fortune 15 companies that I'm working with does care about the Amazon Web Services APIs, and is a big Amazon consumer. So I think over time some of the customers will help us get maybe a blanket and deminification or agreement between Amazon and OpenStack Foundation. That's certainly a risk right now. But if you're really uncomfortable with that, use the Google Compute Engine APIs because they're not going to see you. They don't care. Any more questions? Oh, come on. I got extra time here. I got two minutes. It's two questions. I usually like to get at least three questions before I leave the stage and stop haranguing the audience. So I didn't quite hear it all of it. But yes, OpenStack metering and cost measurements are extremely immature and not designed to scale. So I was wondering about the QoS that you're talking about and things like CPU limitations. Are you using the KVM hypervisor? And if so, how are you managing those limitations? Yeah, so it's basically through managing the subscription or oversubscription rates now. We don't actually use any baked-in quality of service. Think of it as a manual way of doing quality of service that's related to the way the bin packing schedule works. If I put four VMs on a box that each have one virtual core and the box has four virtual cores, I know that I'm going to get most of one core for every VM. I can even potentially pin the VMs to a particular core, which Amazon does in certain cases. And I can get rough guarantees that I'm going to get what I'm going to get. There is overhead for the hypervisor. Some hypervisors are better than others in terms of dealing with large amounts of oversubscription rates. So there is some variance. But the general way that I think about is that one of the problems with using a more sophisticated quality of service system is that a lot of times they manage everybody down to a really common baseline. And then they just allow certain people to burst above that to provide guarantees. And the problem is that in a more dynamic world with cloud native applications, you sometimes don't know what's going to take off or not. And you don't want to throttle everything by default. It's still a very valid technique to deal with quality of service problems by throwing brute force at it. Big fatter pipes, big fatter boxes, more cores, more RAM. OK, thank you very much.


a benefit that the playbook afforded us and all the efforts of having better inclusive practices afforded us was we were able to take our time so it created space for us to move timelines around and to use our engineers and to use our product managers to step up to the role of analyzing the data and I'm part of the community tech team and we're the wish list team so for those of you who may not be familiar it's a wish list that we run every year where engaged contributors to the platforms can come and propose ideas and we saw through analyzing the data that for the past six years there's been an underrepresentation of EngagedContributors.com from Spanish speaking communities and from Chinese speaking Mandarin speaking communities so the time that it afforded us gave us the space to go through the data combed through all the surveys in the past and then switch our strategy based on that so we can use those users. Just to connect and switch it over just a little bit let's go over next to Gergo who also works on a team that hears a lot of feedback from the community specifically thinking about newcomers but can give us the perspective from an engineer point of view. Hi, I'm Gergo, I'm a software engineer on the growth team our team works on helping the editor communities grow. We focus on the first few weeks of people's experience when they sign up to be a Wikipedia editor and we try to give them a good user experience and try to help them find their footing and get familiar with the policies of the site which means that we need to we need both a lot of feedback from the new users point of view because they aren't familiar at all with Wikipedia yet and then we also need a lot of feedback from experienced users because we help the new users make edits and we need to make sure that these edits do not cause a burden on the established community and the playbook has been very helpful for us as a generic guide currently it contains I think something like 50 items which is way more than we could keep in our head so it helps to make sure that you do not forget anything and it helps to make sure that you can be disciplined like for example we did think about accessibility before we had the playbook but we usually started thinking about it in the development phase which is often too late and now with the help of the playbook we can make sure that it's integrated from the start and we consider accessibility during planning and during the design phase and it also helps to focus efforts because everyone is doing the same thing so for example the playbook is recommending a pre-mortem a pre-mortem is a way of thinking in a structured way at the start of how things could go wrong and there are a number of practical questions of how you structure such a discussion and because every team is doing a pre-mortem now it's a lot easier for each separate team to figure this out in terms of challenges the playbook has a lot of different items so they are necessarily very short in how they are defined it wasn't always easy to figure out what when we should consider something done whether we have done enough to check it out and a more specific challenge was around multilinguality so the playbook recommends multilingual usability testing which is something we found very helpful because sometimes we get different feedback from different language communities but it also brought up a lot of practical challenges because that means you need to write mocks in multiple languages you need to maintain those in parallel you need to translate the usability testing documentation to other languages you need to find speakers for every language who can conduct the test and the interviews you need to translate everything back so it's it's pretty involved and in practice what we did is we relied on multilingual speakers in the design team which is not a really scalable approach so that's something we still need to figure out thanks Gergo that's really helpful and to dig even more into the technical point of view we did have one team that was a back-end team that originally had a product manager and was able to connect the teams work to some front-end user thinking and then through some shifts that changed and so Desiree has stepped in on that team and to help the platform engineering team know how to do the application of the paybook and we'll talk more about that experience great thank you so much Jasmine so thanks Desiree Baud I'm the director of platform product management here at the Wikimedia Foundation and I work with a lot of different teams across technology and product in what I call our foundational technologies back-end is another way of putting it but essentially these technologies are what power our sites Wikipedia keeping it up and running commons et cetera and so without a lot of the work that teams like the platform engineering team the sites won't run so often historically we never really thought of these technologies as products and so that's been a real challenge trying to then say well okay let's plug in some product management to this which we started for the first time and now let's adopt this concept of this playbook about how to build these products in a diverse equitable and inclusive way when we're just starting to think of them as products so we had a few key challenges as a team kind of rolled through this the first was making sure we had the right roles and functions and building the connections into the community and thinking of our work as products so many engineers for example struggled to think about how would something like an API which we're building for many different internal teams and the movement and the community and tools be thought of as a product and so we were trying to go through the playbook and we're not a feature team so often times the typical things that you would think of for features usability testing etc we had to translate them a little bit in order to make them relevant and digestible to the team and so some of that included shifting the way we were thinking about the products and so this was a real benefit in the team where we started to say what are the dominant languages that people are using how do we make APIs language agnostic how do we think about service and performance for different users across the world and how do you guarantee that how do you build so that everyone has equitable access and so it was a really different way of thinking that we had to start looking through the work instead of just saying we built an API and it's done and it meets a specific use case and so we had the balloon out our thinking quite a bit to think about how do we make this that we can use for many different use cases and that the movement consumed more readily and more easily instead of just for a specific product or feature that we're trying to develop and so it's a muscle that we've been building and we've had ups and downs through the process some of it a lot of it has been this translation and I think we're going to keep going with equity how do we think about applying the playbook and the scope of our technical and technology products Thanks Desiree that's really helpful and definitely something we'll continue to work on and I'm excited for us to all continue to partner to move that forward and so the last person that we'll hear from here is Alex who will share the perspective from standpoint and who has been working on a really big project and also applying the playbook at the same time which I think is a really big feat so Alex can you share what that has been like Yes Hello everyone and thank you Jasmine I'm Alex the designer on the web team and as Jasmine mentioned for the past two or so years we've been working on Vector 2022 which some of you are probably familiar with so yeah I'm excited about the playbook I'm proud to say that prior to the playbook our team was already somewhat focused on testing in multiple languages testing with people in multiple parts of the world and also focused on accessibility to a certain extent however these focuses weren't particularly formalized in terms of process they were sort of things that were important to individual members of the team not necessarily something we would formally plan around or have kind of a systematized approach to so I think those are two clear areas that stand out to me that the playbook has helped us with prior to using the playbook we were testing things in maybe like three languages on average and our most recent feature we tested in six or seven different languages and part of that has enabled us to do that again is the playbook and then planning ahead of time which has allowed us to build sort of tools specifically in terms of how we build prototypes and make those prototypes available in multiple languages to streamline some of that process as Gargo was talking about it can be overwhelming to prepare mockups in so many different languages so we've actually switched to using prototypes that use the wikimedia apis and allow us to do that a little bit more easily and then on the accessibility front Bernard who is an engineer on our team has kind of taken the cues from the playbook and started to set up some automated accessibility tests and I know he's also working to get a sort of consultant or expert reviewer to come in and work with us on accessibility stuff again these things have been prompted by the playbook so yeah it's been exciting and interesting for sure in terms of open questions and potential improvements for the future things that came up in our team review recently is actually that there are a lot of different accessibility standards available online and even within accessibility standards there are various degrees like AA, AAA, etc that you can adhere to so I think we wanted to clarify what the sort of exact guidelines are that we want to be following and then the second thing we talked about is potentially having better integration with the knowledge gaps which is coming from the research team specifically the technical fluency knowledge gap we have found in our user testing that there's quite a range of technical fluency and that sort of variation leads to different needs that people have and so we're wondering how to better build that as a dimension into the playbook and have it be something that we explicitly call out when we are developing and testing features thank you Thanks Alex, that's really helpful now that you have heard from us we would like to hear from you please share with us in the etherpad which has also some helpful links based on some of the things that the panelists have shared here what barriers you have had to overcome when engaging with our projects and what tools would have been helpful to you to overcome those barriers we're hoping to take those use cases and apply it to the playbook before sharing version 2 of the playbook next week for all of the teams in product and technology to test against thanks again for joining the panel and thank you to all of our panelists


Income Tax 2023-2024 W-2 Income Tax Software Example Get ready and some coffee so we can lessen the sting of the IRS smack with Income Tax Preparation 2023-2024 First, a word from our sponsor Yeah, actually we're sponsoring ourselves on this one because apparently the merchandisers they don't want to be seen with us but but that's okay whatever because our merchandise is is better than their stupid stuff anyways like our trust me I'm an accountant product line Yeah, it's paramount that you let people know that you're an accountant because apparently we're among the only ones equipped with the number crunching skills to answer society's current deep complex and nuanced questions If you would like a commercial free experience consider subscribing to our website at accountinginstruction.com or accountinginstruction.thinkific.com Here we are in our form 1040 example problems using LASERT tax software you don't need tax software to follow along but if you have access to tax software it's a great tool to run scenarios with you can also get access to the forms schedules instructions at the IRS website at irs.gov irs.gov starting at our normal starting point with Adam Taxman just trying to avoid a dang tax man living in 90210 Beverly Hills we're back to a single filer status to start off with no dependence W2 wages are starting point as usual 100,000 standard deduction for a single file or $13,850 getting us to the $86,150 taxable income marrying that in our Excel worksheet 100,000 $13,850 standard deduction $86,150 taxable income the tax calculated by the software on page 2 was $14,266 as we could see on page 2 here $14,266 and then we'll get into the payments or withholdings which we don't have at this point in time at our starting point now when we think about the first line item here this is going to be our most common line item we first think about typically coming from that W2 form so let's take a look at a W2 form the most important boxes typically will be box 1 and 2 those having the big impact on the tax return box 1 providing the federal income tax box 2 the withholdings that the employer was forced to take out of the employee wages and then of course we have box 3 which is going to be the social security which is usually going to be more of a reporting form here possibly not having a big income tax effect because it's a social security tax social security taxes and then box 5 is the Medicare similar kind of thing you can see box 1, 3 and 5 then are the actual three forms or three types of income which could be all the same but also could differ and then oftentimes the confusion comes over in these boxes over here where they could have different things that are basically taking place type types of benefits for example and then we also have this checkbox that could be important for with regards to the retirement for example if you have state taxes then the state information is going to be important down below states could have an income tax but they may not they may be providing their their tax needs with say a sales tax for example we hear focused in on the federal on the federal side of things now also note that when you see anything marked in say box 12 you'll you'll also have the instructions if the instructions will typically come with the W2 if they're not provided by the clients you can go to the IRS website and then pick up the instructions so you can look at the instructions from the IRS so here's a part of those instructions and then instructions for the employee and you can see here we have importantly the box 12 instructions which could give you more information if you're confused about something that's entered in box 12 and possibly have some code in it here or say on the next page once again you have more kind of codes that could be in there to help give you indication of what is included in box 12 and then if you need to do further research based on this information you can drill down from there and further your research alright so let's just run a couple of our examples this first one we had 40,000 in wages and everything was the same for the wages box one three and five being the same because there were no 401k plan withholdings and they didn't hit the cap for Social Security what would what would that look like over here we're going to go okay let's say it's W-2 income 40,000 of the income and then the federal income tax you have to do the data input for this one because it's not a flat tax the software cannot calculate it so we're going to say it came out to 4,000 I'm going to say 4,000 now notice here is guessing this software is guessing that the Social Security wages is the same that is not a guaranteed that will not always be the case but could often be the case and it's correct in this case if this number is correct then the Social Security will be calculated for us because it's in essence a flat tax so if I have the 40,000 Social Security wages then 0.062 is going to be the Social Security rate giving us the 2480 so I don't actually have to do the data input there the same is true for the Medicare wages it's guessing that's the same as the total wages may not always be the case but often the case once I get that number correct the software can calculate the tax because it's basically a flat tax rate 40,000 times 0.0145 in this case that's going to give us the 850 so and obviously you're going to have to give more information with regards to the employee or information on the W-2 form such as the identification number and the address because as the we can give more information to the government because of computers they want more information they want to know everything about you they're going to put that computer chip right on your forehead pretty soon drill it in there so you can't you know you can't get it out of there because they're not liking the fact that they have to rely on the cell phones these days because then you could put that thing down if you wanted to whereas if they drilled that chip right in your forehead okay any case let's uh if we scroll down here we've got the 40,000 of wages now and then we still have the standard deduction the 13,850 we can mirror that over here that means the taxable income is at 86,150 so we have the taxable income wait what happened W-2 income let's change the income 40,000 getting ahead of yourself don't get ahead of yourself 26,150 I hate waiting for myself I'm so slow you have to wait for yourself page two tax is calculated at 2921 so then we're going to go okay 2921 and then there it is and then we saw that the withholdings 4,000 so I'm going to go and say okay on the withholdings payments and credits tab I'll say W-2 first job W-2 W-2 one was I withheld uh 4,000 should get it from here 4,000 boom 4,000 that's going to pull on to the my formula so there's the 4,000 so I have a refund of 1,079 and so I can say okay does that tie out here 1,079 on the refund so that's the general basic basic type of W-2 form obviously we could have more than one W-2 form so we could have imagined that we worked at two locations so if I was to do that and so let's just say we double this W-2 form and this was W-2 one again I'm going to use the same location but let's say this is another 40,000 we'll just double it 4,000 so now I have two W-2 forms that are adding up to a total of 80,000 both of them withheld the 8,000 so we have the social security wages up to the 80,000 and so on and so forth if I go back on over and say okay let's check that out so now I've got the 80,000 if I mirror that on this side I'm going to say income this was second W-2 form W-2 2 of 40,000 and then we withheld another on W-2 to 4,000 total withholding is 8,000 pulling that over so that means 80,000 minus the 13 out 850 same standard deduction should give us to 66,150 so if I look at page 1 13,850 gets to the 66,150 page 2 calculating the tax at the 9,866 so I'm going to plug that in 9,866 and the payments were 8,000 so now we have an amount due of 81866 so 1866 and and so then there's the penalty of 45 let's put 45 to get us to the 1911 now you might say how in the world did that happened because I got a refund at 40,000 and then I doubled everything including the withholdings and now I owe money why because because we have a progressive tax rate that second 40,000 was taxed as a as a much higher tax rate the first 40,000 highest bracket was at was at the 12% the highest dollar amount on that last 40,000 was taxed at a marginal rate or the last hit rate of the 25% that's the progressive tax system now note that you could run into it notice what's happening here is we're not doing much with with the social security Medicare because these are flat taxes they're not having a big impact impact on the tax return because these are kind of more informational things because they've already been paid through the employer withholding but you can imagine that cap happening where we saw that the cap I believe is at the 160,200 what if you had two different w twos where the combined wages goes over that cap that could cause a problem let me show you what I mean so we're going to say let's go back on over to the detail and let's say that this second one is a hundred and a hundred and fifty thousand right it's a hundred and fifty thousand so then if you tell if you calculate the social security tax on that you'd say okay it was one hundred and fifty thousand times point oh six two that's going to be the nine thousand three hundred but the same taxpayer also paid the two thousand four eighty and so the total being paid is eleven thousand seven eighty but there's supposed to be a cap of I think it's the one day sixty thousand two hundred times point oh six two see so there should be a cap of nine thousand nine thirty two social security that can be assigned to one social security number and we paid minus eleven seven eighty so now we have kind of an issue with an overpayment to social security because of big beat because of the two w twos that are adding together and didn't know about the cap being hit because the other one was at the other employment so we could say it like you'll see that you'll say it like the software will catch that usually because you'll do the data input that's why you want to make sure that you input the social security even though it might not be something you see see if i got a page two i'm like okay everything looks no way what is this what is this that looks funny it's not in my worksheet over here and then i'd go okay that's coming from schedule three their schedule three at that why is that there that just popped up out of nowhere and then we're going to go all right on page two schedule three excess social security oh they paid excess why because there's two w twos and therefore this this amount was overpaid into the social security because they went over that cap now you have to also be careful when you have a married couple to assign the social security to the proper number because the social security although they're married the social security is a tie is tied to one person at a time so maybe we'll take a look at that but before we do let's go back on over and say all right let's i see that let's go back and get rid of the second one and sales delete this one and let's do the second the next scenario where we say uh... let's do this one let's just do this one so we have one seventy thousand but then the social security are are different because now they hit the cap on one w two form and then the medicare wages are different so okay so so if we see that we're going to go okay the w two was that wages uh... what what what was it again one seventy thousand one seventy thousand and then the withholdings were at the forty two five box two forty two five that always has to be input now it's trying to guess that this one is correct they got it right how to get it right because it's capped so it's all that one's at one seventy this one has to be capped at one sixty thousand two hundred so we got it right that time and then if i multiply that times point oh six two one hundred sixty two hundred times point oh six two that's got that right so nine nine three two that's where this number comes from and then we have the one eighty thousand one hundred eighty thousand it tried to guess the medicare wages now the medicare wages are wrong so i have to do the data input how did it get it wrong well it tried to pull in the medicare wages from this one seventy because it's not subject to the cap however it's possibly this this wages got decreased how why is that one different well because we had in this case a a contribution to a retirement we're gonna imagine that went to a retirement account so the retirement account box is checked off so i'm gonna go in and say okay now if i looked on my instructions i think that should be in boxed i'm gonna imagine that was in box twelve here and then and i go all my instructions had a d in it let's say so elective deferrals two a four one k cash or deferred agreement so we're gonna say okay so let's go back on over is there spot in my data input to put that in here well here's box twelve and i've get this nice drop down i'm gonna say it's an elective deferral of ten thousand dollars ten thousand and then i can go back on over and say okay k posse what happened there's the one seventy thousand so obviously we're gonna pay federal income taxes on the on box one so i'm gonna put this one job two is gone rat one seventy thousand and the withholdings then the second one is gone the withholdings are now at what did i say forty two five uh... forty two five do it and then if i go back on over standard deduction still at the thirteen eight fifty that brings us to taxable income one fifty six one fifty so we're gonna go okay one fifty six one fifty page number two calculated the tax at thirty thousand eight seventy six so i'll plug that in here thirty thousand eight seventy six and we have the payments at forty two five okay so bottom line eleven thousand six twenty four on the refund so so so so there so there is that one so like i say you might not always have an impact of of uh... the social security tax and medicare tax but it's possible you could if there's multiple w two's and if you explain this to a client you might have to explain why these three boxes which all indicate wages are different and you might help them to kind of understand what their total compensation really is which is generally closer to box five the medicare wages because it's not being reduced by the by the amount that was put into the uh... taxes for example i mean the 401k plan is what i meant to say for example okay so that's so so that you can you can look at for example this forum to see it some of these other uh... other things you can find in box twelve and then basically do more research on each of these items and and then drill down on that research if you wanted to but for now let's also just look at a married couple just to take a look at that scenario let's bring it back to our original scenario where it was one hundred thousand and we're gonna say the withholding let's just remove the withholdings to start with and one hundred thousand here and medicare as that one hundred thousand as well to do one hundred thousand so now we're back to then our to do to do one hundred thousand thirteen thousand eight fifty eighty six one fifty so i'm gonna say okay one hundred thousand to do it to our starting point and thirteen eight fifty and eighty six one fifty eighty six one fifty page to calculate in the tax fourteen two sixty six we're gonna say okay tax one four two six six and i'm gonna get rid of the payments for now and so that's where that's going to be our starting point so now let's say they get married so now we've get married so we're gonna say okay so let's go on over and say single married now so if we just move it to married and we keep it the same we can see what has happened now we've got two individuals filing status married filing jointly same one hundred thousand i haven't added another w two or anything that gets us to the uh... standard deduction at twenty seven seven hundred i can mirror that over here by saying now the standard deduction is for a married couple and so that is that that gets us to the seventy two three hundred on the bottom line page to calculate in the tax eighty two three nine so we're gonna say that eight two three nine and so that gives us then the and i didn't withhold anything so there it there that is okay so now let's say that we had another double you two so if i go back on over and this is something to that's important if i say okay another double you two and and i did let's say i don't mark the spouse that it's going to by the way this retirement plan if i check that checkbox would be important if there was a retirement plan on the checkbox so that your software will indicate that that you know that is there to do any kind of cap calculations on the retirement plan okay let's say the second one was eighty thousand and i'm not going to do i won't do the withholdings i'll just keep it here so it calculated the eighty thousand the social security and the medicare properly but if i didn't check off that it went to the spouse then now i have a hundred and eighty thousand that the software might try to apply to one taxpayer which means again i went over the cap for the social security so if i go back on over and i was to look at this i can go okay let's take a look at we've got the one hundred and eighty thousand twenty uh... twenty seven seven if i go to page two uh... notice here once again it did this thing on on schedule three and if i look at it i'm gonna go man what it is what why did it do that and it's because that i didn't apply the social security to the spouse right if i go back on over and i say okay this was the spouses w two now the one eighty isn't going over the cap because note the social security is applied to each social security number not to the tax person itself in other words when someone is single they're their own entity when they get together they have united body soul and and uh... tax return altogether uh... for federal income taxes for the most part uh... for social security they're still separate for each number because the social security benefits are going to be paid out based on social security number not filing status so therefore this that becomes very important so i can say okay and if you do your double checking over here in excel you'll see that right then when you if a mistake like that happens now i can go okay so i double-checked it so there's a one eighty so there's the twenty seven seven form three is now gone there's uh... the tax on it and i don't have that social security thing kind of popping up there it's going to be important to assign the social security we'll talk more about social security later but it's important to assign the proper social security to the proper person it's not going to have an impact possibly on the federal income taxes but it could and that social security type of situation and it's also something that you might get questions about with regards to people trying to maximize their social security benefits so that they get the when they get paid out in retirement it's properly allocated and will get into problems and issues with that when we get into self employment tax for example uh... on a schedule c like who's going to who who should be allocated the schedule c now also just realize with this married couple that we we have to assign someone on line one and line two right and so in that typically you're going to put that the man on line one and the woman on line two but you have to is you could be so you have to do it that way because the software is going to say this person is the is the taxpayer in the other ones going to be the spouse so that they can assign the two line items so so so when you do the data input for most tax returns that's going to be the language that's going to be used right so if i'm gonna say spouse that's the person that's on line two of the tax return typically a wife in a married couple situation so that's the general uh... scenario and like i say if you if you uh... have something that's that's somewhat unusual on the w two typically you can have a data input place for it uh... if it's on the w two in your data input form for your software and you can also go to the instructions and basically look at the letters for the line items that might be included for example in box twelve and then from there you can further do your research to make sure that you're properly reporting anything that's somewhat more unusual on uh... the w two form and some of those topics will talk more about in future presentations