Can you use Serverless Everywhere? Any Drawbacks?

Rohit Akiwatkar — Fri, 09 Mar 2018 14:28:24 +0000

Update: I recently wrote a post on different use cases of serverless. A list of 10 serverless use-cases which is a good introduction to the areas in which serverless can be useful. Though the article is AWS focused, these ideas can obviously be used elsewhere.

As a huge promotor of serverless, I am very positive about its future. But I feel bad when this technology is falsely lauded as a panacea for all the future applications.
// Detect dark theme var iframe = document.getElementById('tweet-944776732380356608-934'); if (document.body.className.includes('dark-theme')) { iframe.src = "https://platform.twitter.com/embed/Tweet.html?id=944776732380356608&theme=dark" }

A discussion on the drawbacks of this technology will give new developers and cloud architects a complete picture.

For the beginners

Serverless architectures refer to applications that significantly depend on third-party services (knows as Backend as a Service or “BaaS”) or on custom code that’s run in ephemeral containers (Function as a Service or “FaaS”), the best-known vendor host of which currently is AWS Lambda.

Despite the name, it does not actually involve running code without servers. The name “serverless computing” is used because the business or person that owns the system does not have to purchase, rent, or provision servers or virtual machines for the back-end code to run on.  

Below are some of the prominent drawbacks in serverless technology

Problems Due to Third-Party API Systems (Simply Vendor Lockin!!)

Startups are agile boats, but the decisions you make initially have rippling consequences over time. There is a reason why cloud providers offer $100,000 initial credit to early-stage startups.

// Detect dark theme var iframe = document.getElementById('tweet-961613404585721856-735'); if (document.body.className.includes('dark-theme')) { iframe.src = "https://platform.twitter.com/embed/Tweet.html?id=961613404585721856&theme=dark" }

Once you make your initial infrastructure on a particular cloud it becomes very difficult to migrate out of it. Vendor control, multitenancy problems, vendor lock-in, and security concerns are some of the problems due to the use of third-party APIs.

Lack of Operational Tools

The developers are dependent on vendors for debugging and monitoring tools. Debugging distributed systems is difficult and usually requires access to a significant amount of relevant metrics to identify the root cause. But recently many tools have come up in the serverless ecosystem for -
Monitoring - Epsagon, IOpipe, Dashbird, Stackery
Security - PureSec, Sync, TwistLock 

Architectural Complexity

Decisions about how small (granular) the function should be, take the time to assess, implement and test. It gets cumbersome to manage too many functions, and ignoring granularity will end up creating mini-monoliths.

AWS Lambda, for now, limits you to how many concurrent executions you can be running on all your lambdas. The problem here is that this limit is across your whole AWS account. Some organizations use the same AWS account for both production and testing. That means if someone, somewhere in your organization does a new type of load test and starts trying to execute 1,000 concurrent Lambda functions, you’ll accidentally Denial of service (DoS) your production applications.

Testing Headache

Integration testing serverless apps are tough. The units of integration with Serverless FaaS (i.e. each function) are a lot smaller than with other architectures and therefore we rely on integration testing a lot more than we may do with other architectural styles.

Implementation Drawbacks

Problems related to deployment, versioning, and packaging also exist. You may need to deploy a FaaS artifact separately for every function in your entire logical application. It also means you can’t atomically deploy a group of functions. On top of it, there’s no concept of versioned applications so atomic rollback isn’t an option. You may need to turn off whatever event source is triggering the functions, deploy the whole group, and then turn the event source back on.

Related Services

Architectural components such as serverless databases, frameworks, libraries are not mature and developers don't have a wide range of choices.

Other drawbacks are performance related issues in functions, security vulnerability (susceptible to DoS attack), event-driven architectural problems such as - snowball effect due to cascading events, asynchronous side-effects, and poison messages.

Final Thoughts

The serverless code can be used in conjunction with code written in traditional server style, such as microservices. For example, part of an application could be written as microservices using compute instances and another part could be written as serverless code. Alternatively, very few application could be written that uses no provisioned servers at all, being completely serverless.

If there is any other drawback which you want me to discuss, please mention in the comment section. Looking forward to the views of Dev community.

How feasible is Serverless technology for startups?

Rohit Akiwatkar — Wed, 31 Jan 2018 12:48:34 +0000

If you are working with a startup, you know that it is a race against time and money.
I have been evaluating a lot of serverless technologies for our clients who are looking to build applications with serverless components. Now that there is a new project ahead of us, we are wondering if it is a perfect fit for our requirements or not.

Since it’s a simple app but has huge potential to scale, we are thinking to go for microservices or continue with monoliths? The application is just going to perform user authentication, registration, push notifications and standard CRUD operations, however, it might have a CRON in the background sending updates to the app.

Here are some of the questions we are looking answers for:

As per my experience, service-based architecture adds a lot of complexity and communication overhead. If we have a team of 100 engineers, we can divide the project into small pieces that can be worked upon by a manageably sized team. Since the initial project team is small, I am not sure microservice will be a good fit. However, we are looking forward to good scalability options. What is your experience?
Serverless seems to be a new kid on the block and the use cases are still fit into a bit of a narrow band. Also, I am particularly not sure about serverless performance and how it operates in a development environment for rapid test/prototyping. How about cold-hot startup time and concurrency? 
Liquid error: internal

Drew Firment

@drewfirment

@RohitAkiwatkar increasing the size of allocated memory not only increases performance (and costs), but also the consistency and predictability of your functions bit.ly/2CHepKC

21:19 PM - 02 Jan 2018
But most importantly we envision faster time to market and are looking forward to improving our MVP by circling back around and ironing out the imperfections and operational issues. How good is serverless for this?

Looking forward to the views of Dev community. Let me know what do you think about this case. Also, if there is anything I should be considering, please mention in the comment section.

Forem: Rohit Akiwatkar