Discover and read the best of Twitter Threads about #Serverless
Most recents (8)
I did a lot of work on outcome (worth based) models back in 2004-2007 ... they tend to expose weakness in the business to define value and inability of budgets to cope with variable models - blog.gardeviance.org/2008/09/sound-…
One of the most interesting aspects of Serverless - as we move to measuring capital flow and opex for running code, as IT becomes even more an enabler rather than an obstacle - is the shift will expose huge weaknesses in other groups (from strategy to finance to HR) ...
... in the past, IT has always been the whipping boy, the one to blame, to point the finger at. In reality, past inefficiency & ineffectivess in IT has simply masked wider organisational problems. The next decade should get very interesting ...
Since it seems to have helped some folks, here is the way I defined "#serverless" to a group of workshop participants at @ServerlessConf this week. 
Note that a technology can use parts of the programming model (kubeless/knative/etc) or the operational model (say, RDS SQL Server), but you only get the full benefits of serverless if you are in the center of the diagram.
As a side question, is there such a thing as a usage-priced service (you pay only for the network/storage/compute resources you actually consume) that is not also fully managed (you have infrastructure responsibilities)? I couldn't think of one.
Arrived in SFO, time for a coffee and then head to the hotel. Crashing out at Marriott Courtyard on 2nd St courtesy of #Google. Flight was courtesy of #Serverless conference. Thank you.
These days, almost my entire schedule of travel involves jumping from one conference to another courtesy of numerous conference organisers. Thank you all, otherwise I'd never leave Kent.
X : Aren't you concerned this might influence your independence of thought?
Me : Not at all. I do warn people that I'm going to say what I think regardless. Some conferences are brave e.g. I've done a few "Devops is the new legacy" at DevOps events.
Me : Not at all. I do warn people that I'm going to say what I think regardless. Some conferences are brave e.g. I've done a few "Devops is the new legacy" at DevOps events.
I’ve been thinking a lot about serverless architecture and I’ve realised what bugs me about it.
This is gonna be a long one. Not gonna lie, I wrote a draft first. If I hadn’t, this thread would end right before it got interesting because I’d get distracted by a butterfly.
This is gonna be a long one. Not gonna lie, I wrote a draft first. If I hadn’t, this thread would end right before it got interesting because I’d get distracted by a butterfly.
At its heart, serverless/FaaS/lambda/whatever-you-call-it works for me because it ties action to cost. The more I do (or the more inefficiently I do it), the more I pay. More users, more money. @gojkoadzic wrote about this years ago. It’s not new. gojko.net/2016/08/27/ser…
The problem, I find, is that in doing so, it breaks your application apart. Now we have many applications. They all work with HTTP, or message queues, or some other data interchange layer I don’t care about when I’m designing functionality for a user.
THREAD:
So, let's have a quick chat about CI/CD and #serverless.
This will be more "overview" than in depth (it's twitter after all)
So, let's have a quick chat about CI/CD and #serverless.
This will be more "overview" than in depth (it's twitter after all)
CI and CD* are not the same thing
*and there are 2 types of CD
*and there are 2 types of CD
CI is Continous Integration
When multiple developers are working on one project, at some point they have to come together and combine their efforts...
...therefore Integration
And that happens continuously over a project
When multiple developers are working on one project, at some point they have to come together and combine their efforts...
...therefore Integration
And that happens continuously over a project
For me a serverless (S-) architecture is much more than a event-driven function as a service (FaaS)...
(Thread)
#serverless #faas #architectures #thread #lambda #fastMovingTeams #ownership #devops
(Thread)
#serverless #faas #architectures #thread #lambda #fastMovingTeams #ownership #devops
A S- architecture is an abstraction on top of a (potentially very complex) infrastructure, so that devs can focus on building great features and products and run their code in production without focusing on boring configuration and scalability.
This doesn't mean there are no servers and there is no care for infrastructure: quite the opposite indeed.
THREAD: A good practice is for each AWS Lambda function to do one thing rather than bundle all functionality into one function.
Why?
Why?
A quick answer is that the smaller the Lambda function, the faster it will load and the quicker it should run (depending on libraries etc), but that's very simplistic
Let's take a slightly more businesslike view of #serverless
When I tell people I am the founding PM on Lambda, the question I often get is how the idea for #AWS Lambda/#Serverless came about in the first place. The truth is, its way too hard to point to one person/event as the defining moment.
It took 100s of customer conversations notes from multiple AWS folks where they told us 1/all the things they wanted to minimize/ not do at all while building applications; 2/architectural patterns they were repeating and wanted a way to build into their development flow.
It took some serious leaps of faith and acceptance of risk from the people involved, and a constant iteration on what we wanted the final product to look like. This is where I first saw the AMZN "Working backwards" process in action and its brilliance in driving the right focus.
