Solved Can You Restrict Important Info In Azure If Customer Owns Azure Subscription? (1 Viewer)

[The_Doc_Man]

Ok, first up, I’m a bit confused by all this talk of patches, updates etc.

Albert, the reason that patches came into play at all is admittedly a side door to the main conversation. However, it is an issue because there are two world views in operation here.

One view is that you can build your software in a way that it will continue to work indefinitely in the environment you have set up.

The other is that if you have ANY internet exposure, your environment is NOT a constant and you CANNOT expect indefinite safe execution. As you might have guessed, I am in the "not constant" side of the discussion.

In isolated systems that have tightly controlled access at all levels and have NO external exposure, that stability might be true. The security agencies have machines that have the ultimate internet security - no direct connection to the outside world. All you can do is INDIRECTLY load them when you log in locally. Such systems are highly secure. And yet... they still get patched regularly.

The discussion about patching came in because if you have external exposure, it is unwise to not consider the predatory nature of the internet. Dalski admits to being unfamiliar with some of the issues of computer security and, with his incomplete understanding, suggested some actions that would have dire consequences to system stability. From there, the diversion to patching occurred as, I believe, a natural offshoot of the topics related to security.

There are other paths that get to "unstable environments" as well - such as unexpected growth of capacity requirements. You have to consider aging of equipment that has to be replaced, and given the rate of hardware advancement, it would become harder and harder to maintain the original equipment. Which means that at some point, the environment just dropped out from under you. It has been my experience, and I wish to clarify that it is an opinion, that the only constant in life is CHANGE. But that's not original with me, I just agree with it. That saying comes to us from the Greek philosopher Heraclitus (535-475 BCE).

 

[Albert D. Kallal]

The other is that if you have ANY internet exposure, your environment is NOT a constant and you CANNOT expect indefinite safe execution. As you might have guessed, I am in the "not constant" side of the discussion.

As noted, i up-voted your response.
However, say I'm using Azure as my database, well it's being updated and patched all the time for you, and your software that uses Azure in most cases will require few updates.

