Microsoft Azure Reviews

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.

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.

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.

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.

I have been using Azure storage for five to six years. 

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.

It is a scalable solution because it depends on how the user manages it. But any services we choose in Azure are inherently scalable.

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.

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.

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.

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.

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.

Our use case involves running on-premises workloads on Microsoft Azure.

The tool has proven to be valuable for our organization by enhancing the availability and reliability of services. Our website and several applications hosted on it now benefit from improved availability features and increased reliability.

Microsoft Azure has significantly impacted operational efficiency by helping reduce or optimize costs, especially in the transition from on-premises capital expenditures to operational expenditures.

Navigating the frequent changes in the interface has been a challenge, requiring effort to keep up with updates. Options or features that were once located in one window may unexpectedly move to another, making it hard to stay current with the changes.

I have been using the product for three years. 

The tool's stability is good, and I would give it a nine out of ten. The challenges in connectivity, particularly when dealing with cloud services. It's complex and challenging to troubleshoot connectivity issues, especially when the source of the problem isn't clear.

The solution's scalability is excellent. My company has more than 500 users. We plan to increase the numbers. 

We chose to use Microsoft Azure primarily because of the package and solutions that Microsoft offered. The features and offerings provided by it were deemed to be better compared to other alternatives.

The product's deployment was a bit complex. The deployment process involved selecting the suitable Microsoft Azure service for migration and considering options like application services or virtual machines (servers). It required a thorough study to determine the most appropriate solution for the business use case. Our deployment team consists of ten resources. 

The deployment was a collaborative effort involving both our partners and the in-house team.

The value and benefits of using Microsoft Azure are significant, particularly for users like me. The services provided make it easy to access and available from anywhere.

The solution's licensing costs are yearly. 

We have initiated the migration of our on-premises workloads to the cloud, leveraging the application services offered by Microsoft Azure. We rely on third-party technologies for security. My advice would be to thoroughly plan and understand the cost implications before migrating to Microsoft Azure. Compare the technical capabilities of your on-premises design with your cloud design, and also conduct a financial comparison between on-premises and cloud expenses.

I rate it an eight out of ten. 

We host all of our production workloads in Azure, including all environments like UAT, development, and production. 

All our mission-critical workloads run in Azure, and that includes Azure Kubernetes Service (AKS), Azure API Management (APIM), Application Gateway, Load Balancer, and a full suite of security products, including Azure Sentinel, virtual machines, Azure Monitor, and ExpressRoute for private network connectivity.

Additionally, we've recently begun using Azure Synapse for data warehousing, and our SaaS solutions include Office 365 and Dynamics 365.

We use so many services, and it's constantly evolving, so there are many features I like. 

For example, Azure DevOps is good for deployment.

Additionally, different Azure products integrate well to create unified security solutions.

I really like the security features in Azure. Defender integrates everything, so I can handle all security posture management tasks within a unified solution. It outperforms SIEM, CIEM, and even Security Access Broker solutions. It's a complete package with unified support within Azure.

For compliance, we follow specific industry standards and government regulations. Azure provides a strong baseline, making compliance maintenance easier.

We use most Azure services. However, there are limitations with a few services, like the Standard Load Balancer. It lacks features like utilization visibility compared to traditional load balancers.

Some older services need better log visibility. Additionally, limitations can be restrictive. For example, the Standard Load Balancer currently lacks the ability to proactively monitor its own health.

Additionally, through the Cloud Solution Provider (CSP) model, Microsoft support isn't ideal. We often need to escalate to outsourced technical support, who rely on documentation. I often need to remind them that we follow the documentation and educate them on the issue. I rarely reach the actual Microsoft back-end engineers. Despite this, the service uptime and monitoring are good.

I have been working with it for seven years. I have been using it since 2017. 

It's stable. However, we had a major incident in Singapore last year, even though we don't have any resources in Australia (where another major incident occurred). 

Aside from that, we consider it reliable. One issue is that Microsoft sometimes upgrades released instances without notifying us (the last notification was in August). This happened with an automated upgrade I'm still working on resolving with support.

It's very scalable. We can scale up to 80-85% without issues. The only limitation is for scaling down below 10-15% due to CSP quotas and limitations, but that only affects a small portion (less than 10%).

We always forecast scalability needs, such as sizes, so it wasn't a bottleneck for deployments or production issues. Instead, it has only enhanced our environment.

