I've spent the past few weeks working on the architecture for a new mobile bank - think of N26 or Starling or other "challenger" banks, but focused on female entrepreneurs, especially those who lack access to traditional banking and credit. Cool project!
A big part of this is evaluating different approaches and vendors for a few needs, and for many of these there are "default" answers.
Commonly accepted good approaches:
Identity: instead of building your own "forgot password" pages and 2FA checks, you can build rapidly on Auth0 or Okta and they will give you user-management dashboards, SSO integrations, and pre-built forms.
The Rest: DataDog, PagerDuty, Sentry, NewRelic, and more round out the go-to tool box.
One of the common threads here - these "default approaches" may be free in the first months but can rapidly scale in cost as your product ages and grows.
The alternative is DIY, and I do not advocate rolling your own. Your dev resources are precious, and I get hives when I see a team building their own analytics or feature flagging. Others have done it better, in a way that lets you push responsibility out to product and account people on your team. Identity may have auditing and security requirements that make it better to push that responsibility out of your org to a professional team as well.
A dev team should focus their hours on the product aspects that are unique to your company - never re-inventing wheels that have been done better by others.
I've considered building some of these in the past, as open-source standards for other teams. The tools and components are all there, lying on the ground, waiting to be used. But again, it's a mis-allocation of my own resources.
So I sign up for Google Analytics, Auth0, MixPanel, and LaunchDarkly.
I have easy implementation, good documentation, powerful tools, and low risk.
Why Not AWS?
Why isn't AWS vertically integrating to compete more directly with some of these services?
Today AWS is the default building blocks of any new venture, why aren't they capturing more of the value, and allowing greater industry standardization and efficiency, by moving up the chain to the tools themselves?
I'm reminded of how Stripe's goal is to "increase the GDP of the internet" (not "facilitate payments"). Similarly, I think AWS' goal can and should be decoupled from the plumbing and wiring, to "increase the productivity of the world's product people".
They've done this admirably in allowing us to stop compiling kernels, configuring MySQL slaves, and developing queueing systems. Keep the work going into the green fields of the higher-level tools.
This strategy would also be the primary way to avoid having the recent push to code-free development abstract you even farther down the value chain. As the tools for design and development become more sophisticated, the differentiation between one VPC or RDBMS provider and another will disappear. This isn't happening yet, but it seems an inevitable medium-term consequence of sophistication.
Ultimately AWS needs to move up the value chain. They've demonstrated this to some extent with AppSync, the Firebase competitor that pulls in API management, web and mobile SDKs, and identity, but most reviews still are that it's not good enough, and still requires a lot of heavy lifting from devs, especially around identity.
There are two constant waves that are not going to change:
Last-generation tools will continue to be commoditized.
See: Google Analytics, MixPanel, Sentry, CircleCI, any analytics, error detection, monitoring, log management, etc...
- This is demonstrated by AWS. Object storage, container hosting and mail delivery were the previous generation of tools that allowed Dropbox, MixPanel, CircleCI, and more to be built. The wave will push forward.
- Result: Big value, bad business - these businesses are a race to the bottom - they all get to feature parity and zero cost, and engender no new competition. At the same time, they are a standard - every new product integrates them because they still provide huge intrinsic value. We need them to make our products go. Big value, no profit. Soon if not now. Would you invest in a Google Analytics competitor?
Tools will continue to become more sophisticated.
- We work in a magical time, compared to 5 and 10 years ago! This progress will continue.
- Aside: I'm launching a course on the AWS CDK.
- Result: AWS becomes low-value (as provided by these tools). More distance between AWS and its consumers. Intermediation, automation, obfuscation.
AWS should do for tooling and utilities what Amazon Basics does for undifferentiated retail products.
What They Need
There are key ways that these products would differ from the current slate of AWS solutions, but the crux of it is this: with almost no exceptions, current AWS products are designed to be configured by the cloud ops / dev ops team. It is expected if you use Cognito for identity, that you will set up multiple related resources, policies, pools, etc..., which can then be consumed by your developers in the code.
The next wave of tools needs to be something that can be configured by a product manager, integrated by an intermediate developer, and consumed by account managers and marketers.
On top of the robust, powerful, but complicated existing AWS platform we need to be able to use the kind of admin tools we're used to in SAAS products: create products, create teams, invite people in, and set permissions.
This "simplified" role, user, and project permissions can be layered on IAM with new UX.
That ethos goes to the entire use of the product. Here is how user roles are configured in Cognito:
And in Auth0:
Right?! In your company, who can create a new role for staff in the first example, and who can create a new role in the second example. It doesn't have to be this way, we can build on top of the power and create the ease and democracy.
I have no problem with the Console UX, but it's not the appropriate approach to product UX unless it's to be used by cloud ops experts.
I'm calling for a category of friendly and easy to configure products to be crafted on top of the powerful and flexible products AWS already has.
Part of this is about risk. RISK in caps. AWS services need properly configured by someone who knows how they work
AWS has a robust and well-defined free tier.
- Their pricing structure can already support tiers of free vs utility-billed consumption, making it easy to scale tool offerings from startup-free to enterprise-rich.
AWS has enterprise, government, and compliance security and administration
- Last company I was in health-tech. I spent weeks hunting for "MixPanel for HIPAA" without success. Any utility tools that AWS rolls out will have the full capabilities of AWS security, privileges, compliance frameworks, etc... baked in.
- This is important. Many of these utility tools are free for normal usage, but charge hundreds of dollars monthly for HIPAA or PCI compliance, or cannot be used at all in regulated environments. On AWS this would be free, as long as you used it correctly. This dramatically expands how much value AWS can capture with this strategy.
Delivery costs are nil.
- There is effectively no cost to AWS to operate these services, other than the human and organizational attention costs of maintaining them.
- This product category can be easily constructed primarily from existing AWS products. This is pretty obvious and great - the building blocks exist at the same company - but it also allows the full strength of the components to be wielded as well. If you're doing an analytics product, and the event hits are streamed on Kinesis to your processing ending, you can also attach other processing consumers to the stream without impacting the off-the-shelf analytics. AWS products come with the capabilities baked in that make up APIs and webhooks at other companies. Abstracting away the how, but making the components and their endpoints available for access gives maximum flexibility and power to a simple product. You can satisfy both ends of the spectrum.
We Trust AWS.
- AWS is not an advertising company offering free web analytics. If there is a free tier, it's because it's trivial to provide, not because we or our data are the product. We already trust AWS as an impartial provider of infrastructure and building blocks, with our health data, our government data, our startup source code. There is no hurdle to trusting AWS with our user analytics, crash reports, and everything else in the utility tools category.
- If Facebook launched an analytics service, we would not use it.
Didn't You Say These Are 'Bad Businesses'?
They're bad standalone P&Ls, but they are the next generation of cloud utilities that enable product teams to move fast and build with standardized components.
Every cycle not spent on monitoring, identity, or analytics by a dev team is a cycle dedicated to product advancement. This is the efficiency that cloud ops allows, and it needs to tick forward an iteration.
What is the enterprise value of being the standard toolkit for product teams? For logging, analytics, error capture, identity?
Look at the enterprise value of Firebase being the default mobile back-end. That's only one slice.
AWS can go beyond this as well, by providing the toolbox, and allowing the components that make up these new tools to be accessed for more complicated remixing and customizing, providing power, simplicity, security, and functionality that doesn't exist currently.
Lock in the next generation of product people by provising the pickaxes and shovels that they need to launch, monitor, and maintain their products, and they'll never leave.