What an engineer can take away from Velocity 2016

Velocity is a DevOps Conference that happens every year in several cities around the world which brings world's DevOps engineers together to talk about Web Performance and cutting edge Ops tech such as containers, configuration management, development automation and so on. 

For sure this year, More attentions were paid to micro services and docker. Here are some highlights that we can take from the conference. Check the flesh out if you are interested. 

1. Front end: 

On the fron end side, there are some amazing things from Google and Facebook. Actually, I believe they are out there for a long time, but maybe it's good to unleash their power now. 

As said, A site or app will lose a visitor if it can't respond in 3 seconds, An app that without time efficiency and better user experience is just a piece of shit no matter how excellent its server is. Google introducedService Workers for buildingProgressice Web App(PWA). Service workersallows you to support offline experiences, giving developers complete control over what exactly that experience is. You can simply take it as a front end proxy. Check out google references here. 

Facebook also spent much effort on speeding up their apps, In their speech given in the conference, they mentioned their design system for speeding up a site, likePagelets, but acutally, you can just checkout BigPipe.The general idea of BigPipe is to decompose web pages into small chunks called pagelets, and pipeline them through several execution stages inside web servers and browsers.

Another fun topic isServeless App using lambda,I don't like this one as the two above, I'd say this is more a play toy for developers and it may useful to build some internal tools to boost up development efficiency, may different to stand in the product environment. just my opinion. don't take it seriously. 

The two techniques share some ideas as the same, like redefining the way we design the site. I am pretty sure this will become the trends of future front end development.

Besides the two new things, Dustin Whittle talked much about more general ideas for front end development, event we have more and more new techs and tools for optimizing an app, but at least for now, almost evey app, we need to care about CSS, JS, so keep using tools likegulp, grunt, bower and yeoman to help you manage front ent burdens and minimize them. Checkout his slideshere.

After an app completed, you'd like to know how it performs, here is some useful tools to checkout:sitespeed.io,psi and webpagetest.com

2 Docker and micro services

In the production user level, Docker is still new, but it's emerging. Look at the digaram below to see how docker is catching up in the tech world.

There are many companies did so good in migrating current architecture to docker,Etsy is the one I want to note as they shared theire experience in the conference. New Relic is another app performance analysis platform which use docker to host all their services too(https://blog.newrelic.com/2015/06/18/zero-to-docker/). 

If you have some experiences with docker, you should know how difficult it is to locate a problem in docker, you can have log files in docker machine, but if the system grows, you may want something like splunk, ELK to do specific docker debug. Sysdig is the first tool I got to know in the conference that can help you to debug micro services efficiently. Although this is still not a highly recommended and widely used tool, stil good to know more efforts went there.Docker security is a known problem, this is another field that many companies and engineers will research.

3 Performance Analysis

This is an area I know nothing about, for a not Ops developer, we only use DataDog, New Relic, AppDynamics or AppNeta (just name a few) to monitor our apps. but is that enough?  

To have a deep insight into your app, you should definitely do RUM(real user monitoring) to give us the result. LinkedIn talked about theire tool Luminol to do Anomaly detection, this is more about data scicene, and it's an adaptive learning process. Good to know.

4 Other tips:

Build a resillient system is never easy. Every desinger should has their design philosoly. System should build for change, as system is always changing. 

Build a resillient system is not stack up any ideas just in your head, please measure it, test it and refactor if required. 

Build a resillient system is not rely on a genious developer, so communicate, communicate and communicate across teams. Learn from security team, learn from Ops team, learn from your user.