Honestly, and without disrespect to Microsoft, I'd rate it a two out of ten.

It bothers me. I don't understand why we spend so much time and money on Azure when Microsoft relies on third-party companies for support in the CSP model. I don't know how the support model works within Microsoft, but giving it to poor-performing third-party companies is not ideal. 

Negative

My company primarily works on Azure now. However, in my previous organization, I used Oracle and AWS Cloud.

Navigation and some features are better in AWS. But the documentation can be complex compared to Azure. 

For example, the AWS documentation for creating a virtual machine end-to-end is very clear, even for someone unfamiliar with the cloud. 

Azure documentation, while good, can be overwhelming, requiring more experience to understand.

The initial deployment is easy now, after five years of using it. It might have been a nightmare a few years ago, but it's very good now.

We primarily deploy using PaaS (Platform as a Service) solutions. We avoid managing virtual machines whenever possible. Approximately 90% of our mission-critical application workloads are microservices run in Azure Kubernetes Service (AKS). We use virtual machines for the remaining 10%. We also use Azure SQL Database. We deploy resources using Azure DevOps pipelines.

Azure's documentation assists with our deployments. I like the recommendation feature, although we sometimes need to create exceptions, as is typical with any baseline. But overall, it's helpful. 

Not just the recommendations, but the entire added value is a great feature and provides valuable insights. The architectural framework pillars are also very useful to use as a whole, not just the individual recommendations.

I wasn't on the deployment team, but I support most architecture decisions. We use Azure DevOps pipelines to deploy to AKS clusters in production. 

We use YAML pipelines for infrastructure as code (IaC) deployments and Azure DevOps for application deployments. 

However, we face some integration challenges, but that's okay. It's not unique to Azure; every other tool has its own challenges.

For PaaS (Platform as a service) offerings, we have no issues with maintenance. However, with IaaS (Infrastructure as a service) services like Azure SQL, choosing maintenance slots is limited. 

For example, with business-critical Azure SQL instances, there are only three available maintenance slots to choose from. This makes it difficult even though the downtime is less than a minute. We cannot create custom maintenance windows for Azure SQL instances. 

We'd like Microsoft to offer more maintenance slots because the current options, like 10 PM to 6 AM Monday to Thursday, are not suitable for mission-critical workloads. It's not always feasible to ask stakeholders for downtime outside those windows. So, I would definitely recommend requesting more maintenance time slots as feedback.

It's a mixed bag. Some services are okay, while others are expensive. Different features within the same service, like Defender, have separate charges. This, combined with the skill shortage in FinOps strategy and management, makes it difficult to control costs. 

Cloud-native development makes it hard to predict future load capacity, so some services need the flexibility to scale up later, while others require full configuration during initial deployment.

Overall, I would rate the pricing on a seven out of ten, with ten being the most expensive.

I would recommend Azure based on specific business needs. However, I would recommend using this solution. 

Overall, I would rate the solution an eight out of ten because of the customer support issues. 

Microsoft Azure is a ticketing system that provides support services to Microsoft partners based on their partnership tier. Partners can raise support tickets, particularly for production-related issues. When we had issues with our Cosmos DB instance in production, we would submit a support ticket with screenshots detailing the error. We usually receive a call from a support engineer the same day.

Once a support engineer was assigned, the process was well-organized. Each engineer worked shifts of about eight to nine hours, and before their shift ended, they would email us to let us know who would be taking over, for example, "John Doe." They would also provide a summary of the issue, progress made, and next steps, ensuring a smooth handover without the need to re-explain the problem to the next engineer. It was a very efficient process.

Microsoft Fabric is a new service that integrates various functionalities into one platform, such as data engineering, data science, and data visualization. While promising, some complexities and limitations become apparent only after you use the service.

Fabric is a comprehensive and expensive service with tier-based pricing. For someone new to the platform, like those coming from Snowflake or Databricks, it can be difficult to grasp the cost implications and potential limitations without extensive exploration. The documentation outlines these limitations.

Pricing is very expensive.

I have been using Microsoft Azure for five years.

Cosmos DB offered better scalability. In Azure SQL, we had to carefully manage the storage tier, switching back and forth based on needs. But when we first implemented Cosmos DB, we had a good understanding of the required data volume over the past three months. This helped us select the appropriate tier because we had those figures.

