Edge computing is one of the buzzwords du jour of the IT world. Arguably, its merely a new term for an old idea. But, either way, if youre not up to speed with edge computing concepts and priorities, nows the time to learn. Toward that end, heres a primer on what developers should know about edge computing platforms: how edge computing platforms work, how they relate to the cloud and data centers, and how to approach application development for the edge.

Edge computing is a broad term that refers to any type of application deployment architecture in which applications or data are hosted closer to users--in a geographic sense--than they would be when using a conventional cloud or data center.

The big idea behind edge computing is that by bringing workloads closer to end users you can reduce network latency and improve network reliability--both of which are key considerations in an age when applications in realms like IoT, machine learning and big data require ultra-fast data movement.

At its core, edge computing is an architectural concept, not a development concept. Applications dont need to be designed or programmed in any particular way to run on edge computing platforms.

Nonetheless, there are a number of things that developers can help their organizations get the most out of edge computing.

For applications to take full advantage of edge architectures, its important for application instances to be able to start quickly. Its hard to benefit from an ultra low-latency network when your applications take 30 or 40 seconds to start.

Thats one reason to consider containerizing applications that will be deployed on an edge platform. Containers can start and scale more quickly, enabling organizations to capitalize on the agility and speed that edge computing platforms offer.

In some cases, edge computing platforms involve hardware devices that you wouldnt find in a conventional data center. You may be dealing with IoT devices or with mobile phones that serve as a device edge (which means that the devices perform processing tasks that would traditionally be handled on the server side). Not only can the hardware profiles of these devices vary tremendously, but they also may also not offer the ability to virtualize hardware (and, by extension, standardize computing environments).

For this reason, its wise to choose a development strategy that can support any type of device or hardware configuration. Even if your edge applications run today on conventional servers, you may want to extend them in the future into more specialized devices. Sticking to programming languages, libraries and processes that help you do that will future-proof your organizations edge strategy.

In addition to the aforementioned device edge, edge computing platforms come in the form of whats known as the cloud edge. In the latter edge computing model, data processing happens in the cloud rather than on end user devices. However, the cloud data centers in a cloud edge are geographically closer to users than they would be in a conventional, highly centralized cloud architecture.

The device edge and the cloud edge both help to improve application performance and reliability, but in different ways. Developers should understand the differences and decide which type of edge model makes sense for their applications. For a device edge, theyll need to build applications that can optimize data processing directly on end-user devices. Applications in cloud edge environments look more like traditional server-side applications.

It can be tempting to view edge computing as an alternative to cloud computing, or even as the antithesis of it. In fact, edge extends the cloud rather than competes with it.

From a development perspective, this means that you can and should take full advantage of cloud services when it makes sense while building an edge application. Edge apps dont need to avoid reliance on the cloud. However, they should be capable of running in an environment where traditional cloud data centers are not available.

The fact that edge applications are deployed outside of traditional data centers also makes software testing extra important when you are developing for an edge computing platform. Not only do you need to ensure that you test each release for all of the environment configurations you will be deploying to, but you should also factor in how varying levels of network availability, proximity to content delivery networks, and even (if you are deploying to a device edge) battery life on end user devices can impact application performance.

In other words, testing edge applications requires planning for more variables and unique test cases than you would traditionally have to handle when building a standard application.

Again, developers are only one set of stakeholders in edge computing. Cloud architects, data architectures, and network and security engineers also have important roles to play in ensuring that businesses capitalize on the benefits that edge computing platforms stand to offer.

But developers can do their part by writing applications that are high-performing under any and all edge configurations that their organizations may choose to use--now or in the future.

See original here:
5 Ways Developers Can Get the Most out of Edge Computing Platforms - ITPro Today

Cloud computing has revolutionized the business world over the last two decades. Enterprises no longer need to provision and maintain costly on-premises computing infrastructure. Instead, they can access resources like servers, storage, databases, and software remotely through the internet. Moreover, those resources can be accessed on demand, allowing enterprises to quickly and efficiently scale their operations.

