What is our primary use case?
In any general use case, if we want to run any application on our own virtual machines, that's Infrastructure as a Service (IaaS). If we want to use a readily available managed service in Azure, like Azure Storage, Azure Security Center, or Logic Apps, those are Platform as a Service (PaaS) offerings.
This is because they're provided on the platform, and they manage them. We can run our data and applications on them. If we're using a complete application as a service provided by vendors, like Office 365 (including the email service), that's considered Function as a Service (FaaS) because we're not configuring anything on our end – we're just using it.
I'm involved in all kinds of services, whether it's IaaS, PaaS, or SaaS. It depends on the specific customer requirement.
How has it helped my organization?
We implemented Azure for our infrastructure needs. Our core components include virtual machines, virtual networks, network security groups (NSGs), load balancers, public IPs, and private IPs. For private endpoints, those are more specific to Platform as a Service (PaaS) offerings.
Additionally, we utilize a hub network with a firewall, DNS server, and Active Directory server (AD). This aligns with the enterprise landing zone concept, where a connectivity subscription with a hub network that includes a firewall, DNS, AD, Azure Monitor, etc., would be implemented.
These shared services reside in the hub network if we have on-premises servers or other large assets running in Azure.
For management purposes, we have a separate subscription – the management subscription – which includes Log Analytics workspace and other data monitoring tools. Finally, the landing zone itself would house our workloads and applications.
What is most valuable?
We rely on many security features to manage our Azure cloud environment. It's a kind of framework we follow. First, there's posture management with compliance by following specific regulations. Then, for specific services, mainly Azure Defender and Azure Sentinel are important. They use the latest threat intelligence to identify threats and vulnerabilities.
On top of that, there are policies to ensure your security posture is maintained, followed by firewalls, Azure Defender, and Azure Sentinel for threat intelligence and response.
All these services are managed services and they are auto-scalable.
What needs improvement?
In Azure, there are so many things. Especially when dealing with different regions. Suppose we are far from a region and using it over the internet, then probably more Edge Zones in nearby cities would help. This would give easier access with no delay or latency.
Right now, the problem in many remote areas is they may have low-bandwidth internet connections. This can make it difficult to access large services that require more bandwidth to download data and such. So, if the service were closer, it would be faster to access. At least they could access it easily.
Again, there are many other suggestions from a technical perspective on different services. But this is just from a user's perspective, and user demographics can create challenges. Other users with very good access might not have latency or other issues, but they might have operational challenges.
For example, let's say ExpressRoute. It's very expensive and mainly available for enterprise customers. Suppose individual users want that kind of dedicated connectivity over a service provider like Airtel or Vodafone and have an ExpressRoute from their phone, but is there any availability for a lower-cost option?
Because it's very expensive as well, if there were any such services available at a lower cost, then that would really help customers, especially SMBs, to have more consistent and reliable applications.
The main improvement I expect is capacity improvement. For example, live streaming applications require a lot of backend computing power. During events like football matches, millions of requests can occur per second. Existing services might not be sufficient to handle this.
We need to know the maximum scalability based on data center capacity limitations. In some cases, we have to deny customer requests due to insufficient capacity. So, improved scalability is a key area for development, and I'm sure other cloud providers face similar challenges.
There are a lot of services already in Azure, but from a regular user's perspective, improvements can be made to specific services and features. For example, in Kubernetes, initially, it was limited. You could only create a Kubernetes cluster in one subnet.
If all the IPs in that subnet were used, you couldn't expand that subscription. That was an issue, but it's been addressed. Now, you can increase the number of nodes by creating a new node pool in the same cluster with additional subnets. Improvements like this feature-based approach can be applied to many services.
Another key area for improvement is the Azure load balancer. Currently, it only supports virtual machines (VMs) running in the same virtual network (vNet) on the backend.
They should definitely support machines or IPs running on-premises (prem) or in other Azure VNets. GCP and AWS already support that. So, Azure Load Balancer should support that as well because being able to provide support is a very basic requirement or a valid request from any customer. These kinds of feature requests can be improved from a cloud service provider's perspective.
For how long have I used the solution?
I have been using Azure storage for five to six years.
What do I think about the stability of the solution?
It is a stable solution because it depends on the workload you expect. Based on that data, you can configure how many users it can handle.
Managed services are definitely more efficient than IaaS and offer a performance-centric approach.
What do I think about the scalability of the solution?
It is a scalable solution because it depends on how the user manages it. But any services we choose in Azure are inherently scalable.
How was the initial setup?
The initial setup is straightforward. Nothing is truly complex unless your solution or requirement itself is complex.
The deployment time depends on my requirements. Suppose a customer needs a very small environment, like two or three cluster machines with a standard load balancer on top, running their application on those VMs. It would hardly take 30 to 45 minutes to create the virtual machines (VMs), create a load balancer, allocate a public IP address, and set up a virtual network (vNet).
At the very beginning, we had to create a subscription. Within the subscription, you'll create a resource group. And within the resource group, we'll be creating a virtual network. Inside the virtual network, we'll deploy the VMs, a load balancer, a public IP, and a network security group (NSG).
Additionally, if I want to make it more secure, I can create a firewall as well. So, all of these together should be deployable within an hour.
What about the implementation team?
The number of people like developers required for the deployment depends on your environment. For instance, if you use an IaaS solution, you'll need more resources on your end to manage it.
But with a PaaS service, you'll need fewer people because the cloud service provider manages half of it. With a SaaS solution, you don't need anyone to manage it – the cloud service provider handles the entire application. You just use it.
So, it depends on the solution type. Therefore, more complex solutions require more resources to manage.
What was our ROI?
When we decide to increase capacity, we always consider the ROI and look at the projections for the next three to five years. Big investment decisions are only made based on that.
Similarly, any customer considering adopting a service in Azure, like Azure SQL Database or Logic Apps, will first look at the return on investment. They'll consider how much they're investing in these services, how many users will be using them, and how much money they'll make from them.
If it's not profitable based on their expectations or KPIs, they obviously won't add those services. So, it depends on the customer's specific requirements and expectations. We recommend the best possible services for their needs.
What's my experience with pricing, setup cost, and licensing?
Azure licensing costs. We always compare licensing to the ROI. Azure costing can be multi-layered. Increased capacity depends on your requirements and any contracts you have. On top of that, there's a separate cost for the licenses of the applications and operating systems you install in that capacity.
So, as long as you're using the existing capacity, you won't be charged extra for that. However, if you increase capacity, you'll only be charged for the services you use on that additional capacity, not for the capacity itself.
This depends on specific guarantees made in contracts that can last from two to eight years. These guarantees ensure investment has a return on investment. So, in that case, you wouldn't be charged for the additional capacity, just the services used on it.
Capacity increases based on customer requests are very rare, typically only for extremely high-volume scenarios. For example, millions of requests per second would require a service capacity increase beyond standard rates. Otherwise, we usually have enough capacity in different data centers across various regions.
Generally, most services and their licensing – it's that straightforward.
What other advice do I have?
I would rate Azure an eight out of ten for managed services and IaaS a seven out of ten.
While I can advise, many factors influence decision-making. For example, if we invest in a ten-million-dollar data center capacity improvement, we need to see the return on investment within a one to three-year timeframe. If not profitable, such a large investment wouldn't be justifiable.
Alternatively, customers could sign a five-year contract guaranteeing capacity usage and payment if we invest in the upgrade. These are the parameters that define decision-making in such situations.
Disclosure: My company has a business relationship with this vendor other than being a customer: Partner