If computing in general and carrier cloud in particular is going to become more edge-focused over time, then it’s time to ask just what infrastructure features will be favored by the move. Even today we see variations in server architecture and the balance of compute and I/O support needed. It is very likely that there will be even more variations emerging as a host of applications compete to dominate the cloud’s infrastructure needs. What are the factors, and what will the result be? I’m going to have to ask you to bear with me, because understanding the very important issues here means going way beyond 140-character Tweets.
It’s always a challenge to try to predict how something that’s not even started will turn out in the long term. Carrier cloud today is almost pre-infancy; nearly all carrier IT spending is dedicated to traditional OSS/BSS, and what little is really cloud-building or even cloud-ready is so small that it’s not likely representative of broader, later, commitment. Fortunately, we have some insight we can draw from the IT world, insight that’s particularly relevant given the fact that things like microservices are already a major driver of change in IT, and are of increasing interest in the carrier cloud. To get to these insights we need to look a bit at the leading edge of cloud software development.
Microservices are in many ways a kind of bridge between traditional componentized applications (including those based on the Service Oriented Architecture of almost two decades ago) and the “bleeding edge” of computing architecture, the functional programming or Lambda function wave. A Lambda function is a software element that processes an input and produces an output without relying on the storage of internal pieces—it has a single function regardless of the context of its use. What makes this nice is that because nothing is ever saved inside a Lambda function, you can give a piece of work to any copy of the function and get exactly the same result. I’m going to talk a lot about the Lambda functions in this blog, so to save typing I’m going to call them “Lambdas” with apologies to the people who use the term (without capitalizing) to mean “wavelength”.
In the broader development context, this kind of behavior is known as “stateless” behavior, because there are no “states” or differences in function outcome depending on the sequence of events or messages being processed. Stateless behavior is mandatory for Lambdas, and also highly recommended if not mandated for microservices. Stateless stuff is great because you can replace it, scale it, or use any convenient element of it and there’s no impact, no cross-talk. They’re bad because many processes aren’t stateless at all—think of taking money out of the bank if you need an easy example. What you have left depends on what you’ve put in or taken out before.
The reason for this little definitional exercise is that both Amazon and Microsoft have promoted Lambda programming as a pathway to event-driven IT, and the same is being proposed for microservices. In Amazon’s case, they linked it with distributing functions out of the cloud and into an edge element (Greengrass). Event-driven can mean a lot of things, but it’s an almost-automatic requirement for what are called “control loop” applications, where something is reported and the report triggers a process to handle it. IoT is clearly a control-loop application, but there are others even today, which is why Amazon and Microsoft have focused on cloud support for Lambda functions. You can write a little piece of logic to do something and just fire it off into the network somewhere it can meet the events it supports. You don’t commit machine image resources or anything else.
If IoT and carrier cloud will focus on being event-driven, it follows they would likely become at least Lambda-like, be based on stateless microservices that are pushed toward the edge to shorten the control loop while traditional transactional processes stay deeper in the compute structure. Applications, then, could be visualized as a cloud of Lambdas floating around, supporting collectively a smaller number of stateful repository-oriented central applications. The latter will almost surely look like any large server complex dedicated to online transaction processing (OLTP). What about the latter?
The Lambda vision is one of functional units that have no specific place to live, remember. It’s a vision of migration of capabilities to assemble them along the natural path of work, at a place that’s consistent with their mission. If they’re to be used in event-handling, this process of marshaling Lambdas can’t take too long, which means that you’d probably have a special system that’s analyzing Lambda demand and caching them, almost like video is cached today. You’d probably not want to send a Lambda somewhere as much as either have it ready or load it quickly from a local resource. Once it’s where it needs to be, it’s simply used when the appropriate event shows up.
This should make it obvious that running a bunch of Lambdas is different from running applications. You don’t need a lot of disk I/O for most such missions, unless the storage is for non-volatile referential data rather than a dynamic database. What you really want is powerful compute capabilities, a lot of RAM capacity to hold functions-in-waiting, and probably flash disk storage so you can quickly insert a function that you need, but hadn’t staged for use. Network I/O would be very valuable too, because restrictions on network capacity would limit your ability to steer events to a convenient Lambda location.
How Lambda and application hosting balance each other, requirements-wise, depends on how far you are from the edge. At the very edge, the network is more personalized and so the opportunity to host “general-use Lambdas” is limited. As you go deeper, the natural convergence of network routes along physical facilities generate places where traffic combines and Lambda missions could reasonably be expected to be shared across multiple users.
This builds a model of “networking” that is very different from what we have now, perhaps more like that of a CDN than like that of the Internet. We have a request for event-processing, which is an implied request for a Lambda stream. We wouldn’t direct the request to a fixed point (any more than we direct a video request that way), but would rather assign it to the on-ramp of a pathway along which we had (or could easily have) the right Lambdas assembled.
I noted earlier in this blog that there were similarities between Lambdas and microservices. My last paragraph shows that there is also at least one difference, at least in popular usage, between Lambdas and microservices. The general model for microservices is based on extending componentization and facilitating the use of common functions in program design. A set of services, as independent components, support a set of applications. Fully exploiting the Lambda concept would mean that there really isn’t a “program” to design at all. Instead there’s a kind of ongoing formula that’s developed based on the source of an event, its ultimate destination, and perhaps the recent process steps taken by other Lambdas. This model is the ultimate in event-driven behavior, and thus the ultimate in distributed computing and edge computing.
There’s another difference between microservices and Lambdas, more subtle and perhaps not always accepted by proponents of the technologies. Both are preferred to be “stateless” as I noted, but in microservices it’s acceptable to use “back-end” state control to remove state/context from the microservices themselves. With Lambdas, this is deprecated because in theory different copies of the same Lambdas might try to alter state at the same time. It would be better for “state” or context to be carried as a token along with the request.
We don’t yet really have a framework to describe it, though. Here’s an event, pushed out by some unspecified endpoint. In traditional programming, something is looking for it, or it’s being posted somewhere explicitly. Maybe it’s publish-and-subscribe. However, in a pure Lambda model, something Out There is pushing Lambdas out along the path of the event. What path is that? How does the Something know what Lambdas are needed or where to put them?
If you applied the concepts of state/event programming to Lambda control, you could say that when an event appears it is associated with some number of state/event tables, tables that represent contexts that need to process that event. The movement of the event through Lambdas could be represented as the changing of states. Instead of the traditional notion of an event arriving at a process via a state/event table, we have a process arriving at the event for the same reason. But it’s still necessary to know what process is supposed to arrive. Does the process now handling an event use “state” information that’s appended to it and identify the next process down the line? If so, how does the current process know where the next one has been dispatched, and how does the dispatcher know to anticipate the need? You can see this needs a lot of new thinking.
IoT will really need this kind of edge-focused, Lambda-migrating, thinking. Even making OSS/BSS “event-driven” could benefit from it. Right now, as far as I can see, all the good work is being done in abstract with functional programming, or behind the scenes of web-focused, cloud-hosted startups who probably have stimulated both Amazon and Microsoft to offer Lambda capabilities in their clouds. It will be hard to make IoT the first real use case for this—it’s a very big bite—but maybe that’s what has to happen.