Wing's Take on Cloud Development With Elad Ben-Israel

Transcript

Tiago Barbosa: Welcome to Page it to the Limit, a podcast where you explore what it takes to run software in production successfully. We cover leading practices used in the software industry to improve both systems reliability and the lives of people supporting those systems. I’m your host, Tiago Barbosa, and you can find me on Twitter at t1agob using the number one for the letter ‘I’. Hello Elad. Welcome to our show. First of all, let me start by saying that I’ve been a fan for many years. When I worked for AWS, AWS CDK was my favorite IaC tool and I’ve used it for many, many of my customer demos and all of the stuff that I created. Thank you so much for creating it first of all. For the ones that are listening in and don’t know you, can you introduce yourself?

Elad Ben-Israel: Sure. I’m Elad. I live in Tel Aviv, been writing code since I basically remember myself, I think. It’s always been really interested in software for some reason, way before it was a popular thing to be interested in. So yeah, about 44 years old, programming for the last 30 years I think almost. in our industry I had the opportunity to see the evolution of the PC universe and then the cloud and the internet, and I feel like there is some value in being able to take a step back and look at these patterns that are cycling and I worked at Microsoft and at Amazon and at AWS and my last role at AWS was to build the CDK, which was a huge privilege. I really love this project and the community that formed around it and it was built based on my pain, our pain building stuff internally at Amazon and at some point we were like, okay, we got to give this to customers because there’s no way we’re asking them to go through all this pain in order to build stuff. I was lucky enough to be at the right place at the right time and stars have aligned well and really proud of the project, really excited to see. We’re talking to lots of customers now and many of them are using the CDK, which is amazing, right? It’s really, really fun to go to a customer and basically see they’ve built a whole stack that uses the CDK and they love it, and so…

Tiago Barbosa: It’s great to see something that we created being used by so many customers in so many situations. It’s definitely interesting.

Elad Ben-Israel: And it takes years, just takes a long time for these things to grow and evolve and mature and figure out the right place, I guess. I feel like that’s one of the things that I keep reminding of building something like Wing, which we’ll talk about that patience is really important. It’s really important to give the organic dimension of this engineering process to happen.

Tiago Barbosa: Yeah, definitely. And that’s exactly where I wanted to go next because you worked on the CDK, but you didn’t stop there. So Wing is, I would say tackling similar challenges but in a even more complex way because it works not only for AWS as far as I understood. So can you explain a little bit about Wing and what challenges you’re trying to solve that weren’t solved by existing tools such as CDK or Terraform or any other?

