11 ms·

> To succeed in using application development to increase agility and innovation speed, organizations must adopt five elements, in any order: microservices; pur

> To succeed in using application development to increase agility and innovation speed, organizations must adopt five elements, in any order: microservices; purpose-built databases; automated software release pipelines; a serverless operational model; and automated, continuous security. When I worked at AWS, it used to take us months to change the position of a button in the UI. Things that our competitors did in hours and days, we did in months and years. I'd say that as a general heuristic, if you want "to increase agility and innovation speed" do the opposite of what Amazon does.

jayd16 7y ago
This is because feature verticals build their own UI, right? Seems like there should be a solution to this.
- DVassallo 7y ago
  Changing a button was just one example. How about this? https://twitter.com/dvassallo/status/1166700686467166208 https://twitter.com/dvassallo/status/1166700686467166208
  - capableweb 7y ago
    You know, instead of linking to your Twitter, you could just embed the content directly here instead. For people who don't want to go to Twitter since they are here, Tweet is about that AWS changed the limit of ElastiCache names from 20 characters to 40 and author says about it: "If you can make a change like this to your SaaS without any fuss, you can probably outcompete AWS on innovation pace and agility. For AWS, this is a significant accomplishment worthy of the “2019 What’s New” page"
  - privateSFacct 7y ago
    Interesting, the claim is that if you can easily change ElastiCache cluster names "you can probably out compete AWS..." It will be interesting to see if that happens soon then. I know IBM and the many other Openshift partners are chasing this. Will be interesting to see if they can deliver. My own view - do not underestimate the depth of services and innovation AWS and GCP can bring to bear. I'm just not hearing folks go - oh, this provider let me use a longer name for my elasticache cluster. Instead its, why shouldn't we just use AWS or GCP.
  - jayd16 7y ago
    This just seems like a pretty dig. The issue of feature verticals/microservices/soa leading to complex UI interaction is a fundamental issue we can actually sink our teeth into. I'm not really interested in the minutia of particular aws failures.
Ididntdothis 7y ago
I think from a certain size and number of users any innocent looking change can cause a lot of unintended consequences. I always wonder how Microsoft or Apple make any changes to their OS considering the large number of legacy code that should keep running.
- solarkraft 7y ago
  The considerations part of developing an operating system can be viewed pretty well in the mailing lists of Linux Distributions (and other OSes, but less so because of the fewer stake holders). The decision making processes are influenced by different cultures: Debian aims for a very stable system with no breakages at least within a major version, Windows aims for close to endless backwards compatibility (hence the bloat), while Apple designs its systems with more of a "move fast" attitude (hence the quick proliferation of new features).
influx 7y ago
When I worked there we had continuous deployment with pipelines straight into Lambda in native AWS. There’s so many different teams at Amazon I wouldn’t take anyone’s advice that claim they can speak for all of development there.
- DVassallo 7y ago
  Agility is not about deployment speed. It's about being able to react quickly and easily to new information (customer complaints, bugs, new opportunities, etc). You don't need a perspective from the inside to make the claim that AWS's evolution rate of existing products is weak. Innovation speed might be high horizontally (launching a ton of new services), but not vertically (improving existing ones).
tnolet 7y ago
Ok, so how do you explain the blistering speed at which AWS (not Amazon) releases new services, updates and features. Not being smarty pants here; It truly boggles my mind how fast they move.
- DVassallo 7y ago
  AWS is great at horizontal innovation (launching a lot of brand new stuff). It's vertical innovation where they struggle (improving existing products). Software architecture helps the latter much more than the former.
  - Rapzid 7y ago
    Two cases to your point. It took a VERY long time for ELB(and thus autoscale/cloudformation) to get the ability to drain connections. This was a show stopper for most serious players on anything customer facing but unless you were, or knew somebody who was, spending close to 500k/mo you would never be able to get a sense of timeframe out of AWS for addressing this. ALB launched without the ability to route requests based on sub-domain even though this was the only direct upgrade path for most people who had been building SOAs on top of ELB and Route53.. Took way too long to get that added in and of course with no public acknowledgement of time frame. Now that I think about it.. AWS is NOT very agile at all because they barely include a small fraction of their stakeholders in their product design and iteration process. You'd have better luck trying to squeeze water out of a moon rock than getting AWS to comment on roadmap for a service.
  - privateSFacct 7y ago
    Excellent point. If they just cycled a lot harder on existing products they would be best in class.
- paulddraper 7y ago
  Do they move fast? I'm still waiting for Aurora to offer PostgreSQL 11 from last October. Hell, I'm still waiting for AWS to offer an upgrade path to PostgreSQL 10 from October 2017.
