The Paved PaaS to Microservices – live blogging at qcon

The Paved PaaS to Microservices
Speaker: Yunong Xiao @yunongx
See the list of all blog posts from the conference

Yunong is from Netflix. Talked about how serving multiple types of devices. Can innovate faster if not worrying about infrastructure

Scale. 1K+ microservices. JavaScriptfront end; Java back end.

Client teams own microservices for front end/client devices. Edge API is server based/back end API

Standardized Components

  • Common set of components – ex: metrics, logging, alerts, dashboard, configuration
  • Don’t want everyone picking RPC mechanism. Invest in one set of tooling
  • Benefits of standardizing: consistency (ease of troubleshooting/support), leverage (more time for business problems with platform team focused on components), interoperability (easier integration so faster velocity and less cognitive overload), quality (more investment so higher chance of quality), support (greater knowledge base)
  • “But I’m a Snowflake” – Netflix has culture of freedcom and responsibility. Helps with innovation. If works, re-integrate into ecosystem. Be concious of talking to the others and the cost to other teams of your choice.

Pre-assembled platform

  • Starting a new project, there isn’t velocity yet nor stats on reliability.
  • Putting components into a pre-assembled platform so can just add business logic. Less likely to be missing things like metrics because in pre-assembled platform.
  • Guarantees standard and consistent metrics. Reducs MTTD (mean time to detect) and MTTR (mean time to recover)
  • Maintenance vs convenience – easier for platform team to include just basics. Easier for app team to have more included. The solution is layers and favors. Having a base platform and add ons.
  • Testing – running other team’s microservices tests when upgrading a platform tests the platform upgrade
  • Design for configuration and hooks
  • API Semantic versioning (like what Maven versions do)
  • Use conventional changelog to automatically creat changelog

Automation and Tooling

  • Provide CLI for common dev experience – allows scripting and consistent environment each time. Ensures can run locally and in the cloud
  • Local development fast – use local debugger and curl. Can still test with container so mirrors prod config
  • Provide first class mocks for components in pre-assembled platform. Facilitate determining where the problem lives. Easier to write reliable automated tests.
  • Provide facilitate to generate mock data
  • Need a testing API so different groups can work on mocks. Component teams create mocks against standard APIs
  • “Production is war” – different levels of experience in ops. Use tools to avoid shooting off own foot. Ex: pipelines for deployment/rollback, automated canary analysis
  • Dashboards provide a consolidated view for ops. Having platform generate dashboard and alerts standardizes them. Also allows for automate analytics and tooling.

Provided warning about not just copying Netflix. PaaS is for certain use cases. Components help regardless.

the top 5 secrets to improving team communication – live blogging from qcon

Top Five Secrets to Improving Team Communication so that you can Scale your Tech Team without Failing
Speaker: Debbie Madden @debbiemadden200
See the list of all blog posts from the conference

Works for Stride – an agile development consulting company – co-locate with team to improve code and team

“We back a good team and a team is the most important criteria for investment” – venture capitalists

Communication gets harder as number of people grows. Plus teams you need to interface with.

Books Referenced

  • The Advantage by Patrick Lencionoi – why organizational health trumps everything else in business
  • No Man’s Land – what to do when your cmpany is too big to be small but too small to be big – Doug Tatum

#1 Recognize chaos

    1. Recognize status quo
    2. Much easier to see someone else’s mess than your own
    3. All teams go through alternating periods of calm and chaos
    4. Greiner Curve – 6 periods of calm/chaos as company grows/time goes on.
      • Start with creativity
      • Leadership crisis – who is in charge
      • Then get direction
      • Autonomy crisis – who is empowered to do what
      • Then get Delegation
      • Control crisis – c-suite fighting
      • Then get Coordination
      • Red tape crisis
      • Then get Collaboration
      • Growth crisis
      • Then get alliances
    5. Chaos looks like hard things, unhappy people,procedures in the way and misaligned management
    6. Your engineers didn’t get dumber. You scaled to the next level of chaos
    7. Peers are most accurate gauge of understanding where team is – don’t hae to be peers on team

#2 Change it up

    • Chaos doesn’t happen overnight; creeps up on you.
    • “Implementing these changes won’t be easy; we’re pretty set in doing things the wrong way”
    • Change meeting rhythms: ex: people/roles/length/cadence/agenda
    • Kill/combine/keep retrospectives on meetings every 6 month
    • Verbally decline to attend meeting
    • Create a spreadsheet of all meetings you (or your team) attend. Which can you get rid of completely? Which meetings have same people and can be merged?
    • “It’s not that people hate meetings; it’s that they hate bad ones”
    • Fist of fives – all rate meeting on scape of 1-5 with finger voting. 1 is waste of time and five is best meeting ever. If didn’t vote five, have opportunity to say what would makeit a five. Can see opportunities for improvement and trends. Did something change?
    • Wipe the slate clean and identify what roles are needed. Figure out most ideal role for team members amongst current team members. People work best if passionate about role. See what gaps remain. Big companies struggle when keep people in wrong seat. [seems scary to have to worry about whether “right person for job” every 6 months. she framed it as setting people up for success, but it still seems scary]
    • People are more productive when have right values more so than having right skills. The people with great skills and bad values are the toxic ones because they have influence
    • As you grow your team, standards increase. This means people who used to be “A players” now aren’t and they don’t want to pair/mentor/etc because struggling.
    • Hard to recognize your own mess. A coach can help. Everyone has own view and can share.

