Amazon’s Away Teams laid bare: How AWS's hivemind of engineers develop and maintain their internal tech Companies inside and out of Silicon Valley have found their own ways to rapidly develop and deploy features and functionality. Within the belly of Amazon Web Services, the web giant's gigantic cloud beast, though, is a specific digestive system – a concept called Away Teams – that accepts certain weaknesses to achieve maximum …
A lot of this seems to echo what the Open Source community has been evolving for decades. Source code accessible to all for use, adoption and modification. An architecture built around interfaces (compare the Amazon API mantra with the w3c RFC ecology). A direction driven by a positive tension between crowdsourced value and the influence of a few powerful visionaries. Amazon's only mistake has been not to expose their model before and engage the wider community in making it better.
Because the history of the Open Source movement teaches us one more thing: have no fear of the competition, for if your competitor is full of sh*t then they won't adopt it anyway.
A lot of this seems to echo what the Open Source community has been evolving for decades.
This was my first thought, too. And then I found myself wondering about the actual tools of the trade that support this model at AMZN. What languages, source control systems, tools and techniques do they use? How do they help? How common they are between the teams? How do they support the scaled-out development process? To me this was missing from the (very good) article.
It was only touched in passing but it seems the tools are selected to fit the job(s) at hand rather than be set on high or even required to have commonality cross-team. That's the second step of the way I did things, picking the tools to support the requirements. It was awfully nice if we already had it on hand and in use, but not a necessary condition. And, why I never used the same language twice. Heck, even the editor at hand varied.
What Amazon and it's employees have accomplished is amazing. However, service-oriented collaboration has been around long enough that I remember having such involvement at MCI back in the late 90's as it related to their Frame Relay and ATM services (among others). And I'm sure examples existed before then, like the Apollo program at NASA.
Anyone who has worked in a large company for any length of time quickly sees how important it is to cross the silos erected to carve out the little empires within a company. It's really hard to react to changing market dynamics and externalities without such a level of collaboration. But kudos to Amazon for codifying how they go about that.
> The policy is to do whatever it takes to provide value to the customer and not worry about duplication or deviating from standards. There is no waiting while the perfect shared service is being developed. There is no friction from having to use the perfect shared service.
Perhaps these superior policies are why the amazon.com website is broken so damn often, with searches turning up zero results, sorting by price resulting in 1/10th as many hits, higher priced items are interspersed through the lower priced items, and utterly irrelevant products show up even though the keywords you used don't show up anywhere in the product page.
You treat everything as an API
But "Everything is an API" - perhaps not true, but certainly more so today than in the past. The guys at AWS I've talked to do say, it's all API's - when you click something in the Management console, its making an API call - which you can make directly via the SDK, CLI, etc...
I wonder how many redshirts they have on these away teams?
combined with duplication of function and multiple development techniques and languages - I will be interested to see how this evolves because that's the kind of cruft that builds up and usually brings a) huge support issues then b) a clean up project
I was also a bit surprised when I read that.
Technical debt is not something you can ignore and put under the carpet: sooner or later it will make a sudden comeback and gnaw at your ankle and you will stumble.
Maybe they made a distinction between the flag development teams who do the new stuff and need to do it fast, and some other grunt teams doing the tedious work of being sure the whole scaffold doesn't break down on its own weight.
I certainly dont believe AWS can ignore technical debt altogether.
Sounds a bit like a PR justification for chaos to me - strongly suggesting that the business has grown to big to control.
The assumption that referring to 'Management' will cause delay is merely an avowal that the said management must be crap. In reality a Manager is there solely to facilitate the work of those being managed, not to gum up the works. However the fashion increasingly seems to be to run an enterprise this way, and I suppose it makes accountability harder to bring home, so maybe there's an advantage there.
> The larger worry is that product cohesion and consistency may suffer.
Heavy user of AWS' public services here, if you look at something simple like 'tag service resource (e.g. Lambda, Table, Bucket) with a k,v', these APIs are vastly different across services, both in naming and workings...
An example of what @lxndr mentions that annoys me is that sometimes the "tags", which are more-or-less everywhere, can be used to "name" an object, such that the Web management UI considers it a name, and sometimes not.
Likewise, one can access EC2 through their Python "boto3" library, but not RDS. What even more irritating about having to learn two completely different ways to access these services is that the way they are presented in aws-shell is different again, even though there has clearly been an attempt to unify everything under it.
Quite honestly, this seems amateurish to me.
"The emphasis on data reduces ideological passion. I may be right or you may be right, but we don’t need to fight it out. We will see in the end because the data is always right."
This seems like a somewhat naive idea, because the problem with "the data is always right" is that it just begs the question: *what* data? What do you measure, how, and over what timescale? Unless all parties involved can magically agree on that (and how likely is that, if the debate is e.g. about a feature that enhances revenue but compromises user privacy - who's going to draw up a framework for measuring that tradeoff?), all you've done is move the question around a bit...
This post has been deleted by its author
There are good ideas and practices in here but ... Calling Architects "Bar Raizers" might be a sign of the key single point of failure (SPOF).
I would like to think the AMZN CTO and "Bar Raizers" have developed a common vision and enterprise road map. But I am not hopeful.
It is perhaps interesting to compare the histories of AMZN and MSFT. Windows is Mount Everest of technical debt, but AMZN are building one that might grow larger.
and the AWS partner portal (https://partnercentral.awspartner.com/SiteLogin) remains down due to:
"...certain technical issues related to a service provider. We have been working closely with our service provider throughout the day, but at this time do not have an ETA on when a resolution will be available."
the irony.
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2024
