Fotolia
A comparison of microservices and functional programming concepts
While often seen together, microservices and functional programming are two different animals. Find out where these disciplines overlap and, more importantly, where they don't.
Cloud providers often use the terms microservices and functional programming together, as do reports on cloud services and software trends. Although the two terms overlap at times, there are fundamental differences between them, especially regarding software design and development.
Ideally, all developers would follow the same universal glossary when it comes to software terms. The problem remains that popular definitions of the terms microservices and functional programming tend to differ from the classic definitions. As a result, we often have to revisit the basics of both microservices and functional programming concepts to talk about the similarities and differences in the programming approaches.
Amount of logic
Both functional programs and microservices are small, meaning that both contain the minimum amount of logic. Don't expect to write big microservices or functions. Also, expect that there could be a lot of application workflow connections that might affect performance. With this in mind, you should use either microservices or functional programs with discretion since major quality of experience problems could develop.
However, the reason for the small size is somewhat different for each concept. Microservices are small in order to facilitate generalization, which enables developers to compose applications from a collection of small functional units. Functional programs are small because they're designed to perform limited tasks. Functional programs are not composed into applications as much as they're linked with events, which is a key difference.
Deployment elasticity
Another similarity between microservices and functional programming concepts is a shared goal of deployment elasticity. In most cases, both functional and microservices components are designed to scale and load-balance as demand increases. They're also designed to replace faulty instances. The greatest point of similarity for the two is that neither functional programming nor microservices should store data within a component.
Stateless and stateful behavior
Functional programming concepts take the stateless idea to the extreme, while microservices generally accept some form of back-end, outside-the-component state control. Functional programming focuses on creating the same outputs from the same inputs. This means there is no external state control, which is another focal difference between microservices and functional programming. In functional programming, you can write functions where nothing but input influences output.
Many microservices exhibit stateful behavior because they maintain state through a database, which is called back-end state control. It's important to design a stateful microservice so that state data can be accessed from a nearby source, such as a back-end database. However, it's wise to think about stateless behavior and avoid back-end state synchronization when possible. Stateful behavior is necessary for microservices, but the context of a given message should be included in the message. Multistep screen dialogs, for example, can easily carry a sequence code along with the data to show dialog process. This approach can be used for both microservices and functional computing, although it is most important in the latter.
Invocations
Given the soft definitions we find today for microservices and functional programming, it can be tricky to know which of the two you're writing. A good way to find out is to look at how microservices and functional components are invoked. Functional programming operates on asynchronous outside triggers referred to as event flows. Microservices are called by other software when they are needed as part of a workflow. If you want to call a small component at a specific point in processing, you're probably calling a microservice. If you want to respond to something external, that's along the lines of functional programming.
Scheduled functions have sequences rather than workflows, and each step in the processing of an event is likely determined by the step before it. It's critical for functional programmers to explore how they're going to sequence the steps in their scheduled series of functions. You should think of your functional application as a series of connected steps that manage information exchanges and use triggers to move from one step to another.
With microservices, all activations of your software are explicit calls, so you don't have to worry about figuring out how to sequence steps. Concurrency is the key with microservices. Event-driven functional programming is sharable across applications, scalable under load and replaceable if something fails. Microservices offer more adaptability with respect to things like stateless behavior, and some variations in development can reduce the extent to which the microservices can be broadly used.
The final issue to consider is asynchronicity. When a software element processes inputs from multiple sources, it has to ensure that the inputs don't collide and affect processing. Queuing is sometimes used for this, but it doesn't typically apply to either microservices or functional computing. If you write stateless code, you can enable simultaneous execution in multiple contexts. If not, remember that microservices are called by other software. Since you can control how they are called, you can control concurrency. Alternatively, you can expect event-driven functions to be concurrent.
