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.
> A cell is a collection of components, grouped from design and implementation into deployment
Not about the PowerPC / Sony PlayStation Cell architecture.
https://en.m.wikipedia.org/wiki/Cell_(microprocessor)
Unfortunately!
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.
Why do they need that many AWS accounts?
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.
Yep.
Once you get the processes and pipelines built to manage account lifecycle, they provide a lot of valuable compartmentalization properties.
Sounds like some random consultant who wants to coin a new buzzword so they can force this upon organizations.
no thaaaaaaaaaaaaaaank you.
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.
[1] https://news.ycombinator.com/item?id=31986784
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).
Very useful and thorough. Thanks for sharing this insight!
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.
Fashion driven industry.
It is so ironic to see microservices being hyped, when back in the Solaris golden days we had "The network is the computer" mantra.
Now we get people to rediscover CORBA and DCOM via gRPC.
Or being told how cool Web IDEs are, when again 30 years ago, we were sharing development servers via telnet and X Windows.
Or "pick your example"…
Not necessarily, COBOL is well and alive.
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.
The concept have been mentioned by Amazon for years.
For reference see:
"AWS re:Invent 2018: How AWS Minimizes the Blast Radius of Failures" https://youtu.be/swQbA4zub20
Yea my understanding is that cell based architecture got really big within AWS 6-7 years ago to make scaling more predictable.
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.
(I work at AWS.)
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.
http://highscalability.com/blog/2012/2/13/tumblr-architectur...
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.
https://github.com/wso2/cellery
An implementation of the Cell-Based Architecture.
Confusing name. https://en.wikipedia.org/wiki/Celery_(software)
So a collection of micro services is a “cell”. What’s a collection of cells called? An “organ”? Wake me up when we’re at the “ecosystem” level. :P
What’s a collection of cells called? A tissue :D
Bless you
A collection of cells called a virtual application https://github.com/wso2/reference-architecture/blob/master/r...
I wish they had better icons, or have shared the SVG for a chance for others to put a different color schema on them, e.g. https://github.com/wso2/reference-architecture/blob/master/m...
this is insanity, just build distributed monoliths if you need something this elaborate holy crap.
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.
the cells being kube pods.
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.
Was this written by GPT-3?
https://cellery.io
I still have anxiety from the last project I had to use named after this vegetable.
lol!
Includes neither bee hive style hexagons nor building architecture. Or pictures if buildings in the former style.
sad beekeeper noises
Hexagonal architecture is the thing you need, then: https://alistair.cockburn.us/hexagonal-architecture/
Was just kidding. Forgot to mention that.
Nice having a name for that, though.