In the aftermath of serverlessconf, Twitter was abuzz with the #serverless tag and it didn't take long for the usual NoOps nonsense to follow (Charity Major's aptly named "Serverlessness, NoOps and the Tooth Fairy" session notwithstanding) .
you look at operations as the traditional combination of all activities
necessary for the delivery of a product or service to a customer,
"serverless" addresses the provisioning of hardware, operating system
and, to an extent, middleware.
Even when we ignore the
reality that many of the services used on the enterprise will still run
in systems that are nowhere close to cloud-readiness and
containerization, approaches like Docker will only take you so far.
you virtualize and containerize what does make sense, there are still
going to be applications running on top of the whole stack. They will
still need to be deployed, configured, and managed by dedicated
operations teams. I wrote my expanded thoughts on the topic a couple of months ago.
may argue that a well-written cloud-ready application shoud be able to
take remedial action proactively, but those are certainly not the kind
of applications showing up on conference stages. Switching from RESTful
methods deployed on PaaS to event listeners in AWS Lambda will not make
the resulting application self-healing.
Whereas I do appreciate the "cattle-not-pets" philosophy and the disposability in a 12-factor app
, I have actually worked as a site realiability engineer for a couple
of years and we still needed to monitor and correct situations where we
had cattle head dying too frequently, which often caused SLA-busting
disruptions to end users expecting 5 9's reliability or better.
Leaving the NoOps vs /DevOps bone aside, when I look at event-based programming models such as AWS Lamba and IBM OpenWhisk,
and put them in contrast with software development cycles, I start to
wonder whether development shops have fully understood the model's
overall readiness beyond prototyping.
What is the
reality of design, development tooling, unit-testing practices,
verification cycles, deployment, troubleshooting, and operations? As an
example, when I look at OpenWhisk, I see NodeJS, Swift and ... wait for it... Docker. There is your server in serverless, unless you are keen on retooling your entire shop around one of those two programming languages. Updated on 7/29: OpenWhisk has added support for Java since this post was originally written, but you definitely don't want to know how it is implemented behind the curtains.
the peril of offering anecdotes in lieu of an actual study, some of the
discussions on unit testing for event handlers can go from clunky to casually redirecting developers towards functional testing. And that should be the most basic material after debugging, which is also something conspicuously absent.
is progress and the lack of a complete solution should bever be a
reason to shy away from innovation, but at the same time we have to be
transparent about the challenges and benefits.
vision takes a sizable number of tinkerers building skunkworks on the
new platforms, that is all good, but we have to realize there is also an
equally sizable number of shops out there looking for the next silver
bullet. These shops will be quick to blame their failures on the hype rather than on their own lack of understanding of the total cost of development and operations of a cloud-based offering.
Click-baiting of dead development methods is well and alive for a reason, until you realize the big development costs depend more on the Big and Complex stuff than on how much time developers spend tending to pet servers under their desk.
the serverless drumbeat continues, it remains to be seen whether we
will witness an accompanying wave of serious discipline prescribing the
entire method before another one is put out as the next big thing.
The obvious next step would be codeless code, which is incidentally the name of one of my favorite blogs.
It contains hundreds of impossibly well-written and well-thought out
material about software development, including this very appropriate
cautionary tale on the perils of moving up the stack the concerns without understanding how the lower layers work.
Know thy wall, mind your trenches. geekish alert. A few years back, a colleague introduced the notion of DevOps to an internal large au...
I watched with interest this TED presentation by Dan Ariely, titled " What makes us feel good about our work " and immediately not...
I have been meaning to document a bit more my experience as former Bluemix SRE and Operations Engineering Lead during 2014 and 2015, which ...