What Is Serverless Architecture For The Rest Of Us
There is a new buzzword in town and it is being pushed by the cloud giants such as Amazon and Google. Let me go straight to the point; this is another marketing trick into buying something you might not need. Based on what is advertised by the cloud players, you will be excused if you thought the only benefit of this “serverless” offering is cost saving. Cost saving is an important part of all projects regardless if you’re building a city or an e-commerce site.
Serverless computing or Cloud Functions, regardless of how you call it, has its benefits. Most of the solutions are still in beta and they have their limitations such as execution time and how to trigger the services. There are some benefits about this architecture when developing software. I’m not against the concept and I even advocate its implementation. This takes me back to software theory. For many years we have been pushing developers to adopt the following development patterns:
Single Responsibility Principle (SRP)
Serverless computing enforces those patterns. Software Oriented Architecture (SOA) demand that developers think in terms of services. The software is separated in multiple services (SoC), encapsulating the internal works and exposing well define interfaces for clients to use. Micro services are subset of SOA and we can see the same patterns repeating itself here again, Separation of Concern (SoC). Let’s not forget about OSGi architecture, the godfather of Platform as a Service (PaaS) in the Java world. Similar to deploying an application into AWS Beanstalk, OSGi allows you to deploy applications called bundles into the service gateway. The bundle does not affect other services already deployed and can be managed in isolation. The developer does not have to worry about the OSGi environment as the DevOps team owns this piece. So clearly, serverless computing has been around for a long time but under different names.
Well according to “Serverless computing” definitions by the likes of Amazon, there is a major point that we have not yet discussed. Cloud Functions are stateless. What do they actually mean? Amazon says that we can run any code that is supported by their platform. There are multiple ways to track states, for example: databases (ie. RDS), files (S3) and memory (Redis). So why force developers to have stateless cloud functions? I believe that what Amazon and Google are trying to say is: don’t store anything in the JVM memory heap, if you’re writing Java functions. The JVM memory is created when the application is first initialised. Amazon also mentioned that the cloud function is also initialised when triggered and short lived, less than 10 minutes. For the most part of the time, the cloud functions are not even sleeping but destroyed and off the heap. Is the JVM even still running? This is baffling me because the start-up time for the JVM could be an issue here depending on your cloud function. You only get charged when your code is triggered and pay nothing when your “code is not running”. Is the application in idle/ sleep mode? As you can see those questions have nothing to do with architecture but infrastructure cost. Well not entirely, if you take cost as a factor when writing your code, you will design an application which executes fast in order to save money. Developers willing to write highly performing applications will need to rethink their algorithms, which means better code and easier maintenance. I have seen code full of “if” statements which could have been replaced with a recursive algorithm or “switch” statements. In the past, it was more difficult to make developers understand that their bad code was costing the company money. Now we Amazon Lambda and Google Cloud Functions you can justify and back up the claims.
In conclusion, Serverless architecture has been around for many years through different names. Serverless, modular or services architecture enforces software development theories and best practices. Cloud vendors approach to Serverless architecture is not aligned with the facet of software development but the use of their resources. They want to “save you money” by deploying code that are not long live and you get charged only when they execute. This is something out of a business lesson. They are marketing the term even though it does not match the definition. Nonetheless, if it is going to push developers to write better and save money in the process, then I’m for it. But developers should really familiarise themselves with software development patterns and practices such as SOLID, Single Responsibility Principle and Separation of Concerns. They should think in terms of modules and services and write applications that can be easily extensible through orchestration. This will increase your time to market with new services and products. It all fits into today’s agile revolution and lean software development.
posted with permission from the good folks at Kiktronik IT Consultancy Cloud and Software Development.