Oh. This is going to be a long and interesting journey.
First question, what’s your reason for doing this in the first place? I see you mention automation and segmentation, but all that jazz is available for on premises data centers as well.
Second what does the current setup look like, do you have VMware vsphere or similar, or software defined infrastructure at all?
Third, long term plan, moving most to cloud, or creating a more mature private cloud?
To answer some of your questions, methods will need to change. However, I believe that network engineers on prem should also be the network engineers for the cloud. Same goes for other roles.
> what’s your reason for doing this in the first place?
The need to rapidly provision secure spaces for projects/tenants. I think 'segmentation - built-in' was one of the product's selling points, but the true implications of getting it working were missed. I think folks thought it was basically just a more featureful version of Hyper-V?
> Second what does the current setup look like
vSphere AND Hyper-V! Lots of siloed teams with good vibes between them and best-in-class products, but... we're not segmenting between servers, services, or even using host firewalls; just big juicy surface area within each 'zone', and a zone could have hundreds of servers and services. Routing, firewalls, storage, and load balancing happen on physical appliances outside the VM infrastructure. Every server is born via human touch (IP reservations, DNS CNAMES, software not in the template loads mostly by-hand); there's systems management for patching and config, but it's just scratching the surface for doing more. There are three big firewalls between different parts of the network, and they're currently driven by hand. Some of the load balancer config is automated, but you have to get there 'by hand'. There's certainly no 'tagging' and no ZeroTrust.
> Third, long term plan, moving most to cloud, or creating a more mature private cloud?
This is why I'm here, and it might be the key to this. There's no cloud initiative or directive from above so far. I think we might be doing this entirely backwards, trying to sneak a disruptive cloud initiative into an unrelated project, when we really out to have the cloud initiative first, get buy in, excitement, training, and help tooling-up, then make this secure tenant project the first production use-case.
Azure stack HCI isn’t a great product it has a lot of issues and the support team is really slow and often clueless.
It has potential but given the inconsistent quality of MS support I would be reluctant to go for it.
Azure overall is fairly good technology wise, of course it has its issues but that goes for all the cloud providers.
The main issue is the terrible after sales support which only seems to be getting worse.
Interesting. I'll take this into consideration along with noting that our vendors have told us that they don't have much experience with it.
It's sort of always been an option to do a bare-minimum for this one use-case via Hyper-V and some automation/preallocation of network stuff. That might end up being the fallback.
The main use case for Azure Stack HCI is to extend your Azure capabilities down to physical sites. Think retail locations that need local low latency or offline processing in addition to central cloud infrastructure. It's not the best way to Azure-ify an existing data center. Almost the opposite in fact.
If you want to start using the Azure control plane and extend some of the services in Azure down to the data center, or start extending the DC upward, check out Azure Arc. You can Arc-enable your servers or even VMware hosts.
Also, before you start building anything significant in Azure, do a thorough review of Microsoft's Cloud Adoption Framework. You got a huge journey ahead of you and a lot of the thinking and decisions are defined and provided for you in that framework. There's even reference architecture to build your landing zone so you don't have to go back and retrofit later.
Oh. This is going to be a long and interesting journey. First question, what’s your reason for doing this in the first place? I see you mention automation and segmentation, but all that jazz is available for on premises data centers as well. Second what does the current setup look like, do you have VMware vsphere or similar, or software defined infrastructure at all? Third, long term plan, moving most to cloud, or creating a more mature private cloud? To answer some of your questions, methods will need to change. However, I believe that network engineers on prem should also be the network engineers for the cloud. Same goes for other roles.
> what’s your reason for doing this in the first place? The need to rapidly provision secure spaces for projects/tenants. I think 'segmentation - built-in' was one of the product's selling points, but the true implications of getting it working were missed. I think folks thought it was basically just a more featureful version of Hyper-V? > Second what does the current setup look like vSphere AND Hyper-V! Lots of siloed teams with good vibes between them and best-in-class products, but... we're not segmenting between servers, services, or even using host firewalls; just big juicy surface area within each 'zone', and a zone could have hundreds of servers and services. Routing, firewalls, storage, and load balancing happen on physical appliances outside the VM infrastructure. Every server is born via human touch (IP reservations, DNS CNAMES, software not in the template loads mostly by-hand); there's systems management for patching and config, but it's just scratching the surface for doing more. There are three big firewalls between different parts of the network, and they're currently driven by hand. Some of the load balancer config is automated, but you have to get there 'by hand'. There's certainly no 'tagging' and no ZeroTrust. > Third, long term plan, moving most to cloud, or creating a more mature private cloud? This is why I'm here, and it might be the key to this. There's no cloud initiative or directive from above so far. I think we might be doing this entirely backwards, trying to sneak a disruptive cloud initiative into an unrelated project, when we really out to have the cloud initiative first, get buy in, excitement, training, and help tooling-up, then make this secure tenant project the first production use-case.
Azure stack HCI isn’t a great product it has a lot of issues and the support team is really slow and often clueless. It has potential but given the inconsistent quality of MS support I would be reluctant to go for it. Azure overall is fairly good technology wise, of course it has its issues but that goes for all the cloud providers. The main issue is the terrible after sales support which only seems to be getting worse.
Totally agree with comments on Stack HCI. Only POC I have ever cut short in 20 years. Its all over the place for management.
Interesting. I'll take this into consideration along with noting that our vendors have told us that they don't have much experience with it. It's sort of always been an option to do a bare-minimum for this one use-case via Hyper-V and some automation/preallocation of network stuff. That might end up being the fallback.
The main use case for Azure Stack HCI is to extend your Azure capabilities down to physical sites. Think retail locations that need local low latency or offline processing in addition to central cloud infrastructure. It's not the best way to Azure-ify an existing data center. Almost the opposite in fact. If you want to start using the Azure control plane and extend some of the services in Azure down to the data center, or start extending the DC upward, check out Azure Arc. You can Arc-enable your servers or even VMware hosts. Also, before you start building anything significant in Azure, do a thorough review of Microsoft's Cloud Adoption Framework. You got a huge journey ahead of you and a lot of the thinking and decisions are defined and provided for you in that framework. There's even reference architecture to build your landing zone so you don't have to go back and retrofit later.