The case for Functional Programming and Serverless Architecture
Increasing options
Sometimes a new computing architecture is so radical, so compelling, it is hard to see it’s value and roadmap from the start. Think of Infrastructure as a Service (IaaS) — “in their data centre, not yours” albeit virtualized, and also Platform as a Service (PaaS), similarly with greater abstraction, and significantly, easier scalability. The value, from the start, was business value:Business has driven the adoption of IaaS and PaaS.
SaaS — Off the virtual shelf
The pinnacle from the business viewpoint has been Software as a Service (SaaS): Why run your own email, calendar and office services if a vendor will do that at a reasonable cost? That’s why I recommend Google Business Services (G Suite) to small business and start-ups. Why run any infrastructure at all if you can outsource it at a reasonable cost? Reliability probably should not be the reason; Information Security might be, but security architectures are evolving where the service provider never has your data in a form they can decrypt, government interference notwithstanding.
PaaS — Build Your Own
However, if you are building your own application or service, what are your options? You could embrace the infrastructure challenge and go for IaaS, and accept the attendant infrastructure cost of ownership; Alternatively, you could base your entire project on technology at a sufficient level of abstraction that the infrastructure challenge vanishes and base your entire project on technology at a sufficient level of abstraction that infrastructure is not a concern of yours.
Caveat Emptor — Trade Abstraction for Control
But be careful: It’s great that you will not be managing infrastructure, someone else will be — keeping security patches up to date and leveraging off experienced availability architecture, but if you choose a closed-system, ‘Everything-as-a-service” monolithic provider such as ServiceNow, be aware that you don’t have options on how that architecture develops, or to revert to hosting your own technology — that is the case with ServiceNow at least. You are taken along for the ride wherever they go, with the attendant costs: You are a disciple, whether you like it or not.
PaaS — Does it have an Image Problem?
I think that PaaS might have an image problem: Folk get that IaaS means no more data centre to manage; They get that SaaS reduces 3rd-party application procurement and management, but PaaS, as a development platform concept, I don’t think has been selling as well. The compelling concept of the infrastructure challenge vanishing, while still providing a flexible, scalable platform can be improved. Enter ‘serverless’:
The ‘Serverless’ Option
There is another PaaS option that is gaining traction, “Serverless” architectures. It is intrinsically linked with functional programming — what a surprise that this 1960s programming language approach finds such application at this time in history. There’s one more infrastructure trick with serverless, not only is the infrastructure virtualized, abstracted and managed by the cloud provider, but it’s spun up on demand and billed on resource usage(CPU, memory, NW bandwidth). Now one can envision architecture solutions with no mind to the underlying infrastructure configuration, provisioning, scaling, or administration. This abstraction is referred to as ‘Serverless’, and I think it will continue to prosper. You don’t need to know when, or for how long, the underlying VM or container (aka “server”) was up, and you don’t care, it’s not what you get billed for: It’s not so much server-”less” as server-”don’t-care”.
The Progress of Functional Programming
Functional programming found application in the area of developing super-resilient services for the telco industry, such as the Open Telecom’ Platform (OTP) and the Erlang functional programming language. Sometimes it is hard to appreciate it, but if you reduce and simplify, you often improve: That has been the case with safer language subsets such as the MISRA-C for the Motor Industry, and it turns out that if you remove data mutability (assignment), then you benefit in many ways, including, importantly, with multiple threads of execution. With this, and their focus on OTP’s manageability, Erlang/OTP became a great platform for reliable, scalable applications, and the Elixir language, based on the Erland/OTP platform, has provided a more approachable, useful language than Erlang. The application area now is much greater than Telecom — anywhere where you need reliability, even embedded systems, and the web application framework, Phoenix, built on Elixir OTP, provides a platform for super-resilient, scalable, and efficient web-apps.
FaaS — Function as a Service — “Serverless Architecture”
To spin the infrastructure up and down sufficiently indiscriminately to provide this “serverless” service, again you need to reduce and simplify to improve. This is achieved by having the service constrained to be a function, in the functional programming sense of a function. Amazon’s FaaS is ‘Lambda’. For a service to operate on-demand it is convenient to have the services defined as functions, and these functions tied to either APIs or events. Scaling multiple threads of execution benefits; Latency of infrequently executed code suffers, perhaps too much for some applications.
Concept Scalability — Complete Applications
This serverless architecture begs the question, “How far can (should) we take this”? For starters, serverless architecture and functional programming are Turing Complete — it’s possible to develop application entirely in them, but (i) should we, and (ii) will we? I think in the near term we will see applications where they fit best — back-end services, data processing, some, or some component of, web-apps, even chatbots and voice recognition services. Will they be entirely hosted on a serverless platform? Perhaps, if the fit is good enough.
Concept Scalability — Similar Services
AWS have other non-compute services that are analogous to the compute serverless service Lambda, and other vendors provide a similar FaaS to Lambda.
- AWS S3 — Simple Storage service — Charged for MB/month + bandwidth usage + get/put rate. In a similar way, you don’t need to know the underlying infrastructure configuration, provisioning, scaling, or administration. Compare that with provisioning and maintaining your own storage service. Also, with S3, if your application hardly ever uses this resource, you will hardly ever receive bills for using it even though it is continuously available.
- AWS Dynamo DB — NoSQL Service — Can be billed for on throughput or storage amount, but otherwise is a similar business prospect to AWS S3.
- Google Could Functions — Is a Google FaaS serverless offering.
- IBM Blue OpenWhisk — Is IBM’s FaaS offering. Similarly “it costs nothing when not in use”, has node.js, python and java interfaces. It is open source, so you can develop your own infrastructure before deployment if you like that way.
- Microsoft Azure Functions — The Microsoft FaaS Service.
Conclusion
I believe FaaS Cloud Services will become a compelling proposition as a platform of choice for the development of services, microservices or otherwise, that fit the functional paradigm because there is (i) no infrastructure to manage, (ii) no fees when the service isn’t being used and (iii) there is scalability and reliability to be had at a reasonable cost. It may even lead to greater adoption of this programming approach where reliability and scalability are critical.
For mission-critical, high-performance applications, I believe the Phoenix/ Elixir / Erlang OTP is an excellent choice: I’ve developed complete services and applications in Elixir and Phoenix and found it strangely compelling and surprisingly efficient and powerful. There’s already great tooling, and application support should continue to grow.
Resources
- “Functional Programming Application and Implementation” by Peter Henderson — Great early book on functional programming using Lispkit Lisp — https://www.amazon.com/Functional-Programming-Application-Implementation-Henderson/dp/0133315797
- Serverless Ops — A Beginners Guide to AWS Lambda and beyond — Free eBook http://www.oreilly.com/webops-perf/free/serverless-ops.csp
- Functional Programming is probably not what you think — Online article — https://dzone.com/articles/functional-programming-is-not-what-you-probably-th
- Serverless Architectures — Another great online article — https://martinfowler.com/articles/serverless.html
- Good YouTube Video on AWS Serverless Architectures — https://www.youtube.com/watch?v=AcGv3qUrRC4
- Elixir Language and OTP — http://elixir-lang.org/getting-started/mix-otp/supervisor-and-application.html
- Wikipedia on Cloud Computing — https://en.wikipedia.org/wiki/Cloud_computing#Service_models
- Wikipedia on Serverless Computing — https://en.wikipedia.org/wiki/Serverless_computing
- Wikipedia on Turing Completeness — https://en.wikipedia.org/wiki/Turing_completeness
AWS Lambda Features
AWS Lambda is a serverless compute service that runs your code in response to events and automatically manages the underlying compute resources for you. You can use AWS Lambda to extend other AWS services with custom logic, or create your own back-end services that operate at AWS scale, performance, and security. AWS Lambda can automatically run code in response to multiple events, such as HTTP requests via Amazon API Gateway, modifications to objects in Amazon S3 buckets, table updates in Amazon DynamoDB, and state transitions in AWS Step Functions.
Lambda runs your code on high-availability compute infrastructure and performs all the administration of the compute resources, including server and operating system maintenance, capacity provisioning and automatic scaling, code and security patch deployment, and code monitoring and logging. All you need to do is supply the code.
Introducing AWS Lambda functions
The code you run on AWS Lambda is called a “Lambda function.” After you create your Lambda function it is always ready to run as soon as it is triggered, similar to a formula in a spreadsheet. Each function includes your code as well as some associated configuration information, including the function name and resource requirements. Lambda functions are “stateless,” with no affinity to the underlying infrastructure, so that Lambda can rapidly launch as many copies of the function as needed to scale to the rate of incoming events.
After you upload your code to AWS Lambda, you can associate your function with specific AWS resources (e.g. a particular Amazon S3 bucket, Amazon DynamoDB table, Amazon Kinesis stream, or Amazon SNS notification). Then, when the resource changes, Lambda will execute your function and manage the compute resources as needed in order to keep up with incoming requests.
Key Product Features
Extend other AWS services with custom logic
AWS Lambda allows you to add custom logic to AWS resources such as Amazon S3 buckets and Amazon DynamoDB tables, making it easy to apply compute to data as it is enters or moves through the cloud.
It is easy to get started with AWS Lambda. First you create your function by uploading your code (or building it right in the Lambda console) and choosing the memory, timeout period, and AWS Identity and Access Management (IAM) role. Then, you specify the AWS resource to trigger the function, either a particular Amazon S3 bucket, Amazon DynamoDB table, or Amazon Kinesis stream. When the resource changes, Lambda will run your function and launch and manage the compute resources as needed in order to keep up with incoming requests.
Build custom back-end services
You can use AWS Lambda to create new back-end services for your applications that are triggered on-demand using the Lambda API or custom API endpoints built using Amazon API Gateway. By using Lambda to process custom events instead of servicing these on the client, you can avoid client platform variations, reduce battery drain, and enable easier updates.
Bring your own code
With AWS Lambda, there are no new languages, tools, or frameworks to learn. You can use any third party library, even native ones. You can also package any code (frameworks, SDKs, libraries, and more) as a Lambda Layer and manage and share them easily across multiple functions. Lambda natively supports Java, Go, PowerShell, Node.js, C#, Python, and Ruby code, and provides a Runtime API which allows you to use any additional programming languages to author your functions.
Completely automated administration
AWS Lambda manages all the infrastructure to run your code on highly available, fault-tolerant infrastructure, freeing you to focus on building differentiated back-end services. With Lambda, you never have to update the underlying OS when a patch is released, or worry about resizing or adding new servers as your usage grows. AWS Lambda seamlessly deploys your code, does all the administration, maintenance, and security patches, and provides built-in logging and monitoring through Amazon CloudWatch.
Built-in fault tolerance
Lambda has built-in fault tolerance. AWS Lambda maintains compute capacity across multiple Availability Zones in each region to help protect your code against individual machine or data center facility failures. Both AWS Lambda and the functions running on the service provide predictable and reliable operational performance. AWS Lambda is designed to provide high availability for both the service itself and for the functions it operates. There are no maintenance windows or scheduled downtimes.
Automatic scaling
AWS Lambda invokes your code only when needed and automatically scales to support the rate of incoming requests without requiring you to configure anything. There is no limit to the number of requests your code can handle. AWS Lambda typically starts running your code within milliseconds of an event, and since Lambda scales automatically, the performance remains consistently high as the frequency of events increases. Since your code is stateless, Lambda can start as many instances of it as needed without lengthy deployment and configuration delays.
Run code in response to Amazon CloudFront requests
With Lambda@Edge, AWS Lambda can run your code across AWS locations globally in response to Amazon CloudFront events, such as requests for content to or from origin servers and viewers. This makes it easier to deliver richer, more personalized content to your end users with lower latency. Learn more »
Orchestrate multiple functions
You can coordinate multiple AWS Lambda functions for complex or long-running tasks by building workflows with AWS Step Functions. Step Functions lets you define workflows that trigger a collection of Lambda functions using sequential, parallel, branching, and error-handling steps. With Step Functions and Lambda, you can build stateful, long-running processes for applications and backends.
Integrated security model
AWS Lambda allows your code to securely access other AWS services through its built-in AWS SDK and integration with AWS Identity and Access Management (IAM). AWS Lambda runs your code within a VPC by default. You can optionally also configure AWS Lambda to access resources behind your own VPC, allowing you to leverage custom security groups and network access control lists to provide your Lambda functions access to your resources within a VPC.
AWS Lambda is SOC, HIPAA, PCI, ISO compliant. For the latest in Lambda certification and compliance readiness, please see the full services in scope.
Pay per use
With AWS Lambda you pay only for the requests served and the compute time required to run your code. Billing is metered in increments of 100 milliseconds, making it cost-effective and easy to scale automatically from a few requests per day to thousands per second.
Flexible resource model
You choose the amount of memory you want to allocate to your functions and AWS Lambda allocates proportional CPU power, network bandwidth, and disk I/O.