According to research firm Gartner, spending on public cloud services will increase by 19% annually through 2022. That growth should be a tailwind for industry titans like Amazon (NASDAQ:AMZN) and Microsoft(NASDAQ:MSFT). Here's what investors should know about these two companies' opportunities in the cloud space in 2021.

Amazon's cloud computing business, Amazon Web Services (AWS), launched in 2006. Today, it's still the clear leader in the space, with a more extensive global infrastructure, a broader product offering, and a larger market share than any of its rivals. In fact, during the fourth quarter of 2020, AWS took 32 cents of every dollar spent on cloud infrastructure services.

Image source: Getty Images.

That dominance has attracted a diverse network of partners -- enterprises that use AWS to build solutions for their own clients. For example, consulting firm Deloitte developed its Smart Factory Fabric, a cloud-enabled manufacturing process, using Amazon IoT systems. This suite of applications brings smart manufacturing capabilities to its clients' operations. Notably, Deloitte's role as a consultant to 80% of Fortune Global 500 companies means it's well-positioned to bring new customers to AWS.

Not surprisingly, its robust product portfolio and large partner network have powered strong growth in Amazon's cloud computing business. Last year alone, AWS's revenue rose 30% to $45 billion.

Moreover, AWS's operating margin was 30% in 2020. Compare that to the combined operating margin of Amazon's other businesses -- 3%. The cloud segment's high profitability has helped the tech giant bankroll its e-commerce efforts, making it an even greater threat to traditional retailers. In other words, AWS generates enough cash that Amazon can afford to run its e-commerce business at a loss to gain market share.

AWS's lead in cloud computing should help the company grow its top and bottom lines quickly. That, in turn, should drive increased profitability for Amazon as a whole, while allowing it to fund the rapid innovation that has kept AWS ahead of its rivals.

Microsoft launched its cloud computing business, Microsoft Azure, in 2008. While it still trails AWS in terms of market share, the company is executing on a strong growth strategy, and Azure is gaining ground.

Market Share

Q4 2018

Q4 2019

Q4 2020

Amazon

33%

32%

32%

Microsoft

15%

18%

20%

Source: Canalys.

Specifically, Microsoft has focused on supporting hybrid and edge computing use cases. This strategy makes sense -- some types of data need to remain on company premises due to privacy or regulatory requirements. That can put an enterprise at a disadvantage, though, if it means they don't have access to cloud services to help them manage, analyze, and secure that data. But Microsoft has a solution.

First, Azure Arc extends Azure's management capabilities across any environment, from private data centers to public clouds. In other words, it allows clients to manage all their digital resources in a unified way, even if some of those resources are stored on-site or in a rival cloud like AWS. For example, Azure Arc makes it possible to train and run AI models using data stored in multiple different locations. That puts Microsoft ahead of rivals like AWS and Alphabet's Google Cloud in terms of its ability to power hybrid AI.

Second, Azure Stack allows clients to run their own Azure environments using on-premises servers. This makes it possible to bring Azure services -- think artificial intelligence, analytics, monitoring, and security -- to private data centers or even disconnected environments. Azure Stack also makes it possible for developers to build and run hybrid applications across cloud and on-premise locations.

In recent years, Microsoft has also forged partnerships with companies like Datadog, SpaceX, and General Motors that have helped expand Azure's client base. In another partnership that began in 2019, SAP started working with it to migrate its on-premise software customers to Azure. And in 2021, the two companies expanded this partnership, enabling SAP to integrate Microsoft Teams into its own software solutions.

On the whole, Microsoft's efforts have powered strong growth in its cloud computing business. In the company's fiscal 2020 (which ended June 30, 2020), Azure revenue surged 56%, and through the first two quarters of its fiscal 2021, sales were up 49% year over year.

Microsoft's size gives it an advantage over the vast majority of its rivals. And its focus on hybrid scenarios should power continued growth as more enterprises migrate to the cloud.

