Works at CGI
Real User
Reduces work for our IT teams and saves us a lot of time
Pros and Cons
  • "Reduces work for our IT teams and saves us a lot of time."
  • "Quite an expensive solution."

What is our primary use case?

We are customers of Microsoft and I'm an IT architect.

What is most valuable?

The solution reduces work for our IT teams. They don't have to keep things up to date, and we can concentrate on our mission. The best feature for us is the help we get from Microsoft to migrate applications to the latest release and support efforts. It saves us a lot of time. 

What needs improvement?

The cost is a big issue, it can quickly go up if you don't control things. We've set up a system that shuts down machines regularly so we don't run up costs. Sometimes our development teams start up machines and forget to shut them down, and we see our costs go up quite rapidly with monthly surcharges. It would be helpful if Microsoft didn't change the control panels quite so often. It means we need to retrain personnel whenever things change and that seems to have an impact on our IT teams.

For how long have I used the solution?

We've been using this solution for nearly four years. 

Buyer's Guide
Microsoft Azure
March 2024
Learn what your peers think about Microsoft Azure. Get advice and tips from experienced pros sharing their opinions. Updated: March 2024.
763,955 professionals have used our research since 2012.

What do I think about the stability of the solution?

Stability is good and the solution is easy to maintain. 

What do I think about the scalability of the solution?

Scalability is really awesome. We don't have to worry about it at all, we're really impressed. Everyone in the company uses Azure. 

How are customer service and support?

Tech support is great. I find that we get answers quickly. It's just the first line of support that I criticize sometimes because it seems that whenever we open a ticket, they give us a run around with certain questions that basically we've answered. But as soon as we get into the next level of support, it's more advanced and questions are answered quite rapidly. Our tech guys know how to open a ticket and basically provide all the available information that they need. We sometimes have to get through that initial loop, and answer the same questions again and again, until they push us to another level of support.

How was the initial setup?

Four years ago the initial setup was quite complex but lately I find it's becoming increasingly easier, and the set up rules for securities are a lot simpler. These are things that are improving all the time. 

What's my experience with pricing, setup cost, and licensing?

Licensing is on an annual basis. 

What other advice do I have?

If a company wants to concentrate more on their mission and less on supporting infrastructure, they should give Azure a go. I find that it saves us a lot of time.

I would rate this solution an eight out of 10. 

Which deployment model are you using for this solution?

Hybrid Cloud
Disclosure: I am a real user, and this review is based on my own experience and opinions.
PeerSpot user
Network and systems administrator at a recruiting/HR firm with 1,001-5,000 employees
Real User
A stable platform with good technical support that is quick to resolve problems
Pros and Cons
  • "My experience with technical support so far is very good."
  • "If the price were reduced then it would be an improvement."

What is our primary use case?

We primarily use Azure for Office 365.

What is most valuable?

My experience with technical support so far is very good.

What needs improvement?

If the price were reduced then it would be an improvement.

For how long have I used the solution?

I have been using Microsoft Azure for one year.

What do I think about the stability of the solution?

For me and many other people, the general view is that Azure is very stable. We definitely plan to continue using it in the future.

What do I think about the scalability of the solution?

This is a scalable solution and we have thousands of users in our organization.

How are customer service and technical support?

I have had to contact Microsoft support about a problem that I was having with my virtual machine, where it could not find my VM. When I called them, they solved the problem quite fast.

Which solution did I use previously and why did I switch?

Prior to Azure, we used all of our Microsoft products on-premises.

How was the initial setup?

The initial setup was easy because we didn't do anything.

What about the implementation team?

We hired an IT consultant who is experienced in setting up cloud solutions. We did not do any of the setup ourselves.

What's my experience with pricing, setup cost, and licensing?

The licensing fees depend on the number of users that we have.

What other advice do I have?

Overall, this product is very good and I can recommend it. It would be difficult to improve.

I would rate this solution a nine out of ten.

Which deployment model are you using for this solution?

Public Cloud

If public cloud, private cloud, or hybrid cloud, which cloud provider do you use?

