chris - Fotolia
How microservices, lambda and functional computing differ
While the terms lambda, functional computing and microservices may get intertwined, it's important to understand what makes them unique. Here, we dive into the differences.
Today, developers in the midst of distributed development are likely to encounter three popular terms: functional computing, lambdas and microservices. Though the differences might seem subtle, understanding the differences among these three terms may determine a development shop's ability to successfully implement a distributed architecture.
All three might mean the same thing or different things, depending on the combination. Let's take a look at what makes these terms unique and also why they are connected.
Understanding functional
The term functional computing is generally derived from math, where a function is something that operates in such a way that the same input will always produce the same result. We might say that variable y is a function of variable x, written as y=f(x). The key point here is that, if the same input value (x) always generates the same output value (y), then any copy of our function will produce the same result -- no matter how many times it runs.
Understanding lambda
In software, most functions have names that are called when the function is used. A lambda is a class of anonymous function (not to be confused with AWS Lambda, the formal, event-driven, serverless computing platform offered by Amazon). An event or external stimulus runs a lambda function, meaning it doesn't require a name since it's linked to the event or stimulus that causes it to run. For instance, we could make a lambda by saying, "If input-stimulus happens, output equals f(input-stimulus)." The code that does the functional work is provided with the identification of whatever invokes the code. In other words, lambdas aren't named; they just run.
Understanding microservices
The generally accepted definition of microservices is that they are small and composable units of logic used to build applications. However, that definition isn't really precise. Some say that a microservice is like a separately deployed application component. Others think a microservice is not just a separately deployed component, but also a component you can deploy when needed that scales in response to changes in workload. In other words, they think a microservice is similar to a function.
One thing that we can say for sure about microservices is that microservice applications are not anonymous. Microservices are explicitly called through named APIs, and they are usually accessed through an API broker, which also handles instance replication and load balancing. This happens because microservices bring the notions of software componentization and component reuse to the extreme. Scalability is built into lambdas, so microservice code is required to create them. It's that dependence on implementation that creates a wide variation in interpretations of what microservices are. There's no specific definition because there's no specific implementation.
The importance of state
Nowhere is the difference among functional computing, lambda computing and microservices clearer than in the way that they approach state, or context of use. Remember that functional and lambda components are nameless and inherently stateless. In theory, stateless implementation of microservices is possible. But fully stateful implementation is also possible if a form of state control is used. Stateless microservices look like named functional or lambda elements, and stateful ones look like minimized traditional software components.
The middle category of state control is usually handled in microservice implementations in one of two ways. First, the call made to the microservice API can include any state information that the caller needs to consider. It's not difficult to make a web-based application support this kind of source-provided state, although it is more difficult with sensor inputs, like internet of things (IoT) sensors. The second approach is called back-end state control. That involves maintaining a database in which state information is stored and is referenced by some transaction or source identifier. When a call is made to a microservice instance, it contains that ID. The microservice (or the API broker) then uses that ID to access the back-end state repository and obtain the correct state information.
They all come together
In a sense, functional computing, lambda computing and microservices may be growing together on stateful behavior. Amazon introduced AWS Step Functions as part of its AWS Serverless Platform, which also includes its functional computing service, AWS Lambda. Step Functions does two things. First, it provides a means to organize functional and lambda elements into coordinated processes by creating a graphic relationship of how they connect. Second, it provides a means to pass information and even maintain transaction state across multiple events. While Step Functions doesn't let you simply incorporate legacy components into functional computing, it does make it easier to develop function-based applications and transition between functional and legacy application elements.
Microsoft may take this even further. Its Durable Functions feature includes a series of design patterns that allow developers to orchestrate multiple functions into a single application, similar to the approach that Amazon takes. Durable Functions can also be truly durable; they can behave like stateful components that run continuously and wait for events, rather than being triggered by them. You can also write multistep durable functions, which are functions that require approval before they continue. This may eventually morph into the ability to orchestrate microservices and other stateful elements into functional and lambda models.
Google calls its functional and serverless computing "microservices," but it adheres generally to the same true functional computing and lambda model as Amazon and Microsoft. Google does not offer a means of state control comparable to its competitors. In fact, there are indications that Google may focus its serverless computing on mobile-specific applications rather than elect to compete with the more general capabilities of Amazon and Microsoft.
At the core of all of this is the notion of event-driven computing or reactive programming. This is a model where software responds to conditions rather than create them. Because of the huge base of software in use and the learning curve needed to adopt this new approach, it's difficult to say how far this model will go or how fast it will progress. However, IoT would be a truly massive driver of change. Nearly every enterprise has some application for functional, lambda and microservice computing today. The key will be to understand what the terms mean, see how they evolve and keep planning and development in sync with the times.
