Excellent post by @mipsytipsy on the future of Ops careers, even if it’s a bit critical of "Lambda: A Serverless Musical". 😉

While I 100% agree that #serverless isn’t headed towards the ridiculous notion of #NoOps, I have some thoughts on the article. 🧵
Context is *extremely* important. The repeating line in the musical of "I'm going to reduce your… ops!" is in the context of setting up and maintaining a Kubernetes cluster. If it's not obvious the first time with "Hey yo, I'm unlike containers, no patching, no maintainers"...
…then the second time around adding "No pods or orchestrators" should make it abundantly clear. Since I consider myself a #serverless purist, I try to avoid the "K" word, but the line "I know all this stuff with K8s is excitin'" should settle any further misunderstanding.
This context is important because Charity incorrectly states that "the chorus chose to double-down on one of the stupidest and most dangerous tendencies the serverless movement has had from day one: misunderstanding and trash-talking operations."
It's true that some in the #serverless movement have taken operational outsourcing to the extreme, i.e. #NoOps, but the vast majority of us DON'T think of it as an elimination of ops, but instead, as a reduction in operational burden that allows us to do more important tasks.
MORE IMPORTANT TASKS, e.g. "write libraries, generate examples, drive standardization", "evaluate use cases" or "write glue code & helper modules to connect disparate data sources." As Charity says, become "an integration point between your organization and the outsourced work."
In addition, ops engineers must work on "evolving release engineering to fulfill the delivery part of CI/CD", they need to take ownership of infrastructure and application observability, and they should extend their skillsets to understand, implement and enforce cloud security.
All of these things need to be done in any organization, regardless of whether you're #serverless or not. However, by going serverless, you dramatically *reduce* the amount of undifferentiated work needed to create the table stakes of infrastructure to run your applications.
Now, if you're looking at #serverless to eliminate your ops entirely, then Charity is right that you're wrong. I stress this so much that I add this slide to every presentation I give. Somebody in your org needs to understand all those configs and the nuances of cloud services.
I've seen orgs (most unsuccessfully) put this pressure on developers. And while, yes, devs should know the APIs and limits of the cloud services they are using, setting up & maintaining CI/CD pipelines, VPCs, security groups, orgs/accounts, etc. are better left up to specialists.
The article also subtly points out the humanitarian aspect of ops reduction. In my recent chat w/ @xavi_lefevre, we discuss the #TCO benefits of a reduced infrastructure staff, but both point out the need to refocus those engineers to higher value tasks. serverlesschats.com/70/
I too was a "jack-of-all-trades" systems person for many years. But times and needs change. Roles and technologies evolve. An ops person of today is not the ops person of tomorrow. Nor will the developer of today be the developer of tomorrow. Evolution is the key to survival.
So, no! #Serverless is not trash-talking, diminishing, or misunderstanding ops. It’s differentiating between what’s important & what's a waste of your team's time. Now, hopefully your org spends that extra time on those *important* ops tasks. #Serverless can't help you with that.

• • •

Missing some Tweet in this thread? You can try to force a refresh

Keep Current with Jeremy Daly

Jeremy Daly Profile picture

Stay in touch and get notified when new unrolls are available from this author!

Read all threads

This Thread may be Removed Anytime!


Twitter may remove this content at anytime! Save it as PDF for later use!

Try unrolling a thread yourself!

how to unroll video
  1. Follow @ThreadReaderApp to mention us!

  2. From a Twitter thread mention us with a keyword "unroll"
@threadreaderapp unroll

Practice here first or read more on our help page!

More from @jeremy_daly

6 Feb
.@alexbdebrie has another excellent post that details the benefits and downsides of using a Single-Table design with @DynamoDB. While I completely agree with him on the “benefits”, I have some thoughts on his “downsides” that I’d like to address. 🧵 alexdebrie.com/posts/dynamodb…
Downside #1: “The steep learning curve to understand single-table design”

There is no doubt that “thinking in #NoSQL” is a complete departure from traditional #RDBMS, but understanding how to correctly denormalize data is applicable to both single- AND multi-table designs.
If you are using a multi-table design in @DynamoDB that implements 3NF, then just STOP! Seriously, this is *beyond* wrong (I think presidents have been impeached for this). This is not what #NoSQL was designed for and you will get ZERO benefit from doing this. Spin up an RDBMS.
Read 28 tweets
4 Dec 19
Very interesting take from @forrestbrazeal on the new #Lambda Provisioned Concurrency. I have a few quick thoughts on this as well... trek10.com/blog/provision…
Yes, "pay-per-use" is very attractive, but I'm okay with AWS's "pay-for-value" model in #serverless environments. I don't expect the cloud to dedicate resources to me for free. I may get the benefit of warm invocations, but that's an internal optimization, not a guarantee.
Steady workloads benefit from "provisioned" capacity, not just from a pricing standpoint, but for performance as well. The "why-not-do-this-high-volume-workload-on-EC2" argument is "sometimes" valid. Provisioned Concurrency w/ Lambda is a step towards negating that logic.
Read 8 tweets
3 Dec 19
Kicked off @AWSreInvent 2019 by attending @houlihan_rick’s @DynamoDB modeling session. As expected, it was a 60 minute firehose of #NoSQL knowledge bombs. There was *A LOT* to take away from this, but here are some really interesting lessons that stuck out to me. #reInvent
DynamoDB performance gets BETTER with scale. Yup, you read that correctly, the busier it gets, the faster it gets. This is because, eventually, every event router in the fleet caches your information and doesn’t need to look up where your storage nodes are.
Big documents are a bad idea! It’s better to split data into multiple items that (if possible) are less than 1 WCU. This will be a lot cheaper and cost you less to read and write items. You can join the data with a single query on the partition key.
Read 15 tweets
2 Dec 19
I *LOVE* what the @awscloud #EventBridge team is doing for #serverless, and this new Schema Registry is an amazing next step! Here are my initial thoughts on this... aws.amazon.com/blogs/compute/…
EventBridge _should_ become the glue that ties together all your cloud services (eventually w/ two-way message bindings). This means that the number of event types (don't forget SaaS partners) is going to increase exponentially...
Security best-practices will evolve to prefer multiple event buses so you'll have fine-grained access control across SaaS vendors, AWS service events, and custom messaging. The cognitive load to understand all those nuances, limitations, and event structures is overwhelming...
Read 9 tweets
7 Jun 19
I've been spending a lot of time lately with @dynamodb in my #serverless applications, so I thought I'd share my surefire guide to migrating to it from #RDBMS. So here is…

How to switch from RDBMS to #DynamoDB in *20* easy steps… (a thread)
STEP 1: Accept the fact that Amazon.com can fit 90% of their retail site/system’s workloads into DynamoDB, so you probably can too. 🤔
STEP 2: Create an Entity-Relationship Model, just like you would if you were designing a traditional relational database. 👩‍💻
Read 23 tweets

Did Thread Reader help you today?

Support us! We are indie developers!

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

Become a Premium Member ($3/month or $30/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!

Follow Us on Twitter!