Serverless Architectures II/III: Business benefits and use cases
This is the second article of the serverless series about business benefits and why industries are embracing this type of architectures
In the previous article, I kicked-off this series with an assessment contrasting design and technical trade-offs. I will shift the focus towards business reasons driving adoption and some of the most common use cases.
Business benefits
Quicker time to market
Rapid iterations that facilitate experimentation are a perfect fit for agile methodologies. This happens because it allows development teams to focus on the deliverable instead of other unrelated items; there is no provisioning time, no need to go through capacity planning, disaster recovery planning and other activities that usually delay the start and release of new ideas.
One of the well-known success cases is cloud guru [3], which migrated from EC2 instances to serverless functions and from RabbitMQ to SQS and SNS. They gained such a massive competitive advantage that catapulted the startup to serious territory quickly. This is because of quicker time to market and obviously cost efficiency, which will be covered in this article.
Off-the-shelf domain knowledge
When a Software Architect is evaluating different options for a solution, you can either spend significant effort designing, building and testing a service or pay for an available one. For instance, if you need a payment gateway and you have to decide between building one or using either Stripe or PayPal; in the majority of cases I would be leaning towards paying for the usage of existing solutions with millions of users rather than building our own. There are several reasons for this. Firstly, the building effort. Secondly, many hours to acquire the domain knowledge of how it works and integrates with Third Parties.
Risk mitigation strategy
Using a serverless service can be an effective risk management strategy by shifting some risk away from your solution. Following the example introduced in the last point about payment gateways; it transfers risk to a third party and also it can help take the PCI compliance off your hands reducing risk from regulatory point of view.
Switch from capital expenditure to operational
Start-ups and small and medium businesses are benefited by the serverless opportunity to switch from capital expenditure to operational. Being able to try new ideas and iterate fast without big upfront commitments. From this perspective, it increases the threat of new entries as it lowers the barrier of initial capital investment. Large enterprises find this technology appealing because it allows them to reduce operational expenditure and shift risks to a third party.
Reduction on data center costs
The costs of running data centers like power, cooling and floor or rack space. We should also include indirect costs like security, data center maintenance, management of the data center and so on. Plus the Disaster Recovery data center costs savings.
Avoid hardware costs
With serverless, the cost of networks, servers and storage to run the solution and other costs like backup and disaster recovery are avoided upfront. This is one of the major shifts from the early Internet beginnings until today.
Reduce implementation costs and increase productivity
The cost of setting up, configuring and testing the solution is reduced because there are fewer components to configure and test. The testing surface is reduced. Also, includes the costs of setting up things like backups, disaster recovery, etc.
Shared security responsibility model
The shared model reduces responsibility but it does not eliminate it. The cloud provider is responsible for physical security of the data center plus all components running below the functions from networking to containers. The owner of the application is still responsible for securing application logic, data in transit and at rest, identity and access management, function permissions and roles, secrets storage management, 3rd party services and integration, among others.
Better skill set fitting
Teams are able to select the most suitable programming language to develop new functions. This allows them to better fit the available skill set in your team and the requirements to be implemented. For example, there are several examples of existing source code and skills in PHP migrated to lambda using different frameworks and techniques.
Hire and retain top talent
There are many factors that will favor retention and hiring of the best Software Engineers. Doubtlessly, top performing Software Engineers usually want to work with best and latest technologies. Developers, software architects, and operations experts who are top performers are compelled to use technology to address the business and technical problems that they see. To do this, they need cutting-edge tools, processes, and culture.
Not every workload is the right fit for serverless
When serverless may be inadequate
Potential high migration costs
In many cases firms underestimate costs associated with cloud usage, migration and exit strategies. I think the best way to analyze the degree of “lock-in” is by simply calculating the migration costs and performing a cost benefit analysis. In majority of cases vendor migration tools behave like black holes, a lot of gravity to get in but not much help on the opposite direction.
Different aspects to think about regarding migration and exit strategy:
- Data
Frequently data will have the biggest cost component of the migration. For instance if you decide to use DynamoDB and later on you realize you want to migrate to MongoDB; then you may face some challenges, and they normally translate into cost. An interesting case of a 6 million records migration from DynamoDB to MongoDB to understand this point [4]. The lesson is to do the cost benefit analysis first and whenever possible select a portable technology across vendors.
- Code (functions)
Migrating your functions is somehow simple, however it will not happen in isolation as other related services will also need to be migrated at the same time.
- Service configurations (API gateways, authentication, identity and access management, function permissions and roles, secrets storage management, etc.)
These proprietary services are needed to compose complex serverless applications
- Documents or other unstructured data
These objects should be the easiest to migrate across
- 3rd party services integration
In cases where moving to a different vendor will erode all benefits gained from serverless, we should consider different options.
Dependency on services
You may be forced to upgrade cause a vendor is decommissioning a version of a service. Or even worth, they could be closing down the service in its entirety.
Hybrid data center approaches with downstream integration
Careful analysis should be performed whenever downstream systems are not elastic in the same way as the serverless solution. Imagine a hybrid approach, in which you decide to build your front-end using serverless components, however your back-end is in your data center. Maybe an ESB and a mainframe sourcing data. Special attention will need to be taken regarding throttling requests to your back-end since front-end will be able to cope with any increase in the workload, but your back-end will not.
Serverless use cases
In this section, five use cases will be presented. Each one with different requirements that influence the design and architecture.
The ubiquitous web application
This is one of the most widely known scenarios to serve static web content or dynamic web applications that require high availability, reliability, cost efficiency and low maintenance among other Non Functional Requirements depending on particularities.
Furthermore, APIs are published usually via an API Gateway for different purposes such as selling data, offering a service (SaaS), for voice activated actions such as Google Home or Alexa Skills, for your web app; realistically an endless list of scenarios can be listed.
The following diagram describes a simple web application with some of the most commonly used services:
I will write a separate article about how each of the Architectures work. Not part of this one.
Mobile back-end
Mobile developers that need a back-end to synchronize data across mobile devices, authenticate users and run data analysis periodically will benefit from this type of architecture.
The following diagram describes a simple mobile back-end using a GraphQL service to execute queries and mutations of data from different sources. This allows you to hide the complexity of existing systems, such as microservices, legacy infrastructures or third-party APIs behind a single GraphQL interface. It can also be connected directly to a Database if needed [9]. There are lots of solutions/permutations, I am presenting one example to describe the scenario.
Usually this will be supplemented with some other service to gather and analyse user activity like Google Analytics.
IoT event stream processing
Event driven architectures are a perfect fit for IoT devices. This architecture enables IoT devices to keep in sync, send bi-directional messages, register / unregister devices, pairing, device settings updates and so on.
The following diagram from Azure IoT describes a high-level reference architecture. It is dividend into 3 sections, one for things, another for insights and finally actions.
IoT edge devices connect through a Gateway (IoT Hub) for further processing (stream) that enable to take actions. Machine Learning will aid decision-making based on data previously transformed. Cross cutting concerns are represented at the top of the diagram (security, deployment and high availability & Disaster Recovery).
The following diagram is an excellent snapshot of the number of global IoT projects per region. Interesting to note that the first 3 segments account for more than half the IoT projects.
Some of the best applications of IoT architectures are:
- Smart house devices. Smoke detectors, switches, plugs, sensors and lights offer a great opportunity to reduce cost and improve lifestyle.
- Industrial applications for remote monitoring, control industrial devices, telemetry data, alerts, security, etc.
- Smart cars applications for driverless, telemetry for insurance and improved services, garage door integrations, etc.
- Agriculture. Useful in farming and livestock management including the use of drones, sensors for soil composition among many others.
- Wearables. Fitness bracelets, GPS trackers, implantable gadgets, and many other IoT applications.
Serverless data lake
This type of architecture is suitable for businesses intending to replace the legacy Data Warehouse or start a new one from scratch. Usually they are facing the following challenges:
- Data is spread across different sources and want to merge into 1 single point of access
- Data is not efficiently accessible due to growing volumes and sourcing queries from RDBMS which is not scalable for analytics
- Data is not modeled in the best way to consume it for analytics
- Data is normalized which is not suitable for analytics
The following diagram provides an architecture reference for a generic data lake scenario in which reports, analytics and dashboards are required for business insights.
Different data sources will be pushed into serverless ETL services that based on different catalogs will model data into the Data Warehouse structure. Several services can be used to query and analyze data to be presented to the final user in dashboards, analytics tools, reports, emails, etc.
Real-time file processing
This architecture is appropriate for processing files that require some type of transformation such as thumbnail images, trans-code videos, index files, process logs, validate content, and aggregate and filter data in real-time.
The following diagram summarizes a simple architecture to process files asynchronously and store results either in an object store or a database depending on the case.
The publish subscribe messaging model allows messages to be broadcasted to different parts of a system asynchronously. In this case, functions are used to process messages which is a great fit due to their elasticity and reliability.
References
[1] Why You Might Not Need Serverless By Chris Riley
[2] The business case for serverless by Zack Kanter
[3] How we migrated our startup to serverless by Ivan Montiel
[4] Yes I had to migrate 6 million records from DynamoDB to MongoDB by Asanka Nissanka
[5] Top 10 Security Risks in Serverless Architectures by Israel Thomas
[6] Azure IoT Reference Architecture by Nandakishor Basavanthappa
[7] AWS Serverless Reference Architecture for Real-time File Processing
[8] Our data lake story: How Woot.com built a serverless data lake on AWS by Karthik Kumar Odapally and Chaya Carey
[9] GraphQL Big picture (Architecture)
[ I. Design and technical trade-offs ] [ II. Business benefits ] [ III. Market offerings ]