This article represents the opinion of the writer, who may disagree with the official recommendation position of a Motley Fool premium advisory service. Were motley! Questioning an investing thesis -- even one of our own -- helps us all think critically about investing and make decisions that help us become smarter, happier, and richer.

See the rest here:
2 Top Cloud Computing Stocks to Buy in 2021 - The Motley Fool

Enterprises with 2,000-plus servers could save up to 84 per cent in various network monitoring and management costs over three years by by using Pensando SmartNIC server offload chips.

This is the headline finding of an Enterprise Strategy Group Economic Validation report, published yesterday: ESGs analysis found that Pensandos scale-out software-defined services approach enabled organisations to centralise management, simplify administration, and optimise performance.

Carriers and CSPs have embraced a scale-out approach, which enables services to be run on homogeneous, industry-standard server hardware, ESG adds. The challenge is that spinning up network or security functions on the generic servers employed by carriers and CSPs burns CPU resources and is generally less efficient and performant than specialty hardware.

Pensando, a California startup, has built the Arm-powered Naples DSC (Distributed Services Card) which connects to a host server across a PCIe interface. The card offloads and accelerates networking, storage and management tasks from its host server, freeing up the host CPU to run application workloads instead of infrastructure-focused tasks.

Pensandos DSC card replaces speciality hardware appliances. Infrastructure services such as security, encryption, flow-based packet telemetry, and fabric storage services are deployed on the DSC at every server. Pensando provides Policy and Services Manager (PSM) software to carry out centralised management. PSM collects events, logs, and metrics from the installed DSCs to speed troubleshooting.

In its report, ESG notes: While at first glance it might seem expensive to implement Pensando hardware and software into each data centre server ESGs modelled scenarios demonstrate significant savings for both traditional enterprises and cloud service providers.

In other words the performance and related savings per server are not enough at a server level to justify the Pensando card cost. But the total cost of ownership savings across large fleets of servers, 2,000 and upwards in ESGs scenarios, over three years make the expense of buying Pensando cards worthwhile.

The ESG researchers modelled two scenarios, an enterprise data centre with 2,000 servers each fitted with a DSC card, and a cloud services provider with 20,000 similarly equipped servers.

ESG calculated the costs of network adapters and monitoring appliances, east-west firewalls, load balancers, micro-segmentation nodes, and their associated license fees and operational expenditures (Opex). These were summed over three years and compared with the same servers fitted with Pensando DSCs and services software.

In the enterprise model and over three years, ESGs model predicts a total three-year savings of $16,180,092, or 84 per cent. In the cloud services provider model ESGs model predicts total three-year savings of $104,456,894, or 64 per cent. These are large numbers and suggest that enterprises and CSP with a thousand-plus servers might be well-advised to look at the costs and benefits of using Pensando DSCs in their data centres.

Continued here:
Pensando tech slashes network management costs - but you may need 2000-servers to benefit Blocks and Files - Blocks and Files

Introduction

Virtualization, containers and Kubernetes are big topics in tech, but the differences aren't always clear. Here, we present a simple analogy to aid understanding for a non-tech audience, and consider the role of these topics in a multicloud future.

The 451 Take

Containers are now a fundamental component of IT infrastructure: 53% of enterprises have at least some adoption today, with just 5% having no plans to implement, according to 451 Research's Voice of the Enterprise: DevOps, Organizational Dynamics 2020. Meanwhile, 43% of enterprises are using Kubernetes to, at least at some level, to manage their IT estates. The crucial benefit of containers is that applications can be decomposed into self-managed components that can live for as long or short as needed, depending on the demand at that time. These components can be updated independently across many physical servers without needing to rebuild the whole application, and components can be shared by multiple applications.

Orchestration platforms such as Kubernetes perform management of containers across many hosts, duplicating containers when needed to handle more requirements, and then scaling back down to save resources when not needed. Because of this, they are a logical enabler of multicloud applications. Being able to update and scale apps so users are always getting the best experience can make the difference between winning business and losing opportunities. In the post-COVID-19 era, the online experience has never been more important.

Virtualization