If we had done it the other way around, it would have been much harder to estimate the data accurately. While you can get a rough idea, whether it works out in practice is more of a hit-and-miss approach, which we have already experienced with Cosmos DB. We applied the knowledge gained from that exercise to build a similar solution over Azure SQL.

On the DevOps side, our team consisted of five members, ranging from senior to junior roles. We would raise requests for specific services needed in the development environment. The process typically takes three to five business days, including all necessary approvals, from submitting the request to receiving the resources and verifying access.

Sometimes, even with the documentation available, understanding how it applies to our specific issues requires contacting a system engineer and creating a support ticket. The support engineer often provided additional details that were not included in the official documentation. This highlights the gap between the provided information and practical, real-world use cases.

Positive

Deployment was relatively straightforward. We didn’t encounter any issues whether we were using the GUI mode or working with our DevOps team, who utilized Terraform to provision resources as needed.

Most people use Azure Synapse for data onboarding and integration. Synapse is a big data analytics platform where data engineers and scientists can collaborate on a unified platform. Another service called API Management serves data outside Azure to downstream consumers or third parties. This is useful for cases where third parties can't be onboarded onto your system due to compliance or regulatory issues or need a specific slice of your data in near real-time. When we used Cosmos DB, we hosted near real-time data with a latency of about 15 minutes and served it via API M. With API M, authentication tokens were shared with the end users, allowing us to know precisely who was consuming data outside of our Azure environment. This setup was unique because it required providing near real-time information with minimal latency, even as the number of concurrent users increased. Cosmos DB worked well in this scenario due to its horizontal scalability. We also hosted similar data on Azure SQL, as Cosmos DB can be more expensive for cases where a smaller amount of data needed to be served, such as just the last one to three months of data. Azure SQL was a good alternative. The same API M interface was used to serve data from Cosmos DB and Azure SQL. Under the hood, one API would fetch data from Cosmos DB, and another would pull from Azure SQL. This architecture was tested and worked well for our client.

It was easy to maintain. Overall, I rate the solution an eight out of ten,

We utilize various Azure services such as Azure SQL, Azure Cosmos DB, Azure Data Factory, Azure Storage, and Azure Key Vault to build our data platform.

One of the features that I really like about Azure is its comprehensive environment for implementing a data platform. The solution provides multiple well integrated services which happen to work together seamlessly and provides flexibility and scale ability for use cases all around the industry.

There are some minor aspects which require improvement but they are very technical for an explanation. For example, the cost calculation for the services can be an unclear aspect which makes it difficult to estimate the expenses incurred accurately. Therefore, it will be beneficial to have it more transparent and apply your user-friendly cost estimation process to help users plan their budgets in a more efficient manner.

I have been using Microsoft Azure for the past 5 to 6 years.

I would rate it 9 out of 10 since it is stable but can get better.

I would rate the scalability 8 out of 10. The number of users on a platform is high but we do not have active engagement from all the users all the time. We have over 100 users but not all of them interact with the platform regularly. Keeping it aside, our main focus still remains on building data platforms which cater to different needs.

I have mixed feelings about Microsoft's technical support. While they do try to assist most of the time, I believe there's room for improvement. 

Neutral

As a data engineer, I mainly use these services rather than being involved in their implementation.

I would recommend Azure since it offers a variety of features and services which work together. This is quite rare in other platforms because they are not scalable. These features have helped us to promote our growth without any major challenges. The wide range of services make it a valuable option for implementing a data platform. However it is really difficult to quantify its value numerically. Different companies can Paradise different factors such as scalability, cost, or support which makes it different for each company.

It is important to keep in mind that there are also challenges such as the complex nature of estimating costs and no realistic expectations of savings due to the presence of hidden costs. Azure is an efficient solution but it requires improvement in terms of stability, support and pricing.

We use it for virtual machines, database services, load balancers, and firewall services.

The platform as a service for MySQL and PostgreSQL have significantly improved our operational efficiency. The performance is very good, and it has improved our business performance a lot.

Azure Security and Compliance features:

Azure offers built-in security called Microsoft Defender. This is a paid version that provides posture management for the servers. If there is any setting that needs to be changed or any problem with any network setting that could lead to a disaster, it shows us on the platform that the posture is not correct, and we fix it accordingly. It provides proactive overall management and monitors the entire infrastructure.

AI initiatives:

AI initiatives have been introduced, but we haven't tested it, so we cannot comment on that.