#3 Communicate the why

  • Feel the meaning
  • Understand the why/how/what of what doing
  • Repeat the why – it takes time to “take”
  • Need employees to believe in the “why”

#4 Prioritize team productivity

  • vs individual productivity
  • Referenced the Google article from the previous session
  • On a good team, people speak in same proportion. Encourage people to speak at meeting. Suggest quieter people email thoughts the next day so have time to think
  • Disagree and commit – silence is disaggreement)

#5 Protect team health

  • Without a team that trusts each other, none of the above matters
  • Trust has capability (skills) and desire (want to be there) aspects
  • Healthy conflict – don’t want to avoid conflict entirely

This was a higher level presentation than I thought. I expected more about teams all less about company wide topics. [I double checked the abstract and confirmed it says team]. She ran out of time for #4 and #5 so they were rushed despite importance

She also went on a rant about telecommuters not collaborating. That’s not always true. Just because YOUR team doesn’t do Google Hangouts well doesn’t mean remote people don’t contribute. I don’t telecommute often, but my co-workers do. And they are effective. She also dismissed remote pair programming and telecommuting being about saving a 30 minute commute and being in your PJs.

what google learned about creating effective teams – live blogging from qcon

What Google learned about Creating Effective Teams
Speaker: Matt Sakaguchi
See the list of all blog posts from the conference

In software, we hire the best people, put them together and hope for the best. In sports, we focus on positions and teamwork.

Google was in NY Times for Quest to Make Effective teams

Matt talked about his path to Google. He was a police officer for 7 years until he got injured and physically couldn’t do it anymore. He then worked in retail. Then Matt upgraded the network to be faster and liked tech. THe CEO would “just randomly come and scream at people”. Had to leave toxic environment so went to Sony has manager of security guards 5am-2pm shift. Keep showing up; keep grinding; something will happen. Recognized as being underutiized and asked to look at operations to detect theft. Did that for a few stores. Still not making much money but doing something useful.

Recognized as being good at solving “weird problems” so Sony sent him to teams weird problems and fixing them. Had 27 people under him and an admin. Then moved to Walmart managing system admins and engineers. Got to learn basics of UNIX. First time managing engineers. Then BEA -> Oracle and Nexttag managing websites. At Postini, got to build a team. Postini got acquired by Google.

“snuck in the back door of Google, but still at Google”

Diagonsed with cancer. Greatful because helped realize what is important. Passionate about making work better. “We spend a lot of time at work we spend a lot of time in teams.”

Think about

  1. What kind of team are you on?
  2. What kind of teammate are you?
  3. What kind of learder are you?

On average

  1. 8.8 hours working
  2. 7.8 hours sleeping
  3. 1.2 hours caring for others

Diversity problems result in people not being able to be whole self at work (gender, race, orientation). Shouldn’t have to pause who you are for 8 hours.

With police, “if you aren’t scared, you aren’t human”. Good application to speaking and other “scary” things.

Everything is measured at Google. Even the placement of the tea/water/red bull/coffee. Example: moved M&Ms away from coffee machine, then hid it and then replaced with 100 calorie packs and measured reduction in calories.

Best teams

  1. Effectiveness – means results to executives, ownership/vision/goals to team leads and team culture for team members
  2. Tried to find algorithm for perfect team. Looked at dependendabiity of team, structure, extoversion, manageable worklowad, # of top performaers, tenure, co-location, impact of work, averge eel of team members ,consensus-drriven team, psychological safety, etc
  3. Most important five from most important to least importantL
    • psychological safety – knowing it is safe to make mistakes. Ok to take personal risks. Ok to bring up concerns. Know will be respectful open discussion
    • Dependency: can depend on teammates to do their part
    • Structure and clarity – enough to know what doing
    • Meaning – is work meaningful to you
    • Impact -is work important

Want a championship team, not an all star team.How a team works matters more than who’s on the team.

Components of psychological safety

  • Voice – am I heard. Are people just nodding or actually listening with respect
  • Trust – can I say anything without it being repeated?
  • Inclusion – not just inviting all people to the party, but making sure everyone has a good time

Set tone for psychological safety

  • Frame work as a series of learning problems; not execution problems – don’t just want to grind away DOn’t learn much in a performance environment because always on
  • Model curiosity and ask more questions. If team sees you ask “dumb” questions, everyone learns the answer and that ok to ask questions.
  • Admin your own failliblity. “Here’s my plan; tell me what’s wrong with it”

Tips

  • If team too negative, first question must be “how can we make this work”. Helps change mindset.
  • If you are the leader, try not to speak much if not running meeting. Putting your opinion out there too soon makes it harder for more introverted folks to state theirs
  • What are the top 3 things you enjoy doing outside of work. Make sure to spend time doing those things. Helps appreciate life. Do not cheat yourself

“The road to someday leads to a place called nowhere”

Fun talk to start the day! Matt is a great story teller. He had the Mac “machine name” screensaver in the background.When he showed the stats, I like how he just put them on the screen in silence rather than reading them. It really called attention to them.