RE: [OffTopic] Curiosity about vision of the future for dba oracle ...

Hmm. I think you actually agree with what I wrote. (except perhaps my autocorrect typo of through in place of throw).

Until a problem that hardware cannot solve is reached things look good. That is sooner or later depending on the customer (and there is a tendency of all-cloud customers to use relatively simple vendor applications, and it is the vendor responsibility to correct problems that more hardware cannot solve.) When things are more complex and the price/performance experience becomes bad compared to the perception and/or reality that either a private cloud or private on-premise solutions would be better, we get a return to using reasonable level talent.

But some, perhaps a lot, of the total goes for a time sharing solution (er, cloud experience) because they have not reached that threshold where either the perception or reality they need their own professionals. The big leaders who were first to try out time sharing (and who probably had the savvy to choose areas of the business that played well on the cloud) initially had a good experience which diminished as applications that were more marginally suited to timesharing were deployed to the cloud.

This still puts pressure on the DBA (and especially the operations focused DBA) job pool. A big piece of operational DBA job functions that are relatively easy to completely automate will be automated. That is a good thing, but it will eliminate some of the uncreative jobs that involved training rather than thinking axiomatically. I suspect you already avoid (and/or have priced yourself out of) the marketplace for those jobs. And you probably automate a lot of boring things yourself if the customer has not purchased the appropriate tools.

That puts you in the part of the job pool that will probably never dry up completely: Building applications that function reasonably and configuring systems and databases to run reasonable applications reasonably. Not actually overseeing them running except as perhaps a burn in phase to verify sufficiently meeting service levels or brief periods to correct something (such as something that needs to be parallel to meet service levels that is not running at the correct level of parallelism).

Notably I wrote that it is too complex to predict the direction of the overall DBA job pool except for the bits that are tedious and reasonably automatable. Whether on-site or cloud time sharing or private dedicated cloud, in the long run no one will want to pay human rates for things that can be automated. (They may continue to pay for overseers watching out that the automation has not failed, but the fan-in of number of databases per DBA of this sort will continuously rise and the real money will go to the folks who make the per database cost of verifying that the automation is working properly goes down.)

There is still some demand for COBOL programmers, and the price is getting steeper as they die off. Strictly operational DBAs (notably different from dev-ops DBAs) are in real danger of being completely supplanted and I suspect that job function will disappear before the need for COBOL programmers disappears.

Denizens of oracle-l are more likely in the part of the pool you are. Whether you work for one or a few individual clients or an expertise aggregator in the future, your value will remain as long as there is a need for new functionality. (Hint: The sun will burn out before folks stop wanting new features.)

mwf

-----Original Message-----
From: Stefan Koehler [mailto:contact_at_soocs.de] Sent: Sunday, November 12, 2017 3:32 AM
To: mwf_at_rsiz.com; oracle-l_at_freelists.org; gogala.mladen_at_gmail.com Subject: RE: [OffTopic] Curiosity about vision of the future for dba oracle ...

Hey guys,
i am sorry but i disagree.

_at_ Mladen: Sure - adding more CPU or memory will give more resources to execute other stuff but it won't necessarily make your slow SQL statement processing (due to inefficient exec plans / data access) faster. Why should anybody pay for more and more resources (as data has the tendency to grow) just because of inefficient execution plans or SQL processing. Care about your SQL and application implementation / code and it will save you a lot of money (especially in cloud) and time. Cloud does not change anything here. So IMHO your statement "Cloud makes it easy to just add more memory and CPU and not bother with trifle things like optimizing your SQL for performance." is not true :)

_at_ Mark: Sure - hardware providers and cloud vendors want to sell you hardware and/or computing time but this does not mean that this make sense (from a technical and business/economical point of view). If you go down this "simple hardware road" you will face some things like this very soon: "We’re starting to see a reverse cloud trend, Strohmeyer says. CIOs who were once excited to save on the capital expense of building or leasing more of their own data centers are now starting to see the long-term impact of the operating expense costs for things like Box, Amazon Web Services, or Microsoft. That stuff starts to get really expensive so they’re now looking at which workloads they can host cheaper themselves and which are best suited to the cloud, Strohmeyer says." - http://fortune.com/2017/09/13/amazon-microsoft-google-sap-cloud/

Best Regards
Stefan Koehler

Independent Oracle performance consultant and researcher Website: http://www.soocs.de
Twitter: _at_OracleSK

> "Mark W. Farnham" hat am 11. November 2017 um 16:49 geschrieben:
>
> I believe you are both correct to a certain extent from distinct viewpoints.
>
> Cloud vendors might well through hardware at a problem to charge higher total fees until some critical process is of the variety that cannot be "hardwared out of" sufficiently to be accepted. Then the last remaining bastion of full service experience DBAs comes into play and the most resource consumptive and elongated response time bits of the software and hardware stack are corrected.
>
> So will demand for doing things well drop over time?
>
> I don't know and I believe it is difficult to project solution spaces for the simultaneous equation including variables of at least:
> 1) Overall hardware capabilities including, but not limited to, reducing memory into cpu lag time and effectiveness of parallelism from the system to the application interface
> 2) Total demand for computer horsepower
> 3) Total demand for reduced elapsed time of very complex problems where a mistake in choosing the solution path can vary by orders of magnitude.
> 4) Relative improvements over time in the underlying software to avoid costly mistake in choosing the solution path
> 5) Network latency and bandwidth versus the demand to collate data from a variety of sources on the fly into a useful aggregation.
>
> I probably have left out more than I have included.
>
> I believe the solution is to plan to be very good at what you do from an axiomatic approach so that you understand the fundamentals and can shift the application of your skills as needed or compete for the possibly dwindling open seats for "database operator" folks who we count amongst DBAs.
>
> That prediction I think CAN be made: User interfaces to operational tools will improve in the sense of becoming less and the things that are tedious and only require somewhat complex automation will be cheaper to do with machines, so those job seats are in peril.
>
> -----Original Message-----
> From: oracle-l-bounce_at_freelists.org [mailto:oracle-l-bounce_at_freelists.org] On Behalf Of Mladen Gogala
> Sent: Saturday, November 11, 2017 10:11 AM
> To: Stefan Koehler; oracle-l_at_freelists.org
> Subject: Re: [OffTopic] Curiosity about vision of the future for dba oracle ...
>
> Hi Stefan,
>
> Replies in-line.
>
> It will give you more resources to execute other stuff, therefore making the crisis less critical.

--
http://www.freelists.org/webpage/oracle-l