How Does a Serverless App Work?
While you might have played around with AWS Lambda, let's see how serverless architectures actually work and what benefits and drawbacks they offer to monoliths.
Join the DZone community and get the full member experience.Join For Free
serverless might look like a bright, sunny day but it isn’t that sunny after all. it has brought about a big difference when it comes to application architecture.
moreover, the change with serverless isn’t gradual, but a jolt . faas drives a totally different type of application architecture through a fundamentally event-driven model, a much more granular form of deployment.
- how does a serverless app actually work?
- what does serverless architecture look like?
- how is it different from monolithic architecture?
these are the questions that we’re going to tackle in this article. let’s dive deeper and understand serverless architecture and its workings.
let’s make some assumptions about our reference application.
- it is a multi-user app.
- it has a mobile-friendly user interface.
- user management and authentication are required.
we’ve certainly overlooked some other features that you might expect in a basic app, but the point of this exercise is not to actually build an app — only to compare a serverless application's architecture with a legacy, monolithic architecture.
given those requirements, a monolithic architecture for our app might look something like the figure below:
- a native mobile app for ios or android
- a backend is written in java and html
- a relational database
in this architecture, a mobile app is responsible for handling the app interface and input from the user, but it delegates most actual logic to the backend. from the perspective of our code, the mobile app is lightweight and quite simple. it uses http to make a request to multiple api endpoints served by the java backend.
authentication and user management are encapsulated with the java application code. moreover, it also interacts with the relational database in order to store user data.
you might say, “ i am perfectly fine with this architecture as it meets all my requirements, so why just not stop there and call it a day ?”
to which i will reply that there are multiple challenges and operational pitfalls that i will discuss in this section to which you might relate. go on!
in building this app, you’ll need to have hands-on expertise in ios and java, don’t you? apart from that, you need to have good experience in configuring, deploying, and operating java application servers as well as a relational database. moreover, think about their host systems, whether container-based or running directly on virtual or physical hardware?
we’ve not yet touched scalability, security, or high availability, all of which are critical aspects of the modern production system. the bottom line is that all these complexities, at one point in time, will create friction when you are be fixing bugs, adding features, or trying to rapidly prototype new ideas.
and hence, you need a change!
a serverless architecture of our basic application would look something like the figure below:
according to this architecture, while the user interface will still remain a part of the native mobile app, user authentication and management will be handled by a baas service like aws cognito. these services can be called directly from the mobile app to handle user-facing tasks like registration and authentication.
moreover, the same baas can be used by other backend components to retrieve user information.
with user management and authentication now handled by the baas , the logic that was previously handled by the backend java application is simplified. you can use another amazing serverless component, aws api gateway, to handle routing http requests between a mobile app and your backend in a secure and scalable manner.
each distinct operation can be encapsulated in a function. a faas platform such as aws lambda takes each of these functions and runs them in parallel ‘containers’ that can be monitored and scaled separately.
those backend faas functions can interact seamlessly with a nosql baas database like aws dynamodb. in fact, one drastic change is that we no longer store any session state within our server-side application code, and instead will persist in our nosql storage.
while it may seem to you like a minute change, believe me, it will help you significantly with scaling.
what got better?
you might say, “there is no significant difference in terms of complexity, and it has, in fact, more specific application components that our traditional monolithic architecture?”
to which i will reply that the code you will write now will be solely focused on the logic of the app. what’s more? our components are now decoupled and separate. due to that, we can switch them or add new logic very fast without the inherent friction present in a monolithic architecture.
scaling, high availability, and security are the areas all backed up with our serverless architecture. this means that as the popularity of your app grows, you needn’t worry about renting more powerful servers, or failure in a database, or troubleshooting a firewall configuration.
in short, labor cost has reduced, as well as the risk and resources cost of running it. all of its constituent components will scale flexibly. what else? if you have an idea for a new feature, our lead time is highly decreased, hence, we can start getting feedback and working on it efficiently.
pretty exciting, right?
the aim of this blog is to clear the confusing clouds over the minds of people who are not sure about how serverless apps work!
serverless systems are still in their infancy, and it will be wonderful to witness how they solve and fit into our architectural requirements.
Published at DZone with permission of Jignesh Solanki. See the original article here.
Opinions expressed by DZone contributors are their own.