segmondy 7y ago
An interface even if it's just a user interface is a contract. You can't just go changing it because you want to. Many immature companies do this and think it's innovation. It's not, all your users will have to relearn the new UI change.
- DVassallo 7y ago
  That attitude is what leads to the AWS console.
  - yongjik 7y ago
    As someone who uses AWS console every day at job, I must say I find it pretty usable. I especially like the part that whatever buttons I learned stays in the place, so I don't have to waste time figuring out what the hell I have to press this time. So if AWS's attitude lead to its console, I think they're doing great.
    - aftbit 7y ago
      As someone who uses the AWS console once a month, I find it incredibly confusing and I'm always hunting for the right sub-section. This is the old trope: experts prefer complex and efficient systems, while beginners prefer simplicity.
  - twblalock 7y ago
    The AWS console is a bit clunky, but would you really prefer it if it was changing all the time?
- tptacek 7y ago
  I'm guessing the person you're replying to understands the implication of changing a UI. Maybe, instead of telling them why they're wrong, you could ask them if resistance to UI changes was the problem, or something else was? They were there. Were you?
cle 7y ago
> I'd say that as a general heuristic, if you want "to increase agility and innovation speed" do the opposite of what Amazon does. That’s a pretty vague and useless heuristic. Since you worked at AWS, maybe you could answer why AWS moved slowly on releasing features for existing services? An Amazon-y “five whys” analysis would probably yield a lot more specific and useful heuristics.
- DVassallo 7y ago
  Don’t take it too literally. My point was that AWS doesn’t show agility and rapid innovation on existing products, so when it tries to tell you how to do that, maybe take it with a grain of salt.
ffflush 7y ago
>When I worked at AWS, it used to take us months to change the position of a button in the UI. Things that our competitors did in hours and days, we did in months and years. From what I understand, the culture in a large company varies from team to team. Was it your experience that all the teams were that slow? Are you claiming the whole of AWS is that way or that since your team was that way we should disregard any advice about AWS? If I invert all the advice from the post, would that be better as a development practice? A large monolith, backed by an off the shelf database where there is a central security team looking after every line of code?
- DVassallo 7y ago
  It's a company-wide issue, and it can be observed from the outside too. Existing products improve at a rate that is significantly slower than competitors (with a few exceptions). And I'm not referring to feature creep, but fixing obvious gaps and issues that the company would have been aware of for years (or more than a decade in some cases).
bg24 7y ago
Your last statement is being blunt on Amazon. Customers come first in AWS culture. With a massive user base, they need to care about not breaking existing customer applications/integrations. If AWS did not evolve its software processes, they would have already fallen apart by now. The teams move reasonably well for the size of a big company.
- twic 7y ago
  > Customers come first in AWS culture As a customer of AWS, it never seemed that way.
SkyPuncher 7y ago
Are you comparing to competitors of your size? I ran an enterprise-backed startup. We built way faster than our enterprise backers when it was our own name. If something carried an association or backing of the enterprise, it took at least 10 times longer. They had a reputation to uphold and needed to ensure everything reflected that.

jayd16 7y ago

This is because feature verticals build their own UI, right? Seems like there should be a solution to this.

DVassallo 7y ago
Changing a button was just one example. How about this? https://twitter.com/dvassallo/status/1166700686467166208 https://twitter.com/dvassallo/status/1166700686467166208
- capableweb 7y ago
  You know, instead of linking to your Twitter, you could just embed the content directly here instead. For people who don't want to go to Twitter since they are here, Tweet is about that AWS changed the limit of ElastiCache names from 20 characters to 40 and author says about it: "If you can make a change like this to your SaaS without any fuss, you can probably outcompete AWS on innovation pace and agility. For AWS, this is a significant accomplishment worthy of the “2019 What’s New” page"
- privateSFacct 7y ago
  Interesting, the claim is that if you can easily change ElastiCache cluster names "you can probably out compete AWS..." It will be interesting to see if that happens soon then. I know IBM and the many other Openshift partners are chasing this. Will be interesting to see if they can deliver. My own view - do not underestimate the depth of services and innovation AWS and GCP can bring to bear. I'm just not hearing folks go - oh, this provider let me use a longer name for my elasticache cluster. Instead its, why shouldn't we just use AWS or GCP.
- jayd16 7y ago
  This just seems like a pretty dig. The issue of feature verticals/microservices/soa leading to complex UI interaction is a fundamental issue we can actually sink our teeth into. I'm not really interested in the minutia of particular aws failures.

Ididntdothis 7y ago

I think from a certain size and number of users any innocent looking change can cause a lot of unintended consequences. I always wonder how Microsoft or Apple make any changes to their OS considering the large number of legacy code that should keep running.

solarkraft 7y ago
The considerations part of developing an operating system can be viewed pretty well in the mailing lists of Linux Distributions (and other OSes, but less so because of the fewer stake holders). The decision making processes are influenced by different cultures: Debian aims for a very stable system with no breakages at least within a major version, Windows aims for close to endless backwards compatibility (hence the bloat), while Apple designs its systems with more of a "move fast" attitude (hence the quick proliferation of new features).

influx 7y ago

