DZone
Thanks for visiting DZone today,
Edit Profile
  • Manage Email Subscriptions
  • How to Post to DZone
  • Article Submission Guidelines
Sign Out View Profile
  • Post an Article
  • Manage My Drafts
Over 2 million developers have joined DZone.
Log In / Join
Refcards Trend Reports Events Over 2 million developers have joined DZone. Join Today! Thanks for visiting DZone today,
Edit Profile Manage Email Subscriptions Moderation Admin Console How to Post to DZone Article Submission Guidelines
View Profile
Sign Out
Refcards
Trend Reports
Events
Zones
Culture and Methodologies Agile Career Development Methodologies Team Management
Data Engineering AI/ML Big Data Data Databases IoT
Software Design and Architecture Cloud Architecture Containers Integration Microservices Performance Security
Coding Frameworks Java JavaScript Languages Tools
Testing, Deployment, and Maintenance Deployment DevOps and CI/CD Maintenance Monitoring and Observability Testing, Tools, and Frameworks
Culture and Methodologies
Agile Career Development Methodologies Team Management
Data Engineering
AI/ML Big Data Data Databases IoT
Software Design and Architecture
Cloud Architecture Containers Integration Microservices Performance Security
Coding
Frameworks Java JavaScript Languages Tools
Testing, Deployment, and Maintenance
Deployment DevOps and CI/CD Maintenance Monitoring and Observability Testing, Tools, and Frameworks

Why Go Serverless?

Serverless architecture isn't right for every app, but here's an overview of what you can expect if you decide to make the plunge.

Matt Billock user avatar by
Matt Billock
·
Jul. 03, 17 · Opinion
Like (6)
Save
Tweet
Share
7.99K Views

Join the DZone community and get the full member experience.

Join For Free

Most of the talk about serverless these days focuses on how to integrate with a function-as-a-service provider, how to orchestrate your calls, tools for troubleshooting in a serverless world, and so on. However, not much of it is focused on the most important question behind choosing serverless architectures over a more traditional approach: why?

In this post, we’ll present a few different reasons to choose a serverless architecture over a more traditional client-server approach, or even over a containerized approach such as Docker.

Reducing Development Costs

One of the primary reasons to go serverless is as the name suggests – you want to remove the server from the equation. While it’s true that there is no such thing as a truly “serverless” application (serverless is just a different way to refer to cloud-hosted servers), by choosing a serverless provider you stand to gain simply from not having to write server code.

In a traditional client-server application, all APIs and endpoints on top of your data need to be implemented by a developer. These are included either by writing the code yourself using a framework like Rails, or by leveraging a third-party tool that can convert your underlying sources into a callable REST API.

With a serverless architecture, you take advantage of a third-party to outsource much of the back-end technology, removing the need to do some of the more complex tasks associated with bringing a web application to market. This significantly reduces your development costs. Your developers can focus on the user interface and user experience, the unique aspects of your app that have the most bang for the buck.

Reducing DevOps and Maintenance Costs

There are a number of costs directly involved in developing and hosting a web application. These include developer salaries, hosting fees, domain registration fees, data transfer fees, and so on. Furthermore, with web applications, you often need to keep the server constantly available, to handle requests that can come in at any time of day. This means that for low-activity apps, that may use only one hour a day of computing time, you still need to pay for the other twenty-three hours your app was available but unused.

With Function-as-a-Service utilities like AWS Lambda, you can further reduce your costs by ensuring you are only billed when the application is active. Function-as-a-Service runs on a pay-per-execution model, so you only pay for hosting and computing resources when your code is actually being called. Many web applications are often idle, so this can prove to be significant cost savings. 

While you can make some similar gains using products like Docker to host containers on Heroku, you won’t be able to get to the sheer level of granularity allowed by Function-as-a-Service serverless providers, who only spin up an instance when an individual function is actually called. This intermittent mounting and unmounting of containers reduces hosting and resource usage costs by making sure that your code is only active when it is actually needed.

Reducing Time-to-Market

In addition to reducing the amount of code and operating costs, serverless apps require less effort to bring to market than their traditional counterparts. By sacrificing hardware and server-side flexibility, you can reduce the amount of time it takes to develop your app simply by moving the complexity onto the client side, unifying your efforts into a single language in your code base.

Furthermore, as you don’t need to find a provider, stand up a server, configure the web server software, and get your app running on a machine, you end up with a far simpler problem. You also end up with a larger array of hosting choices, as serverless apps need only a CDN that can serve their files to end users, as opposed to a specialized web server running a programming language’s runtime while handling requests from users over the web.

Finally, by outsourcing your app’s server-side to a serverless provider, you enhance your security by allowing the third party to manage that aspect of your application. In doing so, you remove the effort needed to secure a web server, a database server, and any other back-end security concerns that would be paramount in a traditional client-server application.

Conclusion

While many apps cannot operate in a serverless context due to unique or problematic application requirements, apps that have the option to go serverless have a number of benefits when compared with their traditional client/server brethren. By using a serverless provider, you can reduce the amount of code you need to write, letting a third party handle building your API on top of your data source for you.

You can also reduce your operating costs by allowing your code to run in a more intermittent manner, spinning up (and tearing down) instances only when they are needed.

Based on these two benefits – and a host of others that would require more space than I have available to touch on – you’ll also see a reduction in time-to-market for your product, as you can focus on the look, feel, and behavior of your application right out of the gate. While a serverless architecture may not be right for you, it is a viable and smart choice for a growing number of companies.

Web application app

Published at DZone with permission of Matt Billock, DZone MVB. See the original article here.

Opinions expressed by DZone contributors are their own.

Popular on DZone

  • Load Balancing Pattern
  • Top 5 Node.js REST API Frameworks
  • 5 Factors When Selecting a Database
  • Iptables Basic Commands for Novice

Comments

Partner Resources

X

ABOUT US

  • About DZone
  • Send feedback
  • Careers
  • Sitemap

ADVERTISE

  • Advertise with DZone

CONTRIBUTE ON DZONE

  • Article Submission Guidelines
  • Become a Contributor
  • Visit the Writers' Zone

LEGAL

  • Terms of Service
  • Privacy Policy

CONTACT US

  • 600 Park Offices Drive
  • Suite 300
  • Durham, NC 27709
  • support@dzone.com
  • +1 (919) 678-0300

Let's be friends: