Although definitions of the metaverse are still being hashed out, most center on the idea that the metaverse is a virtual 3D world where people can interact. In other words, the metaverse is what you get when you fuse social media with virtual reality.

But here's another way of thinking about what the metaverse means: It's what happens when you combine cloud computing architectures with human beings. In other words, what the metaverse proposes to do is instrument humans as a service by deploying humans as virtualized services, just like the cloud has done to servers and software.

Related: Top 10 Industries Profiting From the Metaverse

Here's what this means, and why looking at the metaverse from this angle is important.

First, let me explain what I mean by terms like humans as a service, or HaaS, and how they relate to cloud computing.

Related: DevOps Teams to Play Big Role in Tackling Metaverse Challenges

The concept at the core of the cloud, of course, is that resources can be delivered "as a service" over the internet. Instead of standing up your own servers in your own data center, you can use cloud-based servers, which is an example of infrastructure as a service, or IaaS. Instead of installing and managing your own applications, you can use software as a service, or SaaS.

Viewed from one perspective, the metaverse does exactly the same thing to people: It makes them available as a hosted, fully managed service that anyone can consume via the internet.

More specifically, consider how the metaverse is similar to cloud computing in these respects:

The list could go on, but I hope the point is clear: The metaverse promises to transform humans and human relationships into abstract, scalable resources that can be consumed on demand with no strings attached.

Viewing the metaverse as the application of cloud computing architectures to human relationships is useful because it provides new perspective on both the positive and negative potentials of the metaverse.

On a positive front, the "cloudification" of humans promises to make it easier to interact with other people. Just as cloud computing brought world-class infrastructure within reach of businesses that might not otherwise be able to access it, a humans-as-a-service metaverse would extend access to human communities for people who would otherwise not engage with them due to geographic, political, cultural, or other barriers.

On the other hand, expect folks to criticize the metaverse for cheapening human relationships by, for example, placing constraints around how humans can interact, and how humans can represent themselves within virtual worlds. Such criticisms would not be unlike complaints that cloud computing limits the control that organizations have over their computing infrastructure that you typically can't access the bare-metal hardware, for instance, or control how SaaS applications manage your data.

Such worries about the metaverse could eventually push some early adopters of virtual communities to retreat from virtual communities back into the "real world." If that happens, it would be sort of like the cloud repatriation trend, which involves businesses migrating workloads from the cloud back on-premises.

To compare the metaverse to cloud computing is not to draw a mere analogy. In many cases, actual cloud infrastructure will be responsible for hosting metaverse communities, so there's already a clear technical link between metaverse and cloud.

I think, however, that it's valuable also to recognize the clear conceptual and cultural links between the metaverse and cloud computing. Ultimately, the metaverse stands to do to human beings what the cloud has done to servers and software: Make us available as an on-demand, scalable service.

If you thought the cloud computing revolution was over that IaaS and SaaS were as far as cloud computing would evolve just wait. The emerging metaverse suggests that there is a whole new chapter playing out in the cloud industry, and its focus is not on servers or code. It's on us.

More:
How the Metaverse Is Giving Birth to Humans as a Service - ITPro Today

These days most software companies use cloud deployment with modern hosting capabilities that make everyone productive, from developers to DevOps and InfoSec staff.

Gary Archer

Gary is a product marketing engineer at Curity. For 20 years, he has worked as a lead developer and solutions architect.

However, not all cloud deployments are the same, and you still need to make sound choices to meet your architectural requirements.

In this article, I will explain how my thinking has evolved after working with various cloud deployment types and integrating security into many kinds of apps.

I will start with a discussion on APIs and then highlight the key supporting security components. One of the most important of these is your identity and access management (IAM) system.

Nowadays, most application-level components implement security using the OAuth family of specifications, which provides modern security capabilities for web apps, mobile apps and APIs. This provides companies with the most cutting-edge options for authenticating users with one or more proofs of their identity, and protecting data in APIs according to business rules.

The authorization server defined in the OAuth specification deals with authentication, token issuing and user management. It enables many security solutions, or flows, to be built over time. Its the heart of any modern IAM system.

When I first started using cloud deployment, like many people, I was attracted by the thought of not having to host any backend servers and using the cloud infrastructure as a black box instead. For a single page application, this might lead to the following backend components that use PaaS:

Technologies like serverless enable you to develop APIs that use PaaS hosting. This can be a cost-effective solution for small startups or for developers to host their own solutions. Meanwhile, developers can use the cloud providers built-in authorization server when getting started with OAuth integration. This is sometimes referred to as Identity as a Service (IdaaS).

Your APIs or microservices are your core intellectual property (IP), and most companies implement them in a mainstream programming language, such as Java or C#. In doing so, organizations will want to leverage these technologies to their full capabilities without restrictions. In addition, code should be kept portable in case you want to use multiple cloud providers in the future. This can enable you to extend your digital solutions to emerging markets, where certain cloud providers may be blocked.

One downside to using PaaS for APIs is that you may run into limitations that lead to vendor lock-in, making it expensive to migrate APIs to another host in the future. Some compute-based API hosting may also have other limitations. For example, in-memory storage may be impossible if a system must spin up a new API instance for every request. These issues can add complexity and work against your technical architecture.

You must also control which API endpoints are exposed to the internet and secure the perimeter in your preferred way. A zero-trust approach is recommended for connections between APIs, as it can enforce both infrastructure and user-level security. Finally, APIs connect to sensitive data sources, so they should be hosted behind a reverse proxy or API gateway as a hosting best practice. This makes it more difficult for attackers to gain access to that data.

These requirements lead many companies to host APIs using a different cloud building block. Although virtual machines used to be more common, container orchestration platforms such as Kubernetes now provide the best API hosting features. This creates an updated deployment picture for APIs, where they are hosted inside the cluster while you continue to use PaaS for some other components:

Once API hosting is updated to use container-based deployment, there are no restrictions on code execution, and you have a portable backend that can be migrated between clouds. Your technical staff will also learn how to use modern patterns that deal with deployment and availability in the best ways. You then need to think more about other critical components that support your APIs.

As you integrate OAuth into your applications and APIs, you will realize that the authorization server you have chosen is a critical part of your architecture that enables solutions for your security use cases. Using up-to-date security standards will keep your applications aligned with security best practices. Many of these standards map to company use cases, some of which are essential in certain industry sectors.

APIs must validate JWT access tokens on every request and authorize them based on scopes and claims. This is a mechanism that scales to arbitrarily complex business rules and spans across multiple APIs in your cluster. Similarly, you must be able to implement best practices for web and mobile apps and use multiple authentication factors.

The OAuth framework provides you with building blocks rather than an out-of-the-box solution. Extensibility is thus essential for your APIs to deal with identity data correctly. One critical area is the ability to add custom claims from your business data to access tokens. Another is the ability to link accounts reliably so that your APIs never duplicate users if they authenticate in a new way, such as when using a WebAuthn key.

All of this leads to the preferred option of using a specialist cloud native authorization server. This is more efficient because the authorization server is hosted right next to your APIs. It also gives you the best control over security, limiting which authorization server endpoints are exposed to the internet.

As well as a hosting entry point, the API gateway (or reverse proxy) is a crucial architectural component. The API gateway can perform advanced routing and security-related tasks like token translation before your APIs receive requests. By externalizing security plumbing, your API code is simpler and more business-focused.

It is recommended to use the Phantom Token pattern so that internet clients receive only opaque access tokens. Unlike JSON Web Tokens (JWTs), which are easily readable, Phantom Tokens cannot reveal any private details that might disclose personally identifiable information (PII). When a client calls an API, the gateway can then perform introspection to translate from opaque access tokens to JWT access tokens. This flow is illustrated below.

There are many other gateway use cases, but a critical capability is running plugins that can perform both HTTP translation and routing as a single unit of work. There should be no limitations on the code you can write in the plugin. This is another area where cloud native solutions may provide better capabilities than the cloud providers generalist solution.

The authorization server and API gateway are key security components, and some companies also use an entitlement management system for their business authorization. Meanwhile, additional specialized components are required to support your APIs. These also must be chosen wisely, based on the providers capabilities and your requirements.

Each company must decide which third-party components they need. For example, it is common to host individual components for monitoring, log management and event-based data flows alongside your APIs. A possible setup is shown below:

PaaS is still an excellent choice for some component roles, though, and these days I follow a mix and match approach. Components that are a vital part of your API architecture should be hosted inside the cluster. I often prefer a serverless approach for other components if it is easier to manage.

The classic example where PaaS works better than CaaS is when delivering static web content to browsers. A content delivery network (CDN) can push the content to many locations at a low cost to enable globally equal web performance. This is more efficient than hosting CaaS clusters in all of those locations. See the Token Handler pattern for further details on using this approach, while also following current browser security best practices.

When companies are new to OAuth, there is often a fear that the authorization server could become unavailable, leading to downtime for user-facing applications. This concern remains valid, but when using cloud native APIs, you are already assuming this risk, and you should be able to follow identical patterns for third-party components. When using a cloud native authorization server, check that its deployment and availability behavior provides what you need.

Also, consider the people-level requirements. An InfoSec stakeholder will want a system with good auditing of identity events. These days DevOps staff should be able to perform zero-downtime upgrades of the authorization server or use canary deployment, where both old and new versions run simultaneously. The system should also have modern logging and monitoring capabilities so that technical support staff can troubleshoot effectively when there are configuration or connection problems.

Companies need to push their software down a pipeline, and discovering issues early on saves costs considerably. The benefits of a productive developer setup are often overlooked, but it is an area where cloud native provides some compelling advantages.

A developer, architect or DevOps person can run most cloud native components on a local computer. This can be a great way to first test the cloud native authorization server and API gateway and design end-to-end application flow.

Operational behavior such as upgrades can then be verified early, using a local cluster. Once the system is working with the desired behavior, you can simply update your Docker-based deployment, and the rest of the pipeline will also work in the same way.

Cloud native architecture provides the most portable and capable platform for hosting and managing your APIs, but keep an eye on the important security requirements. This will lead you to choose best-of-breed supporting components and host all of them inside your cluster. Choose an authorization server based on the security features you need and review it from an operational viewpoint.

At Curity, we provide a powerful identity and access management system designed to be cloud native from the ground up. It also integrates with modern cloud native platforms. As well as having rich support for standards, the system is based on a separation-of-concerns philosophy and is extensible to provide customers with the behaviors they need. There is also a free Community Edition, and it is trivial to spin up an initial system using a Docker container.

As a final note, the security components in your cloud native cluster will enable many powerful design patterns. Still, good architecture guidance is also a key ingredient when building cloud native security solutions. Our resource articles, guides, and code examples provide many end-to-end cloud native flows to help you along the way.

The New Stack is a wholly owned subsidiary of Insight Partners, an investor in the following companies mentioned in this article: Docker.

Image byThomas BreherfromPixabay

Originally posted here:
OAuth Security in a Cloud Native World The New Stack - thenewstack.io

Interview OVHcloud is perhaps best known for cloud computing, hosting, and dedicated servers in its network of datacenters but the company has also made news in other arenas. For instance, taking on Microsoft in the European courts or the fire at one of its datacenters that destroyed customer data.

Backups? It's the cloud, right?

CEO Michel Paulin addresses the fallout from the March 2021 fire during a chat with The Register. "We have decided to increase the level of resilience," he says, "above all the regulations."

This comprises, according to Paulin, containerization, fire extinguishing systems, and batteries. The opening of a new datacenter is being delayed "just to readapt with higher standards of security and safety of our servers."

A recent report on the conflagration highlighted a lack of an automatic fire extinguisher system and a wooden ceiling that was only rated to resist fire for an hour. Expensive lessons, we'd wager, were learned.

Affected customers who assumed their data was safe were not pleased. A class-action lawsuit was filed over the situation and Paulin notes that more clarity is required over who is responsible for backups. "Many customers, especially small customers, were not really very interested in that and they believed 'because it's in the cloud... my backups are secured.'"

The devil will be in the legal detail. As for the assumption that backups were part of the deal in the time before the "incident," Paulin says: "In fact, it was not. So we decided to clarify that."

Backups are now the default and it is up to the customer to opt out.

It's a timely reminder to all those who have shoveled their data into the cloud over the years to check their contracts to see exactly what Ts&Cs they and their vendor have agreed.

OVHcloud's legal team was also recently called to action for an entirely different reason. Along with several other companies, OVH has filed a complaint with the European Commission's antitrust unit over how Microsoft runs its licensing operation. Namely, trying to run the Windows giant's services somewhere that isn't Azure can result in some hefty fees. Not ideal for competing cloud vendors.

"We see today that there are a lot of practises to avoid [allowing] the customer to choose, but also to use trojan horses to impose their cloud. And this is a type of claim we've made against Microsoft," says Paulin.

CEO Michel Paulin, left, and Hiren Parekh, VP for Northern Europe

"Because we are not on Azure, and we refuse to resell Azure, the conditions financially, legally, and technically are very different. We pay more... if we agree to resell Azure, most of them change; the pricing changes, it's less expensive..."

Unsurprisingly, Paulin also isn't keen on the antics of the other major cloud vendors, such as Google and AWS. "I think it's not good for customers. Because in the end, if only one or two companies or three companies have 100 per cent of the market, innovation, pricing, everything will be very bad."

In calendar Q1, AWS, Microsoft and Google sucked in 62 percent of customers' spending globally on infrastructure cloud services, according to Canalys.

Paulin worries that due to their size, dominance, and deep pockets, the big tech vendors "have a lot of capacity to impose their solutions on the rest of the world and on the rest of the customers," thus eroding freedom of choice and innovation in the long term.

"Each time there is a new player, which is threatening a little bit, this type of monopoly immediately buys them or they are killed," he tells us.

It all sounds awfully familiar to anyone who has followed the activities of some of the current cloud giants over the years, even those that seem to have a born-again attitude to openness nowadays.

"The cloud should stay open," says Paulin. "Reversible, interoperable."

By "reversible," the CEO refers to the occasionally heart-stopping fees demanded by vendors for extracting a customer's data. "Interoperable," however, brings the EU GAIA-X initiative to mind.

"The principle of GAIA-X," explains Paulin, "is to maintain openness. On paper, everybody is OK; the governments, the customers, and industry."

For the uninitiated, GAIA-X is Europe's data infrastructure initiative to take on the US and Chinese cloud businesses, the idea being to address the concept of digital sovereignty. It started off with 22 members and has swelled to 343, including Microsoft, Amazon, Google Ireland and other titans.

Paulin used the word "sabotage" in reference to some of the players in the project. "They don't want to make in practice the objective, which is to create an open cloud," he said.

As the charge to the cloud accelerates, there is a danger that by the time GAIA-X is ready to go, the world will have moved on to the extent that the initiative is irrelevant. "Yes, this is a threat," Paulin admits. "Speed of execution [and] speed of implementation will be a key factor of success."

"As we are many, it's difficult to find sometimes a consensus to be able to move forward quickly," he adds. And, of course, the processes could end up being delayed by other factors (or contributors perhaps more keen on the status quo), "to be sure that they will never be visible, and they will never be implemented."

According to Paulin, 80 percent of OVHcloud's revenues come from Europe, although the company is keen to expand outside of the region. He also reckons the future is not just hybrid, but also multi-cloud as customers minimize their exposure to local regulations.

"Multi-cloud is the fact that the customer will have the capacity to give workloads, storage, and to exchange data across the different vendors easily. And not very costly. And again, sometimes to be compliant with the constraints of data sovereignty or any type of regulations."

OVHcloud also makes its own servers, and while Paulin is keen to boast of the company's approach to sustainability thanks to its designs that require "zero air-conditioning in our datacenters," OVH is up against the supply chain issues faced by the rest of the industry.

"We have a capacity to switch our CPUs and GPUs and to offer a similar type of services but with different hardware, depending on the how the supplies are working.

"We have stocks," he adds, which goes some way to mitigate the supply chain risk and keep its French and Canadian production lines ticking over.

OVHcloud's stock price is currently not far off its IPO last year, having risen as 2021 drew to a close and subsequently fallen back during 2022. It reported 382 million in revenues for its first half-year 2022 results, an increase of 13.3 percent year-on-year. The company subsequently raised its revenue growth guidance to 15-17 percent from 12.5 to 15 percent. France, however, remains the big beast in terms of its revenues accounting for nearly half at 190 million.

See the original post:
OVH: The cloud should be open, reversible, interoperable - The Register

Colocation in itself is not sufficient for a complete digital transformation. The entire functionality is now dependent on a host of services. Business owners may have difficulty accessing data due to security breaches, disasters, or decentralised networks that disrupt business continuity. A multitude of supplementary activities, therefore, need to be taken that ensure your hybrid model of work has uncontested data availability.

With geographically distributed teams, it puts an added onus on the technologies to ensure virtual collaboration, asynchronous communication, and result-based tracking. In these scenarios, Colocation Data Centers play a critical role in handling Cloud storage, virtual meetings, VOIP traffic, and web-based applications.

Here are some of the crucial services to ask from your Colocation Data Center provider:

It is not a revelation that effective business continuity is dependent on creating ample redundancies within the Data Center ecosystem. Where IT teams are already overextended in the pandemic age, managing dispersed endpoints and increasingly complex cyber threats, BaaS protects the organisations information by replicating the entire contents on an offsite location. This makes an organisation less susceptible to evolving threats and frees up resources for revenue-generating operations.

In essence, organisations should look for:

When there are bundles of assets and information to protect, an organisation needs to develop a varied set of capabilities to keep up with DDoS and data loss threats in todays time. SECaaS consolidates them all to provide network security, vulnerability scanning, identity and access management, encryption, intrusion prevention, continuous monitoring and security assessments. It is outsourcing the security of your company within a Cloud architecture. This ensures that you dont have to increase your costs while scaling your business in a hybrid model.

Essentially, organisations must look for:

Data loss is accelerating at an unprecedented pace due to both natural and man-made disasters. In the face of this uncertainty and its relative impact on a hybrid style of working, it is absolutely important to document and deploy a Disaster Recovery (DR) solution that provides failover for your Cloud computing environment. DRaaS is an effective option that can help you save recurring costs, ensure a faster recovery time, build in-house controls, and get cohesive data security.

Organisations should look for:

STaaS works as Cloud storage rented from a Cloud Service Provider (CSP) for data repositories, multimedia storage, backup, and DR. It is designed to handle heavy workloads without disrupting the ongoing business operations. A key benefit here is the offloading of any cost or effort involved in managing a full-fledged infrastructure and technology while giving you the bandwidth to scale up resources on demand. You can respond to market conditions faster and spin up new applications which turn out to be service differentiators in the evolving digital landscape.

Organisations should look for:

Round-the-clock monitoring and issue resolution are the two indispensable aspects required to keep an organisations remote environment functional. This includes software patching, reporting, and performance tuning on a need-to-implement basis. In totality, a third party vendor within a Colocation Data Center can cover your applications, middleware, web hosting, data management and other critical missions within the ecosystem that allow you to access technology and scalability without breaking the budget.

To ensure 247 availability, organisations should look for:

A unified policy around the Clouds is crucial to optimise application experience and automate Cloud-agnostic connectivity. Hence, a Cloud networking solution should deliver extensive integrations, flexibility, scalability and security while promising a consistent Colocation environment that consolidates all enterprise functions. The ideal way to ensure seamless remote communication is to go for a low-latency route optimisation engine with maximum network performance.

Organisations should look for:

To sum up

The pandemic has given rise to this new trend of working from home and office simultaneously, thus calling for a better infrastructure to support the trend. As this model is taken up by most companies, a hybrid data center architecture is needed as well, particularly for colocation providers. It is only this way that they can adjust to the changing dynamics of digital India.

(The author Mr.Nikhil Rathi, Founder & CEO, Web Werks and the views expressed in this article are his own)

Original post:
Significance of colocation in hybrid working - CXOToday.com