Elad Ben-Israel: The way I see Wing is kind of like the next evolutionary step from the CDK, so it’s not like tackling the same problems, but it’s basically trying to tackle a bigger problem in a sense. And Wing is using the CDK under the hood and actually interoperates with the entire CDK ecosystem, so you can use CDK constructs and libraries and so all the good stuff that we built at AWS. To me, the thing that was always missing with the CDK and I feel is also missing with other IaC tools is that it basically looks at only part of the picture. When you’re building applications that are deployed to the cloud, you obviously have a lot of infrastructure involved and more and more, right as we’re leaning more on the cloud and using more cloud services, then this part of your application is more complex and you need better tools and the CDK is a tool that helps you manage that complexity, but there’s also your application code. There’s also the part that actually implements your application logic that runs on reacts to events and performs stuff and CDK has always had this glass ceiling, right? Because we were confined to using or not confined, we decided that we’re going to basically support all existing programming languages or popular programming languages. Then we took upon ourselves the constraints of these traditional languages and the basic constraint of most languages is that they assume that everything is running inside a single machine. That’s actually a pretty strong assumption. Almost every popular programming language out there, like when I’m calling a method on an object, the compiler assumes that this thing is happening in memory and the rules and the way the compilers work. They basically, they don’t understand the fact that when you’re running on the cloud, you’re running inside a distributed system and your application is actually distributed across multiple compute elements and infrastructure resources. And so what we’re trying to do with Wing is basically say, let’s take a step back and imagine what would it take to describe a cloud? What would I need as a developer in order to describe a system that runs on this new type of computer called cloud? And in a way it comes down to this combination of infrastructure and application code combined together. Is this, combining these two together is what makes cloud application in a sense. And so that was the glass ceiling. We couldn’t have figured that out and we’ve tried, to be honest, I don’t dunno if you’re familiar, CDK has some higher level, we call ‘em L2.5 in the CDK. NodeJS function and Python function and Go function and just trying to reduce this barrier between infrastructure and application code, but eventually, because these are two different runtimes, right? The code that compiles your infrastructure and synthesizes your infrastructure is your CDK program and the code that runs on your cloud is, I don’t know, a NodeJS runtime on your Lambda function or a Go runtime on your container or whatever. These are two separate worlds and the fact that they’re separate makes it really, really hard for you to reason about the entire thing and makes it hard for compilers and the tooling to reason about the entire thing. And so that’s one of the things that we’re doing with the wing language is the language. So that’s one side of it. The other side, the CDK has never tackled in a sense is what is the right abstraction for developers? In a way, the CDK comes from AWS. AWS’s target audience is infrastructure engineers, right? It is basically AWS started from bring me your computers from the data center. And so in the DNA, the engineering DNA and the DX DNA for AWS has always been very kind of like IT ops, DevOps centric and eventually when you’re thinking about, and that’s actually one of the blind spots Amazon has, I feel when they’re, they’re designing these solutions because internally at Amazon there’s no such thing as a DevOps engineer. Everybody is just an engineer. It works really well for, Amazon works really well for AWS especially because when you’re at AWS, you’re building infrastructure systems and so obviously all of the engineers need to understand how VPCs are structured and IAM roles are structured, but when you go out of the industry you’re like, okay, I’m going to Fiverr and Fiverr are building an application. And so the developers that work at Fiverr, their problem domain is matching workers tasks and customers. These are the problems that they’re trying to solve. This is the model that they’re building in their application. It’s not about IP tables, it’s not about VPCs, not about IAM roles. These guys, they need to focus on that problem. And so you go to Fiverr and you end up and you talk to them and they’re like, well, we can’t bring in new engineers to the team. It takes us six months for them because they have to go through all the training to understand all the stuff that’s related to how AWS is structured because they can’t, even if they’re using CDK, they still need to understand all of the details of the platform. And so this decoupling between platform and application is something that we’ve never tackled in the CDK intentionally. We were like, okay, we’re creating an API for AWS, but when you go to the industry you’re like, this is actually not good enough because developers do need to be able to work at a higher level. They need to be able to think about their problem domain but still use the cloud. And so these are the two main things that we’re trying to solve with Wing two pretty big challenges I’ll say.

Tiago Barbosa: Yeah, I do agree and it’s not only a technical challenge like you were referring to, but I think it’s also a cultural challenge, right? Because we have been for many, many years we have been thought to decouple all these different, as you were saying, infrastructure is one thing, then the code is another thing. I have separate teams that tackle these. And so are you seeing any pushback in the companies eventually that are working with Wing at this point in time? Are you seeing any kind of pushback because it doesn’t fit how teams are structured? Are you seeing that?

Elad Ben-Israel: So I actually think that Wing fits much better to how teams are structured than the CDK because of this decoupling that Wing introduces right? Wing is actually saying, you know what? The fact that you have a platform team and an application team, that makes total sense because the platform team is responsible for the platformic components or the security and the compliance and the deployment and the costs, and there’s a bunch of things that are at the platform level and the application developers are responsible for the application. So this decoupling is actually something that I feel is more compatible with how organizations work before the cloud than what we’ve been trying to do with the CDK and I think kind of some of what Amazon’s trying to do or the way Amazon thinks about how you should build on the cloud. The problem is that, and that’s definitely a challenge that we’re trying to crack in a way, is that today a lot of companies I would say we’re attracted to use Kubernetes because of this decoupling, because Kubernetes is actually perpetuating this delineation. In Kubernetes you have the platform, you have the cluster itself and everything that you set up on the cluster and then you have the application. And the application is the containers that are running in the cluster. And so in that sense, Kubernetes is way more compatible with the traditional model that we use in IT before the cloud. What I’m trying to say is that this is not good enough because in this model, developers are not really empowered to use the cloud. They’re containerized. Their world is everything that’s just running inside the container. And so if they need a queue or a bucket or a topic or a static website, that’s it, right? It’s out of their responsibility. They have to go to the platform team and figure out how to get that resource and provision it and provisioning in all the environments and how to develop, how it has it worked with the development experience. It’s just completely foreign to their world. And on the other hand, the platform team, which supposedly is responsible for this platform, they end up having to be responsible for a lot of components that are part of the application. This queue or this bucket, they have a functionality that they serve within the application. And so that’s what we’re trying to do. We’re trying to say, Hey, this decoupling makes sense, but the line is actually not crossing at the right place instead of crossing at the container level. There should be some layer where applications can be built on the cloud without having to become DevOps experts or become infrastructure. You see what I’m trying to say? And by the way, in the serverless world, it’s almost the opposite. The line is too low in a way, and so you see developers having to own the VPCs and the IP tables and there are subnets masks and the routing in the Route 53 zones. And so I feel like this is our challenge is how can we create this boundary in the right place?

