Posts

AI Festivus

Image
  Or an AI Jargon Decoder Ring This post is a whirlwind tour of AI terminology and the key players. Given that this field moves at the speed of light, expect these facts to be stale by next Tuesday. Take any claims about "who’s winning" with a bucket of salt. Models, Tokens, and the Meaning of Life Consumer AI apps usually let you pick your "brain" by choosing a Model . These differ in Size —measured in Billions of Parameters (e.g., Llama 3B vs. 405B)—and Sophistication (e.g., GPT-4o vs. GPT-5 or Gemini 2.0). Generally, the smarter the model, the more it costs to run. While consumers pay a flat monthly "All You Can Eat" fee, the pros (Enterprise/API users) are billed per Token . A token is roughly a word’s worth of data. You’re metered on Input (what you ask), Output (what it says), and Thinking Tokens . These are the model's internal "reasoning" steps—essentially the AI talking to itself before giving you the final answer (which is, obvio...

Is AI Really taking over software?

Image
  Or, The lessons of History. The Hype Curve (or by t he stuggey analyst name - technology adoption curve ) of adoption has become a cliche in technology circles, and like many other cliches, its anchored in experience and history. By Olga Tarkovskiy - Own work, CC BY-SA 3.0 , https://commons.wikimedia.org/w/index.php?curid=27546041 It inevitably raises questions about any new technology - is it pure hype? Where is it on the curve? Despite the fact that the curve itself is driven by history, discussions often rage for long times about how to answer these questions about any new technology wave. Obviously, the same is happening around AI. How can you tell that AI Adoption is maturing? What is a good parallel or pattern matching hint? That last big trend to flow across software development was Containerization . First there was Docker which was the new cool kid (parallel OpenAI ). Then there were competitors (ala R ancher ) and eventually standardization in the form of Open Con...

Pricey Architecture

Or, How architecting in the cloud is different  When designing cloud scale always on system, system architects are expected to be experienced in core system requirements - scale, security and high availability. By this day and age, this art is pretty well understood. The public cloud is a great help in driving solutions to those core concerns by providing the hard-to-acquire and hard-to-build foundational elements: Apparently infinite amount of compute and storage capacity for scale Fine grained control at the network and API level for security Fault zone isolation in the form of independent zones and regions for HA However, the tax the cloud imposes on these building blocks, even if not apparent at first, is its own complexity. If you don't consider the pricing models for the underlying building blocks and misapply them the tax is converted to $'s. Here are a few examples from recent design mishaps I've witnessed. An expensive scaling story: What with a...

Dude I'm (not) Getting fired

Or how to make the conversation be about $200 mistakes rather than $20,000 mistakes. It appears that the common wisdom about cloud has finally caught up - the main benefit in leveraging the cloud is all about agility and other factors (e.g. cost) are secondary. The ability to go to market quickly, with new prototypes or actual solutions, is critical for competitiveness. The evidence supporting these statements is most visible in the movement of large enterprise organizations into the cloud, and the growing ecosystem of MSPs and supporting businesses. However, agility, while ignoring costs, is sometimes risky and.. pricy. Here are some horror stories I have heard (and committed), while enjoying the benefits of agility in the cloud: Volumes of Couch Potatoes: To support overnight backend processing in an economical fashion and leverage the dynamic nature of the cloud, we setup an Auto Scaling Group - we automatically provisioned instances & storage to process 100’s of GB’s o...

Why is this blog so UGLY

AND, hard to read to boot. The short answer: intentionally. The rumor: because I can't create a decent UX even if my life depended on it. (Dont believe it). So why so ugly and hard to read? Stats and Tracking, and selective user targeting. Lots of people will read the site with the catchy headline, picture rich and attractive looking pages. I do that while waiting in the checkout line, and looking for something to pass the time with.  The marketing industry got a name for it - ClickBait . I however am not looking for clicks. I'm looking to find which ideas resonate with people. I'm looking to see which entries get passed hand to hand and have an escalated readership. So, I keep it ugly intentionally. If you tend to judge books by their cover, please move on. Ugly cover here. Please move off this page in < 5 seconds as to not skew my stats. If on the other hand, you find the ideas intriguing, by all means, drop me a note, sing me a song or just enjoy and c...

SaaSy Cloudy SSD's

Or, Should you abandon old wisdom In the world of Public Cloud little is stable, especially Common Wisdom. Following accepted Common Wisdom blindly leads to lost opportunities to capitalize on these enhanced offerings. Case in point - databases on EC2. Databases are demanding beasts, which  presents a few challenges: Databases tend to be mission critical. Recovery Time Objectives (RTO) and Recovery Point Objectives(RPO) are very stringent These demands are somewhat in conflict with the fickle nature of public cloud - your servers might disappear or fail with little notice. In the datacenter this implied highly redundant hardware and expensive and scale up architectures.You have more data, you get a forklift to deliver a bunch more disks for your SAN (or whatever your storage solution is) , and a few more blades/chassis to increase the number of cores in your Oracle RAC cluster. The first generation mapping of the old datacenter architecture into the public cloud had ...