DEV Community: Durgadas Kamath

BreathOfLife: How a Serverless App Built on AWS Helped Meet Critical Covid-19 Needs

Durgadas Kamath — Fri, 24 Mar 2023 09:19:54 +0000

The Covid-19 pandemic changed our lives in many ways and one of the most significant impacts has been in the healthcare domain. Hospitals and medical facilities were overwhelmed by a large number of patients and the scarcity of hospital beds and oxygen machines became a very major issue. There was panic all around.

During this time, we (a group of friends from an IT background) realized that many people were struggling to get access to oxygen machines, which were critical for patients with Covid-19. We knew that we needed to act fast and find a way to help people in need.

As we were from IT backgrounds, we decided to leverage technology to build an application that could help people reserve oxygen machines quickly and efficiently. Our focus was to build an application that could be deployed quickly and was cost-effective. After brainstorming and developing a plan, we named the application “BreathOfLife”

We chose AWS as it offered a serverless architecture that was perfect for our needs. The serverless architecture meant that we did not have to worry about managing servers or scaling the infrastructure. The platform could automatically scale based on the traffic, ensuring that our application remained responsive and fast 24x7.

Journey begins…

We started building the React UI (as we were most comfortable with), which we hosted on S3 with CloudFront. The serverless Lambda function was used to handle the API requests, while API Gateway was used as the interface between the API and the application. We chose DynamoDB as the database as it is a highly scalable and cost-effective NoSQL database that can handle large volumes of data ( p.s: we didn’t have that much data ;-) ).
One of the key features of our application was the ability to upload medical certificates or Doctor’s notes to confirm the need for oxygen machines. We also set up email triggers for the admins to approve or reject the reservations, which helped us to manage the large number of requests we were receiving. Notifications were also sent to the users on approval or rejection and when the machine was due for return. We used SES to send emails.
Next, we created a subdomain and registered it with Route 53, which allowed us to create a custom URL for the application and make it easily accessible to the public. This helped us to reach more people in need and made the application more user-friendly.
Cost-effectiveness was a crucial factor for us as we were building this application in our spare time and with limited resources. So, we took advantage of the AWS free tier, and the pay-per-use pricing model allowed us to keep the costs low. We were able to run the entire application for under 1$ per month (the major being route53 hosted domain cost), thanks to decent low traffic and usage.

The partnership with the NGO group was instrumental in the success of the application. The group arranged/purchased oxygen machines and helped us to reach more people in need and spread the word about the application.

As the pandemic continued, we worked to improve the application based on feedback from users and the NGO group. We added new features and simplified the request process thereby ensuring that the machines were made available quickly.

One of the biggest challenges faced was managing the large number of reservations we were receiving. The traditional approach of using spreadsheets and manual record-keeping was not going to be sustainable, which is why we built BreathOfLife. The application allowed us to manage the reservations efficiently and provide real-time updates to the users.

Simple Architecture (Nothing Fancy)

To conclude, the Covid-19 pandemic was a challenging time for everyone, but it also showed us the power of technology and how it can be used to help people in need. By leveraging the serverless architecture of AWS and the commitment of the Rotary group, we were able to build an efficient and cost-effective application that helped people reserve oxygen machines quickly and easily.

What is satisfying is we were able to help many people during a time of crisis. The outcome also highlighted the importance of innovation and creativity during difficult times. As the pandemic continued, many businesses and organizations were forced to adapt to new circumstances, and the ones that were able to innovate and find new ways to solve problems were the ones that thrived.

The experience of building this application taught us many valuable lessons about the power of collaboration and the importance of community. Looking ahead, we believe that the lessons learnt from this experience will continue to be relevant in the post-pandemic world. The importance of technology and innovation will only continue to grow, and the need for collaboration and community support will remain as critical as ever.

Hope this post inspires many more people to come forward and respond to critical situations. Cheers!!

The Serverless Mindset: Strategies for Building Scalable, Event-Driven Applications

Durgadas Kamath — Mon, 13 Mar 2023 14:28:15 +0000

Serverless computing has gained popularity in recent years as a way to build and deploy applications without having to worry about the underlying infrastructure. In this article, we will explore the concept of serverless computing and discuss some strategies for thinking about and building serverless applications.

What is serverless computing?

Serverless computing is a model of cloud computing in which the cloud provider (AWS, Azure, Google Cloud, IBM Cloud etc) manages the infrastructure and automatically allocates resources as needed to run applications. This means that developers can focus on writing code, rather than managing servers or infrastructure.

Some common characteristics of serverless computing include:

Pay-per-use pricing: With serverless computing, you only pay for the resources that your application uses, rather than having to pay for a fixed amount of resources upfront.