Tiago Barbosa: Yeah, exactly. I really feel so as a developer myself I always, at least when I started my career, I struggled to identify or I didn’t have a lot of knowledge on infrastructure side of things to be honest. And so I forced myself to learn because I really depended on it. I thought I would be a better developer if I understood slightly, at least slightly better where things would run, but I wouldn’t of course necessarily be the one deploying the applications every single time. But it definitely helps. I really see your point where developers want to deploy their applications. Of course there are some basic knowledge that they need to have, but it needs to be a higher level and finding that balance is really interesting, and I really like the approach that, well, some of the conventions that you brought into Wing things, the pre-flight and the in-flight for functions. It’s actually pretty interesting because so as someone like me used to use the CDK, the infrastructure side of Wing is pretty straightforward, but then you have this right and this is something that allows me to write the code that will run inside of the function as well. And so this is pretty cool. Is this concept basically trying to be the glue between the infrastructure and the code that you were mentioning already?

Elad Ben-Israel: Yes, exactly. I think if there was one thing interesting about Wing as a language is this concept of pre-flight and in-flight. And it’s exactly like you said, this is the glue that connects the infrastructure in the application code together, and we actually have this concept of lifting where you lift objects from pre-flight to in-flight, and the compiler has heuristics, has logic on how to do this. So for example, you can refer to static data super naturally when you say, okay, I have some string in the preflight world, I can just refer to it in the in-flight world, it’s just referring to the string. Practically, it’s not trivial, practically actually need to bundle this string into the code that’s going to run on your container or that’s going to run on your Lambda function. There’s some mechanics that need to happen in order for this stuff to happen, or you’re referring to a file or to an array of strings or an array of primitive data or static data. And even this simple, allegedly simple capability is really, really useful because I don’t know how many times have you tried to share values from the infrastructure side to the application side? I’ve seen people do horrific things to do that. And so this is the basic mechanism, and then the other part of this is that you can actually lift pre-flight objects, so you can actually lift a bucket, and when you’re lifting a bucket from pre-flight to in-flight or any other custom resource that you create, then basically wing gives you access to the in-flight API of that object. And it also allows this object to bind itself to your runtime environment, which means, for example, that it can automatically generate, IAM permissions for you because the compiler basically sees this relationship and says, oh, you’re trying to put an object into the bucket. Great! What does that take to do this when you’re compiling to AWS, for example. And then the bucket says, oh, I need these and these permissions in my IAM policy, and then you get an IAM policy that has exact least privileged permissions based on the interaction between your inflight code and your pre-flight objects. And so it’s a very, very powerful mechanism. It’s also really complex. We’ve been iterating on it for a year and a half already. I think we’ve gotten to the point where it’s pretty solid and it won’t surprise you. There are still things that are not working out of the box. For example, there are situations where the compiler can’t qualify the lift. It can’t determine exactly what you’re planning to do. Let’s say you’re calling a function, the function returns a pre-flight object, and then you don’t know which pre-flight object was it. And so you can say, oh, well this is the bucket that you need to add permission. Eventually there’s a bunch of things that you actually need to execute the code in order to understand. And so we’re adding some capabilities to make this explicit, but it’s actually really beautiful. I’m super proud of it, and sometimes you use it and it’s so natural and you forget what’s going on behind the scenes. Super cool.

Tiago Barbosa: Yeah, that goes back to what you said initially, which is that the compiler or most programming languages assume that you are running inside of the same laptop or the pc, right? But that’s, yeah, same machine, but it’s not the case. So as a developer, you’re writing basically the code in the same file, but then kind of maps to different resources, and that’s pretty cool. So yeah, high hopes for this one because it really solves a big problem. As you said, I’ve done this in the past kind of sharing information. It always requires another external service that I need to maintain most times. So it’s very, very challenging. So one question that I have for you as well is, so this is mainly focused on say the developer or trying to improve the experience of developers while building their cloud applications, but how do you enforce standards? Well, you already mentioned when you create resources, it goes with the least privileges, I assume, in an automated way, which is great, but typically in larger organizations you have teams like, I don’t know, platform teams or the IT operations side of things that maybe they want to enforce some standards. This is something that you can bring into Wing as well, and how do you do that?

