Serverless – Are you ready to 737 Max 8 your core business?

Ok, I agree that this is not the best way to draw and comparison and some might find it in bad spirit as well. Apologies for that. But, I am amazed at what the organizations are willing to bet on given the lure of not managing your infrastructure. After the horrendous Max 8 episode, I have become a firm believer of the fact that Technology, more than what you need, is going to corrupt you and your business. The manufacturer of the ill-fated planes bet on a technology which eventually overrode humans.

This is not an isolated incident. More often than not, we have seen technologists drive a technology roller coaster and end up the journey without delivering any tangible business value. It is a horrible waste of time and resources. At Knoldus we believe in Pragmatic Technology. Technology which would add business value and is easy to maintain and enhance.

So how does Serverless compare to this conversation? Let us first talk about what does serverless mean.

Serverless architecture (also known as serverless computing or function as a service, FaaS) is a software design pattern where applications are hosted by a third-party service, eliminating the need for server software and hardware management by the developer. Applications are broken up into individual functions that can be invoked and scaled individually.

Twilio

This sounds magical. It started with applications that significantly or fully incorporate third-party, cloud-hosted applications and services, to manage server-side logic and state (Paas Platform as a service & Baas – Backend as a service). Then it gradually got to the stage where the logic written by the developer is run in stateless compute containers that are event-triggered, ephemeral (may only last for one invocation), and fully managed by a third party (Faas – Function as a service).

Let us take a simple example of a service that we would have written earlier.

There would have been a client. There would have infrastructure on which middleware the resource layer would have been deployed. So far so good. Then came the modern world of containers, microservices, domain driven design which allowed the technology team to divide and conquer and deploy in a way which was super efficient. Excellent.

We landed into a situation like this

This is still very good. Independent teams were able to work on individual components. Scale them, maintain and enhance them separately. In the original version, all flow, control, and security were managed by the central server application. In the Serverless version, there is no central arbiter of these concerns. Instead, we see a preference for choreography over orchestration, with each component playing a more architecturally aware role—an idea also common in a microservices approach.

The technologists, as always, dreamt further for making the business easier.

• What if you could use a 3rd party authorization service which would handle the ACLs for you, it would handle the complexities of authentication, authorization and you should focus on your core business logic.
• What if instead of hosting your own database, we give you database in the cloud like firebase or rds.
• What if you could just concentrate on your business logic and we give you containers in which you could deploy your logic. We would take care of your uptime, scaling, DevOps etc etc

This led us to the path of FaaS

FaaS is about running backend code without managing your own server systems or your own long-lived server applications. FaaS offerings do not require coding to a specific framework or library. For instance, AWS Lambda functions can be implemented “first class” in Javascript, Python, Go, any JVM language (Java, Clojure, Scala, etc.), or any .NET language. Deployment is very different from traditional systems since we have no server applications to run ourselves. In a FaaS environment we upload the code for our function to the FaaS provider, and the provider does everything else necessary for provisioning resources, instantiating VMs, managing processes, etc.

Utopian era? dream on …

Amazing right? We have reached the Utopian era of software development. At least Boeing thought so for flying.

When 737 Max 8 software continuously kept overriding the pilots, what guarantees does the Faas provider give that it would not do the same? Are you ready to bet your trading platform on a Faas function which might go down when you are executing your billion dollar transactions? Amazon would have outages, Facebook recently had a huge outage. And this is just the tip of the iceberg

Let us see the other parameters which would make you nervous

1. Vendor Control – Once you sign up to deploy on Lamdas or GCF or Azure Functions then you are playing in their garden according to their rules. You would be affected by downtimes, by their upgrades, by their new policies. You would be living in a condo and would have to abide by the condo rules along with paying a maintenance fee.
2. Multi-tenancy – You would be living with a huge number of other customers and multi-tenant solutions are not perfect. They can have issues with security (one customer being able to see another’s data), robustness (an error in one customer’s software causing a failure in a different customer’s software), and performance (a high-load customer causing another to slow down).
3. Lock in –It’s very likely that whatever Serverless features you’re using from one vendor will be implemented differently by another vendor. To switch, you’ll probably need to change your code, you may even need to change your design or architecture if there are differences in how competing vendor implementations behave.
4. No in server state –With FaaS we typically have no control over when the host containers for our functions start and stop. This is a good architectural paradigm but a deal breaker in a lot of situations.
5. Implementation restrictions – mostly because you are running in a multitenant controlled environment
   1. No server-side optimizations possible
   2. Limited configurations on your Faas functions
   3. Limits on concurrent executions of Faas and execution times – If your function takes more than 5 minutes to complete the Faas platform is going to kill it
   4. Startup latency – Once your container is not needed the Faas platform would kill the container to optimize resources when it is needed again it might have to re-instantiate a new container and that would take time. The time would depend on whether you are starting from warm mode or completely cold mode.
   5. Testing, debugging is non-trivial and is dependent on the Faas provider.
   6. Monitoring is tricky since these containers are ephemeral and there is limited support by the Faas providers
6. DR Risk – For covering your DR risk you would now like to deploy on multiple clouds but each cloud would have its own way of working with functions and the code could be different unless you would like to use an abstraction like Apache OpenWhisk or similar
7. Developer discipline – A significant amount of developer discipline is required so that the code does not become an unmanageable function sprawl. There have already been instances of serverless being compared to modern day stored procedures
8. Lack of standards – For different provides to cooperate and allow a seamless transition from one provider to another

Conclusion

The future is certainly not very dark for serverless as I might have painted it. It does have its bright spots in throwing something quickly to the market and see if it would stick or not. It is also probably suited for your non-critical just value to add features. Send me a thank you email once I fill your survey, sure, that kind of functionality.

That said, at this point, I would be very very wary of putting my core business and business critical functions to an aeroplane that is not proven yet and I have limited control over.