My name is Handoyo Sutanto and I am the co-founder and creator of Lyrid. Today has only been the 2nd week of December of 2020 and there are already so many announcements from different aspects of our lives. Ranging from COVID-19 vaccine news, to AirBnb, and Doordash IPOs. But on top of all the big news, we have bigger news of our own! This month is where we decided to publicly start allowing access to our platform without any restrictions!
Yes, really! You can register to our platform and deploy your own serverless applications in less than 5 minutes without any credit card requirements!
We are a collection of tools and frameworks that are put together as a SaaS platform. You will be able to use these to help build your cloud-native serverless application that can run on multiple, serverless public cloud platforms (such as AWS Lambda or Google Cloud Run).
Lyrid is first and foremost a platform provider for anyone to run their application servers. We create a seamless experience for anyone to develop their idea as efficient and frictionless as possible without compromising security, inter-operationality, and scalability. Multi-cloud serverless compute is one of the tools to get there.
We perform all the build and deployment process for different cloud platforms for our users. So, they can just focus on what is important for them, which is, their business. We mean it when we say, they should just focus on their business and operations, not figuring out things like:
We achieve this by managing and driving your cloud build, deployment and executions using policies, and building more intelligence into the platform on how/where/when your application should be built, distributed and executed. We also deploy and execute your functions using our Universal API Gateway.
Prior to Lyrid, my background for the past 15 years was working on enterprise infrastructure and distributed system software. The workload varied from software that distributes media, transcoding jobs to building scalable storage, and, compute and networking subsystem using various technologies.
I love experimenting with new technologies, but the more I wrote and deployed my code in the cloud, the more I started to realize something.
That is…most of the things we (Cloud Engineers and DevOps) do is actually repetition. We like to think that what we do is so revolutionary, but in most cases are just a combination of your muscle memory (repetition) and guesswork. The challenge of knowing exactly what kind of resources and the amount needed at a given point in time is an ongoing battle for us. There are tons of tools/analytics/monitoring solution software that revolves around these problems.
Here’s what you feel like doing when you guess wrong:
We are not condoning property destruction, but boy I can really relate to them!
I am sure we can do better than this…It was about 4 years ago that I got my first exposure to serverless by AWS Lambda, and was immediately drawn into the technology. Especially, on how it can remove almost all of the guesswork (at least on the question of “how many instances do I need?”). The baked-in efficiency that is inherited from pay-per-execution cost structure is just something that I had never seen before!
However, the benefits that I mentioned above does comes with a cost, almost every managed serverless platform out there (AWS Lambda, Google Cloud Function, Azure Function, etc.) needs to confirm with the cloud’s specifications on how to “run” your function. Case and point, check out these different entry points for your function input/output that the user has to put together in order to make their code work inside the platform:
And because of that, serverless is probably the most misunderstood technology in the past 4 years. The amount of conflicting information floating around the internet is toxic for the growth of the technology itself. Here are some of the information titbits that I found from my personal experience with some of my colleagues that resist deploying a serverless solution:
And here are some examples of the conflicting information about serverless that confuses most people:
One more misconception about the technology is an association that people make. We also want to create this new way of thinking that AWS Lambda != Serverless. AWS Lambda is a compute platform that runs a serverless workload.
They were the one that coined that term so a lot of people associate them together, and this association is a hinderance to the adoption.
We will get into more detail about what we think to be the common misconceptions about serverless on the next upcoming blogs.
Don’t get us wrong…we are actually strong believer in serverless! And we believe everyone should write more of them! So I had a vision of what serverless should be. With that I start this company, and our views are that serverless is a piece of technology and a philosophy on how a developer should build an application:
This is pretty much the driving force that makes us wants to create Lyrid.
At the end, what we want to create is a platform for everyone to test and build their ideas rapidly while still keeping all the best cloud practices built in.
We believe in the power of serverless that given the right tools built around it, that we can make your application run on serverless on any given platform.
We see an opportunity here where we can provide the ecosystem of tools necessary for running applications as efficiently as possible (using serverless on any cloud), thus removing all the guesswork and excess as much as possible.
The bulk of what our platform does, runs after the user submits their application into our platform. Our command line client at this point will zip and upload your code to be submitted into our pipeline.
At the code submission, our platform will wrap the users application with a lightweight wrapper that makes your function run on different cloud vendors that we support.
This wrapped code will be stored inside our infrastructure to be built inside our platform. Then we will execute recipes depending on your current programming language, web server framework, and the target cloud infrastructure. The output of these builds are build artifacts that can be directly deployed into the appropriate cloud vendors.
We will then use those builds to run our deployment process. During the deployment process, our platform will determine how your function application will be distributed globally based on the policies.
This allows the application or service creator the flexibility to determine what is important for their application. Some users need deployment policies that are able to run their compute as close as possible to the end-users while others need to have something that can utilize all the public cloud resources as much as possible.
For execution, your request will be routed to our closest managed region (currently we are managing 3 major regions: US West, South-East Asia and Europe Central) and executed based on the policy that you set globally on your account or at the application level.
Read more about it here in our Universal HTTP API Gateway Documentation.
The mark of good and successful platform companies are its ability to let their users experience the power of the platform and successfully repeat them with consistency.
And with that in mind, we are building an ecosystem with the platform. An ecosystem of reusable components that is built using our serverless-first mindset.
We are also looking to expand our pricing, and build more cost predictability and consistency using analytic data for all tiers of our users that are looking to burst up and down in more efficient way.
Here are some topics that I will be covering, along with some examples of the components that we have successfully integrated or use inside our platform along with some projects from our early adopters:
We will share these processes in future blogs and publish more guides on how to build different things using a mixture of open-source materials hosted on our GitHub page at https://github.com/LyridInc, blog, and video content. It will take us some time to create these contents and if you are interested to know about one of the above topics sooner, just contact us at email@example.com!
As for what we are looking for:
We want to be more available all across the world and expand our network and ecosystem to include as much support for every cloud vendor, web framework, and programming language!
With that said and done, you can register a Free Lyrid account to get started with this following link:
Lastly, please don’t be shy to contact us firstname.lastname@example.org or join our Slack channel to say hi. Let us know what you want to build with our platform!
99 South Almaden Blvd. Suite 600
San Jose, CA
Jl. Pluit Indah 168B-G, Pluit Penjaringan,
Jakarta Utara, DKI Jakarta