Search icon CANCEL
Subscription
0
Cart icon
Your Cart (0 item)
Close icon
You have no products in your basket yet
Save more on your purchases now! discount-offer-chevron-icon
Savings automatically calculated. No voucher code required.
Arrow left icon
Explore Products
Best Sellers
New Releases
Books
Videos
Audiobooks
Learning Hub
Conferences
Free Learning
Arrow right icon

What is serverless architecture and why should I be interested?

Save for later
  • 6 min read
  • 01 Jun 2017

article-image

I’ve heard the term “serverless” architecture for over a year and it took awhile before I even started seriously looking into this technology.  I was of the belief that that serverless was going to be another PaaS solution, similar to cloud foundry with even less levers to pull.  However, as I started playing with a few different use cases, I quickly discovered that a serverless approach to a problem could be fast, focused and unearthed some interesting use cases. So without any further ado I want to break down some of the techniques that make architecture “serverless” and provide you with suggestions along the way.  

My four tenants of the serverless approach are as follows:

  1. Figure out where in your code base this seems a good fit.
  2. Find a service that runs FaaS.
  3. Look at dollars not cents.
  4. Profit. 

The first step, as with any new solution, is to determine where in your code base a scalable solution would make sense.  By all means, when it comes to serverless, you shouldn’t get too exuberant and refactor your project in its entirety. You want to find a bottleneck that could use the high scalability options that serverless vendors can grant you. This can be math functions, image manipulations, log analysis, specific map reduce, or anything you find that may need some intensive compute, but not requiring a lot of stateful data.  A really great litmus test for this is to use some performance tooling that's available for your language, if you note that a bottleneck is related to a critical section like database access, but a spike that keeps occurring from a piece of code that perhaps works, but hasn't been fully optimized yet.  Assuming you found that piece of code (modifying it to be in a request/response pattern),and you want to expose it in a highly scalable way, you can move on to applying that code to your FaaS solution.

Integrating that solution should be relatively painless, but it's worth taking a look at some of the current contenders in the FaaS ecosystem, thus leading into the second point “finding a FaaS,” which is now easier with vendors such as Hook.io, AWS Lambda, Google Cloud functions, Microsoft Azure, Hyper.sh Func, and others. Note, one of the bonuses from all the above vendors I have included is that you will only pay for the compute time of your function, meaning that as requests come in, your function will directly scale the cost of running your code.  Think of it like usingjitsu: (http://www.thomas.gazagnaire.org/pub/MLSGSSMCSLCL15.pdf), you can spin up the server and apply the function, get a result, and rinse/repeat all without having to worry about the underlying infrastructure. 

Now, given your experience in general with these vendors, if you are new to FaaS, I would strongly recommend taking a look at Hook.io because you can get a free developer account and start coding to get an idea of how this pattern works for this technology. Then, after you become more familiar you can than move onto AWSLamda or Google Cloud Functions for all the different possibilities that those larger vendors can provide.

Another interesting trend that has became popular from a modern aspect of serverless infrastructure is to “use vendors where applicable,” which can be restated as only focusing on the services you want to be responsible for.  Taking the least interesting parts of the application and offloading them to third parties, which translates, as a developer, to maximizing your time by often paying for just for the services you are using rather than hosting large VMs yourself, and expending the time required to maintain them effectively.  For example, it'srelatively painless to spin up an instance on AWS, Rackspace, and install a MySql server on a virtual machine, but over time the investment of your personal time to back up, monitor, and continually maintain that instance may be too much of draw for your experience, or take too much attention away from day-to-day responsibilities.

You might say, well isn’t that what Docker is for? But what people often discover with visualization is it has its own problem set, which may not be what you are looking for. Given the MySql example, you can easily bring up a Docker instance, but what about keeping stateful volumes? Which drivers are you going to use for persistent storage? Questions start piling up about the short-term gains versus long-term issues, and that's when you can use a service like AWS RDS to get a database up and running for the long term. Set the backup schedule to your desire,and never you’ll have to worry about any of that maintenance (well some push button upgrades every once in a blue moon).

Unlock access to the largest independent learning library in Tech for FREE!
Get unlimited access to 7500+ expert-authored eBooks and video courses covering every tech area you can think of.
Renews at €18.99/month. Cancel anytime

As stated earlier, how does a serverless approach differ from having a bunch of containers with these technologies spun up through Docker compose and hooking them up to event-based systems frameworks similar to the serverless framework (https://github.com/serverless/serverless). Well,you might have something there and I would encourage anyone reading this article to take a glance. But to keep it brief, depending on your definition of serverless, those investments in time might not be what you’re looking for. 

Given the flexibility and rising popularity in micro/nanoservices, alongside all the vendors that are at your disposal to take some of the burden off developing, serverless architecture has really become interesting. So, take the advantages of this massive vendor ecosystem and FaaS solutions and focus on developing. Because when all is said and done, services, software, and applications are made of functions that are fun to write, whereas the thankless task of upgrading a MySql database could stop your hair from going white prematurely. 

About the author 

Ben Neil is a polyglot engineer who has the privilege to fill a lot of critical roles, whether it's dealing with front/backend application development, system administration, integrating devops methodology or writing. He has spent 10+ years creating solutions, services, and full lifecycle automation for medium to large companies.  He is currently focused on Scala, container and unikernel technology following a bleeding edge open source community, which brings the benefits to companies that strive to be at the foremost of technology. He can usually be found either playing dwarf fortress or contributing on Github. 

I’m not sure but is ‘awhile’ an adverb? Also, I thought the first sentence could read better maybe if it was a structured a little differently. E.g. The term “serverless” architecture has been thrown around for over a year, and it’s taken some time for me to start seriously looking into this [adjective] technology.