Pretty easy to dunk on this kind of thing as architectural wankery, but it can be useful for companies that need to build opinionated platforms on which business applications run.
I recently left a role at a company with ~4,000 AWS accounts and they will likely have ~20,000 within a couple of years. It's extremely helpful to see a nicely abstracted architecture that you can cherry pick from when building your platform.
They're probably using AWS accounts for all or some of the following:
1. Compartmentalization (security incidents and manual mistakes are isolated per account). On the extreme side even some sensitive [micro]services may run in separate AWS a/c.
2. One AWS a/c per environment (i.e. dev, staging, prod).
3. One AWS a/c per large enterprise tenant (in case of the multi-tenancy).
4. Every team/division inside the organization have their own sets of AWS accounts usually with separate billing.
While "Change gives the illusion of progress"[1] and there's a lot of overcomplicated "enterprise architecture" BS floating around, peddled by consultants looking to make big bucks off locking an organization into their schemes - isn't some organizational strategy needed for organizing large distributed computational systems? (I don't want to use the word "clouds")
If so, then it's worth taking a look at the proposal and assessing it based on its own merits. I, personally, would rather swallow my pride and admit that a particular architecture, while coached in buzzwords, is actually a good idea and will prevent me from pulling my hair out, then eschew all outside advice and have my workdays be filled with stress.
Yes. A new buzzword to fight and avoid for the next 3-4 years or so. Thank you but I'll wait for the O'Reilly "Building cells, 2nd version" to come out and maybe consider it (not).
Why fight and avoid? Embrace and make money on the hype!
I remember it was "APIs" everywhere. Before that it was "mobile first" everywhere. Before that it was "everything through XML". Plenty of opportunities! Don't miss the hype train!
I know this is sarcasm but this is the plague of the industry. It's mostly why we have poor software and why a lot of economic activity consists of adding cool new techniques one year, and then removing it again four years later.
I gave this a brief scan. Cells sound like an abstraction of kubernetes pods. I do find the k8s structure useful, and I would point someone to just use that rather than going through this document and basically creating your own version of k8s. Hiring will be much easier.
I think a pod gives you how to deploy a cell. But there's still a discussion to be had about what goes into the pod. The key part (from a quick read) seems to be the gateway component. That looks like it has a significant role in managing the architecture as a whole.
AWS uses something it calls "cells" absolutely everywhere, as a basic unit of scaling and fault boundary. I'm not sure this link has much to do with it though. I skimmed through it and didn't really recognize it as the same concept; this looks entirely unrelated and weird to me.
Travel back in time with me to the halcyon days of 2012, when Tumblr was the hot new thing. highscalability.com did a writeup on their novel "cell-based architecture", a whole decade earlier than this paper. It certainly inspired me at the time. We don't talk about Finagle as much anymore, but there's lots of good stuff here that still applies.
Not the same notion of ‘cell’, that was describing something more like a macro-shard.
Instead of sharding within a given DB, sharding all the things necessary to deliver a given user:
Cells - A cell is a self-contained installation that has all the data for a range of users. All the data necessary to render a user’s Dashboard is in the cell. Users are mapped into cells. Many cells exist per data center.
we use this architecture at $job. the cells being kube pods. That's just on the platform side of things.
I'm sure it was based on something on someone's promotion doc.
given the recurrent problems we've, it hasn't helped at all.
I don't think that's what this is about. It's more like your whole kube environment is one cell, your VMware environment is another cell, etc. It's a semi-principled way to incrementally migrate/modernize an app without having to do a big rewrite onto a single platform.
Not about the PowerPC / Sony PlayStation Cell architecture.
https://en.m.wikipedia.org/wiki/Cell_(microprocessor)