A little while ago, I was in some corner of YouTube, maybe 15 videos deep when I stumbled across this video, How to do Intermittent Fasting: Complete Guide which I had actually been recommended to by a friend about 5 months prior. I had been meaning to watch it, but never got round to it, so I clicked away and so began my research and adventure into intermittent fasting.
The inception pipeline which Mechanical Rock’s very own Pete Yandell pioneered back in early 2018 was created as a way to manage a pipeline through code, which even has the ability to update itself through CloudFormation steps. What I love about it is not only the self managing aspect, but also that there is checked in history (so you can easily go back to a point in time), accountability, and repeatability. Because you’re not using the console to setup your infrastructure, reproducing it should disaster strike is minutes of deployment time for resources to provision.
Using this for a few projects over the past 18 months or so has highlighted its value as projects develop, more steps are added, additional permissions are required or locked down and once you have a few resources, it quickly becomes a very large YAML file with over 1,000 lines of text. Anyone who’s ever written large CloudFormation files will understand the pains of making sure resources are lined up and will be created and updated in the way you expect. Yes there are linting tools and other developer tools which can help make sure resources are referenced correctly etc, until you go to deploy. Enter: Cloud Development Kit.
‘Twas the night before Christmas, and all through the house, not a server was stirring, not even a mouse! This meant that my side project Secret Santa was not being used, yet is still highly available with no running costs! Why? Well, because on Christmas Eve, you might be too late to organise a secret santa and when an app is not in use when it comes to serverless, you don’t pay. Merry Christmas!
This story is a brief overview of how I converted and refactored a ruby on rails application to use a serverless architecture approach and solved the same problem, made it highly available and at a fraction of the running cost. It covers what I had to start with, the changes I made and the infrastructure I needed to complete the implementation. Towards the end I discuss what benefits there are and briefly talk to cost. Let’s get into it!
One of the important considerations when running an application is knowing when there are errors, whether or not the service is busy and understanding how your users are using the application to build the best user experiences and work on delivering more business-value. In order to do that though, you need to implement some monitoring, alerting and/or analytics tools to build up that picture.