This talk isn't about grunt, bower or yeoman, it focuses more on the concepts and theory behind devOps and specifically how it can relate to the Front End.
There is this Catch 22 situation around a lot of these topics: where it’s very hard to actually learn them without being exposed to them (usually in large organisations) - and equally difficuly to get the role where you would be exposed to them, without the skills.
Importantly for me, the operational side of your application is still part of the product. If we want to build the best product we can, we need to be responsible for putting our own code into production and understand how it runs there.
Front end developers are probably the worst culprits of throwing code over the wall. The mentality of, “I pushed it, now it’s an Ops problem” is becoming a dated paradigm, one which has so many drawbacks.
As front end developers we should be levelling up and taking ownership of our code working correctly locally and in production, as well as understanding all the variables that sit between our code and the user.
Plus you don’t have to wait around for the ops guy any more… ;)
“The metric by which a front-end operations engineer would be judged is speed.” - Alex Sexton, Smashing Magazine
I'd never heard the term 'Front End Ops' before the Alex Sexton article. To me it was still DevOps but it was saying, "Step up, this is no longer just the work of back end devs." As it shouldn't be, we should always be looking to learn new skills which will help us become better developers.
By enabling the three quick processes and constantly finding ways to reduce the latency of the feeback loop, we are creating a better product.
And it’s not complicated to understand. There are two key principles which will work together to create a successful product lifecycle:
You should have an understanding of the full stack, but that doesn't mean you need to be an expert at all of it.
If you have this high level understanding it gives you the ability to pick out which parts are the bottlenecks, weak points for your particular application.
By protecting your application we talk about blocking ddos attacks, bots etc. It's important to cut this off before your application. A broken app is the slowest kind.
If we split traffic we can run server side AB tests, carry out rolling deploys, split our application into small parts etc.
Load balancer latency is a good metric to alert on because it cuts out some of the variability of the network layer.
Knowing what to measure is really hard, and very specific to your own product/application. What you measure will evolve as your app evolves.
Find creative ways of exposing them to your team.
* Highest paid person's opinion
Or ask away on twitter - @ianfeather