Automatic scaling: Serverless platforms automatically scale up or down based on demand, so you don’t have to worry about over or under-provisioning resources.

Event-driven execution: Serverless applications are typically triggered by events, such as a user uploading a file or a message being sent to a queue. This makes them well-suited for building microservices or handling asynchronous tasks.

Thinking serverless

So, how do you go about thinking serverless when building an application? Here are a few things to consider:

Break down: Break your application into small, independent pieces: Serverless computing is well-suited for building microservices, which are small, independent units of code that perform a specific function. By breaking your application into small pieces, you can take advantage of the event-driven nature of serverless computing and scale each piece independently.

Focus on the business logic: With serverless computing, you don’t have to worry about the underlying infrastructure, so you can focus on writing code that addresses the core business needs of your application.

Use managed services: Cloud providers offer managed services for common tasks, such as database management, authentication, and messaging. These services can save you time and effort by taking care of the underlying infrastructure for you.

Use appropriate patterns and practices: There are many patterns and practices that can help you design and build effective serverless applications. Some examples include using queues to decouple services, using a state machine to manage complex workflows, and using a cache to improve performance.

Conclusion:

Serverless computing offers a number of benefits, including pay-per-use pricing, automatic scaling, and event-driven execution. By breaking your application into small, independent pieces, focusing on the business logic, using managed services, and using appropriate patterns and practices, you can effectively design and build serverless applications that meet the needs of your business.

Check out my Youtube Channel for videos on serverless computing. Do like, Subscribe the channel :-)

. Follow me to receive notifications on new articles.

Event-Driven vs Workflows: A Comprehensive Comparison for Developers and Architects

Durgadas Kamath — Thu, 09 Mar 2023 07:38:28 +0000

As cloud workloads become increasingly complex, developers and architects need to carefully consider which orchestration approach to use in their AWS architecture.

Two popular approaches are Event-Driven Architecture and Workflows using AWS Step Functions. In this comprehensive comparison, we’ll take a closer look at both approaches and evaluate the trade-offs between them.
By the end of this article, you’ll have a better understanding of which approach fits your workload and be able to optimize your AWS architecture for maximum efficiency and performance.

Event-driven architecture (EDA) and Workflows, such as AWS Step Functions, are two popular approaches for building distributed applications in the cloud. While both approaches share similarities, they are fundamentally different in their design and use cases.

So, what is Event Driven Architecture (EDA)?

Event-driven architecture is a design pattern in which the system reacts to events that occur within the system or in the external environment. Events can be generated by user interactions, sensors, and other software components. Event-driven architectures are commonly used in IoT, real-time analytics, and microservices.

Why do we need Event Driven Architecture?

Event-driven architectures offer several advantages over traditional, monolithic architectures.

Highly scalable — they can handle large volumes of events and distribute workloads across multiple services.
Highly resilient — they can tolerate failures and continue to operate despite partial system failures.
Highly decoupled — each service can operate independently and without knowledge of other services.

When to use Event Driven Architecture?

Event-driven architectures are best suited for applications that require real-time data processing, high throughput, and dynamic scaling.

They are well-suited for scenarios where events are generated by user interactions, IoT sensors, and other sources that require immediate response.

EDA is also an excellent choice for applications that require complex event processing, such as fraud detection, sentiment analysis, and predictive maintenance.

Before, we dive deeper — lets understand Workflows (AWS Step Function)

What is AWS Step Functions?

AWS Step Functions is a fully managed workflow service that enables you to coordinate distributed applications using visual workflows. With Step Functions, you can build and run workflows that integrate with AWS services such as Lambda, SNS, and SQS.

Workflows are defined using JSON-based Amazon States Language, which allows you to define the sequence of steps in your workflow.

Why do we need AWS Step Functions?

AWS Step Functions provides several benefits over traditional workflow engines.

Fully managed — you do not need to worry about infrastructure management or scaling.
Visual editor — makes it easy to design and debug your workflows.
Seamless Integration with AWS Services — makes it easy to build complex workflows that span multiple services.

When to use AWS Step Functions?

AWS Step Functions is well-suited for applications that require complex workflows that involve multiple AWS services.

It is an excellent choice for building serverless applications that require coordination between multiple Lambda functions, SNS topics, and SQS queues.

It is also well-suited for applications that require long-running workflows, such as video processing or batch processing.

EDA is an example of a choreography-based architecture, where services collaborate by reacting to events. In contrast, AWS Step Functions is an example of an orchestration-based architecture, where a central orchestrator controls the flow of the application by coordinating services.

Maintenance cost and total cost of ownership (TCO) are important considerations when choosing between event-driven architecture (EDA) and AWS Step Functions. Here are some points to consider:

Maintenance Cost:

