Architecture
The context people and tools need to work with your Cloud
Operating applications involving more than a few components without explicitly modeled contextual clues is difficult for humans and might be impossible for tools. This is especially true when people are a couple steps removed such as is often the case when analyzing costs and/or assessing risk. Both people and tools rely on: identifying resources at
What is different about Kubernetes
Kubernetes is a container orchestrator built by a large community of technology vendors and users that was inspired by Google’s Borg orchestrator. Kubernetes is operated by everyone from major Cloud providers to you. From the What is Kubernetes page: Kubernetes is a portable, extensible, open-source platform for managing containerized workloads and services, that facilitates both
What is different about Elastic Container Service (ECS)
ECS is a first class container orchestration platform for teams committed to AWS. If you’re in one of the ‘best for’ categories, give it a serious look.
Container orchestrators are the same but different, Docker Swarm
This is the first of several posts that will provide a high-level introduction to the top container orchestrators in late-2019, differences between them, and which might be best for you.
Concept: Container Orchestrator
A container orchestrator schedules, runs, and supervises containerized application processes, usually across a cluster of hosts. This post describes the responsibilities of a container orchestrator and what the orchestrator integrates with.
Prototyping helps clear the err
Reading time: 2.5 minutes We create and review designs primarily in our minds. While our expertise is worth a lot, we’re not perfect and neither are our diagrams. We’re still subject to: known-knowns we think are true, but aren’t known-unknowns we uncovered in the design process unknown-unknowns we didn’t forsee One of the ways we
How to review a design
Today, I will share how I like to review a design produced by my design process: I call this a ‘semi-formal’ design review, because it leverages key aspects of a ‘formal design review’ such as: the design is built from a structured template tailored to our problem space and is written to be read and
The design process
This post describes QualiMente’s design process. This design process incorporates feedback from authors, a design review, and (optionally) prototypes. Once design feedback is collected, the delivery team and product manager have much more knowledge about whether to continue, how to approach the solution, and how to break up and sequence the work. Additionally, you can communicate to collaborating teams with the confidence that you’e probably identified half or more of the design’s defects.
The genesis of a design
Designing a solution is one of engineering’s primary creative activities. We use our knowledge of principles, techniques, and primitives from science, engineering, and industry to create a solution to a problem. This post describes my initial steps for designing.
Form follows function
Teams must select the right steel — the patterns, compute platforms, algorithms, languages, and frameworks that form the core of our systems in order for them to function well, or at all.
Can you handle 10x or 100x more application components?
Reading Time: 2 minutes Many organizations are making fundamental changes to the way their applications are structured and operated. These changes are intended to address real problems. Structurally, monolithic applications can severely hamper change delivery rate as the regression test process comes to dominate change delivery time or changes from many teams being held up
Why I Design
(Reading Time: 2.5 minutes) I design to avoid waste. Waste in building something: nobody wants can use effectively can afford That is, design is a process that helps maximize the value of systems we create. The design process is also critical to understanding whether we should build them at all. Some systems will have low
ADRs are not the only doc in an Architecture process
A successful architecture decision-making and recording process depends on creating and socializing a design doc on the matter.
Scaling Architectural Processes with Guilds
Reading Time: 2 minutes Comcast published a detailed description of how they use Architecture ‘Guilds’ to scale investigation, review, and decision making: https://www.infoq.com/articles/architecture-guild-800-friends Scaling decision making is a hard problem because you want to: gather input from interested and knowledgeable creators and users focus on the most important parts of the problem and solution, avoiding
Why did we do that?
We make every decision with imperfect information. ADRs give you a way to quickly record what you knew at the time and why you did what you did.
Cloud lock in and the cost of portability
All systems have dependencies and you’re always “locked-in” to something. Evaluate dependencies in the full context of the delivery problem and business goals. Base your strategy on this wide context and resume the task of delivering value to customers.
Identifying Undifferentiated, Heavy Lifting
In The Promise of Clouds and Optionality, I said: Cloud providers are competing to offer high quality services that meet their customers’ needs at decreasing cost and increasing scale. They want you to offload whatever you consider undifferentiated heavy lifting to them. But what the heck is ‘undifferentiated, heavy lifting’ and where do I find
The Promise of Clouds and Optionality
The real magic Cloud providers give you is optionality to build the right thing.