Profile picture
, 19 tweets, 4 min read Read on Twitter
1/ Twead incoming...
2/ I have some #serverless localhost v. cloud Dev n' Testing thoughts. As a teaser:
3/ Disclaimer: not everyone, not all the time, not always possible, hyperbolic by intent. But I think it should be the default position.
4/ 1. Developing and testing in the cloud pushes integration costs left in the value chain. Integration costs are the exponentially increasing unplanned work that shows up as "deployment pain". Code a customer can't access is as valuable as code never written.
5/ 1.1 Unplanned work: becoming less manageable since at least 2006: computerworld.com/article/256326…
6/ 2. Cloud-native development opens up the ability to test with team-wide shared state. How many times has a localhost-passing feature failed in stg/prod because of DB state? Tests against empty state ignore system state/data evolution. Shout out to the DBRE crew.
7/ 3. Testing in the cloud forces observability. If you can't understand why a test fails, you need to increase system transparency. That transparency is *also* useful when the system fails in production. Because it will fail. Users don't care about passing tests.
8/ 4. The observability imperative can open up a dialog about operator empathy. You (well, the 3am version of you or your team member) will really appreciate the ability to more deeply inspect the internal system state using a phone and an updated config param.
9/ 4.1 What else does someone need to know? Can they know it? How can it be exposed?
10/ 5. It mitigates the frustrating feeling of "feature done, just need a deploy" that disincentives sufficient operational awareness. If you've already "done the deploy" as part of normal development, that last hurdle can feel less imposing/aggravating.
11/ 6. Integrating cloud dev into a standard workflow increases overall cloud familiarity. This creates conditions for a serendipitous #servicefull approach: rather than coding it, is there a service *you can access* that handles the 80%+ case?
12/ 6.1. Those cloud services often require "infrastructure configuration", but if that's done by someone else, you may not even consider it a viable option since it's coordination. And coordination, well, you know, that sounds like a meeting....Yeah, no.
13/ 6.2 If a normal dev workflow is about configuring infrastructure and verifying expectations, it's a much shorter jump to composing systems from those higher level services.
14/ 7. Yes, there are places where connectivity isn't available. That's ok. Consider that the customer-facing service is still running, so there are on-call operators who need higher levels of access. Instead, sketch out some crazy ideas in a notebook.
15/ Code them up when you're out of the flying metal tube.
16/ 8. Ultimately developing & testing against the cloud shares similarities with meta-engineering practices: blog.acolyer.org/2018/01/17/som…
17/ 8.1 What behavioral practices does CloudFirst development and testing incentive? Does testing in the cloud eliminate potential sources of system (both technical and organizational) flow interruptions?
18/ 9. I understand the need for quick feedback. However, if a deploy is ~60s (CloudFront 👀) I've made a choice to accept that so that I don't need to deal with 60 hour meetings trying to get a feature to all the way to production.
19/ PS: I also have some milquetoast thoughts on `latest`:
Missing some Tweet in this thread?
You can try to force a refresh.

Like this thread? Get email updates or save it to PDF!

Subscribe to Matt Weagle
Profile picture

Get real-time email alerts when new unrolls are available from this author!

This content may be removed anytime!

Twitter may remove this content at anytime, convert it as a PDF, save and print for later use!

Try unrolling a thread yourself!

how to unroll video

1) Follow Thread Reader App on Twitter so you can easily mention us!

2) Go to a Twitter thread (series of Tweets by the same owner) and mention us with a keyword "unroll" @threadreaderapp unroll

You can practice here first or read more on our help page!

Follow Us on Twitter!

Did Thread Reader help you today?

Support us! We are indie developers!


This site is made by just three indie developers on a laptop doing marketing, support and development! Read more about the story.

Become a Premium Member ($3.00/month or $30.00/year) and get exclusive features!

Become Premium

Too expensive? Make a small donation by buying us coffee ($5) or help with server cost ($10)

Donate via Paypal Become our Patreon

Thank you for your support!