Where to start...
-
@jaredbusch I'm actually trying to decipher it, and basically everyone uses that term for everything.
You have public clouds like Azure and AWS.
Then you have everyone else it seems competing against them. The INAP / iland , etc. Who I guess are more colocation type of companies.
The stuff I'm doing and referring to as cloud is running VM's in a datacenter. The company classifies it as a virtual private cloud from my portal.
-
@mmicha said in Where to start...:
Then you have everyone else it seems competing against them.
No one else can compete against them. There are basically only 3 cloud providers; Amazon, Microsoft, and Google.
No one else is cloud. Cloud is a specific type of design. You as IT need to understand that. @IRJ or @stacksofplates are free to expand on this as they work in this daily.
Any other use of the word is marketing. There is also nothing wrong with that, but when IT is designing their systems, they have to understand reality from marketing.
-
@jaredbusch The vmware infrastructure is not domain joined. It is the paid edition with Veeam as our backup solution.
I just have a domain controller running on each of the two hosts. There is no HA, and each is local storage.
I like keeping everything separate, so to save on a license of windows maybe something like samba for a file server would work.
SQL runs the Sage ERP databases, as well as our in-house system which I hate to say still mostly runs on Access 2003 ADP files. That's a developer thing/responsibility.
The IIS server is a developer thing too for stuff he has rewritten in .NET and is hosting on it. I do nothing with it. SQL / IIS / and the Access stuff are his babies.
WDS is really running MDT. I use it for deployment of PC's and such when needed. Saves me a lot of time.
-
@mmicha said in Where to start...:
@jaredbusch The vmware infrastructure is not domain joined. It is the paid edition with Veeam as our backup solution.
I just have a domain controller running on each of the two hosts. There is no HA, each is local storage.
I like keeping everything separate, so to save on a license of windows maybe something like samba for a file server would work.
SQL runs the Sage ERP databases, as well as our in-house system which I hate to say still mostly runs on Access 2003 ADP files. That's a developer thing/responsibility.
The IIS server is a developer thing too for stuff he has rewritten in .NET and is hosting on it. I do nothing with it. SQL / IIS / and the Access stuff are his babies.
WDS is really running MDT. I use it for deployment of PC's and such when needed. Saves me a lot of time.
on WDS -
Look at MS AutoPilot - Should do all the things you want.
-
@gjacobse I've used that at another location, and really like it. Probably what I will pivot to with the move to M365.
-
@dustinb3403 said in Where to start...:
don't work for solutions like AutoCAD without crazy high Opex costs to get the performance to match local performance
Two things. One) autocad files aren't that big. Other cad software is larger. Two) you do realize they don't copy the whole file back and forth right? They use block level dedupe and only diff the blocks that are necessary.
-
I would start looking at what the business needs are, not what infrastructure is needed.
Moving workloads to the cloud is legacy thinking. You're thinking that you don't need to worry about the hardware, which is true. But you can go much further than that.
If you move to using services instead (SaaS) you get the functionality without having to worry about hardware or software or infrastructure or monitoring and a myriad of other things.
So looking at the business needs I would start with the intention of having zero servers on prem, in the cloud, in colo or elsewhere. And go from there.
-
@stacksofplates said in Where to start...:
@dustinb3403 said in Where to start...:
don't work for solutions like AutoCAD without crazy high Opex costs to get the performance to match local performance
Two things. One) autocad files aren't that big. Other cad software is larger. Two) you do realize they don't copy the whole file back and forth right? They use block level dedupe and only diff the blocks that are necessary.
You do you realize I lumped all design files in with AutoCAD, indesign files can be massive, I've personally dealt with 13GB files because of how the designers had to use them. If you want to be a pedantic dickhead go ahead, but don't expect someone to list out every possible file and how it could be accessed.
Lastly, apple computes lock every file pre-emptively when accessing a share in the hopes of speeding up performance for the user, while we don't know what user systems @mmicha has, it's also not something that has been discussed.
This feature of apple's design makes dealing with file shares that much more painful in general.
-
@dustinb3403 said in Where to start...:
@stacksofplates said in Where to start...:
@dustinb3403 said in Where to start...:
don't work for solutions like AutoCAD without crazy high Opex costs to get the performance to match local performance
Two things. One) autocad files aren't that big. Other cad software is larger. Two) you do realize they don't copy the whole file back and forth right? They use block level dedupe and only diff the blocks that are necessary.
You do you realize I lumped all design files in with AutoCAD, indesign files can be massive, I've personally dealt with 13GB files because of how the designers had to use them. If you want to be a pedantic dickhead go ahead, but don't expect someone to list out every possible file and how it could be accessed.
Lastly, apple computes lock every file pre-emptively when accessing a share in the hopes of speeding up performance for the user, while we don't know what user systems @mmicha has, it's also not something that has been discussed.
This feature of apple's design makes dealing with file shares that much more painful in general.
Don't get mad because you specifically named a tool. Yes direct modeling software generates larger files, but even things like Dropbox still chunk the data into 4 mb blocks. I've worked with a shop that used Dropbox to sync their solidworks data and it was fine. Not sure why you think that when @IRJ mentions running the workloads in public cloud you think that means setting up a giant SMB/NFS share that things would "access". Amazingly TeamCenter runs fine on pub cloud and I guarantee they handle larger than 13GB models.
Stop the childish attitude.
-
@mmicha said in Where to start...:
The stuff I'm doing and referring to as cloud is running VM's in a datacenter. The company classifies it as a virtual private cloud from my portal.
Private cloud is something very specific, and specifically not this.
VMs in a datacenter is called "hosting."
"Private Cloud" is when someone builds a cloud and it is used by you, and no one else. Extremely expensive, extremely unique and rare. No normal company needs a whole cloud infrastructure of their own.
Your company SPECIFICALLY is wanting PUBLIC hosting, probably not cloud.
-
@pete-s said in Where to start...:
I would start looking at what the business needs are, not what infrastructure is needed.
Or to word this differently.... you have to know the business needs to be able to make infrastructure decisions.
-
@mmicha said in Where to start...:
I just have a domain controller running on each of the two hosts. There is no HA, and each is local storage.
How do you have two DCs that aren't HA? I think that they must be HA and you aren't aware. DCs create an HA cluster simply by getting domain joined.
-
@jaredbusch said in Where to start...:
No one else can compete against them. There are basically only 3 cloud providers; Amazon, Microsoft, and Google.
No one else is cloud.This is not correct, at all. Those are the three well known clouds that offer gobs and gobs of different services.
There are others that do what they do, as well. But none are very well known.
There are cloud providers, yes REAL cloud providers, like Digital Ocean, Linode, and Vultr that offer, just like AWS does, non-cloud interfaces to make using their systems more approachable by people who don't need cloud at all. But they are real clouds, both under the hood, and accessible to customers as clouds.
-
@jaredbusch said in Where to start...:
Any other use of the word is marketing. There is also nothing wrong with that
When marketing becomes a cover word for lying, there is actually something very wrong with it.
-
@mmicha said in Where to start...:
I'm actually trying to decipher it, and basically everyone uses that term for everything.
Everyone uses it, but they all use it for the same reason: to make themselves sound "cool" while attempting to cover for the fact that they don't know anything about IT or business, including knowing how important making good decisions is.
-
@scottalanmiller said in Where to start...:
@jaredbusch said in Where to start...:
No one else can compete against them. There are basically only 3 cloud providers; Amazon, Microsoft, and Google.
No one else is cloud.This is not correct, at all. Those are the three well known clouds that offer gobs and gobs of different services.
There are others that do what they do, as well. But none are very well known.
There are cloud providers, yes REAL cloud providers, like Digital Ocean, Linode, and Vultr that offer, just like AWS does, non-cloud interfaces to make using their systems more approachable by people who don't need cloud at all. But they are real clouds, both under the hood, and accessible to customers as clouds.
Let's not forget large cloud providers such as Alibaba, IBM, Oracle et al.
-
@mmicha said in Where to start...:
My thought is that first step should be get the email to Exchange Online.
Instead, I'd start with "evaluating your email needs." If your Exchange is so unimportant that they wanted to run it in house, without being updated all of this time, it sends a strong message that no one really likes it. If it was, why is it being treated so badly?
Step back and start with "what is the right email solution for our needs?" Don't only assume that you are going to take one legacy system and find a newer version of it hosted. Start even farther back and ask why are you on such an expensive system in the first place? Look at the problem holistically, don't start with a giant assumption that basically determines everything else. It's the cart driving the horse.
That isn't to say that you want end up back at Hosted Exchange at the end of the day. But don't start with the answer, start with the question and determine if the answer you got was correct.
-
@mmicha said in Where to start...:
Then move our systems to a cloud somewhere.
Tear down all your workloads and evaluate one by one. Why do you have them? How best to run them.
Then when you know that, you can look at if there is value in consolidating them all to one place, or if using different strategies for different workloads makes sense.
-
@mmicha said in Where to start...:
Build out a site to site to a their datacenter and slowly build / upgrade things.
A lift and shift can be a good idea. But it isn't very likely. Taking applications that aren't well maintained on premises and just shifting them off premises is just "moving" a problem, it isn't addressing it in any way.
That doesn't mean that you might not benefit from keeping these applications in this way. It's not to say that colocation is bad. But you can't start with the assumption that the "less common" solution will automatically be the right one with no evaluation at all.
