In event-driven architecture, each component of application logic emits events, which other parts of the application respond to. We have examined this pattern in previous shows that focus on Pub-Sub messaging, event sourcing, and CQRS. In today's show, we examine the intersection of event-driven architecture and serverless architecture. Serverless applications can be built by combining functions as a service like AWS Lambda, together with back-end as a service tools like DynamoDB and Auth0.
Functions as a service give you cheap, flexible, scalable compute. Back-end as a service tools give you robust, fault-tolerant tools for managing state. By combining these sets of tools, we can build applications without thinking about specific servers that are managing large portions of our application logic. And this is great, because managing servers and doing load balancing and scaling is painful.
With this shift in architecture, we also have to change how data flows through our applications. Danilo Pocha is the author of AWS Lambda in Action, a book about building event-driven serverless applications. He also works at Amazon Web Services as a developer evangelist. In his book, he discusses the connection between serverless architecture and event-driven architecture.
And we explore that here as well. We start by reviewing the evolution of the runtime unit, from physical machines to virtual machines to containers, and now to functions as a service. And then we dive into what it means for an application to be event-driven. We explore how to architect and scale a serverless architecture.
And we finish by discussing the future of serverless, how IoT and edge computing and on-premise architectures will take advantage of this new technology. Danilo Pocha is a technical evangelist at Amazon Web Services. He's also the author of AWS Lambda in Action. Danilo, welcome to Software Engineering Daily.
Hi, Jeff. Thank you for inviting me. It's great to have you because we are going through this transformation where cloud computing is going from the runtime unit from the container becoming the runtime unit of serverless or functions as a service. It seems like we've gone from virtual machines to containers and now we're going to functions as a service.
Describe this evolution as you see it. Why are we evolving in this direction? Well, what I've seen is that developers, they want to go faster. They want to gain more speed.
So I think this is what is behind these moves. So with little machines, everything you do, it's in a matter of minutes, with containers in a matter of seconds, with functions, it's even faster. You enter into the milliseconds range. And this is really the different where you want to spend your time.
So what are your interests? So if you want to do the fine tuning of the kernel of the operating system, then probably you need to run machines. If you still want to manage a cluster of application components, then containers with the management platform, they are great, of course. But with functions, you can really focus on the code that you write on what you want to build.
With virtual machines and containers, we have a stateful execution environment. We've got memory, we've got a file system. It feels like classic computing. How does our thinking about applications need to change, given the fact that we're going to serverless and in serverless, we have a lack of state because we're not addressing an actual box.
We're just throwing a function up into an anonymous blob of compute somewhere. Yeah, personally, I think stateless is good. It's a good architecture or pattern. So it's something that I would suggest even to people that is working with different architecture.
It's good for scaling and for availability, because it's much easier to manage the scaling of an availability of something that doesn't need to keep a state. And the state should be normally managed for a distributed architecture differently. So each service of, for example, a distributed architecture should keep its own state inside only if needed. And then you should think that since their architecture is distributed, things are different than with a monolithic application.
You should think of things like eventful consistency. So data will slowly converge into a final state. And also, you should build all the interface that you design if possible as it's important. So that if the same data comes again, then you get the same result.
So eventful consistency are probably two ways to overcome this limitation. When we're using serverless, that means that we don't need to care so much about load balancing or auto scaling groups or capacity planning. That's one of the sets of advantages that people have said in previous episodes, it is really valuable about servers. And serverless is, when we're talking about functions as a service, it may be hard for some people to understand, because it's like a paradigm shift where it's not pure upside, it's not pure downside.
It's just a different paradigm. And you have different advantages and disadvantages, help people understand what are the upsides and the downsides of moving to serverless. Well, the upsides, I think it's a set that you can focus on what's on the features that you want to build, not the boring stuff. You don't pay for idle, and you pay very little for some other workloads.
So this is fostering experimentation. So you can build a prototype in a way. So if you're a startup or even if you're a large company, you can quickly build a prototype, test it, and you don't have the impact, the economic impact of building something difficult and working. Running experiments is the only way to build something new, not to innovate.
And also, I think that's a big advantage in security, because security is part of what you build. It's your force to give permissions to a lambda function. You have to think about permissions, and this is different from when you start creating something locally on your lambda. And so as we have to make this paradigm shift, maybe you don't want to call it downsides, but it seems like there are some shifts in thinking that we're going to need to make, because we're not deploying our applications.
You're not writing a big Node.js application and deploying it, and then it just stays up and running for a long time. It's kind of a different world. So how does it contrast? What are the paradigm shifts that we need to make as we start to build in a world of functions as a service?
As you said, it's in your approach. So you need to understand it, so that you use probably a different mindset. It's a distributed architecture. So everything that runs inside functions, you can control, for example, the order of delivery of messages, you have to think that the availability is punished by the platform, but you still need to program how the logic flows, so what are the relevant events, where that should trigger your function.
So I think the downside is really thinking in a different way. That's why, for example, in my book, I have a long tutorial spanning across multiple chapters of building a simple media sharing application, where you create a user, you validate the user, sending an email to test the email address, and then if the user is okay, you can start uploading pictures and so on. So this is a lot of tutorial that is not really focusing only on the technical side of it, but really thinking in the right way. Yeah, it's like a different set of constraints.
And I think there are, in many ways, very healthy constraints. Sometimes constraints can really help you go in the right direction. You mentioned security advantages. The lack of servers means that we don't have to worry about our servers getting logged into and misappropriated.
The serverless functions as a service, and the other platformers as a service, things that we might use to wire our application together, they have a very specific set of functionality. So if our units of functionality have more narrow scope, they can't be told to do things that we don't want them to. These are some security benefits. What are the other security implications of functions as a service?
Well, the operating system and the programming framework are the run time you want to use, like to use Java or Python. They are taken care of by the provider, by the bless, in the case of the bless lambda. So you don't need to do the patching of the operating system, for example. You only need to look at patching your code and the dependencies, the libraries, the modules that you bring with your code.
And the narrow scope that you mentioned, the fact that each function is usually covering only a smaller narrow scope, can help you embrace the principle of least privilege. This is a security principle that tests that every module in your application should only have the minimum amount of privilege that they need to perform the action they're supposed to do. So for example, if you build a customer service application, where in some way, sometimes you need to refund money to your users. You don't need to give the permission to give the refund to everything that is running inside the customer service application, but only in a specific function that will be the refund money function.
Your book focuses on event-driven applications in much of the narrative. When we're talking about event-driven applications on this podcast, sometimes people don't really know what that means, because most people are building these imperative applications where you're making calls, explicit calls to a function, and it feels like you're writing the script for what's going on. An event-driven application feels like more of a responsive, reactive application. So I want to help disambiguate what this means for people.
What is an event? So if you look at the definition, an event is something that happens or something that takes place. And in the sense of a computer application, an event is telling you the list of events is telling you the history of what is going to do with what happens. So telling you the history of every that happens inside your application.
So for example, a file has been uploaded by your users or some part of the application has updated that base table, changing some values. And each event by itself is interesting because it's immutable, because it's telling you that something happens. It's not something that is going to change. And in computer-in-disturbated application, immutable data is always easier to manage than something that you can have on current banks.
And what does that translate to in terms of an application? What is an event-driven application? It's an application where the business logic executes in response to the events that are received. As you said, it is a reactive architecture because you are reacting to an event.
In some ways, bringing the reactive programming approach that normally we use in the front end to build the user interfaces into the can't. I would say finally. And what I like to think is that the event is like the course or something, and then the logic that is executed is the effect. And if we start thinking of this course effect, so event and logic, they are the course and the effect, it's much easier for our minds, for our brains to understand how an event-driven application works, because a course effect is something that we are used to looking into anything since we are trying.
Tell me some of the implications of that change to a cause and effect-driven application. Why is that useful for a serverless environment? It's not useful at a single function level, maybe, but it's useful when you start to design an architecture that is more complex than a single function, because you start to think, you look at the data of your application, you start thinking, what happens if something happens here, like a new file has been uploaded or a new user is inserted in the database or a new item is inserted in the shopping cart of my commerce application, and then you start to think, okay, if this happens, then I should do that. And in this way, you start thinking, of course, in event-driven architecture, but also you start to link the logic of your application with the flow of the data.
So there's a typical pattern for event-driven computation, and you've talked about this in some of your presentations that I've seen, where, for example, a front-end app like my mobile application, let's say my media sharing, or my media consumption application, I've got a video player application on my phone, and it makes a call to a serverless function, and the serverless function makes a call to a database like DynamoDB, and then that change to the database, like let's say I'm playing a video, and so DynamoDB registers that I have just played a video, and that changes to a database trigger, sorry, that change results in a database trigger, and that trigger leads to another serverless event. So here we have a cause-and-effect relationship, a series of cause-and-effect relationships, user-requested video, database updates, database causes an event, change to the database triggers, another event, that event propagates to another serverless function, and we can start to see how we can have a chain of cause-and-effect leading to broader functionality. Maybe you could give a more full-fledged example, since you spend a lot of time talking about this, where we might want to use this pattern. Well, there's lots of use cases, a very basic one, similar to what you describe is when you create a new user, so you can have a create-user function that writes the new user data on the database, so it can come from a mobile application, or it can come from a web application, and this triggers another function, so the fact that you insert the user data on the database, you can trigger another function that can verify the data, can, for example, depending on the contents, send them an email to verify the email address, or a personalized welcome email based on the interest that you flag when you sign up.
So this is a very simple use case where you chain a function, a database trigger, and another function. A more interesting use case, as I've seen, is for example, in data processing, so maybe you receive a stream of data, the origin data point can be processed as an event, or grouped in micro-vegetes, and after you insert a data point, for example, this is coming from, I don't know, an IoT sensor, you can have a function that is triggered, is looking for the last 10 minutes of data points sent by the sensor, and can update some statistics that I can give you, like the minimum, the maximum, the average, or something like that on the data reported by this sensor, and moving forward, you can be even more interested in architecture that where the function that is triggered can look at a set of data and do a normal detection, for example, is a sensor that is deployed in the field, is working correctly or not. Right, yeah, and how would you contrast, you know, maybe you can take one of those examples, in contrast, how the architecture might work with a monolithic or a different deployment unit, like we were deploying to a virtual machine or a container, what would make that architecture more difficult to manage? You mean, difficult to manage in a serverless use case?
No, no, so in the serverless use case, why is it advantageous? Like, why is it better that we're deploying this to this cause and effect serverless composition world? Because it's completely not rather to the architecture, because when you create a function, a serverless function, it just sits there, it doesn't, there's no way to call it if you don't link this function to an event, it can be an API call, it can be an update on the database as I said, but you need to think of this trigger, and this brings you to thinking in a different way. Right, and I guess you don't have to stop, sorry, go ahead.
No, I was thinking that this is at single function level. If you start to have lots of functions, then you need, it's good to design the overall architecture of all the flows goes, but you also need to have everything inside a single description of all your functions of all your event-driven architecture in a single repository, such as a single template file. And that's why there are tools that came from the open source, like the serverless framework or Terraform, as it was released in open source, the serverless application model, it's an open source specification that extends and simplifies its transformation for several use cases. So you have a single template file that describes your functions, how they correlate with the other repositories that you have, like a stream dynamic build on the databases, and then you can use this template with your source code to recreate the overall architecture.
Awesome. Yeah, you're describing how we start to manage this world, because people who are a little afraid of this might think, oh, we've got, you know, five or 10 different serverless functions that are all wired together, and these are replacing my monolith, and I'm very comfortable with my monolith that has all of these functions in one place. Talk more about how we manage all of these functions, how we compose them together, and keep track of what's going on when we're moving out of the world where we've got all of our functions defined in a single node application that we can just deploy to a container, and we can easily understand how do we keep track of what's going on? Well, from a practical point of view, you should have this central template that can help you take track of what functions you're using, how they relate to another and to another particular list that you have.
And so you can use serverless framework, the same Terraform, this is probably something that I would strongly suggest. Don't work creating by hand one function at a time, you can lose track of what you're building. So I think a central repository helps. And then you should have the right mindset, not we said at the beginning, or you should start thinking a different way.
And for this reason, I created an open source tool that is available on my website, it's called serverlessbydesign, and the website is svd, serverlessbydesign.denilop.net. If you go on this website, you can really graphically design a sign, and have an even architecture, so you can create your repository, your objective functions, then you can connect one repository to a function, so that this trigger is something is changed, for example, in an database or you get an API call. And the idea behind this tool is really because I want to give everybody a tool so they can quickly prototype, quickly design and start thinking in this way. It's a great tool.
I've seen it. And it's sort of like the UML that we always wish we had. I think the problem with UML has always been that you take a look at a UML diagram, and it sometimes is confusing what's going on. You've got maybe triangles or boxes, or you've got a diagram that you've got a little symbol that looks like a database, and that's very easy to understand.
But when you start to get into components with richer functionality, it's unclear what each UML diagram is supposed to represent. But if you're doing it with, let's say your entire applications architected in AWS, AWS has those nice little symbols for each of the different services. So if you're making a UML diagram that's basically AWS services wired together, it can be easier to understand what each of these modular units is, because it's just an AWS service. Yeah, it's definitely more colorful than a UML diagram.
But apart from that, I think when you use an interface for developers, you need to think that developers know what they want to build. And if you start to put too many features, or if you reflect all the possibilities, all the configuration possibilities that you have in the user interface, then you make the user interface to context to use and the developers start just using the textiles as usual. So what I did is to get something very, very easy to use. I take a lot of assumptions when you create these diagrams, so that I don't need to ask 10 questions every time you deploy something graphically on the architecture.
And I think that's why it's interesting. And this is something that you should always think when you create a user interface for developers, that it should be easier to use than the textiles. When I'm building a traditional monolithic application, I'm oftentimes building that application out of libraries that already exist. I'm depending on certain libraries.
And you can end up with complex dependency graphs, where I build one system that depends on another, and then I build another system on top of that that depends on the previous system. When we're breaking down our applications into serverless functions, how does the notion of dependencies and dependency graphs change? Well, at some level, you should think similarly to what you would do in microservices, even if it's of course a little bit more extreme or smaller components. So the same guidelines work.
And then inside each function, you can bring your own dependencies. I usually suggest only bring the dependencies you really need so that you can keep the functions smaller. But every function can bring your own libraries, so with the best lambda, for example, you can bring binaries. I have an example that is on the website that I created for my book where I use OpenCV.
It is the Open Computer Vision Library. It's a C++ library that I compiled statically and brought together with by with the lambda function, and then I use it through their JavaScript and their Python and points. So this is from a technical point of view. And then from an architectural point of view, what I did, for example, with the two-degree data with serverless by design, is really to map an architecture into a network model with nodes and edges, so a formal mathematical network.
And that was an idea that was with me since last year. I was, I think, at serverless conf in London. And I decided that every event given architecture could be mapped one-to-one to a network where the nodes are the functions and the data repositories that you have. And then the interaction between the nodes can be a other graph.
So a better network. When we're architecting our applications, how do the back end and the front end responsibilities look in an event-driven application? Like, how can we start to think about architecting what we would traditionally call the front end and the back end? So my suggestion is to take this to create a standard interface between these two words so that they can communicate to a stable interface.
So usually you would put an API gateway. And API gateway can map API calls into the execution of one of more functions. And you can start using the gateway with mock implementations. And then you can start with a different team that can be working on a native mobile app or a web or a library application can work on the mock implementation and start creating the client.
And then the kind of team can implement the integration between the gateway and the London functions, for example, one by one, so that you can implement the right functionality. And then you can integrate to the two of the tests. For people who haven't built these kinds of applications, explain in a little more detail what an API gateway is and how you're interacting with it as a developer. So the gateway is a place where you can design a web API, usually a REST API, but you can even go beyond the default rest model.
So you give a web interface to the functions that you implement in the backend. Normally you want to model a good API. You want to create a good API model because that's like a contract between the backend and the front end. You don't want to change it differently.
It's not really a requirement. So you should spend some time in the find the right API interface. So, for example, you can have you should look for what resources you need to manipulate from the front end. You probably want to create, I don't know, users and then these users can have a shopping cart and then they can put items in the shopping cart.
So this will be the three resources that you model. And then on top of these resources, you should create HTTP interface so that you can create a new update user, the data user, the data user, add content to a shopping cart and so on. Usually with the REST model, you use the HTTP methods to do so. Like HTTP get, it's used together as all the HTTP posts and put or used to create a new object and your resource or to update one that already exists.
And in this way, you create an HTTP interface that is like a contract and then you can start implementing on the both sides in parallel. When you start with a API gateway that is the central routing point for all of your application logic, let's say you start a company and everything is managed in that single API gateway, but then your company gets huge and you realize, oh, I've got all these different departments and all these different companies, you know, these like if you start with a book selling company and eventually you, you know, you branch and all these other things, do you create more API gateways and you have a central API gateway that routes to another API gateway? One side of this is how you manage this as an infrastructure and that's something that depends on how you want what you're using. But generally speaking, each microservice that you want to build should have their own interface, probably their own endpoint.
So what that normally means that you can create one API gateway that is on multiple services or one API gateway depending on the implementation of the manager single service, but the important thing is that each service has their own endpoint because each service should be in charge of managing their own interface, their own contact with the consumer of the API. Okay, I see. Okay. So after you hit this API gateway, different requests are going to get routed in different directions.
Let's say some of the routing logic hits a server, you know, function as a service and the function as a service triggers some small amount of processing and then it goes to a database and there's lots of different backend databases that we can use to give us some stateful functionality. I mean, I think the way that we look at these, you know, these applications, a lot of the ones that you talk about is, you know, you treat the function as a service for doing this ad hoc processing and then you have these really rich databases that we have today. And these databases have really nice APIs and then they can, the databases can generate events that can, you know, you have to write after you write something, it's like the database calls back and you continue this cause and effect relationship. Describe how we think about these different databases.
What are the different databases that we use for or maybe databases to specific word, you can almost say data store because like a, you know, Redis for example is not exactly a database, it's a in memory storage solution. Describe some of the different ways that we're managing state because we're not managing that state in a stateful function application, we're just reserving the function as a service for these transient processing. So what are the stateful data storage solutions that we're using for different parts of our application? No, there is like this relational world and this non-secret world where you can have multiple kind of databases such as graph databases, document oriented.
It's really not different from a traditional application. So you should really find the best data model for your application. Normally what I suggest is start to look how much your data is structured or unstructured. So if you have a very structured data set then you can go more towards a more rigid database, even relational or if it's completely unstructured like you can text media content, binary content, then maybe you can go to an object store like Amazon S3 for example.
And then you can also integrate non-standard database with a serverless world. So for example, if for any database you have access to the transaction log, you can very quickly create a plugin that can trigger a lambda function for example or a serverless function in general if you have something happening in a transactional log of a database. So you can really choose the database you want. Some of those are already integrated.
And the choice between relational or non-secret is really depending on what you need to build. If you don't have lots of relational dependencies across multiple tables, then I would go for a non-secret like that on the b because it's much easier to scan. The devices that are accessing are services like my iPhone for example. My iPhone's got a reasonable amount of space.
It's got memory. It's got essentially disk storage. How much state do you want to keep on client devices? Or does that story change at all when we're talking about a serverless environment?
I don't think it's really changing. I'm a great advocate of putting all the logic and all the data that is possible on the on the client on the front end and only use the backend when there is a compelling reason. And normally there are like for many reasons why you need to put data or something in the backend. So either you need to share that across different devices or at different users.
And then of course you need some point in the backend. You need to backup data because you can trust the robustness of the device. Or you need security. For example, if you have some payments in your application, you can trust probably the client to take track if you gave money to someone else or not.
You need like a centralised payment service in the backend or distributed ledger such as blockchain to take trace of that. And the final reason I find is usually if you need more computational storage capabilities, that's inside the device. And even if now it's much more powerful than where so a few years ago, you still can go beyond those limits, especially if you start to do fancy things with probably artificial intelligence and machine learning. And also this is very important for less capable devices like IoT, wearable.
If you go in that space, then probably the devices that maybe needs to run on batteries, they don't have the computational capabilities of the storage capacity that you need. And then you need to be able to do that for that. Yeah, what a great explanation of how to, that was a great set of rules for how to decide what logic you should put on your client, what you should put on the server. We're going to need some notion of identity to do sessions for our serverless applications.
How does identity management work in the world of serverless cause and event, cause and effect event driven applications? It's in a way similar to what happens in microservices. Not microservices, you still need to trace the identity and the authorization of the user across multiple services on AWS. We have a service that can help you do that.
It's called Amazon Cognito and you can use it to federate with other platforms such as Twitter, Facebook, or with standard protocols such as Sunnal or OpenID Connect. And or you can also manage your own user pool and the likes cycle of the users with Cognito. Or we can work with partners like out zero or top. So the idea is that you start getting an identity.
This identity is mapped using for authentication of course. And then this authentication can be mapped at any component with different organizations. And then this can be managed depending on the service, inside the logic of the function or in the service itself. We have for example on AWS, you can really fine tune the level you access DynamoDB, DynamoDB table directly from from a device from a mobile application so that you can read or write without any server in between because you can say only this user can access this table and this user can only access the type of item, the item in this table where this user ID is in the in the Ash key, so in the main key of the item.
So it's quite complex so I'm not entering too much. But the services themselves can sometimes give you the feature to try the identity and information. Okay, so I don't want to go past your area of knowledge. But in that kind of world, so like Cognito is Cognito doing the session management and it's maintaining, okay, is this person's authorization token still fresh enough?
Yeah, you can get JWT tokens from from from the user pools and those they have a validity and then they can give you the endpoint to manage the refresh of the session if you want. So you can really build a session management platform and federate this with external identity if you want or manage your own users. Okay, that's cool. We've done a series of shows about companies that migrate to some sort of container management platform.
Some of them use Kubernetes, some of them might use Amazon ECS, some of them might use MESOS. But in any case, a lot of companies, you know, they migrated from a place where they were just using VMs or they were just on, you know, real bare metal servers to a place where they were managing things in containers and maybe they were managing them in the cloud, maybe they were managing them on premise. And now they're looking at the serverless world and they're thinking, well, I could save maybe, you know, for some domains of my application, 80%, 70%, 60%, 50%, I could save a ton of money by moving to serverless and I can, you know, help make my application easier to scale. What's the process of that migration?
How is a company that has decided has been building into this container world? Or maybe they're, you know, they're still just on-prem and they have a monolithic situation. How do you begin to migrate your infrastructure to this serverless world with the appeal of the cost, you know, cost and scalability and all this stuff? First of all, I say that most customers that migrate to the cloud and specifically, they want to use serverless, it's more to gain agility.
It's not just the cost saving, it's more the agility that can be able to develop faster and especially to move what you develop in production faster. But when you have an architecture that you want to migrate to serverless, some of the initial thinking points are the same as when you want to migrate to microservices. You should start thinking what are the right boundaries where you want to appeal the onion, not like create an isolated component. And the idea is like for microservices, you should think really of business drivers, not of technical drivers because business drivers would probably be the same across a longer amount of time and you don't want to have your requirement change while you are developing something.
So you should look like, okay, maybe the inventory, the product catalog, user management, this should be separated by the overall application that I have. And then technically speaking with serverless architecture, you can start using the API gateway. So you can put an API gateway in front of everything. At the beginning, it will be mostly a reverse proxy that can help you with advanced features such as throttling or authentication, but you can already put it in the front.
And then when you have a standard interface with your consumer of the application, the kind of application, so I'm talking about API, so you can start taking one component at a time. My suggestion is start at first with something easy to migrate, like something that is maybe with low risk and low dependencies so that you can start understanding the pooling that you want to use, how that maps with your own internal process because any company has different development pipelines that they want to build and use. And then after you start being successful with your first component, then you can start to look for something that is maybe creating some problems right now, maybe there's these features that it's two years that you want to move in production, you're not being able to, and you can start looking into a more interesting use case for your next serverless experiment. Indeed, once we start to move to the serverless environment, how does our testing and debugging cycle work?
You can test locally if you want, there's lots of tools, and we released recently two links called some local, it's on GitHub that can help you to test locally your APIs and points and your functions, for example. But I think that lots of people doesn't remember that we started to have a scale like a simplified testing environment because in the past production, the production environment was too expensive. But now with serverless, you can create a complete replica of the production environment with almost no cost because the test environment, unless you do in performance test will be almost idle. And I think this is something that you should leverage.
So you can test local, but do unit testing also in the same environment where you would do the production. When I say the same environment, I mean really, that must be the same production website, but can be complete replica but using the same core services. And then when you need to go beyond unit testing and you want to do some integration test of how everything works, you can use synthetic transactions, something that can be can test all the data flows across all these components that you have. My suggestion, and it's something that I see lots of customers going is testing production if possible, even if it's sense crazy, but look for small changes so that every time you do something in production is a small change, do I be testing in production so that maybe you do like a blue green deployment where you keep the new deployment, the new version for a small subset of your users, and then you can get some metrics, even business metrics to understand if the new deployment is working and then you release it to all your users.
And this is something that we are also looking at. And we also pre-announced some new features for the Dev West lambda in the serverless conflict we did in New York City, that was in New York City in October. I want to talk about more far-flung concepts. The current model of compute is that we interact with a front end from our smartphone or our laptop, and then the back end execution happens on servers in the cloud.
But we're inching towards a world where there's going to be so many more devices where we could have processing occur. So we can have smart earbuds, we've got smart glasses, we've got a watch, we've got a drone outside our window, we've got a smart car on the street, maybe our shirt has a processor in it, and all of these computers can execute code. How will that change the current model that we have where we see the front end and the back end as these binary well-defined areas of compute? Yeah, I think we're going into something different now.
There's a lot of discussion around that, that is edge computing term with not a clear definition as often happens. My idea is that the logic is going to get distributed more and more outside of traditional data centers. So you will be able to execute logic closer to the users. And in web architecture, also the content delivery network, the way content is distributed to the user is something that is also interesting, it can be interesting to understand how we can put logic closer to the users.
And we are looking at how we can help people run lambda functions in this way. So we have a project, it's called it's a trigger service, now it's available in production, it's called AWS Greengrass. And it's an extension of our AWS IoT platform where you can deploy lambda function and run them on devices. We support x86 or ARM devices, like last week I was in Cambridge in an AWS user group and we were running lambda function on RSPY and it was quite fun, but it's also useful because we work with very large customers here, like for example, and now it's a public utility that is present in Italy, Spain, and South America, and Eastern Europe.
And they are planning to use this framework to run logic in smart gateways that they can use both for consumer in the consumer space and also in industrial space. Okay, help me understand why I want to do that, because I think of serverless as being useful because you're, you know, so I make a call to AWS lambda. And what I'm actually doing is I'm making a call to Amazon's massive reservoir of services, sorry, of servers, and Amazon is scheduling my function as a service onto whatever blob of compute is available. And the reason it's so cheap, but so reliable is because Amazon has extra resources that it can schedule small blobs of compute onto.
Why would I want to have AWS lambda running on my IoT device on my Raspberry Pi? Because you want to go beyond two limits. One is the latency that is due to the speed of light, so we can go faster than that. And so if your device is somewhere where you have high latency on the internet, you want to have a faster response time towards the maybe other things that are connected to this client device or you want to take autonomous decision at very low latency.
And also if you want to go beyond the this couple of disconnections, so maybe you're building on healthcare architecture. And if you have an hospital with thousands of sensors and this hospital gets disconnected from the internet, you still want to be able to take local decisions very quickly based on the value that these sensors are reporting to you. For example, AWS Gingra is also embedded in some of our products such as AWS Snowball. There's no voice, like a storage device that you can order from our console.
You can fit it with your data and ship it back to AWS to import data or do the opposite if you want to export data. And they all go on state university. They literally using this to collect data in the middle of the ocean. So they have sensors, they collect data in the middle of the ocean on a boat.
And since now they have green grass inside, there's no old edge. They can start running Lambda function that can preprocess this data. And since the preprocess data is much smaller, they can upload this data much quicker to the cloud and then send the raw data that is maybe in order to the terabytes ship back with the device. So it's a way to overcome the limits of latency and impossible disconnection from the internet.
Cool. Now, does this help me do something like most like, let's say I run a common pattern, common pattern today is let's say I'm like a financial trading company. And I've been doing trading since the early 90s. And some of my architecture that I deployed to on-prem stuff over the years has been augmented by the cloud.
Eventually, I saw the usefulness of the cloud and I started moving some of my architecture to the cloud. But I've still got all of this on-prem resources and deciding what processing to schedule onto my on-prem resources versus my cloud resources maybe is not straightforward. Does this kind of green grass model, does that help me more easily do that? Because I can just say I want to schedule my jobs onto whatever Amazon devices available, whether that's on my own machines or in the cloud.
That is that you have the same programming model, the same management interface as traditional lambda functions, but then you can decide to deploy these functions on a device that is outside of the WS data centers, the WS regions. And to do that, you normally, you can do lots of different use cases. Now, just the two I mentioned with the hospital and the both are so different from each other that gives you an idea. But normally, the two drivers that we see are customers are trying to overcome a really latency.
So you want to do something at low latency. And this is especially important for some use cases. And sometimes, if you want the possibility to go to continue to work even if you get disconnected from the internet, think of the IoT world, for example, if you will think of farming, like if you have sensors that you can use for defining your irrigation systems or stuff like that. You don't want to be dependent on who is providing the internet connection to you.
Okay. Let's talk a little bit about machine learning. How can we model machine learning pipelines in a way where we can utilize serverless architecture? And that's an interesting question.
So we're working with a few customers for that. The most notable approach now is to use traditional services or infrastructure to do the training of the model, where you can leverage, for example, GPUs or graphical processing units or FPGAs to accelerate the training. And then when you have the model that is training, you can deploy the model inside the Lambda function. So your customers are doing that, for example, with TensorFlow or with Apache MXNet.
And in this way, you can have the production side of your machine learning project when the consumer of the users of the model, you train, can get the benefit of the scalability and availability of tools like the best Lambda and API get-wing. You touched on the benefits of moving to serverless in terms of how your development team might be able to change. You might be able to become more agile. How are development teams changing because of that serverless movement?
This is a great question. And it's something that I always, when I talk with customers, try to also to understand on their side and I give my own suggestion, but it's something that I have to say more on the learning side. What I see is that with serverless, we have smaller teams that are more independent. There is more prototyping.
So if you have an idea, you can quickly build a prototype, approve of concept and validate the idea or not. And if it works, you really are on the right path to implement scalability, availability, security. So it's much easier to move a prototype in production than from an additional infrastructure. So this is probably the biggest change.
And it's something that we also have in Amazon. I know you heard about the two pizza team that we have, the small team that are in charge of everything from the development to the deployment in production can give you the speed that you need when you start to grow. So it's better to have lots of smaller teams that are big team, where if something happens, you don't, it's not scale, it's not in charge of that. And it's very easy to build internal dependencies that nobody's aware of.
Of course. All right. Final question. You are doing lots of evangelism around serverless and you're talking to user groups, you're talking to customers, you're seeing the bleeding edge of how people are using this technology.
What are you realizing about how people are using serverless? And what are some of the cutting edge use cases you're seeing? Give me a picture for what's, you know, what's on the cutting edge of serverless? And what are the kinds of changes to application development that we're going to see become popular in the next couple of years?
It's always difficult to talk about the future, because the future, but what I see that is that the main reasons why people are adopting serverless right now, like the speed that GDD gives the capacity to build a prototype, have very limited impact costs in your cost, unless you're going in a large scale production environment, those advantages will be there and are probably the one, the driver that is being in people to adopt this new, this new variety of creating applications. We've seen customers create lots of different use cases. So from, you know, the Vogue magazine, they created a photovogue in Italy. It's a platform for photographers to exchange and promote their photographic work.
And it's like, it was a faster in production, quicker to build and cheaper than what we're expecting to order more conservative users, like the driver driving license government agency in the UK, they are adopting an API first, an API first approach, and they are using the API gateway to use to split the onion, to start to create standard interface, start to contract to interface different components and then modularize their architecture. So it's really a very great word that we've seen. All right. Well, Danilo, thank you for making the time to come on software and sharing daily.
It's been great talking to you. I recommend listeners check out your book, AWS Lambda in action. And you know, maybe we can do another show in a year or so when the world is turned on Ted once again. Okay, all right, great.
Wow.