Azure Functions, Logic Apps, Azure Stack, and .Net come together for the next stage of PaaS both in the cloud and on-premises

Microsoft’s adoption of serverless computing is a big piece of Azure maturing as a platform. There’s a lot going on here, as architectures and services evolve to take advantage of the unique capabilities of the cloud and we as users and developers migrate away from traditional server architectures.

Mark Russinovich, Microsoft’s CTO of Azure, has a distinct view on the evolution of cloud as a platform. “Infrastructure as a service [IaaS] is table stakes,” he said at an Azure Serverless computing event at Microsoft’s Redmond, Wash., headquarters last week, “Platform as a service [PaaS] is the next step, offering runtimes and developing on them, an API and an endpoint, where you consume services.” That’s where we are today, where we still define the resources we use when we build cloud applications.

Then comes serverless computing. “Serverless is the next generation of computing, the point of maximum value,” Russinovich said.

What he’s talking about is abstracting applications from the underlying servers, where code is event-driven and scales on demand, charged by the operation rather than by the resources used. As he said, “I don’t have to worry about the servers. The platform gives me the resources as I need them.” That’s the real definition of serverless computing: The servers and OS are still there, but as a user and a developer you don’t need to care about them.

Serverless computing is the next phase of virtualization

You can look at it as a logical evolution of virtualization. As the public cloud has matured, it’s gone from one relatively simple type of virtual machine and one specific type of underlying hardware to specialized servers that can support IaaS implementations for all kinds of use cases, such as high-performance computing servers with massive GPUs for parallel processing and for scientific computing working with numerical methods, or such as arrays of hundreds of tiny servers powering massive web presences.

That same underlying flexibility powers the current generation of PaaS, where applications and code run independently of the underlying hardware while still requiring you to know what the underlying servers can do. To get the most out of PaaS (that is, to get the right fit for your code), you still need to choose servers and storage.

With serverless computing, you can go a step further, concentrating on only the code you’re running, knowing that it’s ephemeral and you’re using it to process and route data from one source to another application. Microsoft’s serverless implementations have an explicit lifespan, so you don’t rely on them being persistent, only on them being there when you need them. If you try to use a specific instance outside that limited life, you get an error message because the application and its hosting container will be gone.

Three serverless computing models

Nir Mashkowski, principal group manager for Azure App Service, noted three usage patterns for Azure’s serverless offerings.

The first, and most common, pattern is what he calls “brownfield” implementations. They are put together by enterprises as part of an overall cloud application strategy, using Azure Functions and Logic Apps as an integration tool, linking old apps and new and on-premises systems and cloud.

The second pattern is greenfield implementations, which are typically the province of startups, using Azure Functions as part of a back-end platform—that is, as switches and routers moving data from one part of an application to another.

The third pattern is for internet of things applications. It is a combination of the two, using Azure Functions to handle signals from devices, triggering actions in response to specific inputs.

For enterprises wanting a quick on-ramp to serverless computing, Azure Functions’ closely related sibling Logic Apps is an intriguing alternative. Drawing on the same low-code foundations as the more business-focused Flow, it gives you a visual designer with support for conditional expressions and loops. (You can even can run the designer inside Visual Studio.)

Like Azure Functions, Logic Apps is event-triggered and can be used to coordinate a sequence of Azure functions. Wrapping serverless code in a workflow adds more control, especially if it’s used to apply conditions to a trigger—for example, launching one function if a trigger is at the low end of a range of values, another if it’s at the high end.

In the cloud and on-premises: Portable serverless computing

Russinovich described three organizations working with serverless computing:

• Accuweather uses it to handle its server logs, replicating them between datacenters and handing them off to analysis tools.
• Similarly, Plexure, a marketing company, uses it to handle feeds from point-of-sale systems, replacing a complex stack of tools with a workflow that drives information from one service to the next.
• At the other end of the scale, the Missing Children Society of Canada used Logic Apps to build a bot that could bring research about missing kids together from various sources, including social media, in a project that took a mere four days to deliver.

One of the more interesting aspects of both Azure Functions and Logic Apps is that they’re not limited to running purely in the cloud. Functions themselves can be developed and tested locally, with full support in Visual Studio, and both Azure Functions and Logic Apps will be supported by on-premises Azure Stack hybrid cloud systems.

Inside the Azure datacenters, its serverless options are all containerized for rapid deployment. That same model will come to your own servers, with Azure Functions able to run on any server, taking advantage of containers for rapid deployment.

Currently, Azure Functions is based on the full .Net Framework release, so there’s a minimum requirement of Windows Server Core as a host. But that’s going to change over the next few months with an open source release based on .Net Core and the upcoming .Net Standard 2.0 libraries. With those in hand, you’ll be able to run Azure Functions in containers based on Windows Server Nano, as well as on .Net Core running on Linux. You’ll be able to migrate code from on-premises to hybrid cloud and to the public cloud depending on the workload and on the billing model you choose.

Such a cross-platform serverless solution that runs locally and in the cloud starts looking very interesting, giving you the tools to build and test on-premises,then scale up to running on Azure (or even on Linux servers running on Amazon Web Services).

There’s a lot to be said for portability, and by working with REST and JSON as generic input and output bindings, Microsoft’s containerized serverless implementation appears to avoid the cloud lock-in of its AWS and Google competitors while still giving you direct links to Azure services.