Imagine a building with a number of floors this represents a server in our analogy. An owner rents it out to a single tenant, but the tenant must pay a lot of rent for the whole building, even though they don't use it all. The landlord is only able to collect rent from a single person.

The owner could break the building into a number of apartments, all sharing the same physical building. Each apartment is a fully self-contained living space. Here, the landlord gets multiple revenue streams, and each tenant pays less than if they were to rent the whole house. This is akin to 'virtualization' in cloud computing, with tenants representing applications that are all hosted within the same building (server).

Virtualization enables the most basic attribute of a cloud service: a massive amount of computing or storage resources can be applied to many users simultaneously, with each user utilizing that service without regard to what other users are doing. Similarly, those users should be able to utilize the service without having to worry about the details of hardware-level implementation. Cloud suppliers virtualize compute, storage and other services on a massive scale using hardware virtualization, where a hypervisor layer (the abstraction layers) that runs on it enables operating systems (and their applications) to share hardware resources such as compute, storage and memory from a single asset, be it a server or even a pool of servers.

Originally, one server meant one operating system, typically delivering one workload. Through virtualization, one server (and its 'host' operating system) can hold multiple 'guest' operating systems, each one operating a logically separated workload, deployed together and contained within so-called virtual machines (the VM is the 'unit' of work in virtualization). Before virtualization, perhaps only a tiny fraction of the asset (the server and its resources) would be used at any one time. Through virtualization, multiple applications can be multiplexed together, so that resources are shared, and the asset is fully used. VMs contain a guest operating system, application payload, and anything else that may be needed (such as a database).

Common hypervisors include VMware ESX, Microsoft Windows Server, Citrix Xen, Red Hat Enterprise Virtualization and Linux KVMs. Cloud providers often have their own virtualization software. Increasingly, the hypervisors are less valuable than the software used to manage hypervisors across large numbers of servers, which allow virtual machines to rapidly be spun up and down, and configured to be resilient and performant the essence of cloud.

Containers

Back to our apartment building. Alternatively, the landlord could just break it up into a number of bedrooms, with a bathroom and kitchen shared among all tenants. In this model, the landlord is squeezing the most from the building, and the tenants are paying the least. Furthermore, a landlord that needs to perform maintenance on the kitchen or bathrooms only has to do it once, and will still satisfy all tenants. This is akin to 'containerization,' where each application isn't just sharing the physical server (the building), it is sharing code that is common across other applications (represented by tenants sharing some rooms). This code can be swapped out quickly across all applications at once, just like the kitchen can be repainted to satisfy all tenants. And if a room is unoccupied, the other tenants can take over that space temporarily, but can also vacate it quickly when a new tenant wants to move in.

The landlord in this case likes the predictability of tenants that have signed a contract to pay rent every month for a term commitment; and the tenants like knowing they have a roof over their head for the foreseeable future. But if there is a steady stream of people who only need a room for a few nights, the landlord might decide to turn the building into a hotel. Here, guests can stay for as long and as short as they need, and can rent as many rooms as they require. Containers can be spun up and consumed for a matter of seconds, to provide immediate capability where needed, but can be rapidly turned down to free up resources for other containers.

Container technology is essentially operating system virtualization workloads share operating system resources such as libraries and code. Containers have the same consolidation benefits as any virtualization technology, but with one major benefit there is less need to reproduce operating system code. Hardware virtualization means each workload must have all its underlying operating system technology. If the operating system takes up 10% of a workload's footprint, then in a hardware virtualized platform, 10% of the whole asset is spent on operating system code. This is regardless of the number of workloads being run. In the same environment utilizing containers, the operating system only takes up 10%, divided by the number of workloads.

In this case, a server runs 10 workloads, but only one operating system in the container environment. In the virtualized environment, the server would be running 10 workloads and 10 operating systems. An application container consists of an entire runtime environment: an application plus all of its dependencies, libraries and other binaries, as well as the configuration files needed to run it, bundled into a virtual container that can run on a variety of infrastructures bare metal, traditional datacenter, virtual environment, or public, private or hybrid cloud. Application containerization represents a method of deploying software that is immune to changes in the underlying computing environment.