When I worked there we had continuous deployment with pipelines straight into Lambda in native AWS. There’s so many different teams at Amazon I wouldn’t take anyone’s advice that claim they can speak for all of development there.

DVassallo 7y ago
Agility is not about deployment speed. It's about being able to react quickly and easily to new information (customer complaints, bugs, new opportunities, etc). You don't need a perspective from the inside to make the claim that AWS's evolution rate of existing products is weak. Innovation speed might be high horizontally (launching a ton of new services), but not vertically (improving existing ones).

tnolet 7y ago

Ok, so how do you explain the blistering speed at which AWS (not Amazon) releases new services, updates and features. Not being smarty pants here; It truly boggles my mind how fast they move.

DVassallo 7y ago
AWS is great at horizontal innovation (launching a lot of brand new stuff). It's vertical innovation where they struggle (improving existing products). Software architecture helps the latter much more than the former.
- Rapzid 7y ago
  Two cases to your point. It took a VERY long time for ELB(and thus autoscale/cloudformation) to get the ability to drain connections. This was a show stopper for most serious players on anything customer facing but unless you were, or knew somebody who was, spending close to 500k/mo you would never be able to get a sense of timeframe out of AWS for addressing this. ALB launched without the ability to route requests based on sub-domain even though this was the only direct upgrade path for most people who had been building SOAs on top of ELB and Route53.. Took way too long to get that added in and of course with no public acknowledgement of time frame. Now that I think about it.. AWS is NOT very agile at all because they barely include a small fraction of their stakeholders in their product design and iteration process. You'd have better luck trying to squeeze water out of a moon rock than getting AWS to comment on roadmap for a service.
- privateSFacct 7y ago
  Excellent point. If they just cycled a lot harder on existing products they would be best in class.
paulddraper 7y ago
Do they move fast? I'm still waiting for Aurora to offer PostgreSQL 11 from last October. Hell, I'm still waiting for AWS to offer an upgrade path to PostgreSQL 10 from October 2017.

segmondy 7y ago

An interface even if it's just a user interface is a contract. You can't just go changing it because you want to. Many immature companies do this and think it's innovation. It's not, all your users will have to relearn the new UI change.

DVassallo 7y ago
That attitude is what leads to the AWS console.
- yongjik 7y ago
  As someone who uses AWS console every day at job, I must say I find it pretty usable. I especially like the part that whatever buttons I learned stays in the place, so I don't have to waste time figuring out what the hell I have to press this time. So if AWS's attitude lead to its console, I think they're doing great.
  - aftbit 7y ago
    As someone who uses the AWS console once a month, I find it incredibly confusing and I'm always hunting for the right sub-section. This is the old trope: experts prefer complex and efficient systems, while beginners prefer simplicity.
- twblalock 7y ago
  The AWS console is a bit clunky, but would you really prefer it if it was changing all the time?
tptacek 7y ago
I'm guessing the person you're replying to understands the implication of changing a UI. Maybe, instead of telling them why they're wrong, you could ask them if resistance to UI changes was the problem, or something else was? They were there. Were you?

cle 7y ago

> I'd say that as a general heuristic, if you want "to increase agility and innovation speed" do the opposite of what Amazon does. That’s a pretty vague and useless heuristic. Since you worked at AWS, maybe you could answer why AWS moved slowly on releasing features for existing services? An Amazon-y “five whys” analysis would probably yield a lot more specific and useful heuristics.

DVassallo 7y ago
Don’t take it too literally. My point was that AWS doesn’t show agility and rapid innovation on existing products, so when it tries to tell you how to do that, maybe take it with a grain of salt.

ffflush 7y ago

>When I worked at AWS, it used to take us months to change the position of a button in the UI. Things that our competitors did in hours and days, we did in months and years. From what I understand, the culture in a large company varies from team to team. Was it your experience that all the teams were that slow? Are you claiming the whole of AWS is that way or that since your team was that way we should disregard any advice about AWS? If I invert all the advice from the post, would that be better as a development practice? A large monolith, backed by an off the shelf database where there is a central security team looking after every line of code?

DVassallo 7y ago
It's a company-wide issue, and it can be observed from the outside too. Existing products improve at a rate that is significantly slower than competitors (with a few exceptions). And I'm not referring to feature creep, but fixing obvious gaps and issues that the company would have been aware of for years (or more than a decade in some cases).

bg24 7y ago

Your last statement is being blunt on Amazon. Customers come first in AWS culture. With a massive user base, they need to care about not breaking existing customer applications/integrations. If AWS did not evolve its software processes, they would have already fallen apart by now. The teams move reasonably well for the size of a big company.

twic 7y ago
> Customers come first in AWS culture As a customer of AWS, it never seemed that way.

SkyPuncher 7y ago

Are you comparing to competitors of your size? I ran an enterprise-backed startup. We built way faster than our enterprise backers when it was our own name. If something carried an association or backing of the enterprise, it took at least 10 times longer. They had a reputation to uphold and needed to ensure everything reflected that.