Our company builds real-time interactive applications for television broadcasters. We have almost no servers ourselves – everything is a service. GitHub for code, a build service, a test service, Datadog for monitoring, a CDN, Redis as a service, DynamoDB. The reason is simple: our business is not running databases. Our business is broadcasting interactivity. So we let other people worry about infrastructure and focus on what we do best.
But that creates a different kind of risk. When GitHub goes down, we drink coffee because we cannot do anything about it. When our build service changes their VM image without telling us, all our builds fail. When Amazon’s load balancer scales too slowly for our TV show spikes, we have to email them in advance to pre-provision capacity. The show is only one hour long – by the time a support ticket gets answered, it is over.
This is where serverless and function-as-a-service became interesting for us. Instead of deploying a whole application, we deploy single functions. For a live TV show where viewers submit testimonials, one function takes the input text and generates an image. It scales per request, we pay per invocation, and there is no infrastructure to manage. The evolution from virtual machines to containers to functions is really about shrinking the unit of deployment until it matches the unit of business logic.
The shift from servers to services changes everything about how devops works. You cannot SSH into a service someone else runs. Your monitoring has to be different. Your collaboration extends beyond your own team to external providers through documentation, status pages, Slack channels, and conference hallway conversations. The practices of devops still apply – you still need feedback loops, measurement, and shared understanding – but the boundaries of who you collaborate with have expanded far beyond your own company.
Watch on YouTube – available on the jedi4ever channel
This summary was generated using AI based on the auto-generated transcript.