<img height="1" width="1" style="display:none" src="https://www.facebook.com/tr?id=160269078105920&amp;ev=PageView&amp;noscript=1">
This service has been removed!
Service successfully added!
Sign up for our blog, talk to a specialist, or just send us an email

Event-Based Computing (AWS Lambda) and the Serverless Future

Tuesday 29 of May, 2018./ Reading Time: 6 minutes./ By Roy Abarca

What is Event-based Computing?

 “An event-driven computing service for dynamic applications,” which means this essentially allows event-based communication between your app and the cloud, without depending on a server to handle the heavy lifting.

 An EBA is a structure based on parts that interact predominantly through event notifications, rather than direct method calls. An "event notification" is a signal that carries information about an event that has been detected by the sender. While you're probably familiar with events like button clicks, events can be defined as almost any technologically possible condition or occurrence. Notifications can be used to carry any type of domain-specific information in any type of system—embedded, GUI-based, distributed, or other.

What is AWS Lambda?

AWS Lambda is a function in the AWS cloud that allows you to run code without provisioning or managing servers. You pay only for the computation time you consume - there is no charge when your code is not running. With Lambda, you can run code for virtually any type of application or backend service - all with zero administration. Just upload your code and Lambda takes care of everything required to run and scale your code with high availability. You can set up your code to automatically trigger other AWS services or call it directly from any web or mobile app. You are only charged for every 100ms your code executes and the number of times your code is triggered.

AWS Lambda is a server-less computation service that runs your code in response to events and automatically manages the underlying computation resources for you. AWS Lambda can extend other AWS services with custom logic, or create back-end services that operate at AWS scale, performance, and security. AWS Lambda can automatically run code in response to multiple events, such as modifications to objects in Amazon S3 buckets or table updates in Amazon DynamoDB.

You can also schedule a Lambda function like you usually do with a cron job. This is particularly helpful when you need to run a code at specific times during the day or even the week. The syntax used is the same; you use cron expressions to configure it in CloudWatch Event Rules.

Exposing Lambda Functions as Web Services

Using the API Gateway (AWS Service), you can provide web access to your Lambda functions. The AWS API Gateway is the only way to expose your Lambda function over HTTP.  

Amazon provides this service to enable users to 'create', 'publish', ‘monitor’, ‘maintain’ and 'secure' their APIs. It acts as a 'gateway' for the end users to access your application's business logic, or in this case, Lambda functions. If you have an existing public API or are planning to make your application public, you might consider deploying it on the AWS API Gateway to achieve better performance, scalability, and availability with lower maintenance and cost. In addition to deploying it on the API Gateway and getting rid of server maintenance, you can also expose your existing Lambda functions as APIs using the API gateway. Deploying an API doesn’t cost anything. You only pay based on the number of requests your API receives and the amount of the data it sends back.

The Serverless Future

Things to consider in this structure.

Microservices are a way of breaking large software projects into loosely coupled modules which communicate with each other through simple APIs. Microservices seem to be simple to build, but there’s more to creating them than just launching code, running in containers, and making HTTP requests between them. Here are some important points that you should consider with any new microservice prior to development:

  • Microservices do not require teams to rewrite the whole application, if they want to add new features.
  • Smaller codebases make maintenance easier and faster. This saves a lot of development effort and time, therefore increasing overall productivity.
  • The different parts of an application can be scaled separately and are easier to deploy.

If you’re not completing said tasks or cycling very quickly, you probably shouldn’t be using microservices because you’re not reaping the true benefits. To maximize the effectiveness of microservices, you need a continuous delivery workflow. This workflow, at the least, must be defined and preferably automated. Automations become necessary as the volume of microservices increases. The controversial question within this field is, where to test the application. We’re going to talk about testing later, but you do need to have the microservice running in production in order to fully test. These questions fall into three categories: organizational concerns, architectural concerns, and developmental concerns.

  • How will your new service be deployed and upgraded?
  • What is going to be the QA strategy?
  • How will the settings/configuration of the services be handled?
  • How will it be secured?
  • How will it be discovered?
  • How will it scale with increasing load?
  • How will it handle failures of its dependencies?
  • How will the rest of the system handle the failure of the new microservice?
  • How will it be upgraded?
  • How will it be monitored and measured?

While it might not be necessary to have very sophisticated answers to each of these questions, it is important to consider each one and be aware of any structural limitations your microservice may have. For example, your new microservice might first be deployed without any disaster recovery or region failure tolerance, and then upgraded later to include that kind of resilience. Being aware of what your microservice can and cannot currently do is crucial, and knowing the answer to each of these questions will help you continue to tweak and improve it until it evolves into a mature, resilient, and reliable system component.

Every piece of technology has a downside. If we consider microservices on an organization level, the negative trade-off is clearly the increase in the complexity of operations. There is no way a human can ultimately map how all of the services are talking to each other, so companies need tools to grant visibility of their microservice infrastructure.

Other Event-based Computing

One of the cloud services out there is Azure.

The Microsoft Azure Service Fabric is a microservices platform that is available to every microservice that can be either stateless or stateful. Stateless microservices do not maintain any mutable state outside of any request and its response from the service. Stateful microservices maintain a mutable, authoritative state beyond the request and its response.

There are 2 reasons why stateful microservices are important:

1) The ability to build high-throughput, low-latency, failure-tolerant OLTP services like interactive storefronts, search, Internet of Things (IoT) systems, trading systems, credit card processing and fraud detection systems, personal record management etc by keeping code and data close to each other on the same machine.

2) The application design simplification as stateful microservices removes the need for additional queues and caches that have traditionally been required to address the availability and latency requirements of a purely stateless application. Since stateful services are naturally highly-available and low-latency this means fewer moving parts to manage in your application as a whole. 

Azure Service enables you to build and manage scalable and reliable applications composed of microservices running at very high density on a shared pool of machines (commonly referred to as a Service Fabric cluster). It provides a sophisticated runtime for building distributed, scalable, stateless and stateful microservices and comprehensive application management capabilities for provisioning, deploying, monitoring, upgrading/patching, and deleting deployed applications.

Azure powers many Microsoft services today such as Azure SQL Databases, Azure DocumentDB, Cortana, Power BI, Microsoft Intune, Azure Event Hubs, many core Azure Services, and Skype for Business to name a few. Azure also allows you to start as small as needed, and grow to a massive scale with hundreds or thousands of machines, creating Service Fabric clusters across availability sets in a region or across regions. 

About Avantica

If you are looking for a software partner who will work towards your own business goals and success, then Avantica is your solution. We offer dedicated teams, team augmentation, and individual projects to our clients, and are constantly looking for the best methodologies in order to give you the best results.

 

Let’s start a project together

Join our newsletter

PREVIOUS
MVVM + Data Binding + Kotlin = Efficient and Easier Code
NEXT
Visual Search for Mobile eCommerce Applications and UX