Microsoft Azure
Disclosure: I am a real user, and this review is based on my own experience and opinions.
PeerSpot user
Buyer's Guide
Microsoft Azure
March 2024
Learn what your peers think about Microsoft Azure. Get advice and tips from experienced pros sharing their opinions. Updated: March 2024.
763,955 professionals have used our research since 2012.
Microsoft and Dev-ops Architect at Mphasis
Real User
Top 5Leaderboard
Very easy to create a Kubernetes cluster

What is our primary use case?

Working Azure Kubernetes Service (AKS) to create a Kubernetes cluster. 

We are maintaining two environments of Kubernetes cluster on Azure using Azure Kubernetes Service (AKS).

We have used other managed PaaS services like ACS, Database, and monitoring, integrated with Jenkins for continuous integration and continuous deployment. 

How has it helped my organization?

We are running our product which is deployed on Azure AKS cluster. This really helps us to drive more business from customers.

What is most valuable?

  • It's very easy to create a Kubernetes cluster with the Azure Console 
  • Able to connect to the cluster using Azure PowerShell
  • Able to connect to the cluster using kubectl
  • Very good help from Microsoft Knowledge Base and also from the community
  • Very good support from the Microsoft team
  • Easy to manage as the core part is handled by Microsoft
  • Easy to add/scale up the cluster with more nodes by using the Azure console window or through scripting
  • Can integrate plugins with Jenkins for auto deployment
  • Integrated with a lot of open source tools for easy deployments and other functionalities like logging, monitoring, etc.

What needs improvement?

Better logging part when deployments are crashed, even when the entire cluster is crashed.

For how long have I used the solution?

One to three years.

What do I think about the stability of the solution?

Should always go with recommendations provided by Microsoft during the creation of new clusters. Otherwise, stability is an issue.

What do I think about the scalability of the solution?

Scalability is very good.

How are customer service and technical support?

Technical support is excellent. Recently, we have encountered a few issues however, the customer support team helped us very quickly to come out of it.

Which solution did I use previously and why did I switch?

We did not previously use a different solution. Kubernetes is the one we are using for container orchestration through Azure-managed Kubernetes service.

How was the initial setup?

The initial setup is very easy; straightforward.

Disclosure: I am a real user, and this review is based on my own experience and opinions.
PeerSpot user
PeerSpot user
Owner with 51-200 employees
Vendor
Windows Azure Migration cheat-sheet

I was recently asked whether I do have some cheat-sheet for migrating applications to Windows Azure. The truth is that everything is in my head and I usually go with “it should work” – quickly build, pack and deploy. Then troubleshoot the issues. However there are certain rules that must be obeyed before making any attempt to port to Windows Azure. Here I will try to outline some.

Disclaimer

What I describe here is absolutely my sole opinion, based on my experience. You are free to follow these instructions at your own risk. I describe key points in migrating an application to the Windows Azure Platform-as-a-Service offering – the regular Cloud Services with Web and/or Worker Roles. This article is not intended for migrations to Infrastructure Services (or Windows Azure Virtual Machines).

Database

If you work with Microsoft SQL Server it shall be relatively easy to go. Just download, install and run against your local database the SQL Azure Migration Wizard. It is The tool that will migrate your database or will point you to features you are using that are not compatible with SQL Azure. The tool is regularly updated (latest version is from a week before I write this blog entry!).

Migrating schema and data is one side of the things. The other side of Database migration is in your code – how you use the Database. For instance SQL Azure does not accept “USE [DATABASE_NAME]” statement. This means you cannot change database context on the fly. You can only establish connection to a specific database. And once the connection is established, you can work only in the context of that database. Another limitation, which comes as consequence of the first one is that 4-part names are not supported. Meaning that all your statements must refer to database objects omitting database name:

[schema_name].[table_name].[column_name],

instead of

[database_name].[schema_name].[table_name].[column_name].

Another issue you might face is the lack of support for SQLCLR. I once worked with a customer who has developed a .NET Assembly and installed it in their SQL Server to have some useful helpful functions. Well, this will not work on SQL Azure.

Last, but not least is that you (1) shall never expect SQL Azure to perform better, or even equal to your local Database installation and (2) you have to be prepared for so called transient errors in SQL Azure and handle them properly. You better get to know the Performance Guidelines and Limitations for Windows Azure SQL Database.

