Thread regarding SAS Institute layoffs

@6kue+1v7RIXtX

Net comment votes sill getting ratio’d by the sheer volume and truth-weight of the comments on this thread. Let them defend Viya with logical arguments in comments if they want to be taken seriously.

“time would be better spent by building something customers want and is easy and economical to deploy.

…that won’t happen. Instead - it will be quintuple down on what exists.”

That’s logical, if the goal is to sell the company.

Publicize that “the user base for Viya is growing (substantially)” -- without mentioning that it's growing from a low base. Announce that you have AI projects in the works. If these efforts don't attract a buyer, you can always IPO.

time would be better spent by building something customers want and is easy and economical to deploy.

Yeah but that won’t happen. Instead - it will be quintuple down on what exists.

This thread has experienced a recent surge in down votes from Viya advocates.

Customers who have said "no" to Viya have long ago moved past the point of reconsideration. Down voting won't change that. Instead, time would be better spent by building something customers want and is easy and economical to deploy.

@5eno+1v7RIXtX

Good insights and precisely why SAS needed an executive management and product vision that actually moved more quickly and impactful with cloud and open source trends. Individual contributors who have kept up skills understand this at a visceral level because the “sludge“ of the status quo management entrenched in last generation technology and business thinking is a big reason why IC efforts and hard-core work ethic could not generate significant forward progress at SAS.

There are engineers and product professionals who have moved to forward thinking tech companies now make twice the money for less effort than they put in at SAS. All because of a larger ecosystem better and more timely aligned with modern business and computing realities.

We're still missing a lot of context. It's not about how smart or skilled the individual workers are. Necessary but not sufficient. The context is key. If you run the world's largest retailer, search engine, or social media site, you have to conquer those challenges at the bleeding edge every day, 24/7. What works at the largest scale in the world (never done before) can then trickle down. The same kind of solution simply cannot come from a legacy on-premise vendor that uses "professional services" at high expense just to get things installed. The economy of scale isn't there at the technology level. The business economics also completely changes b/c those companies monetize through other means, not via licensing packages someone else goes and runs. Open sourcing projects makes sense for them b/c lowering the costs and reliability and accelerating innovation of those inputs helps them with different outputs. Vendors who do not want those things commoditized because it was their payday suffer. You cannot put the cat back into the bag. SAS is just one of many old school vendors who never seemed to comprehend these basic changes and could not pivot to play by "the new rules" of the game. It doesn't matter how many "A" or "hardcore" individuals you have if they all still play the wrong game.

@4cdh+1v7RIXtX … continued.

It’s fair to say that CAS was designed to be “cloud-friendly” (yet not “cloud-first”) to the extent the principals understood cloud environments. However, almost no one involved, at least for the first 2 or 3 years, had any serious experience deploying complex software into public clouds using their various services, APIs, etc.

In years that followed, emphasis on and knowledge of public cloud infrastructure has grown tremendously at SAS. The problem seems to be the memory footprint, resource management techniques, I/0 requirements, etc. native to CAS and other foundational Viya components are not cost effectively for public cloud computing — at least not for the perceived customer value delivered. Some of this must go back to the original design.

@4cdh+1v7RIXtX

very eye opening (and sad) to read. thanks for the explanation.

Viya’s CAS engine was not initially designed with a cloud-first architecture. in fact, before the branding term “Viya” was even conceived, ongoing CAS development activity retreated back to emphasize customer on-premise deployments. This came down straight from the top.

AFAICT, for the first several years of its existence, nobody attempted to estimate how much it would cost to run CAS+Micro services with VA, etc. in public cloud scenarios based on common workload patterns. In fact, beginning first in engineering/test then eventually to a handful of Custom customers, CAS was never even run the cloud, but was instead tested and measured on single Linux machines or VMs having typically quite a few cores and on high core, multi-machine grids. The same was true with the micro services required to run VA/VDMML and other interactive based Viya products.

On a large scale, SAS did not start developing bonafide detailed cloud expertise until about 6 years ago. There were a few individuals who had more or less expertise, but on the whole nothing rivaling the OS/host platform brain trust that existed when MVA (and then eventually TK) was designed and programmed. Therein lies a big reason why Viya continues to fall short. SAS had not invested in developing the ongoing internal technical expertise to correctly target the cloud revolution.

One of the problems of Viya is the huge bill to foot to Amazon or Microsoft for their cloud. One of the SAS partners tried Viya for a simple demo in one of their local offices and had to pay 50k to Microsoft at the end of the month. That was the end of the trial.

My opinion is that Viya should not require K8s certifications, DB admins, and entire teams of people for a company to run and manage the software.

If rewriting Viya in Rust results in the same user experience then it is a not a good investment. That would be like putting lipstick on a pig.

One of SAS's troubling behaviors has been repeated rewrites (but only implementing 80% of the functionality with each rewrite)

SAS has been dealing with memory safety issues for its entire existence as a company going back to the 1970s. When I left a few years back, there was automated tooling being used for static and dynamic analysis, some of it mandated before code could even be pushed. Of course, these tools never catch everything because there are too many runtime scenarios to test all the edge cases and even others more common.

Rust is an excellent choice for forward thinking systems programming, and other high-performance, fault-tolerant, etc. NEW software development scenarios. Seems like one would be hard-pressed to justify the engineering economics of converting a few million lines of extremely complex Viya C code, even with automated tools. Doing so it’s just kicking the can down the road which apparently is what the last several years have been about, and a significant reason why SAS finds itself in ongoing decline.

A simple feature-by-feature, component-by-component conversion from C/C++ to Rust is incongruent with reality at this juncture in time — late 2024. It’s been a decade since CAS was designed and several architectural limitations have been identified in customer scenarios and comparisons with platforms like Spark and Snowflake.

Any effort as significant as converting the CAS/Viya core to Rust should also focus on a simplified platform, architecture from which SAS can build components and tools the market actually wants. at this point, this is probably futile because the big cloud vendors, data bricks, snowflake, and many others, including open source already provide these capabilities.

Passionate, innovative, programmers love hot new technologies and Rust satisfies this while delivering an exploding ecosystem, memory safety, and other modern capabilities. It’s downright fun to learn and used too. Just don’t see SAS moving forward with it on massive scale unless JG wants to invest a serious amount of his fortune into completely remodeling the company! if so, there are probably better ways to go about it through acquisitions Instead of the “must be invented here” that has markedly contributed to SAS’ decline.

Viya already amassed enough "Rust", by not selling enough :)

Viya does not need to be rewritten in rust…

@ilc+1v7RIXtX Sales numbers. Migrated customers. Read the numbers posted in internal reports.

Or do “LinkedIn searches” to determine details of how a product in private company is doing. LOL.

We had 1 user, now we have 2, thats 100% growth!

“the user base for Viya is growing (substantially)”

Where is the evidence to support that assertion???

“the user base for Viya is growing (substantially)”

A LinkedIn job search for “SAS” “Viya” returns exactly ten open positions in the entire United States.

Rust can fix some problems, but not a fundamental lack of demand.