Want to understand where Liberty InstantOn fits in the cloud-native serverless containers world, then read on.
Why cloud for your applications
The top two reasons businesses are adopting cloud are typically to reduce costs and increase agility. You're looking to reduce spending on IT infrastructure and at the same time, tap into the agility promise of the cloud to make your business more innovative.
Cloud enables you to pay for the infrastructure you use in a way that aligns better with business success. This is especially true with serverless technologies where if your applications have no work to do, you pay nothing. The corollary to this is when work does come in, or grows rapidly, serverless enables that rapid scale.
Why containers for serverless
Functions as a Service (FaaS) environments are one option for serverless but they restrict how an application can be written and at the same time, tie those applications into the cloud vendor's opinion. Containers as a Service (CaaS) environments have no such limitations, and with CaaS solutions available in all leading clouds, your applications are portable too. But what should you put in those containers?
Serverless performance needs
As with any environment, performance is going to be incredibly important. It's directly aligned with your cloud costs and customers' experience. Contrary to popular belief, under load, serverless environments re-use instances. This means the long-standing requirements of high throughput and low memory under load still apply. The higher the throughput and lower the memory, the fewer instances you will need, and the lower your cloud bill.
Where serverless is unique is in the fact it can scale to zero and also potentially scale up more rapidly. When scaling up, and especially from zero, you need your instances to be ready to respond to a first request quickly. If they don't, then your customers' experience may suffer.
Fast start with Liberty InstantOn
One approach to starting fast is to use 'native image' compilation, but this can seriously impact performance and requires development to be done on a JVM with production on a native image, which is a shift-left anti-pattern.
Liberty InstantOn takes a different approach - it provides the ability to take a 'checkpoint' of a running instance and then 'restore' it as many times as you like from the point the checkpoint was taken. The restore is super fast and because it picks up from where the checkpoint was taken you're not waiting for the JVM to start, classes to be loaded, and so on.
With Liberty InstantOn a basic application can start and respond in around 100ms and a full enterprise application in around 300ms, and because it's running on a JVM you still get the great throughput and your dev environment can match production - it's InstantOn without compromise.
Give it a try