Codebase

Logging

When we target own server (that includes co-locate/virtual/shared/etc.) we usually use local file system (or local database?) to write logs. Owning a server makes diagnostics and tracing super easy. This is not really the case when you move to Windows Azure. There is a feature of Windows Azure Diagnostics Agent to transfer your logs to a blob storage, which will let you just move the code without changes. However I do challenge you to rethink your logging techniques. First of all I would encourage you to log almost everything, of course using different logging levels which you can adjust runtime. Pay special attention to the Windows Azure Diagnostics and don’t forget – you can still write your own logs, but why not throwing some useful log information to System.Diagnostics.Trace.

Local file system

This is though one and almost always requires code changes and even architecting some parts of the application. When going into the cloud, especially the Platform-as-a-Service one, do not use local file system for anything else, but a temporary storage and static content that is part of your deployment package. Everything else should go to a blob storage. And there are many great articles on how to use blob storage here.

Now you will probably say “Well, yeah, but when I put everything into a blob storage isn’t it vendor-lock-in?” And I will reply – depending on how you implement this! Yes, I already mentioned it will certainly require code change and, if you want to make it the best way and avoid vendor-lock-it, it will probably also require architecture change for how your code works with files. And by the way, file system is also “vendor-lock-in”, isn’t it?

Authentication / Authorization

It will not be me if I don’t plug-in here. Your application will typically use Forms Authentication. When you redesign your app anyway I highly encourage you rethink your auth/autz system and take a look into Claims! I have number of posts on Claims based authentication and Azure ACS(Introduction to Claims, Securing ASMX web services with SWT and claimsIdentity Federation and Sign-out, Federated authentication – mobile login page for Microsoft Account (live ID), Online Identity Management via Azure ACS, Creating Custom Login page for federated authentication with Azure ACSUnified identity for web apps – the easy way). And couple of blogs I would recommend you to follow in this direction:

Other considerations

To the moment I cant dive deeper in the Azure ocean of knowledge I have to pull out something really important that fits all types of applications. If it happens, I will update the content. Things like COM/COM+/GDI+/Server Components/Local Reports – everything should work in a regular WebRole/WorkerRole environment. Where you also have full control for manipulating the operating system! Windows Azure Web Sites is far more restrictive (to date) in terms of what you can execute there and to what part of the operating system you have access.

Here is something for you think on: I worked out with a customer who was building SPA Application to run in Windows Azure. They have designed a bottleneck for scaling in their core. The system manipulates some files. It is designed to keep object graphs of those files in-memory. It is also designed in a way that end-user may upload as many files as day want during the course of their interaction with the system. And the back-end keeps a single object graph for all the files user submitted in-memory. This object graph cannot be serialized. Here is the situation:

In Windows Azure we (usually, and to comply with SLA) have at least 2 instances of our server. These instances are load balanced using round-robin algorithm. The end user comes to our application, logs-in and uploads a file. Works, works, works – every request is routed to a different server. Now user uploads new file, and again, and again … each request still goes to a different server.

And here is the question:

What happens when the server side code wants to keep a single object graph of all files uploaded by the end user?

The solution: I leave it to your brains!

Conclusion

Having in mind the above mentioned key points in moving application to Windows Azure, I highly encourage you to play around and test. I might update that blog post if something rather important comes out from the deep ocean of Azure knowledge I have. But for the moment, these are the most important check-points for your app.

If you have questions – you are more than welcome to comment!

Disclosure: I am a real user, and this review is based on my own experience and opinions.
PeerSpot user
PeerSpot user
Owner with 51-200 employees
Vendor
Windows Azure Basics (part 2 of n)–networking
In my previous post on Windows Azure Basics, I tried to introduce you the cloud computing concept and explain the Windows Azure Platform with not so technical terms. It is time now to get over the networking. What is happening behind the scenes? What we can or cannot (currently) use?
Lets first take a look at the following picture, which tries to show almost complete Windows Azure hosted service:

