This is part of my live blogging from QCon 2015. See my QCon table of contents for other posts.
Excited to see Mary as the keynote. Good speaker and good role model.
Abstraction
The presentation started with Moore’s law going back to the very early calculators and covering the different generations of hardware. We are a trillion times faster since 1940’s. Massive minuiturization as well.
Happened both by becoming small and by abstracting out how classes of things. For eample, no motherboard in 1970’s.
Then she went into how code changed over her career. Fortran to HTML Baby steps as far as abstraction is concerned. Same generation. Changes not as vat in hardware.
Generation changes – reading/writing, printing press, personal computer, internet, culture of participation.
Currently a project where you can design your own sensor and plug into your phone.
Federation
Federation scale
- mini-computer evoloved to embedded – control you rown process
- pcs evolved to servers – retail software packages
- internet evolve to services – websites
- smartphone evolve to wearables – apps interact through the cloud
Federation leads to wide participating. Can share from own serice. More open source. Sharing helps industry grow. Reputation on sites like ebay allow anyone to share. Share practices on blogs. Education online.
If thinking about scale, think about how you can share.
Friction
Large systems don’t deal well with friction. Container ships helped with this. Standards size/shape.
Enterprises have databases. We create deep dependencies across apps because all hit same data. Which means high friction because hard to change. Amazon microservices have local data. Trying to decouple.
What is a microservice
- A microservice must be indpededently deployable to be useful.
- Small team-endto endreonsibility. You build it. You monitor it. You fix it
- No central db. Extensive automation and monitoring. Canary releasing. Smart versioning services. Double mock contract services
Companies with very high volumes like Amazon seem to require microservices. Requires strict discipline/operational excellence. Teamsnee situational awarenss. Must know all the time how service impacts customers and providers.
If you and provider change rapidly, how do you know mock returns same value. Create a pact so can check. See pact github project
Goals: limit risk and lower friction
How do you deal with a monolith if you have one?
Pack dependent code into containers. If put service and dependencies into a container, can put box around it and isolate it. Refactoring to make smaller/simpler. [I like how nicely she got from container ships to virtual containers]. This gives you portability, consistency, isolation, ease of use and better server utilitation. Most importantly, get lower friction and less risk.
Smashing it doesn’t work. Poking it does. Smashing is like a releae. Poking it is continuous delivery.
DevOps
If have branching, aren’t doing continuous delivery. Deploy mainline always with new features on switches so can turn on when ready.
Some people want to be safe (safety goals) and some want to be experimental (aspirational goals). With safety, failure/setbacks cause more efforts. With aspirational goals, prasise causes more effort. For safety,attention is for bad behaviorand asprirational, it is for good. Ops tends to be safety and dev tends to be aspirational. Marriage works well when have both, but must work towards same goal.
Who is responsible? Everyone. “Nobody succeeds unless everyone succeeds”
Getting to continuous delivery isn’t inherently harder than other tech issues. The main obstacle is organization.
In military, need to maintain situational awareness one level up and command awarenestwo levels up.
Great talk. A nice start to the day. I like that she sprinkled book and blog references throughout