Everything is in the same control panel, and the management is very easy. If there's a new feature, it takes less time to understand the working procedure on the platform. So, it's user-friendly.

I would like to see improvement in the technical support. Sometimes it takes a long time. Only sometimes, not every time. It gets delayed. The response time should be faster.

I have been using it for six years. 

It is a very stable product. We haven't faced any issues with it, and it's been about five or six years.

I find it scalable. Whenever there is a large requirement to increase resources, we can increase them on the fly and decrease them when it's not necessary. It's very easy, and it takes very little time to scale up deployments.

Sometimes there are some problems that need to be taken care of by the Microsoft technical support team. We raise tickets for these cases, which are not solvable by email support. They call us back and resolve the problem.

Neutral

Previously, we used in-house servers. We moved to Azure. As for other solutions, no. There was no other solution. Everything was in-house. We had physical servers, and then we moved to cloud services.

I did not have any challenges or complexities with the initial setup process.

There's a vast knowledge base available. So, there were no challenges. If there's a new deployment, the tutorial is already there. You just have to follow it.

It took a couple of days to complete the migrations.

Maintenance happens at the machine level, not the platform level. There's no maintenance requirement at the platform level.

The initial deployment consisted of about twenty-five virtual machines and five to six services.

We did it in-house.

It has impacted cost savings or business productivity overall. We can easily scale up and scale down the services as per the requirement. 

During some months, the requirement is high. During that time, we scale up the service and scale it down when not necessary. So, it saves a lot of cost for us. The resource cost is not fixed here, and we can scale up and scale down as per the requirement. When we scale it down, the cost gets reduced by a lot.

The pricing is fine. Whenever you deploy a new service or virtual machine, they provide a calculator service that can upfront calculate the tentative cost for the service or resource, monthly or annually. On top of that, the third party through which we have taken the services adds some more discounts.

The recommendation would be to first go through the tutorials, or you have to know the requirement first. As for that, you need to go through the tutorials provided by Microsoft, and then you are good to go.

Overall, I would rate it an eight out of ten because there's always room for improvement.

I integrate our technologies into Azure. I just deploy, do some tests and POC for Azure. A recent project leveraged Azure's analytics services, it was related to Security Hub and Azure B1.

I support customers with their Azure implementations to better understand Azure architecture and how to integrate our technologies.

I like the ease of implementation and development and how quickly everything is ready.

Azure's security and compliance tools are not enough, and that's why other technologies like Fortinet would be much more recommended than the native ones.

Security, for sure, is an area of improvement. 

I have been working with it for three years now. 

I would rate the scalability a ten out of ten. Our customers are medium and enterprise businesses. 

I would rate my experience with the initial setup a ten out of ten, where one is difficult, and ten is easy.

It's cloud-based, both public and private.

The deployment can take a few days. I deploy it in the customer's premises, in their private or public cloud account.

I would rate the pricing a six out of ten,  where one is cheap, and ten is expensive. It's in line with other public cloud providers.

I would recommend it because it's easy to implement. But it always depends on the customer's needs. If their specific needs match with going towards the public cloud, then Azure would be one of my main recommendations.

Overall, I would rate it a nine out of ten. 

Our use cases for Microsoft Azure are financial-related.

Microsoft Azure covers all aspects, and having a single pane of glass becomes easier.

Microsoft Azure's design language is a little too basic. I would prefer Jira over Azure Boards. While Azure Boards offer quite a lot of customization possibilities, they also have their own limitations.

I have been using Microsoft Azure for more than a year.

Microsoft Azure is a stable solution.

I rate the solution a nine out of ten for stability.

Microsoft Azure is quite a scalable solution. More than 5,000 users are using the solution in our organization.

I rate the solution’s scalability an eight to nine out of ten.

I have previously worked with AWS and Jira.

We didn’t face any challenges with the solution’s initial setup.

The solution's deployment time takes less than hours. We continuously keep doing it. We have releases every week, and our pipeline keeps running. We update the product every week.

One or two engineers are involved in the solution's maintenance. Microsoft Azure has positively affected our operational expenses and revenue growth, which is why we switched from Amazon to Microsoft Azure.

I would recommend Microsoft Azure to other users. I can use Azure Boards to do brainstorming. Microsoft Azure covers all aspects, and having a single pane of glass becomes easier.

Overall, I rate the solution an eight to nine out of ten.