As the technical architect here at ImVitro, I am responsible for designing the structure of our software Embryoly and overseeing its development with the engineering team. In this blog post, I will walk you through the reasoning behind two key decisions made while building Embryoly around AWS cloud computing and serverless architecture. This can be interesting to any audience, but more particularly, for technical architects and engineers working on a SaaS product hosted on a cloud platform.
If it is your first visit to ImVitro’s blog, let me first introduce you to the solution we have developed. ImVitro provides a software as a service (SaaS) platform; its first feature aims at automating embryo evaluation, to make it faster, less variable and more accurate.
Now, let me explain why AWS cloud computing?
Before answering this question, here is a general definition of cloud computing: According to Amazon web services (AWS) experts, “Cloud computing is the on-demand delivery of IT resources over the Internet with pay-as-you-go pricing. Instead of buying, owning, and maintaining physical data centres and servers” .
Here at ImVitro, we take the security and reliability of the platform very seriously, especially because we are dealing with medical data. Thus, we have investigated AWS security measures thoroughly and compared it to on-premise solutions. Conventionally, on-premise solutions offer greater data protection than cloud computing. However, with AWS, we are leveraging a myriad of cloud security services to protect data and comply with medical regulations (e.g. CE marking) such as: Data encryption on the client side, encryption on rest; automatic encryptIon of the data flowing across the network at the physical layer before transmission, continuous monitoring, multi-factor authentication, access control management and other services. We have come to learn that some clinics require that their data does not leave their country or region: thankfully, AWS is opening servers in an increasing number of regions to bypass this limitation.
And now, why Serverless?
The serverless concept was introduced by AWS in 2014. The name “serverless” might be a bit misleading, as we always need a computing engine and storage to execute or run an application! In simple terms, serverless means that the cloud will dynamically allocate resources and storage to the application ONLY when it is running.
Thus, instead of reserving a machine, which needs to meet the peak demand at all times (plus a safe margin), the cloud will take care of allocating the resources upon demand. For example, the cloud might allocate 16 CPU and 250 MB of memory at the peak hours, while downgrading it to only 4 CPU with 16 MB when a couple of clients are using the platform. Furthermore, no resources are allocated at all when no one is using the platform.
As a live example, here at ImVitro, the peak usage of the SaaS platform normally is in the early hours of the morning, when the embryologists typically examine the embryos to be potentially transferred, while the demand decreases in the afternoon. Also, it is mostly idle at nights and during the weekends. As a consequence, the allocation of resources will vary a lot during the day.
Below is a graph representing the variation on the number of invocations of one of the functions used in our SaaS platform, for a period of three months. As demonstrated in the graph, the number of invocations vary by time and this demonstrates the importance of serverless when compared to the reserved instances model.
Figure 1: An illustration on the variation of the number of invocations for a certain function for a period of 3 months.
Yet, another advantage of serverless consists in getting rid of the overhead work of managing the servers, memory, network, scalability…etc. Consequently, the engineering team at ImVitro can spend more time on the functionality of the code itself and on building innovative features.
Moreover, the cost is another important factor for favouring serverless computing over reserved instances. With serverless, we pay only when the computing services and storage are used. Thus, the cost may be reduced drastically by simply converting the architecture to be serverless. For instance, functions running on Lambdas in Production costs us less than 4$ per month. This is roughly 10% of the cost, when compared to the scenario where the platform runs on a medium reserved EC2 instance. As a result, this allows us to make our solution more cost effective to our end customers.
Last but not least, it is important to highlight that serverless computing is environmentally friendly, given that the machine is reserved only when it is needed instead of 24/7.
To conclude, hosting Embryoly’s serverless architecture on AWS offers security, scalability, cost efficiency and accelerated innovation while complying with medical data protection.