 Hello, everybody. Thank you for coming. My name is Marcella Ponell. I'm a software engineer at Intel, but I'm from Mexico. And I'm also an OpenStack contributor and a member of the apico-system working group. So I hope you enjoy my presentation. So app developers are very important for OpenStack grow because they are the ones who create applications that run on the top of OpenStack. App developers are the people who create ecosystem, and they are the drivers of any technology adoption. That's why OpenStack had to embrace application developers and provide the resources that they need to create their cloudware apps, taking the adoption of OpenStack to the next level. In this session, you will understand the current state of OpenStack about application developer experience and what it's needed to do to provide the proper resources that application developers need to succeed in OpenStack. So where is OpenStack in terms of developer experience? This is a tough question, and it's not easy to answer. But in order to drive efforts in the apico-system working group to make OpenStack more efficient for application developers, we decide to analyze the most popular public clouds, like Amazon Web Service, Google Cloud Platform, and Microsoft Azure, and compare them against OpenStack. The latest OpenStack user survey in the application development section tries to know how developers are using and interacting with OpenStack. The section has four questions about what SDKs do you use for interacting with the OpenStack APIs? What are the improvements that you want to see in OpenStack about application developer? And what other clouds do you use and the stack for build your apps? And this is a great question, but just forget a general insight. The community needs to go deeper for no more details about how our developers are using OpenStack. For example, how are they monitoring the application? Or how are they packaging and deploying the apps? Do they have a failure notification system? What are the major errors or issues that they face during development applications that are on OpenStack? These are the available resources about development in the OpenStack developer portal. Basically, the OpenStack API reference, SDKs, and the OpenStack first app guide, better known as My First App. There are 37 available SDKs for languages like Python, Java, C-Sharp, and so on. But none of them are official. I mean, they are not OpenStack projects. And My First App is the only sample app available, and it's only published for one SDK, LeapCloud. So if we want to make OpenStack more efficient for application developers, first, we need to take a look at this current developer experience. That's why at Intel, we decide to support the creation of a cloud comparison to analyze the developer experience across these providers and compare them against OpenStack. Our goal was discover the best practices and gaps in OpenStack against the others. We choose Rackspace and OVH as OpenStack providers against the most popular. And this is the process that we follow to create our cloud analysis. First, we select the cloud providers. Then we create accounts for these providers. And basically, we use free trials, because it's the first way that developers do things, free. Then we prepare a questionnaire with basically this spreadsheet with questions focused on assess the developer experience on each one of the development stages during the development lifecycle. Then we select the apps to deploy. And we choose the apps in the GreenStory tutorials on each provider. And for OpenStack, we use my first app with LeapCloud and Shade SDK, because it's the only available. Then we recruit developers. And these are the application developers that have to leave the whole experience during the development on each cloud provider. And my Intel folks, Ivan Escareno and Angel Perez, help me out with this. Next, we observe and document the whole developer unit. So the developers and observers have to work together on shadowing sessions. I was playing the role of observer. So I was making the questions, taking screenshots, and documenting everything, while Ivan and Angel was testing all the clouds. And finally, we present the results, and we share as a report in the app ecosystem working group. And this is the developer's journey that represents basically all the stages that developers follow during this cloud analysis, since the creation of the accounts until they're destroying or deleting all the resources. So now I will start presenting the findings that we discovered during this cloud analysis. They will be divided by each one of the developer unit sections. And they will be classified in red for critical issues, yellow for gaps, and green for best practices. So in sign up. And at this stage, the developers create and activate the accounts. So for Rackspace and Novish, this was very easy because they only require an email and a password to create and activate the account. For Azure and Google Cloud, you need a proprietary account. I mean, an old look, or a Microsoft account, or a Google account. So it's an additional step. And on AWS was a tricky one because the activation is through a phone call. So the developers never receive the phone call because the process about how to write your phone number is not very clear. So at the end, the developers create a support ticket to activate the account on Amazon. Next, Welcome Pack. We call Welcome Pack to the emails that the provider sends you when you create your account. And these emails basically contain useful information for developers, like links to the developer's center, videos on tutorials. So OVH doesn't send you a Welcome Pack. And indeed, it doesn't have a developer portal. Azure sends you a Welcome Pack, but it's so overwhelming that the developers didn't find a way to go through the amount of information. The other providers send very useful Welcome Pack, billing. Being aware of the money or the resources that they are spending is very important for developers. They want to know how the resources are spending the money and forecast future charge. So here are some images of some dashboard about billing in different clouds. Our developer says that AWS has the better user experience in the dashboard billing, because it has the tailored reports, summary support service, graphics, and everything is very visual and easy to understand. OVH shows little information, but it's very clear and easy to understand. Rackspace also shows little information, but the developer says that they would like to see more details, because they're not sure how the money was spent. And Google Cloud, well, is not a dashboard, because it's not very visual. It's just a list of all the charge. Infrastructure. At this stage, the developers create all the resources that are needed by their apps, like application servers, databases, storage services, networking setup, and security. This was the hardest step for developers on OpenStack. We have red bullets here, so let's see what happened. The first one. And on OVH and Rackspace, the instances, security groups, float and IPs cannot be created using LeakCloud SDK, because LeakCloud used the Compute API, Nova Network, for networking setup. And those providers use Neutron. So LeakCloud has not implemented the Neutron API. That's why the developers were getting 404 errors, something like their resource cannot be found, because the SDK can communicate with the API. So if you have an OpenStack cloud that uses Neutron and your application will interact with it, LeakCloud is not an option for the SDK of your app. So then the developers moved to Shade SDK. And it works fine on OVH, because Shade support both APIs, Nova Network and Neutron. So all the resources that my first app required were created successful with Shade in OVH. But in other hands, for Rackspace, the developers tried the same, but it doesn't work. Because despite the fact that Rackspace used Neutron, the API is not exposed to developers. So Shade cannot communicate with the API. And so my first app can run on Rackspace using LeakCloud or Shade. Also, the developers didn't find how to create floating IPs, because they are not available yet. And the security groups are not able by the file in the dashboard. For the other clouds, infrastructure was not a big deal, basically, because, for example, Google Cloud and Azure provides platform as a service. So developers don't care too much about infrastructure, just deploy their code. And on Amazon, you have to create the infrastructure. But it was very easy, because the developers say that all the tools and services are very easy to follow. And if not, they have too much documentation. Development. Here, the developers follow all the tutorials choosing an available language on the cloud. So the good news is that the developers didn't have to learn a new programming language, all the language that developers like are available on the clouds. The preferred ones was Java, Python, PHP, and C-Shar. For my first app, well, it's not available, just available for one SDK that is LeakCloud. So the developers say that AWS has the most complete developer portal, because it's very well organized, has many tutorials for different languages, and some videos. Deployments. AWS and Google Cloud provide their own deployment tools. It's basically a CLI, and developers can deploy their app without seeing some comments. And for OpenStack, my first app used CloudInit. And CloudInit is a tool that allows you to run some batch comments after the creation of a virtual machine, for example. So if you want to deploy your application or automate the deploy of your application on OpenStack, you have to create your own scripts. There is no tool or available, very easy for developers, for entry developers, for onboarding developers. Updates and redeployment. In case that you need to update your app, something that happens every day, AWS, Google Cloud, and Azure, it automatically will do it just with a single push code, pushing your code to the cloud. So in OpenStack, you can do the same, but only if you prepare your scripts and has some projects available in your cloud, for example, Heat, Murano, or Solving. And then last stage is monitoring and cleanup. So the Rackspace and Amazon Web Services, as far as also Google Cloud, provides a monitor to see all the resources that you are ruining in your cloud. And developers love these tools because they want to be aware how the resources are in the cloud. So also they use these monitor clouds to take decisions about when to grow the application in case that the app doesn't do it by itself. OVH also have a monitor tool, but it's very basic because only show RAM, CPU, and traffic by instance. About cleanup, well, in this case, all the providers have good methods to delete the application, the resources of the application without any problem. So we are in the same for every provider. So now I'm going to present maybe the most important slide of my presentation. And this graphic is the visual representation of the developer experience lived by our developers during this cloud analysis. And how we come up with this. The developers grade their developer experience on each cloud provider by each one of the stages during the developer journey. So they grade from 1, the lowest grade, to 5, the highest grade. So this is the graphic that represents the developer experience in these providers by the way that we did this analysis. As you can see, there are different colors by each provider, and the areas represent the findings that we discover in this analysis. This is a clear representation to see what is happening. So as you can see, AWS has covered more areas. The developers say that AWS has varied developer experience for them, followed by Google Cloud and Microsoft Azure. So right now in OpenStack, there is a lot of work to do about improvement of developer experience. And that's part of my mission, to contribute to the community to make better for OpenStack for developers. So another result that we get with this is that the two major gaps about the developer experience in OpenStack is, first, the SDKs. Some developers like to use SDKs. So they say that the OpenStack SDKs are outdated or incomplete, so they can do many things with them. For example, the APIs are moving every release and improve it and improve it, but the SDKs are done. So they are very slow, maybe because they are not OpenStack projects. And the other important gap was the tremendous lack of development documentation and resources for developers. In developer.openstack.org, we only have one sample lab for one SDK. So we need more resources there. So what are some of our recommendations to make OpenStack better for application developers? Yeah, we must to load the barriers that our developers are facing. And there is a huge improvement area that plans to be fixed and augmented. So what can we do as a community to help app developers? I have three items here. First, to provide a better developer portal. We know that we have some SDKs, sample labs, but it's not enough. Developers need more. Need more real sample labs. Need more workload reference. They need usable SDKs. They need more tools. They need to be trained and they need to be ready. They want to create cloudwares, but they don't know how. So also, my second point is to improve the SDKs that we have. We have Stereo7, so we can do something about it. The last one is to promote hack-a-tons of our training focused on app developers. Because we need to change the development mindset that right now is like the traditional model because it's the way that we learn. But from here to the future, developers have to think only on cloud-aware apps and I don't know what other things will appear. So for example, yesterday in the keynote, we saw about the Taiwan hack-a-tons. And it was amazing. Everything that developers can do when they receive coaching, mentoring, and resources to create ideas and create products. So also, I'm very proud that the next hack-a-tons will be on Mexico. So I'm part of the organization. And if you want to help us with mentorship or sponsor, yes, please contact me. So we need to have these things as priorities and start working on more items also. So I'm looking for help from all the OpenStack community to improve developer experience in OpenStack. That's why I have three call-to-action and invitation for you all. First, the SDKs improvement. There are 37 SDKs, but they are incomplete, outdated. So how developers can create applications if they don't have, for example, SDKs? So the first chart represents the distribution of the 37 SDKs by parameter language. And the second chart is the status of those SDKs. As you can see in the colors, the 59% of the SDKs available are incomplete with issues or death. So it's not good news. And the next call-to-action is the first app completion. In the apical system working group, we want to drive this effort, the effort with the SDKs, with the efforts with my first app. And this table represents the sections that compose my first app by some of the SDKs that have tried to create the tutorial, at least for one SDK. Red, sorry, green is for publish. That is click cloud, remember, the only one. Or yellow for ready to test. Orange for in progress. And red for not done. Where's the predominant color? Red, not done. So we need your help. We need app developers that want to help app developers to succeed in OpenStack, in the Cloud Hour wall. So my third call-to-action is to do your own Cloud comparison. Today, you learn the process that I follow. And in the link there is all the documentation that I have for run this kind of comparison. So do your own Cloud comparison. If you are an OpenStack Cloud provider of your own interest in test the developer experience in your Cloud, use the material. And most important, share the findings with the app ecosystem working group. We want to know what is happening. And also there is a link to the email for the app ecosystem working group. So finally, this is an invitation. Today is the working session about the app developer and the app ecosystem working group. So we need your help. You can join us to give us feedback or volunteer to say, for example, I'm a Go developer and I want to help with the Go SDKs for OpenStack. Or I'm a Node.js developer or, I mean, JavaScript developers. And I want to complete the developer My first app for JavaScript or, I don't know. But I would like to see some of you there because we are going to define our goals and priorities. And we need help. So questions. By now we only have the material for tests during the Cloud or your experience. But that kind of material is the one that we need. Like direction for developers. Or how we, as OpenStack contributors, we can help with our contributions to the app developers. Because they're different kind of developers. So it's different, yeah. These kind of developers make, they want to like, the things more easy, yeah. So I may have missed it, what type of application it was. And part of the reason I ask is that public cloud providers are providing platform level services, not just infrastructure level. So they're providing things like latency based routing. And I know OpenStack has a load balancer and that sort of thing. But there's also ElastiCache and RDB support. All these kind of app layer services. And they're highly reliable and very good. And OpenStack seems to be lacking in some way. So I'm wondering if your app touched upon those sorts of things. And if the people who were familiar with the public cloud could leverage those things and give you good feedback on where the gaps might be. Yeah, good idea. Yeah, I mean, the first app, the only one that we have, it pretends to be like a high application. But at the end, it uses APIs. So it's connected to the infrastructure. So this is a good point, right? Thanks. Something else? No? Well, thank you everybody.