Elad Ben-Israel: Yeah, of course, it’s related to this decoupling that I mentioned earlier between the application and the platform. One of the keys to this decoupling is what we’re calling a cloud abstraction layer, which is the API for the application developer. And so when application developers build applications on Wing, they can use this cloud abstraction layer. They can actually, as I said, they can use any other resource in the cloud environment, but let’s say that they’re using this cloud abstraction layer. And so in a sense, you can think of it as, I don’t know if you’re familiar with POSIX or the JDK or the nodeJS API, so when you’re building applications on Node, you’re using the NodeJS SDK or the JDK or the .net framework, and so that’s your application development interface and this interface can be implemented and target different platforms. And so we’ve created this cloud abstraction layer and the mechanisms in the Wing compiler so that you can actually create your own platforms. And so this backend, the backend part of the compiler is completely pluggable, and so we are shipping a bunch of built-in platforms for Wing, for example, ones that compiles to Terraform in AWS, we have one that compiles to AWS CDK, Cloud Formation, and we have GCP Terraform, Azure Terraform. A lot of the stuff that’s done there is actually contributed by the community, but what we’re starting to see is that platform teams are able to use this platform layer to codify their concerns, their standards. And so I’ll give you an example of something that we’ve seen someone do. We have this resource called cloud.api, which is an API gateway, and you can define REST APIs with it. So you can say get/something post/something, blah, blah, blah, and you can specify the handlers and the default implementation in our TFAWS platform is to use API gateway and then a Lambda function for each route, which is pretty standard. Now, this team had an issue with cold starts, which is very familiar. And so what they did is they basically created a platform extension that implements cloud API using a load balancer and fargate. And the application didn’t change at all. The same application can run both on Lambda or on Fargate, and this completely eliminate cold starts. Of course now they need to manage the Fargate service, it’s ECS, whatever. There’s some trade off there, but the fact that they could do this without touching the application was really, really cool because I feel like it’s just exactly a good indication that something was right about the design of the abstraction at that level. And of course, we’re still pre 1.0, we’re still, this is a moving target in a way. We’re still kind of exploring a lot of these abstractions and we’re definitely going to get some of them, but the fact that we are able to decouple those things is super, super powerful. We’ve seen people use platforms to maintain standards such as limitations. They didn’t want Lambda functions to take up more than two megabyte or one megabyte. They had one gigabytes of ram, and so you can just write a check inside the platform and then when the developer compiles, they get an error. And so it’s a super powerful mechanism. These platform, we call them platform providers or platform extensions.

Tiago Barbosa: Okay, that’s good. And that’s also how you would create extensions to other platforms as well, let’s say. Yeah, you want to integrate with PagerDuty. PagerDuty! Yeah, so basically you can bring your own integration and you can have that logic.

Elad Ben-Israel: So that’s actually even easier. You can create libraries like NPM. We’re actually NPM as the distribution mechanism, but you can create Wing libraries. And so we already have a bunch of libraries. We’ve taken a pretty cool approach I think. We have this concept of trusted libraries, which is a repository on GitHub called Wing Libs, and people can just go to that repository and there’s a really easy way to add libraries to the wing ecosystem. So we basically said we’re going to do this big monolithic repository of all the libraries and we’ll see how much water that that’s going to hold. It’s really great to get started for sure. And so you can go to this repository, you can create a Wing lib for PagerDuty, literally just need one file in this directory. So you create a directory called PagerDuty. You put one file there, sorry, two files there. You need a Wing file and a package json file. If PagerDuty has a Terraform provider, which I’m sure it does, and you can use the Terraform resources for PagerDuty. And so you can say, if this is compiled to TF AWS or to TF, then use the PagerDuty resource and you can define the API and then you can also provide the simulator implementation, which we haven’t talked about the simulator yet, but anyway, it’s pretty straightforward to create something like that and then people can just do bring PagerDuty into their application. Bring is Wing’s import statement, so you can do bring PagerDuty and now you have PagerDuty in your application.

Tiago Barbosa: Yeah, cool. It’s probably one of the things, and I think we discussed this before, it’s one of the things that I really wanted to do while experimenting with Wing, so probably something for the future. Definitely. You mentioned the simulator, which is something that I had here in my notes as well, and it’s one of the coolest features. I’m pretty sure that every single developer out there loves it because it provides a UI, right? That’s the console, like the Wing, how do you call it? Wing console, right?

Elad Ben-Israel: Yeah, so actually the simulator is just a platform provider and we also have a tool called the Wing console, which is a UI that can run on top of the simulator, but you don’t have to use it. You can write Wing tests and run them in the CLI if you like. What we’re trying to do is we’re trying to create an experience that’s almost similar to the one when you’re building websites, when you’re creating a website and you’re running a dev server on your machine and you get this really quick feedback cycle and hot preloading and all that stuff. And so basically you get that for the cloud and the reaction time is basically seconds.

Tiago Barbosa: It also solves a problem that in my opinion, when you are working just with a single cloud provider, after a few weeks, months or years, you start to get used to working with that specific cloud provider. But when you are working with multiple cloud providers, I think having something that allows you to abstract the knowledge of what is a function and what is a bucket and all of that is really powerful. And also the fact that basically you can do this locally, I assume up to a certainly level of trust because you are not actually running in the cloud provider, but you can do this locally. From a developer experience point of view, it’s really good.

Elad Ben-Israel: We call this functional simulation. So basically it’s not a full fidelity simulation, it’s a functional simulation. And let’s say if we’ve managed to create solid abstractions, then the functional simulation is very, very valuable. If the abstractions are very leaky. Then obviously this is where things don’t work. But the way I’m thinking about it more and more is that I used to build, when I was in the Army, and actually when I was at Amazon, beginning at Amazon, I worked at Prime Air, the drone project, which was really, really fun, but I used to build stuff that’s running on hardware and airplanes and stuff like that. And when you’re writing software like that, then you are designing this software from first principles to run in a simulation because obviously you’re not going to go and fly the airplane every time you want to fix a bug, right? That’s not realistic. And so as a developer you’re like, okay, I need some abstraction layer and on top of that abstraction layer, I’m building my software and then I’m able to simulate the behavior of the platform that I’m running on. And I think that actually there are other engineering domains where simulation is obvious that you have to simulate, and I think the cloud is actually one of those. I think the fact that we’ve been kind of obsessing about developing with the cloud in the loop and testing with the cloud in the loop, I think that’s the wrong turn to be honest. I think that’s just not a good idea. I understand why. Obviously by the way, the first year of Prime Air, we did go and fly the drone every time we wanted to test this. We actually built this huge flying cage in our lab just so that we can fly the drone in order to be able to test our software. But then after a year of experimentation, you’re like, okay, this is not holding water. And so we rewrote our code to run in the simulation. And so what I’m trying to say is that I think the cloud deserves a simulator. It actually makes total sense. It’s not a dogmatic simulator in a sense. You can actually decide that certain resources are not simulated and they’re actually using the real thing or it’s not pure in that sense. It really changes the game in my mind. It just really changes the way your iteration cycles work and it changes the way you think because you don’t have to. I remember spending hours and hours writing CDK code before I go and deploy it because it’s taking 30 minutes to deploy. So I’m like, I better just get this writer the first time and then it’s never right this first time. Right?

Tiago Barbosa: True. Yeah, that’s pretty interesting. I never thought of the simulator like that, but with you for example of flying a plane, it totally makes sense and it also comes with a cost attached to all of this. So if you make a mistake, it’s not only the time that you spend waiting for the deployment, but you might end up deploying something that costs a lot of money. It’s also that part. You did mention, Elad, that you have community and the community plugins, so you have a GitHub repo where you have plugins that I assume are also contributed by the community. Winglang is an open source project, so I see the community is very active. Do you get a lot of contributions from the community at this point in time or are the integrations mostly done by you and the team still?

Elad Ben-Israel: We’re getting more contributions than I expected to be honest at this point because the project is still early. It takes time for stuff like that to mature. As I said earlier, you need to be patient because you need to flush out all the kinks despite the fact that it’s early. I think there are over 60 external contributors to Winglang already. We’re seeing a lot of people who are super excited about the vision and really like you say, this is how this should work. And so we want to be part of this, but we’re also seeing a lot of people just filling holes. I feel like because the surface area is so big, there’s a lot of opportunity to help out. And so we have someone who owns the AWS CDK target. AWS CDK is actually not a target that we maintain directly. There’s a community member that’s maintaining that and we’ve got people helping out with the GCP support and this Azure support. So that’s one area. And the other area is these libraries. And so we’re slowly seeing more and more people publishing these libraries with some really cool ideas. And it’s early, it’s just the beginning of this ecosystem, but it’s also really exciting times. I remember I’ve been around for the .net ecosystem when it started. I remember I was I think 19 or 20 or something like that. And it was really fun. I really enjoyed, again, if you’re an early adopter, it’s a really, really fun time to kind of be involved because you see how things are shaping up. Then I had the opportunity to do this with NodeJS, which is also really, really fun and amazing and with the CDK obviously. And so I feel like it’s, for me, it’s sort the most exciting time is when this is forming.

