⚡️ Speed Week: Cloudflare Images

Hello everyone. My name is Zaid. I'm the product manager along with Rita on Cloudflare Images. We're really happy to have you join us and to announce that we've launched Cloudflare Images and every Cloudflare customer with an account can begin using it as of today. So I've been at Cloudflare for about three years. I work on images as well as our video products. The two go hand in hand. The way I look at images is a lot of the applications we use all day long. We tend to, whether on our phone or otherwise, we tend to share stuff and often the things we share end up being images or videos. So traditionally Cloudflare Stream has done a good job of making it easier for our customers to build use cases around sharing videos. And our goal with images is to essentially let you share your favorite memories with the same ease as you can share videos with Stream, being able to do that for images with Cloudflare Images. So we'll go around. What you see here is our all-star team, the people that actually made the Cloudflare Images product happen. And we'll go around, we'll do introductions, and then we'll talk a little bit more about why we built it, how we built it, and what you can look forward to in weeks and months ahead. Because Cloudflare, we move fast, we ship a lot of things. And what you see right now is just the beginning of a really ambitious set of features and plans that we have to help you build applications with a fraction of the effort and cost. So I'll start with Rita, who is also on the images team. Rita, you want to give a quick intro? Hello, everyone. I'm Rita. I'm a product manager for the images team. Super excited to have the product out there for all of you to try it. It might seem like a small step for the humankind, but it's one giant leap for all image enthusiasts, and I'm pretty sure you will love it. Do you want to go next, Greg? Sure. So hi, everyone. I'm Greg, and I just started at Cloudflare last month. So it's been a quick turnaround, sort of getting images, getting up to speed, and then getting this product out. But it's been very exciting and great working on it, and I'm really excited to see what everyone builds on top of images. Hello. My name is Kornel. I'm responsible for the backend of our image processing pipeline, image compression, and optimization. Now to you, Yevgen. Hello. My name is Yevgen. I, as the rest of the team, working hard on the launch of the images product and super excited about the potential of this product. Thank you, everyone, for the intro. So I'll ask Rita. Rita, can you talk about why we built images? Sure. So we spoke with a lot of customers, and we saw that they all had, or most of them, they had in common at least four things. So they have enormous egress fees. So each time they need to move a product from, let's say, from their storage into an optimization tool, and then to deliver, they pay an enormous fee. So every part of this process of the image pipeline and delivery, it needs to have egress fees associated. So we saw this problem, and we started to think, OK, what else? Then a lot of customers said, buckets everywhere. We have a lot of buckets. We need to have buckets. So the current pipeline and the landscape were our clients need to use a lot of buckets to store, and they couldn't use CDNs to store because they don't have long-term storage. So this means that they have a very huge dependency on buckets. So they need to rely on buckets. Other thing that was important for our clients was the load time. So when an image is not correctly optimized, let's say, it can be much larger than needed. And so the website might need some more extra time to load. This can become a very bad user experience for their end user. And also the fact that there is a high maintenance associated with this image pipelines. And so we wanted to break all these pains and to create a product that would not only store, but also optimize and deliver. So all in one tool where our clients could do a pipeline from scratch. Wow. I think Rita covered a lot of really important points. And a lot of these insights that we learned from a different product that we have called image resizing. We have many customers using it that I think Cornell in this meeting was very deeply involved in building. So the images product uses our image resizing product under the hood. And I would love to hear Cornell, your thoughts on the features that we have in images at launch, how it can help customers who are really concerned about load times as well as, and then we can cover some of the things that you think we can do in the future to further help customers. So I know Cornell is really focused on optimization and all things images. So we'd love to hear his insights. Right. So our goal is to deliver the right kind of image to the right user at the right time with image resizing. And we had a product where you can ask us to take any image from anywhere on the Internet and process it, resize it, compress it, and serve it to user with a certain size and cropping and other parameters. And this is a service that works real time. So whatever image you ask, we'll do it immediately. But this puts a constraint on us that we have to do it quickly. And with compression, there's always a trade-off that if you do it quickly, you will do it not so well. And if you have more time to process an image, like multiple seconds, then you can compress much better. But multiple seconds is a not acceptable response time for a real-time service. So we had these constraints. But now with Cloudflare Images, you can store the images with us. So we have always access to them. And you define ahead of time what presets you will have, what sizes, like thumbnail, hero image, banners, sidebars, and whatever you're going to use. When you define those sizes ahead of time, we can prepare to serve them immediately when you ask for them. And we'll have time to optimize them in the background. Yeah, that makes a lot of sense. As a follow-up, I know you're very deeply involved with with your deep knowledge about all the new technologies that are coming out and features in the browser around serving the most optimal images. What are some of the features that customers can leverage, new developments in HTML that you would recommend customers looking into who really care about load times and that can be used in conjunction with images? So in terms of image compression, the latest thing that you can use today is the Avid Image Format. It is very well compressed. It's much smaller than WebP and JPEG. However, it takes much, much more CPU time to compress, which is another advantage of using Cloudflare Images. We'll have time to prepare Avid Format images for you. Apart from that, what I would recommend is looking into source set attributes in HTML and picture. We are compatible with that. We can prepare you appropriately sized images for use with those HTML attributes. But the bit of HTML, you have to do on your own website. So we provide pixels for you and you write the markup that pulls the pixels out of our storage. Yeah, and I think to the point of Avid, as Karnal said, Avid is a new format that can compress an image and make it much smaller than even WebP. The trade-off is that it requires a lot of compute, like orders of magnitude more CPU power to compress. So one of the advantages of using Cloudflare Images is both for us and the advantage that we can pass on to our customers is because you have the images stored and because we know how you're going to be transforming them, because you're defining it in advance as a variant, we can use, we can leverage that data and the architecture to use CPU power that we have left over and give you features like Avid in the future. So Avid is something to be super clear, not supported at launch, but it's something that we expect to launch in the very near future. The best part is you don't have to change anything in your implementation. When we support Avid, you'll automatically get Avid. Browsers that supported images that we think can benefit the most will be rendered in Avid. The second great thing about using images is you continue paying the same cost. So traditionally, if you had a million images and you create five different versions of them, if you wanted to support a new format like Avid, you would first go into your code base, make a set of changes to generate Avid variants, and then you would run that, run some sort of a script to either generate the Avid versions at runtime when somebody requests an image or in advance. All of those things require a lot of engineering and compute work. You have to make decisions like, do I generate these variants in advance or do I do it in real time? If you do it in real time, you have to think about what kind of latency does it add to the processing time and the loading speed, at least for the first time that the image is rendered before you cache it. So those are all the little implementation details that we built so you don't have to worry about. So folks like Cornell and Greg and Yevgen can really put their heads together and come up with figuring out the best path forward so all of our customers can leverage without having to reinvent the wheel. I want to ask you, Yevgen, I know you were very involved with sort of the architecture of the images product, not just on the compression side, but really making it usable and consumable and getting the different parts like storage and variants to all work. What was kind of the biggest challenge you would say in terms of architecture that you spent a lot of time thinking about? Right. I think one of the things that you're learning at Cloudflare is that there is a lot of complexity in the system we're running and at the same time, it's not because of superstitious requirements. It's because we actually have a lot of different use cases for that. So one of the things that we early on wanted to double down is to come up with a solution for images that will scale and provide the customers the type of benefits that we expect will make it a compelling solution on the market. So we went through different phases of design discussions and we started with internal beta that helped us to settle on the solution that we were using at launch. And I think one of the benefits that we already have in place is that we have a quite powerful infrastructure with image sizing service. And this is a service that native at Cloudflare and run on Cloudflare Edge. So we decided that we shouldn't reinvent the wheel there. We should extend the existing functionality of this service with some additional requirements that will allow us to build Cloudflare images for scale. And at the same time, get it faster to customers for trial and get feedback and come up with new features. So I think that was one of the key decisions early on to build the images product on the technical side using the power of existing service. And at the same time, we did some interesting things on the reusing part where I mentioned this in the blog post I published today that not only we are reusing the service that runs on the Edge, we're using some of the implementation building blocks by using the same type of language and technology using Rust and workers internally. So we use those common parts on the Edge and on the core. And I described it more deeply on the blog post what exactly we're using and how it helps us to iterate faster. Got it. Yeah. I mean, I think Yevgen is touching on a really important point. So one of the biggest advantages that we have at Cloudflare that really helps us deliver a lot more value a lot faster to our customers is products like workers that our customers can use too. But what people might not think as much about is our teams use it extensively as well. It lets us move really fast and lets us deploy code that can be accessed from all of our different pops that we have all over the world. Yevgen, can you give just a quick overview of what are the key products apart from workers and imagery sizing that is being used in Cloudflare products that really helped us in implementing Cloudflare images and building a product and shipping it rapidly? Right. I think it's a lot of questions inside of one. What actually helps us to iterate faster is the collaboration that we get out of other teams working hard to deliver a system that we can rely on. So it's a whole data pipeline that powers all the analytics and building infrastructure at Cloudflare. So it allows us to reuse some of the components and approaches that will be shared among different teams. So we actually get a great help from a data team to set up this properly and in a very, very fast time. So that's a huge help for us. At the same time, we have, yes, quite a lot of help from just discussion with the cache team, for example, how we can integrate our images product on the caching side of the things that will allow us to build it with the feature sets we expect it to do. One of the key things that we implemented is that how we can keep our images up to date all the time, even when, for example, some of the product requirement changes, like definition of the variant changes on the edge, or like a customer decided to change the definition of the resizing options, what should happen at this time. We should basically invalidate all the information on the images that we already cache at the edge and in the shortest time possible. So we made sure that on the edge, we're caching it in a way that allows us to purge those data very fast and efficiently. So that's one of the key takeaways that we collaborate with different teams to come up with a solution that will solve the product requirements for us. Another advantage that we have is our network. So it's important to actually deliver those images very quickly. And for example, we've done a really good work on H2 prioritization. So all the JPEG images are progressive and delivered very quickly to render as soon as possible to take advantage of the progressive rendering of those images. It all works together. It's awesome. So I'm gonna go to you, Greg. I know you joined, as you shared with the audience, Cloudflare not that long ago. And what was your experience like working on images in the last few weeks? Yeah, it was pretty fast and furious for sure. And so, like Yevgeny had said, there was a beta earlier this year, which really helped sort of specking out the product requirements and everything. So when I joined, we pretty much had that set up and figured out. And it was just a translating those into the product that solved the problems we'd identified and figuring out sort of how to design the system that did that. So yeah, it was pretty rapid and a lot of very fast iteration on the APIs and then the front end UI, which is what I predominantly worked on. But it came together for the launch that you're seeing today. And I think Greg is being very conservative in sharing what he worked on. I know that in working with you on the UI, often you brought up really good questions about the customer experience and ultimately it influenced other parts of the product, like the API. What was your experience like working with that whole discussion with different teams, like the design team and the people working on the backend? Well, exactly like you said, it's a big mix of all of these teams. So PMs, yourself and Rita, have had all the discussions with the customers. And so you have the perspective of the problems that they're trying to solve, but the designers had input on how users should actually be interacting with the UI and how they can keep the mental model of like an image is designed this concept and a variant is this other concept and how we keep that distinct. And then really getting into this nitty gritty of how do we best explain how we're doing access control, for example, like our images, you can set them to require signed URLs and how do we best explain that in the UI? And so we have iconography and all this sort of stuff scattered around to try and help guide the users or through using Cloudflare images. And then interfacing back to the API, it was just a case of these concepts meeting the definitions of what we even call these things and how does that affect the data structure when we present it in UI in a specific way? So it did sort of all mesh together from their different perspectives. That's so important, right? Because UIs can change, but APIs are very expensive to change, right? You can't just change the label, the property in an API as easily as you can change the label in a UI. And I think that's where the questions that you would pose, why is this property called this and how is the UI going to be consistent with the API? I think those were questions that I found very useful and they came up again and again and made us go back to the whiteboard and really get on the same page. Because if the UI says one thing and the API says something else, generally that's a problem. Absolutely. And you're right, it maybe was more work to change something in the API than it is the UI. But for images, which I think it's fair to say is going to be a predominantly developer focused product, the API is probably going to be primarily consuming it. So it's really important that is a first class citizen of the product and we treat it such. And I think it's good that we spent the time to develop it as best as we could so that everything was consistent, like you said. Yeah. And in many ways, I always saw someone in your position as customer zero of images because you're using the API, right? And you are building a UI using the API, many of the APIs that are public and you would raise questions and I would always put my, I'm talking to a customer hat on and say, well, these questions are valid for what we are trying to build. The API is inconsistent or doesn't really map to the mental model that we are trying to achieve or deliver to our customers. I wanted to plug two things that as a developer driven product, we have docs at developerscloudflow.com specifically describing how to use the product. And we also have all the APIs we use for building the UI, like the APIs for images that power our UI. They're all publicly available at our API.cloudflow.com as well. So please give us feedback and we are ready to iterate and extend things that customers will want to see. Yeah. On that note, I'm going to, I'll do a quick screen share and kind of share the different resources that our customers have available as they're considering building something using images. So as Yevgen was saying, we have developer docs that really give you, walk you through the API. And then we write developer docs. We write from the point of view of your outcomes that you're looking to achieve. For us as a company, we love implementation details and all the different technical terms. But what we really try hard to do as a product like images is made for a customer that understands those technical details, but doesn't necessarily want to be, want to engage with them in shipping an MVP or a new image pipeline from their in-house solution onto a vendor that they can count on for the next 10 years. So really when you go to Cloudflare images, the docs, you can find sections on how do you upload images, resize images, and serve images. Rita and I really think a lot about it because at the end of the day, we believe that the best products have a few core features that you should be able to just explain to people. If you start using technical terms, then you're really talking about the technical terms and risking losing sight of the overall problem. The overall problems are problems like how do I handle accepting millions of image uploads a day? How do I handle delivering these images to millions of people who request tens of millions of images? That's the level that we think our customers want to engage. And we'd love for you to play with the API and give us feedback, but that's our perspective. And we build API and developer-friendly products, especially products like images and stream. It's really focused on helping you deliver outcomes. So you can focus on what makes your app special and not so much worry about how do I optimize images in the most efficient way possible? Because those are generally solved problems that people like Cornell and the Afghan are in a really good position to build products around and so you don't have to reinvent the wheel. We also have, so when we launched beta, we didn't have a UI. So now when you log into your Cloudflare dashboard, you will actually see images listed, which you can click on. Images cost $5 a month to get started. And for five bucks, you can store 100,000 pictures each month for $5 and you can add additional blocks and blocks of 100,000 images. The best part about this model is you don't have to worry about how your cost will increase as you create more variants or different types of variants, whether it's AVIF or JPEG. You don't have to do all of that mental math, which can easily take your focus away from the heart of what makes your app, your business special. The way we build, we simply charge you for the original images that you upload. The variants, there is no additional charge. The types of variants, JPEG or AVIF, there's no additional charge. And again, I want to remind that AVIF is something that we plan to support in coming weeks. But whether your file is 10 megs or 5 megs or 500 kilobytes, you pay the same rate, no additional price for resizing.