Yes, the Startech device is an industrial embedded server.
I am checking to make sure of the model of the ones that are in use now. But basically the devices that I am thinking of, all they do is take whatever comes in over the serial port and send it to the server ip and port you set it for.
If your program is a special program that requires using a COM port, it can be set up for that too. (for instance, if your scale has to communicate over COM3 in Windows).
I understand what you are saying. It's a fact though that every device that does this is a linux/bsd computer of some kind. It doesn't take much processing power but you need a complete tcp/ip stack inside. There are a bunch of manufacturers for these devices.
Also if we talk about scales that you would normally use in some kind of production or quality control, nowadays they commonly have an ethernet port either as standard or as an option. Still any real-time processing will be on-prem. Results might be sent to the cloud though for presentation and final storage.
That's what I'm seeing... can't imagine when we'd want a server "somewhere" storing a bunch of random scale data.
All it takes is one absentminded click or drive-by that's completely shielded from us as we go about the day to day stuff and it's done. Game over. Say, "Bubbye".
There's always going to be that risk or one absentminded click.
Granted an Air-gapped PWA is a good way to handle it.... but so is not saving passwords in RDP files (I don't do this), and if you use an app like MobaXterm that can encrypt the files for you, use a good pass phrase.
However if your admin machine is owned, you have bigger issues to start with.
Well, the idea is that the air-gapped machine won't ever be in a situation to become compromised, is my guess. I haven't had a chance to look at the MS link Philip sent earlier.
There are several ways to implement with the simplest being the main machine having two VMs installed on it. One for day-to-day and one for client/systems management. Nothing is done on the machine itself with all designated tasks being done in their respective VM.
We have a number of laptops that came back from client refreshes. So, we're using them as our dedicated management machines. Asus makes a great external USB3 DisplayLink and DisplayPort external monitor that allows for two screens. That makes the work easier.
There is security leakage between VMs on a client machine for instance over clipboard.
MSP Maturity Model. Strictly speaking, the MSPMM does not tell MSPs to make all of their customers identical. But in practice, it encourages it and many MSPs talk about the MSPMM in these terms - finding ways to make customers all run the same tools, software, practices, network design, etc. This makes management so much easier for the MSP, but has two major problems.
First, it forces the customer to conform to the vendor, which makes very little sense. IT needs to adapt to the business, not the business to IT. But that's another topic.
Secondary, it means that an attack vector that works on the MSP will likely work on every single one of their customers making the prospect of breaching the MSP that much better. Sure, if a targeted attack by experienced state-sponsored hackers goes after an MSP, the MSP has little chance of winning that battle. But that isn't the real risk. In the real world, the risk is automated attacks looking for common vulnerabilities and spreading organically through shared tooling - things that are only possible or reasonably likely when the environments are homogeneous: both amongst the MSP clients, and between clients and the MSP themselves.
The traditional approach of MSPs, especially VAR - MSP combo companies, is to have not only the same tools and software, but even the same hardware and products so that any hole anywhere because a hole everywhere and breaching any one piece of the infrastructure means you are likely to breach it all.
This may seem simplistic, but if I were in this scenario, on which side of the MSP / VAR would I stand?
A person hires me to help spec out a server for their office. I'm paid to help them determine how much RAM, storage, processors, etc. they need.
This part is clear, I'm being paid for advice; thus, MSP.
A point of clarity - advising only this is not being an MSP - you'r not managing anything (managed service provider). ITSP or Consultancy would be better terms for this portion... heck - the whole thing, including recommending a hardware vendor, because again, you're not managing anything.
Maybe not directly for the company, but the MSP has to recoup the costs of time and travel somehow, and that will affect rates if you're going to stay profitable.
That is very true, no denying that. But you can build those costs in. There are certainly costs involved, but there are savings too. You have to look at the whole picture.
In this example, we have housing costs about 20% lower than they do, our fuel is way cheaper ($.25 I bet), and our Internet is a fraction of the cost (about 10% the cost, I kid you not.) Going local to them would require us to raise prices, traveling to them is trivial.
For an MSP to be truly agnostic it would either have to massive (to be able to employ both Oracle and SQL Server experts), or it is full of generalists who can support both but lack expertise in either.
That's part of the goal, or typical goals, of moving to the MSP model. They bring more scale and with scale comes agnosticism (the move towards it, but obtaining it as you pointed out.) You might not have expertise or experience with every OS out there, but even a moderately small MSP like NTG regularly supports and works with many databases. Not Oracle, which isn't a big deal as it has essentially no place in any intentional deployment, but MS SQL Server, MySQL, MariaDB, PostgreSQL, REDIS, MongoDB, SQLite, etc. all regularly supported.
MSPs are way more likely to have the desire and ability to grow support skill sets, although this can happen internally as well. But internal skill growth is costly and risky to maintain. For an MSP, skill growth increases potential customer support options. So MSPs have more incentive to consider things they've not done specifically before than internal IT departments do.
Nothing is perfect, but MSPs make agnosticism easier and more likely.
That's a lot of investment for a system like that. If you have hundreds of customers, it can make sense. But it takes a lot of customers to recoup the lost time into that system. It can work out well for a traditional MSP, but depends on large scale standardization to justify the investment.
I don't know about hundreds of customers. The number of end points might be more relevant. For me at about 10 MSP customers I can justify the investment. When you look at the time it takes to set up something like a zabbix server and maintaining a WSUS server vs not having to that helps make it worth it. Missed revenue because you didn't have a system in place to capture every minute hurts.
It would be a blend, I'm sure. A single customer with a million end points wouldn't make sense because you'd use more traditional tools in a single customer scenario. And a hundred with only one end point each wouldn't do it either. So some combination of enough end points for volume and enough customers for complexity put together.
Same problem for the vendors. If you are dealing with unpatched spares, so are they. Having worked for some of the big ones, I know that their supply chains struggle to get parts, too. Heck, IBM couldn't deliver a server internally in more than six months, imagine how hard it is to get support parts!
Shit like this just blows my mind.
Parts Bins, internal supplies for labs, and customer supply chains are all completely different (well IBM may have been a gong show). Dell and HPE staff can't just go grab something off the line, with Mfg you have to account for the costs and someone gets to pay (and often at a premium to prevent abuse) for those internal servers.
Parts Bins and stocking those are different, and supply chain for a OEM might actually be different in the us than EMEA.
At IBM< we were an external customer, even though we were inside IBM. We showed up just like any external enterprise customer. So their inability to support was universal.
reason for this, to me, is partially induced by the amount of work/materials required in a company to get the job done.
When you start it is really close to what you do in your house, so you go to the mall and buy a router, a laptop and so... you do not think about planning, it is just another piece of HW you need, like the smartphone. You do not hire a consultant to buy a smartphone.
a SMB with no more then 10 people will need not so much, maybe just an intervention now or then, let say to change a burned router every 3/5 years, or a broken disk in a NAS. This stuff is so rare that the SMB do not hire competent people to manage it - they just buy stuff like in their own house-, therefore, the SMB has a relevant degree of ignorance on a topic.
the commercial guy in front of the SMB is (apparently) a huge source of information for the SMB, they do not need to go deeper on tech details: they can't even totally understand what the commercial is exposing.
Now you will say: hay, consultants are there for this very topic: let SMB not be fooled/deviated by bad commercial practices.
Yes, but this implies that the SMB has - at least - a bare minimum degree of knowledge about its own ignorance.
Unfortunately they have not. Everything starts with something small, let say a small 2-disk NAS. Hey it worked! now what, oh we need a small server. Hey the commercial guy has solved the problem last time, let's call him again, he will solve it!
Then you start buy stuff and stuff, in the end IT is not the core business it is just like other tools you need to make the job done. period. what matterst is if you have margins.
Here is where you start thinking about consultats. when margins are hard. and the bigger you are the harder to keep margins high. therefore you start minding about what you are doing. And consultants start here. But it is not the IT consultant. the IT consultant is at the end of the queue, first you start with company organization, with people and procedures, THEN you ask for consultancy on tools.