TL;DR: when are we going to get all these Open Source cloud projects in a room together with developers from both sides of the stack so we can understand how to work together better?

Recently in Berlin I attended the Kubernetes Conference which is the latest coding framework to be released by Google. Kubernetes enables Application Developers to deploy their applications to their users in what is known as ‘continuous integration continuous development’ <– note the recursive iteration of the acronym: CICDCICD, etc.

The ironies of having a conference in Berlin where we are trying to knock down the walls between DevOps and AppDev?

The purpose of CICD frameworks like Kubernetes (aka #K8S) is to enable the next generation of cloud application development teams to have a toolbox of “CICD pipelines“. These pipelines are ways in which to deploy your application on the cloud to your users via various audience profile segments. In short, CICD is a social engagement methodology which will empower your product team to continually innovate without making too many of your users upset as you continuously upgrade your digital product.

Features need to come little and often, otherwise the communal psychology of your customer community becomes anger.

For example, you might want to role out a new feature button for your app, however you only want to roll it out to your power users (aka the top 10% of your customers who use your tool). This is known as a “canary deployment pipeline”. You can imagine the other kinds of CICD pipelines an application team might want to use:

regional deployment pipelines to test a specific language or geo specific feature, e.g. a new tax widget for your employees who use your HR system in Australia and New Zealand.

skill level pipeline roll-outs, i.e. you might want first time users to only have access to a minimum viable feature set of your app until they are ready to have additional features/buttons made available to them as they increase their skill. FYI there was a fascinating debate in the conference hallways discussing if using age data on your users was an ethical way to approach a CICD pipeline roll-out.

closed beta pipeline rollouts, such as a new mobile app to compliment a website, with automatic in situ failure rollback. Also know as blue/green CICD pipelines.

NB there are also a ton of pipelines all about testing your application prior to integrating with your customers.

Yes, this new toolbox of CICD pipelines is a methodology, and likely to be as popular as agile/scrum was this previous decade. However, it still has a glaring problem which needs to be discussed. This problem was nicely outlined in Berlin by Michelle Noorali from Deis (which is a startup product that integrates CICD pipelines using K8S, recently acquired by Microsoft Azure):

The problem which Michelle outlines via her “broom/vacuum/roomba” metaphor is that application developer teams are still using vacuums and are still trying to agree which kind of robot vacuum-cleaner they should jointly use?

Trying to convince all your devs to use the same technical tool…

Forrester’s report on “Container / Platform as a Service” products earlier this year, supported Michelle’s point highlighting that there are over 70 projects which are integrating CICD pipelines into their product toolbox. The majority of these products are still very beta, without evidence for which pipelines will work best for different application developers teams? Which of these C/PaaS are going to emerge as the right set of CICD pipelines suited for varying application development teams?

To name a few of the dominant C/PaaS who are enabling CICD-like features, including K8S capabilities: Cloud Foundry, RedHat’s OpenShift, Apache’s DC/OS, Cloudify, Microsoft Azure’s Deis, Google Cloud Engine/Borg (FYI Borg is the original code base which Google Open Sourced as K8S).

“Trust me you should all use this same pipeline for developing our digital product”

To compound the problem, you also need to engage developers further down the stack to get agreement with your application developer team (i.e. remember all these folk who get your application to work worldwide: SROs, DevOps, SysAdmin, NetEng, et al). These ‘lower down the stack’ cats are much less likely to embrace change rapidly.

“Please can I have a new way to access the compute (virtual machines, baremetal, containers) I need?” – “none shall pass”

What is the answer for finding out which pipelines are the right ones for your team to use?

My answer: Open Source CICD Pipeline Hackathons!

build all these Open Source CICD enabled C/PaaS onto the clouds.

invite/train application development teams how to use these pipelines for the competition.

bring these teams into the same room as the DevOps/SysAdmin/NetEng who administer the C/PaaS and can provide mentorship to the competing teams.

have a great weekend hacking and learning with one another in a fun yet informative competitive training environment.

Survey/interview the teams (behind closed doors) to provide feedback to the C/PaaS re the advantages/disadvantages in using the pipelines.

Promote the winning hackathon teams to the world and let them speak to the advantages of using CICD.

Rinse, wash and repeat!

We are now at the edge of computing where engineering science meets social science. CICD pipelines are where your customer team needs to agree the ‘digital playing field’ where your product will be improved together with your infrastructure engineers.

Described as ‘inception for thinking about the future computational application’. This lecture asks the big questions about how “the cloud” (aka ‘digital infrastructure’) applies to the research sector and the cloud applications of the future. Like any good research proposal, this talk asks more problematic questions, than it provides answers:

Part 0: What does ‘digital infrastructure’ mean to us as a shared community metaphor? Has K8S solved what Bezos called the ‘undifferentiated heavy lifting problem’, meaning we can move onto a new metaphor? Is the next community metaphor one of ‘intelligent applications’.

Part 1: What does an ‘intelligent application’ look like, and how do we reverse engineer intelligence. Let’s look towards science and what they are currently doing in terms of intelligence circuitry.

Part 2: Let’s try and build applications which will embrace the future cloud application paradigm of intelligence! What kind of capabilities do technologies like K8S give us in terms of enabling scientists to collaborate in building complex applications?

Part 3: Ok so this ‘cloud native’ thing is just getting started. Let’s not get too impressed with the technology and ask the hard questions about what is missing?! If we are going to build intelligent applications what other technologies are we going to need added into the stack so this stuff works in the real world?

Part 4: The future and beyond? As we build more intelligent applications, they will replace jobs. How quickly do we want innovation to progress if getting rid of jobs causes more strife (and potentially costs lives!)?

Please feel free to ask me questions while you are watching the video via Twitter or IRC(freenode): @DFFlanders.

As a community manager my day to day quest can be summed up by NiNiNi!

After fifteen years and helping build five major communities, the following quests are written above my desk (as adapted from the Berkana Institute):

Name: a day should not pass without naming the people in your community, be that a shout-out at the start of an event or a tweet/blog/slack message saying why others in the community should listen to this person.

Introduce: once you’ve started to identify (name) the key champions in your community, you need to introduce them to like-minded champions. These connections between key community members is the foundation stone to building a community.

Nourish: as time passes don’t forget to nourish your named and connected community champions. It is easy to become obsessed with recruiting new community members. Growth of you community is nowhere near as important as making sure your core members are engaged and the core connection hubs.

Instruct: no community can grow from its early days unless new community members are inducted and instructed into how the culture of the community works. Always be educating and creating opportunities for your champions to be recognised on stage to provide training.

Nirvana: of you are doing your job as community manager well (naming, introducing, nourishing and instructing) then you will start to hear common ideas emerging. Your ability to listen and bring that idea to the wider community so the community can sell Nirvana together as a community

Iterate: to do the above everyday, over and over again you must take care of yourself. Find time as you iterate (year on year) to make sure you are right with the world. The community are incredibly perceptive and if healthy are always talking about how you are helping lead.

Next community blog post will be on the stages of group development (storming, forming, norming, performing, adjourning) and how they apply to you as a community manager in the ebb and tide of your community.

“…the words of community are living and effective, sharper than any two-edged sword, penetrating even between soul and spirit, joints and marrow, and able to discern reflections and thoughts of the heart.” (Old Testament)

There are several words which a community wrangler must continually be vigilant in monitoring. I myself define these words as ’emotive adjectives’ (often parading as adverbs). In the grammatical sense, these words are usually applied to direct objects, usually technical components or methodology for how to build certain technologies. However they are not agnostic engineering terms intended to improve the mechanics of the system: they are words intended to remove and/or intimidate people out of the conversation. Often times, these words are semi-swear words, but the tagging of emotion onto the word or sentence is the meta alarm bell you should hear ring in your head.

All in all, these words are intended to be anti-inclusive. To push people out of the conversation so ones argument can win.

Below I’m attempting to collect such words to help act as a cue for being hyper aware of the situation unfolding in your community.

Boring, bored, etc – by far the most important #alarmBell word as it represents self-imposed anti-inclusive behaviour of the very person saying it. Wether they mean it or not, they are trying to convince themselves that they do not care and want to exclude themselves and others from the conversation.

Crap, shit, etc – swear words are emotive because they look to illicit a raised response for everyone in the conversation.

Stupid, idiotic, etc – speaks directly to the frustration one can feel when a technological solution is not fitting together as the puzzle once envisioned.

Hate, dislike, grumpy, etc – highly significant if this word is used without easy to understand explanation for why one feels those way. See ‘I’m OK, you’re not ok’ matrices behavior.

Tired, sick of, etc. – another word which requires serious consideration as it can speak to the emotional psychological health of the person saying it.

The reason why these natural language words are important to monitor is because of their ability to be anti-inclusive. As a community manager, anti-inclusive behaviour is the disease you are trying to fight. Inclusivity is the behavior you are trying to reward.

Please note, the listing of above words is not intended to remove these words from our vocabulary in some kind of Draconian ‘political correctness’. Rather I would suggest these words when used should be carefully considered as to their root cause. They are an opportunity to help change your community through the bottom up process of one to one relationship building (as time consuming as it is).

For me, I’m still trying to figure out the best way to understand the “response” for anti inclusive behavior, but kindness and bit of light-hearted comedy can go a long way to support the person who ends up feeling excluded because of the above words. Approaching the person using anti-inclusive word is not something I tend to do. Reward good behavior, ignore bad behavior is my usual default when not sure of the response.

What other anti-inclusive words do you see appearing on community mailing lists, slacks, irc, twitter, listservs, fb, etc? Please let me know via @DFFlanders especially if you have example of how you solved the problem.

Hello, this is David Flanders. This is my little audio report on PyCon 2016 in Portland, Oregon: which went from Saturday, May 28th to today, which is Wednesday, June 1st. Overall, the conference had about 3,000 people this year. It continues to maintain the idealism of an academic conference, and more importantly, an academic conference very focused on being able to onboard people who are just learning the programming language in a professional capacity (the new postgraduate degree for CS students?). All of the track I went to were very accessible, allowing people to understand how to use Python in different professional scenarios.

Overall, perhaps one of the most interesting things to see was the number of women speakers in this year’s program, up well near 50%, which is a great initiative as more women are empowered to lead the commtunity. Of course, the conference still is predominantly men and definitely white men in their twenty-somethings, plenty of inclusions still to achieve.

Perhaps one of the best talks that I saw was by Kate Heddleston and Joyce Jang, who are consultants and are talking about usability of DevOpps, which, of course, applies to the community I work with, the OpenStack community. As productivity (usability) consultants, Kate and Joyce, go into big companies and actually look at how rapidly expanding companies are onboarding new developers … Of course, in the startup space as companies experience rapid growth, the problem is that each developer a startup adds doesn’t necessarily result in more productivity. Kate and Joyce are often hired in to look at how developers are onboarded into companies as they’re quickly growing from 30 to 300 people, and what DevOpps procedures they can help optimise.

Both made solid points around why usability is about functionality, some really practical lessons to think about. Things like APIs and the tools which developer use to do tests; alongside, the common methods and techniques which a team commonly uses is really important. Increasingly the industry is moving away from a single brilliant developer and balancing genius across a team dynamic.

Another interesting theme was the rise and rise of bots! Of course, everyone in the community is using Slack now. Every session I walked into had a different slack going on half of the screens. Slack has really taken over the space, and of course, everybody’s writing these bots to participate in the community channels. Perhaps the coolest bot I saw was in a talk by Alex Gaynor, entitled “The Cobbler’s Children Have No Shoes or Building Better Tools for Ourselves”. He was talking about a very cool bot they’re using at Facebook, which analyses branches of code with previous branches to suggest likely evaluators. This bot pings people in their slack channels and lets them know that their is some code they might enjoy reviewing.

Another, perhaps more subtle theme of the conference, was around the psychology of developer communities. Interestingly enough, Guido van Rossum, the inventor of the Python language, gave a really interesting keynote about what makes him happy and how that looks from his PoV with someone who is on the autism spectrum. The enjoyment for him was in knowledge of this thriving community and that it wasn’t necessarily about isolation, even though he seemed to be very isolated over the years sometimes because of his intellect. Community enabled him to help other people which brought him happiness.

There were also several other developers who touched on the importance of psychology and being able to better participate in developer community via “positive play”. Almost all open communities will have a ‘code of conduct’. These documents might not be the best wording for what the community should be aiming to uphold? Maybe there needs to be more positive patterns. Some people talked about anti-patterns in community. On the whole -in these all male developer communities- there does tend to be an emotional trend towards a bit of anger sometimes, or perhaps some other negative emotions, especially when it comes to new people coming into the community. More than anything else there was a real drive for talking about how communities be better behaved and help bring people in who want to participate, learn and share.

Again, another thing which Guido actually touched on was that there are still no core reviewers for Python. Further efforts are being made to enable the best developers to take on mentor roles so more inclusion opportunities will result in a better diversity profile.

On a technical note, one of the cool little things that I did like other than the bots, even though the bots were related, was talking about new API’s and the way API’s can be used with apps. Google has put out something called “Progressive Apps”, which is all about being able to do a lot more caching on devices like mobile phones or smaller chipsets, so that you can actually build HTML apps for the web browser on your phone instead of having to build for iPhone and iOS and all the other iOS’s. That’s coming about because of HTTP/2 and the new API’s becoming available. Maybe we’re finally starting to see some trends which are pushing towards native apps for the phone that can work in the browser, instead of having to write for the operating system itself on each one of the phones.

There continues to be a lot of conversation around both Microservices as well as containerization of applications though perhaps not as dominant here inside of this application developer centric community. I was very aware, in talking with many dev, that there was less concern about containers or the way that people want to build apps for the cloud. One of the simple reasons is is because for them, application developers, if it isn’t broke don’t fix it. The idea of containers and Microservices is not yet a high priority. There’s a lot of other things that they’re concerned with in the stack layers above (usability, testing, customer engagement, etc.)

AppDev are not looking down in the stack towards the SysAdmin and DevOps layers. Application developers are looking up the stack. They’re looking at usability or the next thing that’s coming in browser app features. It was an eye opening experience realising that they are not necessarily concerned about containers and Microservices the way that we think they should from a DevOpps PoV.

Plenty of conversation around deep learning and, of course, machine learning. On the small scale as well, and how this can actually help the DevOps and application developers to be able to just have a little bit more logic in the way that we are doing things. Humans are bad and remembering so why not let the machines help you?

API’s seem to still be difficult for application developers in some senses. There were a couple of nice talks on the way you can build API’s for your application from the ground up, but again API’s are perhaps a second thought for a lot of application developers when they’re trying to build an application. Nonetheless, there are some great new frameworks in the form of Flask and OpenAPI, which OpenStack is starting to use. Those are good signs that people are starting to care about the abstraction of their applications so that they can connect better and work across Microservices or even across cloud apps.

Finally, was the closing keynote by K. Lars Lohn who is a biker and a hippie that works for Mozilla Science. He gave a very sprawling conversation around what I would call “a book report for Godel, Escher, Bach, aka GEB” which is all about coming to peace with complexity. I must admit it is really interesting to come back to a PyCon conference, which I’ve missed the past three years. The old is new and new is old, as per usual 😉

For the PyCon foundation there’s a recognition that to grow the community there needs to be more support. Now saying that, of course, PyCon wasn’t looking to expand. They actually said that 3,000 developers at the conference was about right for them. What they were really pushing for was a story more about the community spreading around the world and having different events in different locations run by the community so that it could spread locally. Especially in terms of cost, local is more effective for a broader community.

In summary I continue to ponder the relationship between community and how it can unpick (or move around) complexity so others can join the conversation and help bring in their PoV to untangle the complexity? Our tendency, especially as developers, is to talk about the complex as we love the feeling of our synapses sparking up to discuss new more complex ideas. Yet, maybe it’s not always the best thing to do when it comes to trying to grow the number of users and the people we actually want to benefit from all of this technology.

Any who, that’s me, David Flanders, signing off. Hope this was helpful. Please do ping me on Twitter @DFFlanders. Please make sure to check PyCon via their YouTube channel where most of the above is available.

The below sound bite picks up the conversation just after we discussed the brief history of developer tools for creating apps, such as virtual machines / operating systems (Vagrant, CoreOS/CentOS) and configuration/orchestration languages (Puppet, Ansibel, Chef, Juju, Heat). Do “containers” represent the 3rd generation of “app tools” which will enable application developers to ‘write once and be read by many clouds‘ aka seamless app #portability?

Naturally, this podcast revealed more questions than answer, of which the following will help guide my next set of developer chats (stay tuned to @DFFlanders):

Who gets the most value out of having *portable* apps which can be built on any cloud? Is it the user, the app-developer, the cloud provider, etc.? Who losses out by not being able to lock in apps to their cloud platform?

How will the end user see the value of “cloud apps” as opposed to “mobile apps” or “desktop apps”? How will the end user understand “the cloud” => as “cloud apps” or “software as a service”?

What does the future “cloud application developer” look like: is it a SysAdmin turned WebDev or will developers be expected to have #SysAdmin #DevOpps #WebDev and #UX skills as part of their “Full Stack” skill-set?

What is a “cloud app” and what will the killer cloud app look like? Or is this just a play on language, and NOT something to spend too much time thinking about?

which community will win this next “app layer” in the cloud computing stack?!

If nothing else the proliferation of developer tool sets for building apps on the cloud is going to be interesting to watch as the community battles it out. Or, is it a battle at all? Perhaps this is just the natural “conversational” movement by the community up the stack as it has been will all the computing layers below? Are we shifting our language to be nearer the end user?

“Finally, I understand what you mean by the cloud!”

My two pence: “programming languages” *are* languages (prog lang are just a bit more structured than the ‘romance languages’ the average user is used to, e.g. English, Spanish, etc[1]). While indeed, most of this “cloud app” gossip is hype, it is developers starting to use their ‘romance languages’ to prototype the next set of ‘programming language libraries’ which will bring cloud to the end user -via understandable metaphors[2]- as the dominant form of computing. Accordingly, watching this conversation evolve *is* watching the next paradigm in computing take shape.

Let’s not stop the conversation there, ping me on the Twitters and tell me how you think the world will come to understand ‘cloud’ 😉 @DFFlanders

[1]= Naturally, I would include Indo-Chinese languages as well, but I’ve used “romance languages” for the audience I am currently writing this post for; I’d welcome a cultural discussion on the use of the term “cloud app” for other non western world cultures as well.

[2]= “Cloud apps” might not be the ‘analogy’ by which the average human comes to understand the cloud, however we can’t expect the end user to understand what we mean by terms like “software as a service” or “big data applications” or “high performance computing” <– not even the average University researcher knows what this is!!!