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.

Public cloud vendors want your workloads forever. Here’s how to create a viable exit strategy

Last month I noted that the big AWS outage proved one cloud isn’t enough. This week, I’d like to go a bit further into the topic and talk about some of the things you can do concretely to embrace the cloud without betting the farm.

It’s not just about outages. Any vendor who has you by the data will eventually extract the maximum value from the relationship. Sometimes the most important question in a business relationship is: “What’s your exit strategy?” Here are my best answers, arranged by cloud type.

For IaaS

1. Use Docker or a similar solution. You should have relocatable containers that you can rebuild and deploy at a whim. This is a critical if you want to protect yourself against lock-in.
2. Avoid direct database integration. OK, your app needs a store, but no two apps should talk to the same operational store. Those sorts of connections and protocols tend to build a house of cards. You can’t move anything until you move the database — but everything goes down once you do, or you end up with a split brain situation.

For IaaS/PaaS

3. Implement API/REST integration. Rest easy that you are connecting over HTTPS and making standard, easily relocatable web calls.
4. Externalize configuration. Don’t hard-code the scheme, server, or domain into your URLs. Anything else that’s environmental should be externalized.
5. Use common APIs. If you’re using NodeJS and Express or other, similar, well-known APIs, then you’re pretty safe from vendor lock-in. If you start using platform-provided services, you’ve got a bigger problem.

For SaaS

6. Ensure there’s a standard method for data export. By that I really mean a way that you could feasibly import your data into another system.
7. Test the method of data export. That they theoretically let you grab a dump of data isn’t really that promising. I’ve seen vendors that offered it, but then the dump feature didn’t actually work on any kind of reasonable timeline and the data was trash by the time it did.
8. Favor solutions with well-known, stable REST APIs. Realistically, you’re not likely to dump, import, and move all in one shot. You may need some custom glue code where you grab and transport.

For everything cloud

9. Favor open source technologies. If the core technology, APIs, and functionality are provided by a healthy open source project, you have a lot better chance of leaving if you need to. This means architectural choices (for example, using Kafka instead of Kinesis).
10. Avoid dependence on unique cloud vendor technology. Sometimes your architectural ties are more process than code. These tend to leak into API calls or other operational management procedures. For instance, maybe you don’t use AWS’ Elastic Map Reduce, because it’s frankly not the greatest financial deal and it’s somewhat flakey. Maybe you just shouldn’t use it because it’s different from what you’d use on any other cloud platform.
11. Use fixed IPs and DNS names tied to your company, not the provider.Using an IP and a DNS name is sort of internet 101. Having virtual instances that go down and come up with a new IP isn’t very resilient not to mention relocatable.
12. Use messaging where possible. If you can do something on more of a message basis, where a service that’s down can be tolerated, do that. It means while you are moving you can forward things somewhere else.
13. Two clouds. As I said before, it is easier to move if you start with at least two different vendors. That’s harder to do with SaaS, but pretty operable with IaaS/PaaS.

The bottom line is that you should favor open source, open standards, and open APIs over vendor-specific solutions. Use microservices architecture or at least the principles thereof. Always maintain your cloud provider exit strategy, and you’ll have a very advantageous relationship with your cloud provider. Always assume your cloud vendor follows the Ferengi Rules of Acquisition.

By  Andrew C. Oliver, source by InfoWorld

Visit ICT Hardware website to get more information

The post 13 tips to foil cloud lock-in appeared first on ICT News.