Tiago Barbosa: Yeah, yeah, definitely. And I think that the fact that you have a lot of people from the community interested and actively contributing just shows that you are going in the right direction I believe, and that they believe the vision that you are bringing to Wing. And on the vision side, I have one question for you, which is around Wing Cloud and the vision and your top priorities and goals for 2024. So if you could share or a little bit about these two, I would love it.

Elad Ben-Israel: So I think at the high level, the way we’re thinking about Wing Cloud and Winglang or the Wing framework, the open source side and the non open source side of this story is that the development experience, the local development experience, the simulator, the SDK, the language, all of that stuff is part of the open source story, but then the lifecycle of the application doesn’t end in the development continues with building, testing, deploying, operating. And so this is where we see Wing Cloud fit in. We also think that this makes more sense for people to pay for companies to pay for. And so everything that’s related to delivery and operations of wing applications is what we are calling Wing Cloud. And we’re really excited about continuing this layer. If you think about it, it’s like we’ve talked about this decoupling between application and a platform in the development phase where you’re able to build your stuff on top of this abstraction. And so think about continuing this layer all the way to production and operating your application at that layer as well. Because I believe in ownership, I really do believe that developers want to build and own their entire, the application across the lifecycle, but I don’t think the developers want to own their entire stack. And I think that’s an interesting distinction because the fact that you’re owning something across the lifecycle doesn’t mean that you have to own the server in the data center, right? That’s obvious that you don’t need to own the server in the data center. As a developer, that’s exactly what we’re trying to do. We’re trying to give developers the ability to own their entire application throughout the lifecycle without having to become a DevOps engineer and also allow the DevOps engineers and the platform teams to actually define the layers and say, this is the platform, this is the stuff that I own. This is the stuff that I’m responsible for. And so Wing Cloud basically takes us all the way from delivery to production.

Tiago Barbosa: Yeah. Cool. And for 2024, any goals that you want to share with us?

Elad Ben-Israel: I really, really hope we’ll get to Wing 1.0, we’ll get there when we get there. That’s what I say when people ask when, because I feel like it’s an organic process in a way, and so we can’t really say exactly, but we’re getting closer and closer and we feel like things are more and more stable, but there’s still ways to go. And we’re trying to be intentional about focusing on those aspects of the framework and the language that are papercuts that are not good. We’re trying to avoid adding too many new features and focusing on quality and bugs and stuff like that. So in order to be able to get there, so I really do hope that 1.0 is in 2024 and on the other side, we’re working way more closely with customers now, and what we’re doing with customers is actually something that’s really hard to do when you’re just picking up wing from the open source is migrating existing systems to Wing because obviously every system is like a little snowflake and we need to figure out the right way to do this. And so I’m excited to see this happening and I’m excited to get Wing into production for systems that are big and mature and that’s going to be really great to see That Wing can create a lot of value in those scenarios as well. And I hope that we’ll be able to generalize some of those projects and create some more tools for the open source community to be able to use. And so these are the two main tracks.

Tiago Barbosa: Perfect. Yeah, sounds great. You and the Wing team and the community as well, they have been doing a great job. Wish you all the best for the Wing project. Thank you so much also for accepting the challenge to join us today. I’ll continue to watch closely how it develops and maybe we’ll talk again in the future when you release 1.0. Thank you so much.

Elad Ben-Israel: Happy to. If I’d love to hack together, if you want to play together and build a PagerDuty library, then happy to help with that as well. Always fun.

Tiago Barbosa: Sounds like a challenge. Thank you so much.

Elad Ben-Israel: Cool. Thanks for having me.

Tiago Barbosa: Thank you. That does it for another installment of Page it to the Limit. We’d like to thank our sponsor PagerDuty for making this podcast possible. Remember to subscribe to this podcast if you like what you’ve heard. You can find our show notes at page to the limit.com and you can reach us on Twitter at pageit2thelimit using the number two. That’s @page it2thelimit. Let us know what you think of the show and thank you so much for joining us and remember on Eventful Days are Beautiful Days.