And same goes for having written web based (public facing) web sites (it's what I do for a significant portion of my time these days).
So, we not talking just HTML markup, but my sites are rather complex applications that are customer facing and exposed to the public, and such sites has boatloads of business logic.

So, how often do I have to update my web based software, and patch it?
Actually, not much.

Of course the web hosting company will be patching and updating the OS and version of ISS (internet services) that they run, but my software surprisingly requires few updates.

However, fair is fair!
No question web software DOES require more updates then say typical desktop software.

The requirements for updates and patches will often depend on which framework being used,
and if you the developer is responsible for updating some of the tools used, or if the web hosting company is.

So, sure, updates to jQuery, bootstrap, jQuery.UI etc. does occur more often.

However, even now, even these libraries are now often referenced by what we call "CDN" (content delivery network), so, now, even the one of "many" libraries that a typical web developer will use?

They are also updated quite frequently, but with CDN, once again me the developer does not have to care or do such updates..

So, just like in desktop land, we used to have to patch and udpate the OS etc. manually?
Well, now it is automatic.
In fact, even ms-access in most corporate environments is now automatic updated and patched for you.

(long gone is having to install the office "SP" updates like we did in the past).

So, as web based technologies mature, then the updating and patching requirements are more transparent and automatic - just like they are for the desktop.

R
Albert

 

[The_Doc_Man]

So, how often do I have to update my web based software, and patch it?
Actually, not much.

If it is your product that you wrote and have sold or licensed said product, the answer may well be in your contract. Many years ago, long before the Navy job, I worked for a company that had a computer-based Supervisory Control And Data Acquisition (SCADA) orientation. Our contract included maintenance; specifically we were expected to update our software within X number of days after finding some flaw in it. If your product is sold to a government entity, it almost surely WILL include a periodic maintenance specification. If you have sold the product to someone who is not very experienced and doesn't have a software-aware lawyer, you might get away without the maintenance topic. Just don't hold your breath waiting for one of those no-maintenance contracts to come around.

Automated patching for some things IS getting much better, so the patches occur ALMOST transparently. Sometimes things can be as transparent as when Firefox tells me it is ready to update. Or my anti-virus pops up a message warning me of an impending update, then Windows says "Your anti-virus package isn't running." Finally, I get the notice that my A/V package has started again. However, depending on the local IT shop, and in particular, depending on their level of paranoia, you (or the IT wonks) might have to manually download the patch files, scan each one, check online for feedback, and finally publish the patches to a local shared disk that is the target for Windows to look for patches. I worked in such an environment for 28 1/2 years. But in that case, I didn't have to worry about validating the patches - our anal retentive IT group did that.

 

[Albert D. Kallal]

If it is your product that you wrote and have sold or licensed said product, the answer may well be in your contract.

Again, much agree, but above is a VERY different context here!

So, while I have to be aware of say some OS patch, or some update to jQuery or ISS internet server, or SQL server?
It's still not me the developer in most cases having to update the OS or IIS or the database.

I mean, we been deploying a access 2010 (compiled accde) to a number of client sites for some time now
(many with 50+ desktops). This is a HUGE and complex application - 250,000+ lines of code, 480+ forms, 350 reports and boatloads of .net code included and called from VBA for this application.

Over time, they have upgraded from access 2010 to 2013 to 2016, and so on.

We not had to update our software as a result of these updates, nor has our accDE broken as a result.
And this includes the now "many" automatic SP updates that occur automatic to office (including Access) these days.

And these sites all run SQL server as the back end - once again, not a issue nor problem on our side of things.
(and again, they updated SQL server multiple times - again, our software did not break nor change).

we were expected to update our software within X number of days after finding some flaw in it

Sure, ok, but that's not a OS update, or some patch to SQL server, is it?

We have to distinguish between software updates and bug fixes as opposed to patching SQL server, or even ms-access which these days is updated all the time.

My point was we as developers don't really much these days have to get involved in patching the OS, patching SQL server, patching ms-access etc. And that as I pointed out also applies to web based systems that I currently work on.

In other words, all these patching and updates?
They don't affect me as a developer all that much, do they?

So, such updates can on occasion break things, but for the most part, us developers tend to not be involved in all this patching of OS and things like SQL server, or even as I pointed out our web based software.

Fixing your own bugs and updating your own software is a vast different issue and process compared to updating OS, SQL server etc. All developers are responsible for their software updates and fixing of their bugs....

R
Albert

 

[The_Doc_Man]

In the final analysis, whether you are patching your own software or patching an O/S or 3rd-party utility program, its a thankless job but someone has to do it. If your customer has an IT shop, you are probably "off the hook" for any patching of general software. But if you have a reputation to uphold, you need to be sure that things will be managed to maximize customer satisfaction and meet consumer specifications..

In other words, all these patching and updates?
They don't affect me as a developer all that much, do they?

I wish I could honestly say "NO" to that question. But it just depends on your target environment, your customer's expectations, and how clearly you can explain what will be needed. The best answer I can give to that question is a qualified "maybe."

 

[Albert D. Kallal]

In the final analysis, whether you are patching your own software or patching an O/S or 3rd-party utility program, its a thankless job but someone has to do it. If your customer has an IT shop, you are probably "off the hook" for any patching of general software. But if you have a reputation to uphold, you need to be sure that things will be managed to maximize customer satisfaction and meet consumer specifications..


I wish I could honestly say "NO" to that question. But it just depends on your target environment, your customer's expectations, and how clearly you can explain what will be needed. The best answer I can give to that question is a qualified "maybe."

Actually, no, don't at all one tiny bit back off on the points you are making here!

While I'm kind of stomping a bit on you in regards to the poster? (since they using Access + Azure - not a lot of need to patch and update stuff, is there???).

However, I'm actually going to state that EVERYONE here should heed your advice, and in fact not overlook the points you are making here!

The simple issue is everyone wants to jump into software development.
Guess what?
Well, as doc man points out?
You THEN have to be responsible for that software and updating it!

In fact, this week, first meeting of the year?

Why of course we going to talk about upgrading our application from Access x32 to x64. We are starting to get a lot of pressure to do this. And the reason of course is most of our sites are companies with 50+ desktop's.

Those companies are thus on Microsoft Volume Licensing - and it is a subscription based model. I mean, when a company has 50+ computers, then quite frequently they are having to setup a brand new computer (as older computers become well, too old).
So, those companies on such Microsoft "assurance" (volume licensing) programs also thus tend to use automated tools to setup a new computer.

So, as a default, all of their computers (one site is over 200 desktops), is of course office x64.

So, IT departments are now complaining to us, since when they setup a computer - the install and setup of office is NOW office x64. (and with their group policy setups, office is quite much automatic installed on each of their computers when setting up a new computer. It's a real pain to thus setup office x32).

However, our software is of course Access/Office x32.

So, they now have to manually un-install office, and re-install office x32 - a royal pain
(so, it's been about 3-4 years now that the new default for Office is x32).

So, not only is the advice here sound, but I have to admit that despite all my "bally hoo" about not having to patch and update software much these days?

Well, guess what - it's still part of wearing the developer hat, and one does not, and should not ignore Doc man's advice here.

It seems all oh so easy to bang out and write some software. However, one THEN has to support and update that software. I don't think anyone should ignore this part of developing and especially trying to deploy software on a commercial level.

About the only advice I can repeat here?
I spent a LOT of time talking about adopting a installer - I think that is a "must" have part of a developers tool bag when attempting to support and deploy software to many desktops.

Thankfully, our installer already has provisions for detecting x64 bit office - but we still are faced with converting our application to run as x64 bits.

So, while today, often a developer has much less issues (due to installers, and automated updates)?
You STILL as a developer have to heed the advice from doc man.

Thus, no matter how one slices and dices this issue of having to update and maintain software?

Yes, you indeed have to do this, and you can't and should not ignore this part of software development.

And these updates it can consume quite a bit of one's resources as the number of desktops grows using your software (so, you better automate as much as possible the issue of issuing updates to your software)..

This advice is by no means limited to Access development (as doc man points out).

R
Albert

 

[The_Doc_Man]

Thank you, Albert, for seeing that I'm not trying to be hard-nosed about this... I'm just trying to be a realist in a harsh world and reminding folks of that reality.

I still have to be careful about being that voice crying out in the wilderness, though. The last historical person of note to do that was decapitated.

 

[Albert D. Kallal]

Thank you, Albert, for seeing that I'm not trying to be hard-nosed about this... I'm just trying to be a realist in a harsh world and reminding folks of that reality.

I still have to be careful about being that voice crying out in the wilderness, though. The last historical person of note to do that was decapitated.

Well, at one time Microsoft had 80 developers JUST working on the Excel installer.

And another example?
I knew some people working for a software company that sold metal quality tracking software.
(tracks grade of metal a it goes though many manufacturing steps - a must have for quality control).

They had 80 employees. (sales, support, documentation, making manuals, training etc.).
And how many developers did they have for that software company?

4 - yup, just 4 developers.....

So, it can be rather amazing what % of people and resources of a software company is not actually developers.

However, like anything, you can't have everything "oh so just right" when you start out.

So, while I high recommend having tools to download + update software (automatic), and have a nice installer like I have now?

When I first started deploying software, I used a paid copy of win-zip. It could/would produce a single self contained .exe file out of a folder.

So, one .exe file, and customer would run that .exe, and it would prompt you for a folder to extract the files to. So, that's all we had.

It was simple, but at least it was a simple single file, and back then, zipping ability was not part of windows. This single .exe thus also included a stripped down version of winzip as part of the .exe file. So, simple, effective, and target computer did not require winzip.
But, of course not near close and nice as using a installer (which can detect what version of office you have, and thus take appropriate actions).

And for Access? For a number of years, the Access developer edition and runtime edition was a "extra" and somewhat costly option for access. .And it would create a runtime + your application installer. It was quite nice.

However, I think it was Access 2007, they dropped this installer wizard and the runtime became a free download (less the wizard and installer parts).
This was nice, but thus quite much means that you have to roll your own installer and setup routines.

I for sure remember going to say 6 computers, and installing the Access 97 SP (service pack) updates to the JET engine, and also the SP updates for Access. Of course, now I include the SP updates in my installer. And now days? Well, in corporate land, they near all are on some "assurance" type plan from Microsoft, and thus no patching or SP updates are an issue or concern.

So, trying to sell and deploy software?
There is a lot of moving parts, and considerable resources and efforts are required, and those efforts are NOT software development....

R
Albert