Yesterday OpenAI shipped what a lot of us have been waiting for since late November: a real ChatGPT API. Not a scraped session cookie. Not another playground experiment. A chat/completions endpoint, a model called gpt-3.5-turbo, and a price that makes side projects feel cheap again — $0.002 per 1k tokens, which they say is about 10x cheaper than the older GPT-3.5 completions path.

I spent December treating the browser tab like a slightly unhinged junior. I wrote about that three weeks in. Yesterday moves the same model family from “interesting tab” to “thing you can put behind a service boundary.” That is a different conversation at work.

Agile software architecture is a way of designing and developing software systems that embraces change, feedback, and collaboration. It is based on the idea that architecture is not a fixed and upfront activity, but rather an ongoing and emergent process that evolves with the needs of the customers and the environment. Agile architecture aims to balance several aspects of software development, such as functionality, quality, performance, scalability, security, usability, and maintainability. It also considers other factors that affect the delivery of software solutions, such as testability, deployability, operability, and observability. Agile architecture follows some key principles and practices that guide its implementation. Some of these are:

Software architecture is the high-level design of a software system that defines its components, interactions, and properties. Software architecture evolves over time to cope with changing requirements, technologies, and challenges. In this essay, I will briefly describe some of the main phases of software architecture evolution.

OpenAI dropped ChatGPT on 30 November as a free research preview, and by early December Sam Altman was saying it had crossed a million users. I signed up the first weekend, poked it with toy questions, then — because I am me — started feeding it the kind of work that actually lands on a .NET desk: failing unit tests, half-remembered LINQ, a nasty regex, a draft of an RFC nobody wanted to write.

Three weeks later I am impressed, slightly unsettled, and not ready to trust it with anything that ships without a human staring at the output.

Kubernetes and Nomad are both container orchestration tools that enable the management of containers across multiple hosts.

Kubernetes has a large, rapidly growing ecosystem of services, support and tools that are widely available. Kubernetes is an open source platform for managing containerized workloads and services, that facilitates both declarative configuration and automation. It has a layered architecture with various components that provide features such as cluster management, scheduling, service discovery, monitoring, secrets management and more1. Kubernetes also relies on a dynamic ecosystem of various loosely-coupled components, such as container runtimes, storage providers, network plugins, ingress controllers, service meshes, etc., that extend its functionality and interoperability.

In today’s world, businesses are increasingly reliant on software to deliver their products and services. As software becomes more complex, it becomes more difficult to keep track of its performance and behavior. his can lead to problems such as outages, performance degradation, and security vulnerabilities. This is where observability comes in. Observability is the ability to understand what is happening inside a system from the knowledge of the external data it produces.