monogram with initials UKR

Pragmatic Approach : Serverless For Startups

Updated: Under: technology Tags: #serverless #startups

Late last-year(June 2020) I spoke about Serverless on TechKatha (Sri Lankan Tech Podcast). From that point I’ve been asked, countless times, why we(new startup I joined) chose Serverless? The weight of the selection didn’t fall on technical details as most would assume. It was much more pragmatic.

Colombo, Sri Lanka 2017, Office Of YAMU
Who is this article for?

  • Engineering Leads, interested in adopting serverless.
  • Software Developers, who want to understand the pros/cons of serverless.

This write-up will explore serverless compute and how it benefits startups with reasoning, key points and anecdotal experiences.

2019, End of December I decided to leave my engineering job at WSO2. What caught my interest was an opportunity of a green-field project to help build a financial SaaS platform.

Agility is key

Technology startups are many, Ideas are never concrete from the get-go. A lot of wiggle room and agility required to enable quick course corrections. The ultimate goal is to quickly get it out to the intended audience.

I have seen the same cycle again and again — great products are created through small teams, with great leaders, who eliminate all non-critical features, while working under extreme pressure, and produce a product that just barely works.

Eric Schmidt

My boss put me on to this quote by Eric Schmidt. And it re-enforces the thought on why It’s important to be agile in certain scenarios. This sentiment played a huge role in the selection of serverless.

When ultimately I joined in 2020 January, what was present in the company IP was a mock-up. With the heavy burden of specific domain knowledge, our team bound to be minimal. For us, time best-spent is on iteratively exploring and building the product.

In the beginning, my mind was set on using k8s micro-services with an istio(Service Mesh). But it was apparent with our small team of polyglot developers, It’s not worth investing time in setting up such a solution.

What is Serverless?

One major thing out of the way, there are servers. But they are not to be worried about, is the takeaway. I think of serverless more as a cloud native application runtime.

Cloud native technologies empower organizations to build and run scalable applications in modern, dynamic environments such as public, private, and hybrid clouds.

The CNCF Cloud Native Definition v1.0

It’s the most cloud native one can be, a manged service for your code. Advantages of serverless are as following,

  • Focus on code, not Infrastructure.
  • Pay only for usage. No cost incurred for idle-time.
  • Certain workloads that require parallel processing is much more cost-effective.
  • Better Developer Experience (DX) with integrated insights and bindings to commonly used components.

My job as the engineering-owner became getting out of the way of the development team. Therefore, ultimately allowing them to iterate on the product. While making sure resilience and quality stays consistent.

Paired with serverless and DevOps, we were off to the races. After the initial proof of concepts iterated and scrutinized. We finally saw maturity in the product that lead for the road maps to be laid out by the end of 2020. Trajectory was visible!

Pros Of Serverless

While there are many advantages in choosing serverless, especially with its tight integration with cloud services. I’d argue the following four trumps as the main pros of serverless.

  • Resilience - Apart from the up-time and production readiness, even in areas such as events/messaging infrastructure.
  • Distributed Tracing - From the user hitting a button on a web interface to the database, tracing is auto-instrumented in most cases.
  • No Boilerplate - With infrastructure being cloud native, code written is for the business use-case. With use of native bindings, common function/component integrations are present.

Yes, these are achievable through traditional means in any stack. But commendable is having the aforementioned capabilities from day one. This aforementioned capabilities allow teams to iterate on software fast while getting performance data back to developers for further tuning.

2021 was exciting, development was steady on and by March we had already delivered an MVP. We built DevOps templates and IaC modules to help deployment, which removed the last fiction points. The MVP was well-received, and had the feedback to steer the plan in the correct direction.

Cons Of Serverless

Selecting the correct tool for the job comes first, some forms of compute may not benefit serverless because of the following,

  • Cold Starts - Because Serverless has no long-running instances and prefer dynamic scaling up and down from zero, the initial request in a session will have startup delays.
  • Predictable Workloads - Serverless is designed for dynamic workloads, not for static and especially long-running workloads, the latter not supported by some vendors in specific plans.
  • Vendor Lock-In - Serverless allows cloud providers to give great integration to cloud native services, which gives value but ultimately locks you in.

Problems such as Cold Starts can be alleviated to a certain extent. Using log-in events to pre-warm instances is one simple example.

We had encounted our own problems with serverless, some caused by programming for it, traditionally not harnessing its native bindings. But most were time-outs and complaints of cold-starts. With metrics and user-feedback, design changes applied to make-sure pre-warming is done. Some workloads optimized or moved to VMs that did not benefit from serverless.

Conclusion

The standard caveat applies, “Your millage may vary”. Given our constraints with resourcing, serverless helped us to quickly get things off the ground.

With more sprints, new features introduced and maintained. No major roadblocks faced. We were given the opportunity to accelerate and deliver our product. Currently standing at a respectable version one.

The value gained by our team(for serverless) is being able to put most of our time on the core product, and not worry about Infrastructure.


Special thanks to my team, as this was not a singular journey at all. Truly a dream team!