By Simon Bisson, source by InfoWorld

Visit ICT Hardware website to get more info about Microsoft Products

The post Microsoft tools coalesce for serverless computing appeared first on ICT News.

The deal will help Microsoft better support the Google-originated orchestration system

Microsoft is acquiring Deis, a company that makes tools to work with the Kubernetes open-source container orchestration system. The deal, announced Monday, marks Microsoft’s continued interest in container orchestration.

Deis creates tools that aim to simplify the development of modern, containerized applications. Containers allow developers to write an application for an isolated, portable runtime that is supposed to be easily transferrable from a workstation to a server environment.

Tools like Deis’s Workflow, Helm, and Steward are supposed to ease the complex process of managing multi-container applications. They build on top of Kubernetes, the popular open-source container orchestration system that Google released in 2014. Deis plans to continue its contributions to those tools as part of Microsoft, company CTO Gabe Monroy said in a blog post.

Microsoft has invested a great deal already in technology that lets developers create applications that run in Windows and Linux containers. The company expects Deis’ technology to help with the use of those existing tools, according to a blog post by Scott Guthrie, the executive vice president of Microsoft’s Cloud and Enterprise division.

Deis’ Kubernetes expertise will be a key benefit for Microsoft, which has been investing in the popular open-source container orchestration system.

Microsoft acquired the company from Engine Yard, a platform-as-a-service provider that previously purchased Deis in 2015. The companies didn’t disclose the terms of the deal.

The news comes roughly a couple months after Microsoft announced the general availability of Kubernetes in Azure Container Service, its platform-as-a-service offering for containerized applications. Last week, the company also announced the general availability of Azure Container Registry, a service that lets customers store and manage different container images in the cloud.

By  Blair Hanley Frank, source by ComputerWorld

Visit ICT Hardware to get more info about Microsoft

The post Microsoft acquires Deis to boost its Kubernetes chops appeared first on ICT News.

IBM follows Google and Microsoft in offering hosted Kubernetes as a service, with direct access to the container orchestration system’s APIs

It’s only a matter of time before every major cloud vendor offers a version of Kubernetes as a service. Now it’s IBM’s turn.

This morning IBM announced the next logical step in its work with Docker containers: Kubernetes support on its Bluemix Container Service. Currently available in a limited beta, its feature set should match Google’s and Microsoft’s offerings.

Kubernetes, the Bluemix way

Previously, the default for managing Docker containers on Bluemix Container Service was to spin them up individually by hand or to use Bluemix’s container groups metaphor, where Bluemix directly managed multiple containers running the same image.

Kubernetes is meant to provide several advantages for container deployments: easier scaling, better visibility into the state of a cluster, and so on. IBM says its implementation of Kubernetes on Bluemix includes everything users would expect from a stock Kubernetes deployment, as well as some IBM-specific features.

For example, see how it deploys master nodes, the parts of a cluster that accept commands and delegate them to the other machines in the cluster. IBM claims master nodes in its Kubernetes implementation are “highly available and fully managed by IBM”—presumably in contrast to simply providing and supporting a VM with Kubernetes that’s spun and run by the customer.

Some features for Bluemix Container Service are essentially conventional Docker/Kubernetes features writ large—such as a per-organization Docker private image registry with image scanning and vulnerability detection built in, or support for Kubernetes secrets (API keys and more) when communicating with other Bluemix resources. Other features, like “binding of Bluemix services, such as Watson APIs, Blockchain, data services, or internet of things” to Kubernetes-deployed apps, more prominently promote Bluemix, allowing Kubernetes-powered apps plug into Bluemix-exclusive services.

Why mess with a good thing?

IBM arrives late to a party that already includes Google and Microsoft. Google has had a leg up on everyone else in offering Kubernetes as a service because it invented the underlying technology. It also worked to Google’s advantage that its public cloud was relatively sparse; it could provide Kubernetes support on its cloud without having to make concessions to many legacy components.

Microsoft late last year added Kubernetes for its container services, after originally supporting Docker Swarm and Mesosphere DC/OS as orchestration solutions. Microsoft delayed its entry because a lot of behind-the-scenes work was needed to add Kubernetes support to Azure and to open-source that work. Kubernetes clusters themselves are provisioned and managed on Azure by way of a QuickStart template, rather than a dedicated managed service.

Amazon’s ECS (EC2 Container Services) doesn’t have a dedicated Kubernetes service; instead it offers a more general Docker as a service, with orchestration and scheduling provided by ECS itself, or through the Blox projects.

Though late to the party, IBM is taking one crucial step for any cloud incarnation of an open source service: It’s allowing the user to lift the hood and plug directly into the original API set. That’s important with cloud container services like Kubernetes, since the promise of a cloud built from open components was that workloads wouldn’t become dependent on the clouds where they’re hosted.

Granted, IBM—or any cloud provider—could try to make a strong case for its cloud versus someone else’s by promoting how well Kubernetes runs at scale on its cloud and works with the proprietary services to enrich those applications. But having Kubernetes at the core and in a form others know is still the most worthwhile draw.

By Serdar Yegulalp, source by InfoWorld

Visit ICT Hardware website to get more info about Microsoft Products

The post IBM chases Google, Microsoft with Kubernetes in the cloud appeared first on ICT News.