 Okay. I hope you can hear me. Thanks for joining this, this webinar that I have decided to call climbing the ladder of abstraction. And what I'm planning to do here is to give you a glimpse or some insight into what I think, where I think the future of cloud native needs to go in terms of the developer experience and how we empower developers. To move fast, but with predictability and, and while reducing costs. This brings applications to the cloud as quickly as absolutely possible, but without risking the business or risking your jobs or risking, you know, getting gray hairs and losing sleep over it. So let's get started. We all want to do more with less, you know, we want to, you know, move faster in general, but faster time to market shipping applications to our developers as fast as absolutely possible. You know, often, you know, they both the users demand that in terms of more features and we, you know, the business usually demands is in terms of keeping up with competition or staying ahead of the competition. But it's easy to move fast and break things. What we also need to do is ensure that we do this in a cost efficient way in an energy efficient way. There, there's sometimes often the same thing but not, not quite. And also do that, you know, while making sure that what we're building can be run and operated in a predictable fashion and the code that we write can, you know, can be can have repeatability and reusability. Because because you're in if you're building an application you're in it for the long game. And it's usually, you know, if, if you build it the wrong way, so to speak. Then it's, it's, it's very easy to end up with a big bowl of mud and that gets more and more costly to to up to to move ahead, you know, to up to to both in, you know, evolve over time but also operate over time. So, all of these things matter, I think, and it's, we've been, we've been getting, you know, quite far with in our industry, especially around cloud native infrastructure, the last years cloud native infrastructure is actually amazing. It's nothing short of amazing it's very easy to take it for granted but you know me that's been in, you know, around, you know, around the lock, a few years, you know, 20 years or something at this point. And it's, you know, when I when I think back how we how we try to move like movies, or, you know, develop applications that do today what you can do quite fairly easily in the cloud, you know, it, it has drastically reduced, you know, the burden on developers and developer teams. It's easy to take it for granted and it's almost hard to remember how the world looked before we had containers before we had things like Kubernetes and the, and the great infrastructure, or ecosystem I'd say around Kubernetes, you know, all the things that you have in the CNCF as well. And of course outside the CNCF as well not everything interesting happens there. But, but the problem is that it's, it's not all good. It's, it's has been, you know, increasingly it's been growing increasingly complex, I think, and we are to some extent you know drowning in complexity. And I think there's there's something that we need to address. And there's hope, I think I will try to explain what I think we need to do. You know, the big problem, the, you know, the, the main problem out of many problems I think is that the options are just overwhelming. There's too many decisions that each team need, need to take to move to the cloud. And this, this image here is taken from the CNCF website, you know, they call it the landscape. And it's extremely impressive. And there's so many good, good things here each one of these products individually are great. Amazing. But the image itself, honestly, it reads almost like a joke I mean if you come into this new how could you possibly navigate this how could you know which product you should pick, and how to stitch them together into single you know, coherent consistent workable system that you know lives up to the guarantees that that that you need. The efficient is very hard things usually break at the edges and ensuring that you guarantee what you need for your customers while navigating this landscape is very, it's very, very hard. And usually comes back to buy to a lot of a lot of companies, some of them have have, you know, moved to to platform engineering where they have a dedicated team, building out an internal developer platform, you know, an IDP to developers from all of this complexity and that's that and that's and that's great I think that's the really a step in the right direction I'll come back to that later in this presentation. Stephen a great at red monkey, you know he wrote this paper called vertical integration the collision of the platforms and database and, and you know one, one, one quote here that I think is very, is very true and says the stage you're not very well for what I'm going to want to talk about here is is this one where he says that there's, there are already too many primitives friend in years to deeply understand and manage them all and more arrived by the day. And even if that were not the case there's too little upside for the overwhelming majority of organizations to select implement integrate operate and secure every last component or service. If you spend managing enterprise infrastructure is time not spent building out your own business. You know, many are stuck with an enterprise stack that they have to build and manage and operate and evolve themselves. You can easily grow quite quite complex. This is actually probably a simplified architecture here but here you have you know everything from load balancer ingress router caches. You know, add the app logic and the framers or libraries you have there you have vent brokers databases often many of them depending on the type of use case that you have that that that you have. It becomes increasingly hard, you know, and this pay this, you know, piece of this image completely ignores everything you need to do to run to operate it well, which is also, you know, a quite different story that that has a lot of complexity to it. So to sum up, it's usually very, very hard. And, you know, I remember when when AWS Lambda came out, you know, and that sets a stage or it was the inception of observe observe less it was, you know, I think serverless is really revolutionary it sets. It really points towards the future. So the way I think about things is that serverless is not a product is not a specific technique or way of doing things even it's definitely not fast function as a service that was the first incarnation of serverless. But I think it's it's a developer experience is a new way of thinking about the cloud and how to how to develop for the cloud. And, you know, I, so I really think that it was it was a seed for a new way of thinking how to develop for the cloud and something that we can continue to build upon with a with a common vision and goal in mind. And, you know, many cloud products have adopted serve serverless individually individually and there's databases their serverless there's serverless message brokers serverless caches serverless XYZ and that's that's that's great but it's it still leaves developers with a complex integration problem project because even if all this the serverless or all these API some products or serverless individually by themselves, the whole system as a whole is not serverless. You still need to stitch things together and making sure that everything works. And often these these different products has not, you know, been been been tested to work well together. So, and to ensure guarantees SLAs correctness of your data, etc. It's still falls into the lap of the developer, which makes this quite hard. Even though I'm not saying that it's a bad thing that more and more products adopt serverless but it's just one step towards where I think we need to be. So some words of wisdom here in Alfred North Whitehead, you know, have a famous quote that I think very much applies to soft to our software industry. And and and you know he said quite some time ago now that civilization advances by extending the number of important operations, which we can perform without thinking of them. You know, let that sink in a little bit, you know, you know, what is really saying that is we need to yet another time, you know, think in terms of higher level abstractions and automate more in order to move fast in order to advance. And a lot of people talk about cloud as the new computer. That's great and it's sort of a good analogy. But if I should take that analogy, you know, you know, one step further than the problem is is if the cloud is our new computer. The, you know, our problem here this is that we are as developers are expected to serve still serve hack the kernel, or write device drivers, you know, you know, the analogy here that we are expected to work at a very low level in this new cloud computer. And that is not sustainable, by any means. And you know, great boost tweet to this a couple of months ago, where he said that the entire history of software engineering is one of rising levels of abstraction, you know, thinking about how we got to where we are today, you know, starting between, you know, the rise of great operating systems like Linux, Unix, etc. And, you know, building up those I stack, you know, politics and, and things like virtualization in hypervisors that led to, you know, containers and machines like the JVM and then eventually, you know, we have no Docker and, and Kubernetes. And the same thing with languages, you know, I mean, I started my days writing machine code or assembly. But you know, then we got C and then C++ and beyond and today we have very high level languages like Java, Scala, Kotlin and Rust, etc. And it's not and it's not stopping here. We should continuously sort of climbing this ladder of abstraction and I think that we in terms of cloud native, we should continue doing that, you know, we should not rest, we should continue pushing forward. And there's, you know, there's light up in the, you know, as further we get into this ladder of abstraction this picture was actually taken by my son and I so I thought it was quite apt for this for this slide. And in order to do so, you know, I think we need to let go of control. The thing is that we as developers were used to control, we're used to be able to have every single knob under our fingers and that gives us power, you know, we feel enabled by it and, and it's, it's sometimes very useful. But I think we reach such a maturity today in terms of the products that it's, it's okay to delegate. We should have the trust to delegate the law, you know, because as the more we can delegate the more we free up time and energy to focus on core business value, which is a good thing. You know, so, so that's something that I, you know, that I will like every developer to think a little bit about and what are the things that I absolutely need to control, and what are the things that it's okay to delegate. And, you know, the last years we move we moved from self managed on premise, where we as developers had to have to own and manage, you know, everything in the whole application stack in the whole infrastructure stack everything from code frameworks database to this transport security Kubernetes operating system virtualizations down to the service storage and networking. And, you know, a lot of great things were built with this stack, but it takes time, a lot of time and energy and it puts a lot of the, a lot of risk, you know, at the foot for the business, which is why we, we got, we got the cloud in which in which we were able to delegate not all of the infrastructure meaning Kubernetes operating systems, you know, the tool supporting operating it and managing and so on the way down to service and storage and networking. But we as developers still need for the most case in the traditional cloud stack, just to continue owning and maintaining the code the frameworks the database, you know, the transports and the security. So what I you know what I think that we should do is try is to enter a world where, where the infrastructure is automatically inferred, or generated from the code. You know, it's where the thing the only thing that the developer needs to care about is the code, the code is king, you know, that's where you define your, you know, the business logic, you know, you're how you should interact with the rest of the world through or, or, or, or other other protocols, you know, you define your, your, your data model, you define, you know, the SLAs and constraints and so on and from the code, we should be able to generate everything else, you know, really liberate the developers to only focus on pure business value that moves the business forward. So, back to this picture, do you remember this picture in this in this sort of new world where I'm trying to paint here. You know, we actually don't need any of these tools, we need them, but you don't need to see that, you know, the developers should only have to focus on writing the code, and the rest is generated. And the platform should assemble the right products in this in this in this in this, you know, a cloud native landscape picture and beyond of course because not all products are here this is just an example. But that will just double really liberate developers. The question is then how can we how can we how can we do that, you know, no, Timothy Keller famously said that freedom is not so much the absence of restrictions as finding the right ones, the liberating restrictions. The question is here there. You know, what are those liberating constraints. If we should embrace the constraints, you know, we need to find the ones that are truly liberating. And, you know, I, in order to find these, you know, I've been thinking a lot about this from from a developer programming mall and developer experience perspective and I think, you know, we need to look at three things, you know, if we if if I try to distill the ultimate cloud programming model, at least for me and for you know, discussing this with a lot of people, we ended up with with three things that developers can never ever delegate that you know this is sort of the top in the stack and that is the first the API. How do I, or do I do my system rather communicating coordinate with services, you know, between each other, and to the outside world. And the second one is defining the data model, how do I model in my business data, how do I model by my business, you know, using things like DDD, you know domain driven design ending up with a domain model that that everyone can agree upon and that can do as well, you know, meaning the structure is constraints, what kind of guarantees I need into we know when it comes to, you know, the cohesiveness of the of the of the of the each each service or how they operate together in terms of you know workflows and things like that. And also the career model how do I query them are the data in a in a in a like, you know, systematic and and structural way. And finally the business logic, how do I work on that data how do I mind intelligence act and operate on this data how do I think like transform down sample relay and trigger side effects on it. And what is this business log how do I write my best log in a way that actually moves the business forward. You know, and of course all of these three API data data model and business logic or are closely interlinked force, however distinct distinct things. But I think that apart from these three things, the rest should should actually actually be able to be automatically inferred meaning automatically generated and fully managed by the underlying platform. And this is what we've been having doing with calyx, you know that's the vision that's been driving calyx is to build a developer pass the platform as a service for building API is for building micro services for building, you know, cloud native applications and cloud native systems. And so the leading, the leading principle principle here has been to have a guardrail hyper productive developer experience that eliminates as many decisions as absolutely possible, focusing on having the right constraints to set the developer. And you probably the listener here free to focus on on on on the things that really matter the things that really drive the business forward. This means that all infrastructure is inferred from the code, meaning that is zero ops, no ops, the ops is completely managed by the by the platform is fully serverless serve next generation serverless since it's not just it's not tied to functions and the constraints you have with function service but it's really liberated to build any type of application. And it's fully polyglot. So you can see you can choose whatever language you like meaning can be Java JavaScript TypeScript Python etc. And it's, it's, you know, calyx is building on the standing on the shoulders of giants of course I mean it's it's built on a lot of different products, but but but probably the one that does the most have lifting in terms of real time event driven applications is So it's fully reactive at its core to really ensure extreme low latency high throughput and being always available. I'm super excited by it. But if I should, you know, try to explain a little bit more what calyx does is, is, you know, if this sort of little, this is an infographic gives you a pretty good glimpse into it, you can actually go and find this itself I'm going to show you quickly. It's going to give you a sort of a map part how to read it before we dive in but this is available on calyx.io slash developer, if you want and you can interact with it as well. But at sort of the bird's eye view here is that everything about this line is this this blue line here is the developers responsibility. I mean the developer experience. Of course that's built by us but do you you manage that process, you work within it. The center is the code you know code is king here and and and and on the on the right hand side here you have the operate experience which is very limited of course because most of the operations are on on on calyx. But you know some things is absolutely necessary to do, of course, but what was interesting is that, you know, everything on top you mean that mainly the code is generating everything under under these line. You know, so so so under you know what is actually generated it's a fully auto generated reactive architecture, you know that is world class performance. You know, and it's fully reactive calyx implements implements all the reactive principles, you know how you have you have a, you have a like a 24 seven SRE operations team that making sure that everything runs smoothly at all times, etc. So, yeah, so. I'm going through this slide here I was just thinking that I should switch to the actual web page and see and show you a little bit more of the of the insights here I hope you everyone can see this. So as I said you know it's it all starts with the developer experience this by the way this one isn't interactive so I encourage you to go and look at this yourself I won't have time to go through everything. I'm going to give you a glimpse and because I think it really highlights what calyx does for you, meaning, meaning, meaning, being this, this system that that sort of infers or generates all the old infrastructure from code and liberates the developer to focus on the essence. So first we have the developer experience there, the only thing you need to do initially is to pick your languages decay mean Java JavaScript JavaScript and scholar for now we have more coming. You need to define your data model, your data model, write the servicing and configure it package it up and test it locally or on, you know, in your CIC CD pipeline that's it. Then you deploy to calyx IO and let calyx deal deal with the rest and the code you're right and look something like this this is just an example here but in this example we have we have. This is Java, by the way. You have you have a customer entity you simply tag it with entity type customer, you say that it will kind of entity it should be in this case we're saying okay so it's a it's a value entity is one of the of the different state models that we have the state models that describes the shape of the of the of the of the data in a way I mean it will kind of sets you know framework or constraints for for for how it's being managed by calyx and and what kind of expectations you would have on consistency and performance and things like that. So create your your records you know that's your data model this case we have customer and with name and email and create customer to different simple records and then we have one one one sort of endpoint here you can say we map it with an entity key. And we say okay this should be you know, from this we should generate an HTTP endpoint that's customer slash customer ID. And it takes a create a create customer command here and and simply run the side effects meaning updating the state creating new customer and then replying down. So so here you here you have a full API, including the data models you have, and the business logic for that it's not much business logic here you can see but you get the idea you can add that straight here. And you know very interesting take on query on on querying we have we have something we call views and view I mean these go in in in in in lockstep here. So so this this view sort of supports the data model that you have that you have here, a view is simply you know just another pojo you can say plain old Java big that you that you sort of annotate that's with a table that you're interested in in in creating. And what it should subscribe to in this case the customer entity that you have up here. And here I mean the only thing you need to do is then create this in this case this fine customers method and annotate it with the query that you that that you're that you're interested in here select star from customers were name equals equals and you can also create, you know, a public and end point here that will then create create service as a continuously updated stream. That will run until until you close it. So here is that this query is your domain model. Then we of course you generate sort of sequel and create a table at the bottom but under under underneath but you still think in terms of these data records and how you should query them. Not thinking about how it actually maps in terms of our mapping and all the relational mapping down to the actual database all that is removed for you. So really no code is required for data persistence and query, you know the data is automatically injected into a service on an ass needed basis. And, and, and you can, and then you can then clear them through these midline materialized views. So that's essentially the only thing that that the developer needs to do. Wrap it up and ship it up to calix and once you once you've done that you know you have you have a you have an operator experience that is evolving you know but but there's still there's already a lot you can do here. I won't go to in all in all the details here. I just wanted to show you know you know a little bit from what we then do with this code. What is actually generated everything below the line as I said, so first you have an auto generated complete reactive architecture, meaning, meaning things like you know we support HDP and your PC for for for your endpoints. We provide an ingress router we have we have full service mesh you know we have all the security mechanisms that that's fully tweakable. And of course, we, we, we bring in a cluster sharding here through the side, the sidecar pattern. You know, you have you have a calix sidecar that sits right next to your user code, all deployed into the same Kubernetes pod. And all of these sidecars, you know, first, you know, that, you know, service, it sits as a proxy for everything in your in your user code and acts as your user code, you know, in a way, by, you know, intercepting all the requests, managing all the data on behalf and sort of injecting it into the user code whenever there's an update, and so on, and, and all of these sidecars you know form an ACA cluster to making sure that everything is replicated wherever needed you can shard it appropriately, and it's fully highly available, etc. Alongside here we have we have we have different ways to do pops up first we have broken list pops up that you know that's extremely fast and, and, and extremely low latency over grpc. But, but if you if you need to work with with external systems or we just prefer to to run everything over Kafka, you know, Google, Google cloud pops up or a, you know, SNS or, or something else, you know, then you can plug that in here. And everything runs on, you know, highly available distributed storage, where we where we provide you know really good mechanisms for both the event logging, and, and, and providing these, these, these, these streaming materialized views, as I talked about the the the the the the, the, the stakeholders that we currently support our event sourcing key value, which is a good way to start and CR and CRDT stands for conflict conflict free replicated data data ties which is a really good way to coordinate state in the distributed system, but they're all abstracted in a way that makes it you don't need to know the nitty gritty details of all of these things. You know, so one of the benefits of running it on a car and, you know, having our, you know, amazing team build this and run this is that you get really unparalleled performance, you know, we have we have down to six, six millisecond for reads and eight milliseconds for rights, which is quite amazing for being a completely general and not not a purpose built system. We have 99.9% uptime and, and, and, you know, there's a lot of customers saying that we have a three three x faster development, some actually say more. So, you know, there's, there's in this diagram also, you know, have laid out the runtime execution of the service won't go into details as I encourage you to look to process at your own pace. But you're taking that code, those two, the entity and the view and a little and showing how it's actually running through the, you know, the architecture that I just showed showed you in the beginning. You know, Kaliq's implementable reactive principles, you know, something you can look into if you haven't looked, if you don't know what reactive principles are, you know, you can go to record principles.org and read, read more about it just really good, a good sort of set of framers for for building truly scalable and reliable distributed systems, you know, like, like, like cloud systems and edge type of systems and so on. And, you know, one of the most important aspects of Kaliq's is of course that we run it for you. Everything is fully managed by our 24 seven SRE team. And, and, you know, it's easy to, to, to not really understand everything that an SRE team has has to do today. And so, you know, these are just some of the things that they do on a day to day basis, in terms of making sure the only infrastructure is up in automation, patching networking firewalls, you know, DNS service measures and make sure the SLAs, you know, databases observability, you know, et cetera, security, of course, and the integrations working as they should, you know, the handle between the different systems is as they should, et cetera. And, and also, you know, making sure that we are a SOC to DDPR compliant. We also have big, big plans for Kaliq's. It currently deploys to AWS and DCP locations, but we're currently working on Azure. And even, even, even more excitingly, at least, I think, you know, being a geek is that, you know, it will all run on Aka Edge very soon, which means that we will roll Kaliq's out across the whole globe in edge locations, which we really will be a way to, to fully, you know, execute and implement this, this vision that I had for a long time, you know, that the cloud and Edge are really the same thing. You should just deploy into this fabric and the things run wherever they should, which might actually change depending on access patterns or usage patterns and so on. So it's a lot of interesting things coming. So this, I just want to give you a glimpse of this. We've been getting quite far in how we're implementing Kaliq's and I'm super excited about it too. So in, in, in, in summary, you know, we all need to do more with less, you know, faster time to market, you know, beating competition, ensuring our customers are happy, but we need to do that while managing cost, while managing resources, you know, both harder resources but also human resources. And of course, everyone wants to be, you know, climate, hopefully everyone wants to be climate friendly and care about the environment. So the energy costs is a really, really important piece of this. The problem though is cloud development has been too complex, you know, we need to find a way to continue to yet, yet another time in this, in this, in this industry, you know, climb this ladder of abstraction, another step or two, or three, perhaps, you know, ideally. And I think it's about time that we find the next cloud-nated developer experience, sort of less worth pointing the way, but I think it's, it's, it's stopped in each, in these tracks a bit. So, you know, pick up on that vision, again, move to the next step. And I really think the way to do that is have all the infrastructure really generated or inferred from the code, avoiding, you know, getting into an integration project and navigating all the complexity that we as developers have today. And Calix is here to help, you know, with this declarative, fully declarative, in some extent, and almost declarative in most other cases, you know, high level, super productive developer experience for building APIs and microservice or actually any type of cloud-nated application. Through a polyglot real-time and event-driven, event-driven is really the key, one of the key here, you know, fully managed pass. And of course, you know, in our DNA is to light-bed, you know, reactive is strong. And, you know, reactive means that are able to build systems that are fully resilient, that can self-heal, that are fully scalable and extremely high-performance, low latency, and high throughput, which is what we all want, right? I mean, we want to make the most out of the hardware and wish will, you know, as a side effect, reduce the hardware expense and also reduce, you know, energy. So it's all pointing in the right direction. So I encourage you to check Kalex out and let me know what you think. Both about, you know, where I think we should go, if you agree or disagree and have experiences on that, but also what you think we're doing with Kalex. I'd love to hear from you. You can find me on Twitter or you can just post it in the Kalex forum. Cool. Thanks, everyone. That was a quick walkthrough. It was on my mind every day nowadays. Yeah, I'm signing out. Bye.