Hi there,
AWS Wishlist: AWS Reference Architectures By Scale And Maturity
This past few weeks I've spent time building some small prototype services. In particular, I was building some different attempts at using API keys for AWS API Gateway authorization with the least amount of management overhead possible. To do this I spent time stripping requirements that I didn't feel were necessary for my scale. For example, my keys only needed to confirm authorization and not authenticate identity.
I'm used to this process from my startup experience. You usually don't have time to do everything so you take your idea or a known best practice and start stripping requirements which leads to a need for reduced features. That process of stripping requirements is a mostly subjective exercise that involves defining your most pressing needs and comparing them against your current constraints like time, expertise, etc.
This made me realize something I would love from AWS to help benefit the startup community. I'd love to see AWS best practices defined that are reflective of different states of company and product maturity. The AWS infrastructure I need for an MVP is different from what I need while searching for product market fit which differs from what I need as I search for repeatable scaling.
For a services at each stage in a reference architecture tell me:
Even just saying, "We acknowledge X is deficient in this spot but we chose not to solve this because we assume you don't have the time right now. You will solve this in a later maturity stage once your head count has scaled," IS SO HELPFUL.
Engineering is never done in a vacuum. There is always context to be considered. It's great to provide a golden standard, but it's very helpful to provide realistic attainable standards. The less time a startup can spend on infrastructure means more time to spend on building products to grow their company.
Returning To Monday Delivery Next Week
For the past several weeks we've been coming to you on Tuesday mornings instead of our previous Monday afternoon delivery. We did this as an experiment to see how it would effect our reach. Would the different time affect open or click rates?
Well, the change in day and time had no affect! It appears we have a very loyal core of subscribers who follow us no matter when this email arrives. So look forward to us arriving on Monday afternoons again.
This Week's Links
In this week's edition of Cold Start we have links on:
- 2018 recaps from Thundra and Epsagon
- Predictions from Stackery
- Serverless security resources
- and more...
Closing
I'm Tom from ServerlessOps and we provide a range of services around DevOps transformation, AWS migration, serverless training, and startup cloud operations. See our services to learn more.
Also let us know what you think of this week's Cold Start using the ๐/๐ links at the end of this email!
Cheers,
Tom at ServerlessOps