Tools are always shaped by their uses. When cloud computing first came on the scene, it was a form of hosted virtualization, and its goal was to look like a bare-metal server. <\/p>\n
Infrastructure as a service (IaaS) shaped the earliest cloud services, and it still dominates public cloud as well as the private cloud software market. Even so, that doesn't mean it's going to be the source of future cloud opportunity. <\/p>\n
Cloud providers are always strategizing for the future, and their plans reveal an important -- and already underway -- shift. Every major public cloud provider has added services to process events. In particular, providers are adding features to help developers build applications for the internet of things (IoT). Could these be the basis for the most transformational set of applications to come along since the internet itself? <\/p>\n
Legacy applications follow a pattern that's decades old: Work comes to the applications that support it. In traditional cloud computing, users pay for the processing resources they use. The terms differ, but it's essentially a lease of virtual infrastructure. This is a direct mirror of what happens in a data center -- a server farm is loaded with applications and transactions are routed to the correct server in the pool. This approach is great where work is persistent, as in the case of a retail banking application that runs continuously. <\/p>\n
Event-driven and IoT apps change this critical notion of persistence. An event can pop up anywhere, at any time. It would be wasteful, perhaps prohibitively wasteful, to dedicate an IaaS instance to wait around for an event. Or the instance might reside within a data center halfway around the world from where the event occurs. If all possible event sources were matched with traditional cloud hosting points, most would sit idle much of the time, doing little but running up costs. <\/p>\n
The reason why there's a specific right or wrong place to process events is simple: delay. Most events have a specific response-time expectation. Imagine a machine that triggers spray paint when an item passes a sensor. Picture a self-driving vehicle that approaches a changing traffic light. <\/p>\n
The information flow between an event and the receipt of the appropriate response is called a control loop. Most events require a short control loop, which means that their processes need to be close to the point of the event. That's the problem with control loops that force event-handling processes to disperse out toward the cloud edge -- and multiply in numbers. <\/p>\n
It's easy to see how the scarcity of events at a given point creates a problem of cloud efficiency and pricing for traditional cloud computing. It's also possible to have too many events. The cloud can allow for cloud bursting, or scaling capacity by spinning up multiple copies of an application component on demand, but it's not that easy. <\/p>\n
Few applications written to run on a bare-metal server can seamlessly scale or replace failed instances. Those cloud capabilities aren't common in data centers, where legacy applications run. Moving the applications to the cloud doesn't add the features necessary to scale applications, either. <\/p>\n
Multiple copies of an application component require load balancing, and many applications were not designed to allow any copy of a component to handle any event or request. Applications that work by assuming a string of requests in context can't work if half the string goes to one copy of the application and the other half to another. How do we make IoT apps scalable and resilient? They have to be rewritten. <\/p>\n
Developers are doing just that, and big cloud providers are responding. In particular, they all see the same IoT-and-event future for the cloud. They have been steadily enhancing their cloud offerings to prepare for that future. Not only do the cloud giants offer special web services to manage IoT devices and connections, they now provide tools to support the kind of programming that IoT apps will demand. <\/p>\n
The functional or lambda style of programming doesn't allow an application or component to store data between uses. As a result, all instances of the component can process an event. Cloud providers now offer functional or microservice support instead of simply providing infrastructure, platform or software as a service, because a function cloud is very different. <\/p>\n
Where is your function hosted in a function cloud? Everywhere. Nowhere. Functions are activated anywhere they're needed -- when they're needed -- and you pay when you use one. Function clouds for IoT, or any kind of event-driven computing, represent the ultimate flexibility and agility. They also demand that users take care to establish policies on just how much function hosting they are willing to pay for, a decision they'll have to make based on the combination of cost and those pesky control-loop lengths. <\/p>\n
Amazon has even allowed for the possibility that IoT will demand cloud applications that migrate outside the cloud. Their Amazon Web Services (AWS) Greengrass platform is a software and middleware framework that lets users execute AWS-compatible functions on their own hardware. This capability will let IoT users do some local processing of events to keep those control loops short, but still host deeper, less time-critical functions in the AWS cloud. <\/p>\n
The old cloud model made you pay for hosting instances. In the function cloud, you don't host instances in the usual way. You have extemporaneous execution of functions, as needed. This is what gives rise to the pay-as-you-go or serverless description of the function cloud, but that's short of the mark. You could price any cloud computing service, running any application, on a usage basis, but that doesn't make those cloud services scalable or easily optimized. Without these features, serverless is just a pricing strategy. <\/p>\n
Developers will have to make changes in applications to accommodate IoT and function clouds. Almost every new program or service stores information, and this makes it difficult to scale. The rule of functional programming is stateless, meaning that the output you get from a process is based only on what you provide as input. There are even programming languages designed to enforce stateless behavior on developers; it's not second nature. <\/p>\n
The notion of the function cloud is likely to accelerate a trend that's already started in response to the use of mobile devices and implementation of BYOD policies. Companies have found that they are creating application components designed to format information for mobile devices, interface with apps written for a variety of mobile platforms and provide consistent support from back-end applications often running in data centers. <\/p>\n
These forces combine to create a two-tier model of an application. The device-handling front tier lives in the cloud and takes advantage of the cloud's ability to distribute applications globally. The cloud part then creates traditional transactions for the core business applications, wherever they are. <\/p>\n
IoT is even more distributed than mobile workers, and some IoT events need short control loops. As a result, cloud hosting of the front-end part of applications could see explosive growth. That puts pressures on the off-ramp of this kind of two-tier application structure because many events might generate many transactions. These transactions can overwhelm core business applications. Cloud providers are working on this, too. Microsoft, for example, has a cloud-distributed version of the service bus typically used to feed business applications with work. <\/p>\n
If you're writing functions for any reason, isn't using a function cloud inevitable? <\/p>\n
Given that IoT is in its infancy -- and cloud IoT is even younger -- it's easy to wonder why cloud providers are already offering IoT features. There are three reasons. First, IoT could radically increase IT spending, and cloud providers want to grab some of that as potential new revenue. Second, IoT isn't the only thing that generates events. A lot of mobile worker interaction, for example, looks like event processing. Finally, functional programming techniques are being promoted for every kind of processing. IoT apps demand them. Developer tools and conferences are already describing how functional programming techniques can make programs better and more maintainable. <\/p>\n
If you're writing functions for any reason, isn't using a function cloud inevitable? <\/p>\n
That's the big question that every cloud provider and cloud user needs to think about. Fully scalable applications -- ones that can increase or decrease capacity under load and repair themselves by simply loading another copy -- are very useful to businesses. The functional programming techniques developed for IoT apps, and the function clouds to support those techniques, will remake programs. <\/p>\n
Tools are defined by their uses, remember? Well, users are already seeing the cloud of the future in event processing, and IoT will accelerate that trend. IoT's potential to generate events over a wide area, in large numbers, while demanding short control loops will revolutionize cloud use. <\/p>\n
Learn the benefits of runtime as a service <\/p>\n
Are you ready for serverless computing? <\/p>\n
Build IoT apps for cloud in a flash <\/p>\n
<\/p>\n
See the article here:<\/p>\n
IoT apps and event-driven computing reshape cloud services - TechTarget<\/a><\/p>\n","protected":false},"excerpt":{"rendered":" Tools are always shaped by their uses. Continue reading