Since AWS launched AWS Lambda in 2014, we, Cloudway, have been using serverless components to build architectures. Since 2015, we have been using a serverless-unless or serverless-first approach and since then, we have delivered many applications built around serverless architectural components.
In recent years, however, we have seen the hype increase and with that hype, the definition of serverless has also become broader. As a result, the definition has become less clear.
In this blog post, I will go through the different perspectives and definitions to eventually reach our Cloudway definition and the reason why we have chosen this definition as a basis.

As one of the most recent start-ups within the Cronos Group, Cloudway has gained a strong brand name for itself as a provider of cloud-native solutions, since its official launch in June 2018. About time to let the founders Michael Willemse and Stef Ceyssens explain their innovative and groundbreaking company.

Java requires that big JavaVM to start and during cold starts this together with initializing your code, can take up to twenty seconds. There is also the memory that the JavaVM uses. Both add to the cost of using Java for your lambda. Compare this to a Node, Python or Go lambda and the conclusion would be Java is slow and costs me more.

There are solutions for these problems, but most of them avoid the actual issue (the JavaVM) and are more or less workarounds, like keeping a Lambda warm thus avoiding the cold starts but increasing the number of executions. But I wish to get rid of the JavaVM and that's why ...