EDA services require more maintenance than AWS Step Functions since EDA services usually require more manual configuration, monitoring, and troubleshooting.
In EDA, services are often responsible for their own event processing and error handling, which can require more effort to maintain and troubleshoot.
In contrast, AWS Step Functions is fully managed, which means AWS takes care of infrastructure management, scaling, and updates. This reduces the maintenance burden on developers and operations teams.

Total Cost of Ownership (TCO):

The TCO for EDA and AWS Step Functions can vary depending on the specific use case and workload.

EDA services are generally more cost-effective for workloads with high volumes of events, as they can distribute workloads across multiple services and scale more efficiently.

AWS Step Functions is more cost-effective for workloads that require complex workflows with multiple AWS services, as it can reduce the overall number of services required and minimize the number of AWS API calls.

Overall, EDA and AWS Step Functions have different maintenance costs and TCOs depending on the specific use case and workload. Developers and operations teams should carefully evaluate the requirements and trade-offs of each approach before making a decision.

One thing to note is making changes to a complex workflow in AWS Step Functions can be challenging and require extensive testing. On the other hand, adding new functionality to an event-driven architecture can be less prone to regressions and may require less testing.

This is because AWS Step Functions are designed to control the flow of a complex workflow by coordinating multiple services. If the workflow changes, it can affect the behaviour of all the services that are involved in the workflow. This can make it difficult to predict the impact of a change and require extensive testing to ensure that the workflow still functions correctly.

In contrast, event-driven architectures are designed to react to events in a decoupled manner. Each service is responsible for handling its own events, and adding new functionality can often be done without affecting the behaviour of other services. This can make it easier to make changes and add new features without the risk of causing regressions.

However, the general trade-off between the two approaches is that AWS Step Functions can provide more control over complex workflows but require more effort to maintain, while event-driven architectures can be more flexible and easier to maintain but may require more design upfront to handle complex workflows.

Conclusion:

Choosing between Event Driven Architecture and AWS Step Functions can be challenging and depends on the specific use case and workload. To make the decision process easier, developers and architects can go through a checklist to evaluate the requirements and trade-offs of each approach.

Few factors that I can think of:

Workflow Complexity: If the workload requires a complex workflow with multiple AWS services, AWS Step Functions may be the better choice.
Event Volume: If the workload involves high volumes of events, Event-Driven Architecture may be more efficient and cost-effective.
Error Handling: If error handling and retries are critical to the workload, AWS Step Functions may provide more control and visibility.
Service Isolation: If it’s important to minimize the impact of changes or failures to individual services, Event-Driven Architecture may be more appropriate.
Maintenance Burden: If minimizing maintenance burden is a priority, AWS Step Functions fully managed infrastructure may be more desirable.

Ultimately, the decision should be based on the specific requirements and trade-offs of the workload. By going through this checklist and considering these factors, developers and architects can make a well-informed decision and choose the approach that best fits their needs.

If you found this post helpful, follow me for more upcoming content! And don’t forget to leave a comment with your feedback. Your input is important to me and will help me create even better
content in the future. Thank you for your support!

Improve the speed of your AWS lambda API (NodeJS) with these two easy techniques.

Durgadas Kamath — Fri, 03 Mar 2023 14:21:34 +0000

Being inquiring is fine, but striving for improvement is better. I have been using AWS Serverless services (Lambda, DynamoDB) with NodeJS as the runtime . I’ve often wondered how to reduce latency while developing APIs that integrate with AWS services.

While adhering to best practises with minimal imports and other requirements is essential, there are two simple measures you can do to further enhance the speed of your Serverless application.

callbackWaitsForEmptyEventLoop = false

Our lambda API accepts (event, context, callback) as an argument when it is defined. NodeJS leverages an event loop, and if you use a callback to deliver a response, it delays sending the output until the event loop is empty.

If this property (callbackWaitsForEmptyEventLoop) is set to false, the callback will immediately return the response, and any outstanding events will run on next invocation.

context.callbackWaitsForEmptyEventLoop = false;

AWS_NODEJS_CONNECTION_REUSE_ENABLED = 1

A lambda implementation will nearly always include integration with AWS services. When interacting with AWS services using the aws-sdk, a fresh TCP/IP connection is always established. This increases latency, which may potentially be longer than the time needed to query DynamoDB:-).

So, AWS offers a “Connection Reuse” method. Simply changing the environment variable AWS_NODEJS_CONNECTION_REUSE_ENABLED to 1 will enable this.

Another approach is to add keepAlive value to the options while configuring the AWS client.

Note: This parameter is enabled by default if you’re using the AWS SDK version 3.

Check out my YouTube channel for videos on serverless computing.

Follow me for more of interesting articles. Happy Learning #AWSCommunity #AWSCommunityBuilder