Here are the terms/abbreviations you see on the illustration:
  • LB – Load Balancer. It is the Windows Azure software Load Balancer, which routes the Internet traffic to and from your hosted service;
  • VIP – virtual IP address. This is the internet facing public IPv4 (currently) network address for your hosted service. You have to pay attention to it, as you only have one single internet facing IP address per hosted service;
  • DIP – direct IP address. This is an internal subnet IPv4 network address that each single instance of your roles has. You have one of these DIPs for every single instance, and there is only one per instance. This IP address in internal subnet and cannot be used to directly access a specific instance from outside the Windows Azure hosted service. You can, however use this address for internal communication between instances of your roles within the whole Windows Azure deployment (hosted service)t;
Any Windows Azure Hosted service is considered a closed environment, meaning that no Internet traffic is routed to your service, unless you explicitly say so (we will later understand how)! And not only that, but any single instance is considered a closed environment. That means two things:
  1. The LB (Load Balancer) will not route any Internet traffic to the instances of your roles;
  2. The Windows Firewall of all your instances is set to default block everything (Effectively blocking even communication between different instances in a single deployment);
Of course the hosted service can access the Internet.
Couple of words on protocols. Currently the Windows Azure hosted service only supports the TCP/IP stack of protocols. Meaning that you can only have TCP traffic to/from/within your instances. UDP is not currently supported (thus excluding  IPSec also). What about web roles? Well, web roles are using HTTP protocol, which essentially lives over TCP. HTPS is also supported, because it also relies on TCP/IP. I very often see questions on whether sending/receiving mails is supported in Windows Azure, and the answer is yes. Before all, SMTP, POP(3), IMAP protocol families are all stacked over TCP. So we can have everything within the TCP stack, and (yet) nothing on the UDP stack (no SMB, no IPSec, no RTMP, etc).
Now, how can we route the Internet traffic to our instances in Windows Azure. The platform introduces an entity called Endpoint.
Endpoint is a combination of protocol type + port number, which effectively expose your instance to the internet at the given port number. What about protocol types? Well, currently you can only choose from “tcp” and “http/https”. There are two kind of endpoints: Input Endpoint and Internal Endpoint.  While the Input Endpoint will expose your instance to the Internet, by routing all Internet traffic on selected port to your instance, the Internal Endpoint will only open communication between instances in a single deployment.
Side note: you maybe already noticed that I am using “instances” more often then “roles”. I hope that you’ve read my first post and already know the difference. The key difference is that the instance is the actual VM (Virtual Machine) where your code lives, while the Role only defines the “footprint” for what to be instantiated on the Virtual Machine.
The catch. There is always a catch, and the current one is on the constraints put on the Endpoints:
  • You can have a maximum of 25 Endpoints per hosted service (Input + Internal);
  • You define your endpoints by a Role! Meaning that two different roles cannot share a single Endpoint;
  • All your Endpoints within a Hosted Service must be unique. Meaning that you cannot have an Input Endpoint (i.e. “EndpointWeb") serving HTTP protocol on port 80 for one Role and have another Input Endpoint (i.e. EndpointWebMVC) serving again HTTP protocol on port 80 for another Role. Here I stress that we define Endpoints at Role level, so every instance of this role will have the endpoints defined;
Behind the scenes: When you add a Web Role in your cloud project, the Visual Studio Tools for Windows Azure automatically create an HTTP endpoint on port 80 for your WebRole. It is named “Endpoint1” (but this might change in the future). Having in mind last of the constraints, if you add a second WebRole to your cloud project, a new Endpoint (Endpoint2) will be automatically created with protocol HTTP and port 8080! So be aware of that fact and do not let it surprise you Winking smile
Something more on Windows Azure networking – the LB (Load Balancers) do not use sticky sessions. That means that every single request is routed on its own. So and end user can open a page on your website hitting Instance 0 of Web Role (check the illustration at the top), that page may create several AJAX requests and all AJAX request will go on their own route. Any of the requests may either hit Instance 0, but they may also Instance 1, and so on. That requires us to build a fully stateless applications. The application logic shall be fully operational and aware that some user’s requests may end up in one instance, other in other instances. So we have to always use a common storage (Azure Storage or SQL Azure or AppFabric Caching service) for all the data that needs to be persisted across user’s requests.
Remote Desktop? Yes, it is supported! Remote desktop operates on port 3389 over TCP protocol. Again the catch: Be aware that enabling a Remote Desktop for all your roles in your deployment (which just a checkbox), will automatically create an Input Endpoint for your service. This affects the total number of Endpoints per service (remember, it is 25)!.
What about sending mails, again? As I already wrote, the common mailing protocols are supported (SMTP, POP, IMAP), however Windows Azure does not provide a “Email-as-a-service” service. Luckily enough, a great collaboration was announced, and every Windows Azure subscription receives a complimentary free account on SendGrid with a limit of 10000 e-mails monthly (I think, this you can check Winking smile). So you can use the SendGrid service to send your application / service e-mails. You get it for free for the first 10k e-mails in the month. If your needs exceed this limit, you can upgrade your account for a very reasonable price!
Disclosure: I am a real user, and this review is based on my own experience and opinions.
PeerSpot user
PeerSpot user
Owner with 51-200 employees
Vendor
Windows Azure Basics–Compute Emulator

Following the first two posts of the series “Windows Azure Basics” (general terms, networking) here comes another one. Interestingly enough, I find that a lot of people are confused what exactly is the compute emulator and what are these strange IP Addresses and port numbers that we see in the browser when launching a local deployment.

If you haven’t read the Windows Azure Basics – part 2 Networking, I strongly advise you to do so, as rest of current post assumes you are well familiar with real Azure deployment networking components.

A real world Windows Azure deployment has following important components:

  • Public facing IP Address (VIP)
  • Load Balancer (LB) with Round Robin routing algorithm
  • Number of Virtual Machines (VM) representing each instance of each role, each with its own internal IP address (DIP – Direct IP Address)
  • Open ports on the VIP
  • Open ports on each VM

In order to provide developers with as close to real world as possible, a compute emulator needs to simulate all of these components. So let's take a look what happens when we launch locally a Cloud Service (a.k.a. Hosted Service).

VIP Address

The VIP address for our cloud service will be 127.0.0.1. That is the public IP Address (VIP) of the service, via which all requests to the service shall be routed.

Load Balancer

Next thing to simulate is the Azure Load Balancer. There is a small software emulated Load Balancer, part of the Compute Emulator. You will not see it, you are not able to configure it, but you must be aware of its presence.  It binds to the VIP (127.0.0.1). Now the trickiest thing is to find the appropriate ports to bind. You can configure different Endpoint for each of your roles. Only the Input Endpoints are exposed to the world, so only these will be bound to the local VIP (127.0.0.1). If you have a web role, the default web port is 80. However, very often this socket (127.0.0.1:80) is already occupied on a typical web development machine. So, the compute emulator tries to bind to the next available port, which is 81. In most of the cases port 81 will be free, so the "public" address for viewing/debugging will be https://127.0.0.1:81/. If port 81 is also occupied, compute emulator will try the next one – 82, and so on, until it successfully binds to the socket (127.0.0.1:XX). So when we launch a cloud service project with a web role we will very often see browser opening this wired address (https://127.0.0.1:81). The process is same for all Input Endpoints of the cloud service. Remember, the Input endpoints are unique per service, so an Input Endpoint cannot be shared by more than one Role within the same cloud service.

Now that we have the load balancer launched and bound to the correct sockets, let's see how the Compute Emulator emulated multiple instances of a Role.

Web Role

Web Roles are web applications that run within IIS. For the web roles, compute emulator uses IIS Express (and can be configured to use full IIS if it is installed on the developer machine).  Compute Emulator will create a dedicated virtual IP Address on the local machine for each instance of a role. These are the DIPs of the web role. A local DIP looks something like 127.255.0.0. Each local "instance" then gets the next IP address (i.e. 127.255.0.0, 127.255.0.1, 127.255.0.2 and so on). It is interesting that the IP Addresses begin at 0 (127.255.0.0). Then it will create a separate web site in IIS Express (local IIS) binding it to the created Virtual IP Address and port 82. The emulated load balancer will then use round robin to route all requests coming to 127.0.0.1:81 to these virtual IP Addresses.

Note: You will not see the DIP virtual address when you run ipconfig command.

Here is how does my IIS Express look like when I have my cloud service launched locally:

Worker role

This one is easier. The DIP Addressing is the same, however the compute emulator does not need IIS (neither IIS Express). It just launches the worker role code in separate processes, one for each instance of the worker role.

The emulator UI

When you launch a local deployment, Compute Emulator and Storage Emulator are launched. You can bring the Compute Emulator UI by right clicking on the small azure colored windows icon in the tray area:

For purpose of this post I've created a sample Cloud Service with a Web Role (2 instances) and a Worker Role (3 instances). Here is the Compute Emulator UI for my service. And if I click on "Service Details" I will see the "public" addresses for my service:

Known issues

One very common issue is the so-called port walking. As I already described, the compute emulator tries to bind to the requested port. If that port isn't available, it tries next one and so on. This behavior is known as "port walking". Under certain conditions we may see port walking even between consequent runs of same service – i.e. the first run compute emulator binds to 127.0.0.1:81, the next run it binds to 127.0.0.1:82. The reasons vary, but the obvious one is "port is busy by another process". Sometimes the Windows OS does not free up the port fast enough, so port 81 seems busy to the compute emulator. It then goes for the next port. So, don't be surprised, if you see different ports when debugging your cloud service. It is normal.

Another issue is that sometimes browser launches the DIP Address (https://127.255.0.X:82/) instead the VIP one (https://127.0.0.1:81/). I haven't been able to find a pattern for that behavior, but if you see a DIP when you debug your web roles, switch manually to the VIP. It is important to always use our service via the VIP address, because this way we also test out application cloud readiness (distributing calls amongst all instances, instead of just one). If the problem persists, try restarting Visual Studio, Compute Emulator or the computer itself. If issue still persists, open a question at StackOverflow or the MSDN Forum describing the exact configuration you have, ideally providing a Visual Studio solution that constantly reproduces the problem. I will also be interested to see the constant repeatable issue.

Tip for the post: If you want to change the development VIP address ranges (so that it does not use 127.0.0.1) you can check out the following file:

%ProgramFiles%\Microsoft SDKs\Windows Azure\Emulator\devfabric\DevFC.exe.config

DevFC stands for "Development Fabric Controller". But, please be careful with what you do with this file. Always make a backup of the original configuration before you change any setting!

Happy Azure coding!

Disclosure: I am a real user, and this review is based on my own experience and opinions.
PeerSpot user
Senior Services Architect at a tech services company with 10,001+ employees
Real User
Highly scalable, reliable, Missing the competitive edge
Pros and Cons
  • "The design of Microsoft Azure is for it to be scalable and it is scalable."
  • "When we work with Microsoft Azure we deploy it in a hybrid system. We do many operations with the open stack and I used it for APIs connected to Microsoft Azure. The reduction is because those APIs and our tools that are required to connect are not for the Microsft Azure solution. It has a bit of complexity, nothing to do with Microsoft Azure as a CSP."

What is our primary use case?

Most of our Customers do not want to have a single Cloud Service Provider (CSP) and have been adopting a Multi Cloud or a Hybrid Cloud scenario. We have addressed client requirements and have adopted CSP depending on the use case. We have worked with Azure and have provided niche solution such as Government Commercial Cloud, Healthcare Cloud etc.

What needs improvement?

We have deployed multiple solutions into Microsoft Azure. In most of the cases we augment our Application monitoring "in-house" developed tool to monitor things like garbage collection, IIS queuing. If these attributes and parameters could be included as part of the Azure Monitor it would be great.

For how long have I used the solution?

Using Microsoft Azure for approximately three years.

What do I think about the stability of the solution?

Microsoft Azure is a stable solution.

What do I think about the scalability of the solution?

The design of Microsoft Azure is for it to be scalable and it is scalable.

How are customer service and support?

I have not contacted the support from Microsoft Azure. We support the solution ourselves. We have Azure architect experts who are on our payroll. We have experience since we have been working on the stack for almost two and a half years.

How would you rate customer service and support?

Neutral

Which solution did I use previously and why did I switch?

We use all different types of CSP, such as Amazon AWS and Google Cloud.

How was the initial setup?

The initial setup of Microsoft Azure is complex.

I rate the initial setup of Microsoft Azure a four out of five.

Which other solutions did I evaluate?

Yes. We have a in-house Cloud CoE, that ensures the changes introduced by CSPs i.e. update on the new services that are provisioned as well as the periodic commercials impacts for the Services being consumed across all CSPs - Amazon AWS and Google Cloud

What other advice do I have?

All the cloud service providers(CSP) are more or less have the same services. The use case for the cloud would need the sustainment of tiering storage. We don't see a big discrepancy when it comes to Microsoft Azure, but there are pros and cons.

I rate Microsoft Azure a seven out of ten.

Which deployment model are you using for this solution?

Public Cloud

If public cloud, private cloud, or hybrid cloud, which cloud provider do you use?

Microsoft Azure
Disclosure: My company has a business relationship with this vendor other than being a customer: Implementer
PeerSpot user
Santiago Ochoa - PeerSpot reviewer
Consultant at Open Source & Cloud Advisory Services Architect IBM
MSP
Top 20
Good storage and elasticity with reasonable pricing on offer
Pros and Cons
  • "The pricing is quite good, and it is designed as pay-per-use."
  • "Maybe Microsoft could improve its monitoring around the networking."

What is our primary use case?

I use Microsoft Azure for different clients. I have different workloads or different architecture in Azure.

The most common use case is for migrations from on-premise to cloud. The principal solution is for a virtual machine, storage, and networking. 

What is most valuable?

The principal features that I use include computing, networking, and storage.

The elasticity within the cloud is great for clients to complete their pre-determined goals.

The cost is pretty good. They have a pay-per-use way of dealing with licensing that is very attractive. Migrating to the cloud becomes very attractive due to this.

The solution can scale.

Stability has been good.

What needs improvement?

Maybe Microsoft could improve its monitoring around the networking.

Clarity on the cost of the things could be better in some cases. For example, it's difficult to do a report with the cost of the things in Azure. Their calculator to estimate the cost needs to improve in terms of the estimation they provide.

For how long have I used the solution?

I have five years of experience with this product.

What do I think about the stability of the solution?

There are some products that have good stability and virtual machines - depending on your setup and configuration - are very good. With Microsoft Azure, it's very rare that I even have a problem with it. In any solution, there's always some form of issue, however, with this, it's less common.

What do I think about the scalability of the solution?

I've found the scalability to be quite good. 

I have worked with clients that have 300 users or more, however, sometimes with a smaller client they will have maybe 60 or 100 users.

How are customer service and support?

Technical support is very good, however, it depends on the problem. There are some problems that originate with the client itself that Microsoft, naturally, couldn't necessarily resolve due to the origin of the problem. However, in general, I haven't had any problems with the support with Microsoft. They are helpful and responsive. 

How was the initial setup?

Whether the initial setup is straightforward or complex depends on the client. There are some products that are more complex to set up. However, for me, it's easy to deploy different features or different products. It's easier compared to on-premise deployments.

Deployments can be two to three months for an enterprise.

For maintenance, you need a good team with good skills in Microsoft Azure, especially in the cloud due to the fact that it's a bit different. Things are different in the cloud compared with on-premise. 

What about the implementation team?

I am able to deploy the solution for clients. 

I work with a team in my company. When, for example, we need help or support from Microsoft, we have a contact with the architect of this provider to resolve some issue or some problem that we have in the cloud.

What's my experience with pricing, setup cost, and licensing?

The pricing is quite good, and it is designed as pay-per-use.

What other advice do I have?

We are partners with Microsoft.

I am an architect, cloud architect, and I work in design solutions and implementing solutions in the cloud.

I'd rate the product at an eight out of ten.

Which deployment model are you using for this solution?

Public Cloud

If public cloud, private cloud, or hybrid cloud, which cloud provider do you use?

Microsoft Azure
Disclosure: I am a real user, and this review is based on my own experience and opinions.
PeerSpot user
Buyer's Guide
Download our free Microsoft Azure Report and get advice and tips from experienced pros sharing their opinions.
Updated: March 2024
Buyer's Guide
Download our free Microsoft Azure Report and get advice and tips from experienced pros sharing their opinions.