The software that actually runs these containers is called a container runtime, and these include Docker, containerd and CRO-O. The Open Container Initiative is an industry project to standardize container runtimes based on Docker, with partners that include AWS, CoreOS, Docker, Google, IBM, HP, Microsoft, VMware, Red Hat and Oracle. As with virtualization, these runtimes are less differentiated and valuable than the orchestration platforms that manage containers across multiple servers, and even clouds.

Kubernetes and orchestration

At our hotel is a reception desk, staffed by a receptionist. The receptionist is responsible for keeping track of who is in what room, and allocating free rooms to new guests. Without the receptionist, the hotel would be static and underutilized. In containers, Kubernetes is the receptionist that manages the lifecycle of containers and automates the deployment, scaling and management of containerized applications.

Kubernetes is a standard today for container orchestration, due to its extensibility, powerful configuration options and ability to manage workloads independent of underlying infrastructure. It is an open source, container orchestration system for automating application deployment, scaling and management. Kubernetes was originally designed by Google, but wasn't the flagship project of the Cloud Native Computing Foundation (CNCF). It load balances the application load, just as the receptionist would allocate a block booking across many rooms, and monitors resource consumption so the hotel isn't overbooked. Kubernetes also allows new resources to be added, and can redistribute containers to different hosts should resources struggle.

Kubernetes 'clusters' are groups of machines referred to as nodes that are responsible for running containerised applications. A 'pod' is a single node in this cluster with one or multiple containers deployed onto it. Each node in a cluster can service pods or machines to run. Kubernetes can automate the management of clusters to perform at a desired state.

Many vendors are building Kubernetes compatibility into their own orchestration platforms, including Docker, Red Hat OpenShift, VMware Tanzu, IBM, Rancher Labs, Mirantis and Morpheus Data. Cloud providers, too, have created cloud services with support for Kubernetes, including AWS's Elastic Kubernetes Service, Google Kubernetes Engine, and Microsoft's Azure Kubernetes Services. There are also offerings from IBM, Oracle, Alibaba and OVH. But not everything is Kubernetes based: AWS's Elastic Container Service and Azure Container Instances are just two examples of container platforms that don't fit the mold.

Multicloud

If a receptionist can manage rooms in a hotel, why can't a centralized receptionist handle rooms at a range of locations, balancing capacity and availability across cities far apart? Kubernetes and containers are being touted as an enabler of multicloud deployments they provide a standard mechanism of managing and updating applications, regardless of the underlying infrastructure platform. This can help remove the risk of lock-in, because containers can be moved between venues without needing to be rewritten, and their lightweight nature (due to the sharing of code) means they can be moved from A to B far quicker than heavy-duty virtual machines.

However, it is unlikely we will see all applications being decomposed to containers. Just like the property and leisure markets sustain houses, apartments, hotels and hostels, there will be demand for physical hosts, virtual machines and containers depending on specific requirements. Some enterprises are happy to pay for a whole physical host, knowing it is isolated and has full access to physical resources. Others might prefer to share resources but isolate code, like in a virtual machine, while others might have the appetite to abstract apps as far as possible into containers. Lots of applications are still monolithic, and slimming them down to VM size or breaking them into containers isn't an easy task. And post-pandemic many enterprises will struggle to find the money and the motivation to rebuild applications from scratch, rather than just move them to more powerful servers.

Anyway, it is often the case that physical, virtual and containerized apps run nested and hand-in-hand. Containers can be deployed on virtual machines, providing flexibility with the benefits of isolation. And no one said containers and Kubernetes would be easy. Virtual machines have reached a point of maturity where they are easy to deploy and easy to manage. Right now, containers are a hodgepodge that are best deployed and managed by experts. This will change over time, but for now, the container hotel is open for business just make sure your receptionist knows what they're doing.

See the rest here:
A room with a view: a non-tech explanation of containers and Kubernetes - S&P Global