A Jenkins Pipeline for Mobile UI Testing with Appium and Docker

In theory, a completely Docker-ized version of an Appium mobile UI test stack sounds great. In practice, however, it’s not that simple. This article explains how to structure a mobile app pipeline using Jenkins, Docker, and Appium.

TL;DR: The Goal Is Fast Feedback on Code Changes

When we make changes, even small ones, to our codebase, we want to prove that they had no negative impact on the user experience. How do we do this? We test…but manual testing is takes time and is error prone, so we write automated unit and functional tests that run quickly and consistently. Duh.

As Uncle Bob Martin puts it, responsible developers not only write code that works, they provide proof that their code works. Automated tests FTW, right?

Not quite. There are a number of challenges with test automation that raise the bar on complexity to successfully getting tests to provide us this feedback. For example:

  • How much of the code and it’s branches actually get covered by our tests?
  • How often do tests fail for reasons that aren’t because the code isn’t working?
  • How accurate was our implementation of the test case and criteria as code?
  • Which tests do we absolutely need to run, and which can we skip?
  • How fast can and must these tests run to meet our development cadence?

Jenkins Pipeline to the Rescue…Not So Fast!

Once we identify what kind of feedback we need and match that to our development cadence, it’s time to start writing tests, yes? Well, that’s only part of the process. We still need a reliable way to build/test/package our apps. The more automated this can be, the faster we can get the feedback. A pipeline view of the process begins with code changes, includes building, testing, and packaging the app so we always have a ‘green’ version of our app.

Many teams chose a code-over-configuration approach. The app is code, the tests are code, server setup (via Puppet/Chef and Docker) is code, and not surprisingly, our delivery process is now code too. Everything is code, which lets us extend SCM virtues (versioning, auditing, safe merging, rollback, etc.) to our entire software lifecycle.

Below is an example of ‘process-as-code’ is Jenkins Pipeline script. When a build project is triggered, say when someone pushes code to the repo, Jenkins will execute this script, usually on a build agent. The code gets pulled, the project dependencies get refreshed, a debug version of the app and tests are build, then the unit and UI tests run.

Notice that last step? The ‘Instrumented Tests’ stage is where we run our UI tests, in this case our Espresso test suite using an Android emulator. The sharp spike in code complexity, notwithstanding my own capabilities, reflects reality. I’ve seen a lot of real-world build/test scripts which also reflect the amount of hacks and tweaks that begin to gather around the technologically significant boundary of real sessions and device hardware.

A great walkthrough on how to set up a Jenkinsfile to do some of the nasty business of managing emulator lifecycles can be found on Philosophical Hacker…you know, for light reading on the weekend.

Building a Homegrown UI Test Stack: Virtual Insanity

We have lots of great technologies at our disposal. In theory, we could use Docker, the Android SDK, Espresso, and Appium to build reusable, dynamic nodes that can build, test, and package our app dynamically.

Unfortunately, in practice, the user interface portion of our app requires hardware resources that simply can’t be executed in a timely manner in this stack. Interactive user sessions are a lot of overhead, even virtualized, and virtualization is never perfect.

Docker runs under either a hyperkit (lightweight virtualization layer on Mac) or within a VirtualBox host, but neither of these solutions support nested virtualization and neither can pass raw access to the host machine’s VTX instruction set through to containers.

What’s left for containers is a virtualized CPU that doesn’t support the basic specs that the Android emulator needs to use host GPU, requiring us to run ‘qemu’ and ARM images instead of native x86/64 AVD-based images. This makes timely spin-up and execution of Appium tests so slow that it renders the solution infeasible.

Alternative #1: Containerized Appium w/ Connection to ADB Device Host

Since we can’t feasibly keep emulation in the same container as the Jenkins build node, we need to split out the emulators to host-level hardware assisted virtualization. This approach also has the added benefit of reducing the dependencies and compound issues that can occur in a single container running the whole stack, making process issues easier to pinpoint if/when they arise.

So what we’ve done is decoupled our “test lab” components from our Jenkins build node into a hardware+software stack that can be “easily” replicated:

Unfortunately, we can no longer keep our Appium server in a Docker container (which would make the process reliable, consistent across the team, and minimize cowboy configuration issues). Even after you:

  • Run the appium container in priviledged mode
  • Mount volumes to pass build artifacts around
  • Establish an SSH tunnel from container to host to use host ADB devices
  • Establish a reverse SSH tunnel from host to container to connect to Appium
  • Manage and exchange keys for SSH and Appium credentials

…you still end up dealing with flaky container-to-host connectivity and bizarre Appium errors that don’t occur if you simply run Appium server on bare metal. Reliable infrastructure is a hard requirement, and the more complexity we add to the stack, the more (often) things go sideways. Sad but true.

Alternative #2: Cloud-based Lab as a Service

Another alternative is to simply use a cloud-based testing service. This typically involves adding credentials and API keys to your scripts, and paying for reserved devices up-front, which can get costly. What you get is hassle-free, somewhat constrained real devices that can be easily scaled as your development process evolves. Just keep in mind, aside from credentials, you want to carefully managed how much of your test code integrates custom commands and service calls that can’t easily be ported over to another provider later.

Alternative #3: Keep UI Testing on a Development Workstation

Finally, we could technically run all our tests on our development machine, or get someone else to run them, right? But this wouldn’t really translate to a CI environment and doesn’t take full advantage of the speed benefits of automation, neither of which help is parallelize coding and testing activities. Testing on local workstations is important before checking in new tests to prove that they work reliably, but doesn’t make sense time-wise for running full test suites in continuous delivery/deployment.

Alternative #4: A Micro-lab for Every Developer

Now that we have a repeatable model for running Appium tests, we can scale that out to our team. Since running emulators on commodity hardware and open source software is relatively cheap, we can afford a “micro-lab” for each developer making code changes on our mobile app. The “lab” now looks something like this:

As someone who has worked in the testing and “lab as a service” industries, there are definitely situations where some teams and organizations outgrow the “local lab” approach. Your IT/ops team might just not want to deal with per-developer hardware sprawl. You may not want to dedicate team members to be the maintainers of container/process configuration. And, while Appium is a fantastic technology, like any OSS project it often falls behind in supporting the latest devices and hardware-specific capabilities. Fingerprint support is a good example of this.

The Real Solution: Right { People, Process, Technology }

My opinion is that you should hire smart people (not one person) with a bit of grit and courage that “own” the process. When life (I mean Apple and Google) throw you curveballs, you need people who can quickly recover. If you’re paying for a service to help with some part of your process as a purely economic trade-off, do the math. If it works out, great! But this is also an example of “owning” your process.

Final thought: as more and more of your process becomes code, remember that code is a liability, not an asset. The less of if, the more lean your approach, generally the better.

More reading:

Automating the Quality of Your Digital Front Door

Mobile is the front door to your business for most / all of your users. But how often do you use your front door, a few times a day? How often do your users use your app? How often would you like them to? It’s really a high-traffic front door between people and you.

This is how you welcome people into what you’re doing. If it’s broken, people don’t feel welcome.

[7/27/2017: For my presentation at Mobile Tea Boston, my slides and code samples are below]

 

Slides with notes: http://bit.ly/2tgGiGr
Git example: https://github.com/paulsbruce/FingerprintDemo

The Dangers of Changing Your Digital Front Door

In his book “On Intelligence”, Hawkins describes how quickly our human brains pick up on minute changes with the analogy of someone replacing the handle on your front door with a knob while you’re out. When you get back, things will seem very weird. You feel disoriented, alienated. Not emotions we want to invoke in our users.

Now consider what it’s like for your users to have you changing things on their high-traffic door to you. Change is good, but only good changes. And when changes introduce problems, forget sympathy, forget forgiveness, people revolt.

What Could Possibly Go Wrong?

A lot. Even for teams that are great at what they do, delivering a mobile app is fraught with challenges that lead to:

  • Lack of strategy around branching, merging, and pushing to production
  • Lack of understanding about dependencies, impacts of changes
  • Lack of automated testing, integration woes, no performance/scalability baselines, security holes
  • Lack of communication between teams (Front-end, API, business)
  • Lack of planning at the business level (marketing blasts, promotions, advertising)

Users don’t care about our excuses. A survey by Perfecto found that more than 44% of defects in mobile apps are found by users. User frustrations aren’t just about what you designed, they are about how they behave in the real world too. Apps that are too slow will be treated as broken apps and uninstalled just the same.

What do we do about it?

We test, but testing is a practice unto itself. There are many test types and methodologies like TDD, ATDD, and BDD that drive us to test. Not everyone is cut out to be a great tester, especially when developers are driven to write only things that works, and not test for when it shouldn’t (i.e. lack of negative testing).

Allistar Scott – Test ‘Ice Cream Cone’

In many cases, automation gaps and issues make it easier for development teams to fall back to manual testing. This is what Allistar Scott (of Ruby Waitr) calls the anti-pattern ‘ice cream cone’, an inversion of the ideal test pyramid, and Mike Cohen has good thoughts on this paradigm too.

To avoid this downward spiral, we need to prioritize automation AND which tests we chose to automate. Testing along architecturally significant boundaries, as Kevin Henney puts it, is good; but in a world full of both software and hardware, we need to broaden that idea to ‘technologically significant boundaries‘. The camera, GPS, biometric, and other peripheral interfaces on your phone are a significant boundary…fault lines of the user experience.

Many development teams have learned the hard way that not including real devices in automated testing leaves these UX fault lines at risk of escaping defects. People in the real world use real devices on real networks under real usage conditions, and our testing strategy should reflect this reality too.

The whole point of all this testing is to maintain confidence in our release readiness. We want to be in an ‘always green’ state, and there’s no way to do this without automated, continuous testing.

Your Code Delivery Pipeline to the Rescue!

Confidence comes in two flavors: quality and agility. Specifically, does the code we write do what we intend, and can we iterate and measure quickly?

Each team comes with their own definition of done, their own acceptable levels of coverage, and their own level of confidence over the what it takes to ship, but answering both of these questions definitively requires adequate testing and a reliable pipeline for our code.

Therein lies the dynamic tension between agility (nimbleness) and the messy world of reality. What’s the point of pushing out something that doesn’t match the needs of reality? So we try to pull reality in little bits at a time, but reality can be slow. Executing UI tests takes time. So we need to code and test in parallel, automate as much as possible, and be aware of the impact of changes on release confidence.

The way we manage this tension is to push smaller batches more frequently through the pipeline, bring the pain forward, in other words continuous delivery and deployment. Far away from monolithically, we shrink the whole process to an individual contributor level. Always green at the developer level…merge only code that has been tested automatically, thoroughly.

Even in a Perfect World, Your Front Door Still Jams

So automation is crucial to this whole thing working. But what happens when we can’t automate something? This is often why the “ice cream cone” exists.

Let’s walk through it together. Google I/O or WWDC drops new hardware or platform capabilities on us. There’s a rush to integrate, but a delay in tooling and support gums up development all the way through production troubleshooting. We mock what we have to, but fall back to manual testing.

This not only takes our time, it robs us of velocity and any chance to reach that “always green” aspiration.

The worst part is that we don’t even have to introduce new functionality to fall prey to this problem. Appium was stuck behind lack of iOS 10 support for months, which means most companies had no automated way to validate on a platform that was out already.

And if anything, history teaches us that technology advances whether the last thing is well-enough baked or not. We are still dealing with camera (i.e. driver stack) flakiness! Fingerprint isn’t as unreliable, but still part of the UI/UX. And many of us now face an IoT landscape with very few standards that developers follow.

So when faced with architectural boundaries that have unpolished surfaces, what do we do? Mocks…good enough for early integration, but who will stand up and say testing against mocks is good enough to go to production?

IoT Testing Provides Clues to How We Can Proceed

In many cases, introducing IoT devices into the user experience means adding architecturally significant boundaries. Standards like BLE, MQTT, CoAP and HTTP provide flexibility to virtualize much of the interactions across these boundaries.

In the case of Continuous Glucose Monitoring (CGM) vendors, their hardware and mobile app dev cycles are on very different cycles. But to integrate often, they virtualize BLE signals to real devices in the cloud as part of their mobile app test scripts. They also adopt “IoT ninjas” as part of the experience team, hardware/firmware engineers that are in change of prototyping changes on the device side, to make sure that development and testing on the mobile app side is as enabled as possible.

Adding IoT to the mix will change your pyramid structure, adding pressure to rely on standards/interfaces as well as manual testing time for E2E scenarios.

[For more on IoT Testing, see my deck from Mobile/IoT Dev+Test 2017 here]

Automated Testing Requires Standard Interfaces

There are plenty of smart people looking to solve the busy-work problem with writing tests. Facebook Infer, Appdiff, Functionalize, and MABL are just a few of the new technologies that integrate machine learning and AI to reduce time-spend on testing busy-work.

But any and all programmatic approach, even AI, requires standard interfaces; in our case, universally accepted development AND testing frameworks and technologies.

Tool ecosystems don’t get built without foundational standards, like HTML/CSS/JS, Android, Java, and Swift. And when they want to innovate on hardware or platform, there will always be some gaps, usually in automation around the new stuff.

Example Automation Gap: Fingerprint Security

Unfortunately for those of us who see the advantages of integrating with innovative platform capabilities like biometric fingerprint authentication, automated testing support is scarce.

What this means is that we either don’t test certain critical workflows in our app, or we manually test them. What a bummer to velocity.

The solution is to have people who know how to implement multiple test frameworks and tools in a way that matches the velocity requirements of development.

For more information in this, see my deep-dive on how to use Appium in Android development to simulate fingerprint activities in automated tests. It’s entirely possible, but requires experience and a planning over how to integrate a mobile lab into your continuous integration pipeline.

 

Tailoring Fast Feedback to Resources (and vice versa)

As you incrementally introduce reality into every build, you’ll run into two problems: execution speed and device pool limits.

To solve the execution speed, most development teams parallelize their testing against multiple devices at once, and split up their testing strategy to different schedules. This is just an example of a schedule against various testing types.

For more on this, I published a series of whitepapers on how to do this.

TL;DR recap

Automating the quality of our web and mobile apps keeps us accurate, safe, and confident; but isn’t easy. Fortunately we have many tools and a lot of thought put in already to how to do this. Notwithstanding ignorance of some individuals, automation continues to change the job landscape over and over again. 

Testing always takes tailoring to the needs of the development process to provide fast feedback. The same is true in reverse: developers need to understand where support gaps exist in test frameworks and tooling, otherwise they risk running the “ship” aground.

This is why, and my mantra remains, it is imperative to velocity to have the right people in the planning room when designing new features and integrating capabilities across significant technological boundaries.

Similarly, in my research on developer efficiency, we see that there is a correlation between increased coverage over non-functional criteria on features and test coverage. Greater completeness in upfront planning saves time and effort, it’s just that simple.

Just like Conway’s “law”, the result of your team, it’s structure, communication patterns, functions and dysfunctions, all show up in the final product. Have the right people in the room when planning new features, retros, and determining your own definition of done. Otherwise you end up with more gaps than simply in automation.

Meta / cliff notes:

  • “Everyone owns quality” means that the whole team needs to be involved in testing strategy
    • To what degree are various levels of testing included in Definition of Done?
    • Which test sets (i.e. feedback loops) provide the most value?
    • How are various tests triggered, considering their execution speed?
    • Who’s responsible for creating which types of tests?
    • How are team members enabled to interpret and use test result data?
    • When defects do escape certain stages, how is RCA used to close the gap?
    • Who manages/fixes the test execution framework and infrastructure?
    • Does the benefits of the current approach to testing outweigh the cost?
  • Multiple testing framework / tool / platform is 200 OK
    • We already use separate frameworks for separate test types
      • jUnit/TestNG (Java) for unit (and some integration) testing
      • Chakram/Citrus/Postman/RestAssured for API testing
      • Selenium, Appium, Espresso, XCTest for UI testing
      • jMeter, Dredd, Gatling, Siege for performance testing
    • Tool sprawl can be a challenge, but proper coverage requires plurality
    • Don’t overtax one framework or tool to do a job it can’t, just find a better fit
  • Incremental doses of reality across architecturally significant boundaries
    • We need reality (real devices, browsers, environments) to spot fragility in our code and our architecture
    • Issues tend to clump around architecturally significant boundaries, like API calls, hardware interfaces, and integrations to monolithic components
    • We stub/mock/virtualize to speed development; signs of “significant” boundaries, but it only tells us what happens in isolation
    • A reliable code pipeline can do the automated testing for you, but you still need to tell it what and when to test; have a test execution strategy that considers:
      • testing types (unit, component, API, integration, functional, performance, installation, security, acceptance/E2E, …)
      • execution speed (<2m, <20m, <2h, etc) vs. demand for fast feedback
      • portions of code that are known-fragile
      • various critical-paths: login, checkout, administrative tasks, etc.
    • Annotations denote tests that relate across frameworks and tools
      • @Signup, @Login, @SearchForProduct, @V2Deploy
      • Tag project-based work (like bug fixes) like: JIRA-4522
  • Have the right people in the room when planning features
    • Future blockers like test framework support for new hardware capabilities will limit velocity, so have test engineers in the planning phases
    • Close the gap between what was designed vs. what is feasible to implement by having designers and developers prototype together
    • Including infrastructure/operations engineers in planning reduces later scalability issues; just like testers, this can be a blocker to release readiness
    • Someone, if not all the people above, should represent the user’s voice

More reading:

Don’t Panic! (or how to prepare for IoT with a mature testing strategy)

Thanks everyone for coming to my talk today! Slides and more links are below.

As all my presentations are, this is meant to extend a dialog to you, so please tweet to me any thoughts and questions you have to become part of the conversation. Looking forward to hearing from you!

More links are in my slides, and the presenter notes are the narrative in case you had to miss part of the presentation.

AnDevCon: Espresso Is Awesome, But Where Are It’s Edges?

For my presentation at AnDevCon SF 2016, I focused on how Espresso represents a fundamental change in how approach the process of shipping software that provably works on a mobile ecosystem that is constantly changing.

The feedback was overwhelmingly good, many people who stopped by the Perfecto booth before or after our talk came to me to discuss topics I raised. In other words, it did what I wanted, which was to provide value and strike up conversation about how to improve the Android UI testing process.

If you’re pressed for time, my slides can be found below or at:
bit.ly/espresso-edges-andevcon

Schrödinger’s Box and other complexities of scaling the software delivery lifecycle

Google Slides

Thank you to everyone at Defrag for attending my session. Great conversations afterwards, and looking forward to any more input you have in the future!

 


You Must Be This High to Ride the Continuous Bandwagon

There’s a lot of hype when it comes to continuous deployment (CD). The fact is that in large organizations, adopting CD takes changes to process, responsibilities, and culture (both technical and management). The right skills really help, but more often the determining factor to success is having the right attitude and vision across the whole team.

continuous-delivery-vs-continuous-deployment-b371cf5be55b1c52635058af7b70188cd2b608bfb92ca5487a3e41694e9ccf6b (1)
(image via Yassal Sundman)

At a carnival, you may have seen a sign that says “you must be this tall to ride”, an indication that the attraction is designed in such a way that it is dangerous to ride for those who don’t meet the specification. Similarly, continuous deployment sets the bar of requirement high, and some teams or products aren’t set up to immediately fit into this new methodology.

Mobile Continuous Delivery Requires Micro-climates

Mobile apps go through a validation process in an app store or marketplace before being generally available to customers, so product feedback loops take a hit in delay to market response to the app update. Mobile apps typically rely on back-end infrastructure which may require synchronous roll out of both front-end app and server-side components such as APIs and database schema. This is not trivial and for apps with thousands to millions of users.

Because of this delay, there’s huge emphasis on getting mobile app changes right before submitting them for review. Internal and beta testing platforms like TestFlight for iOS and HockeyApp for Android become vital to a successful app roll out and update strategy. For organizations that are used to 3 month release cycles and who control their whole stack, being prepared to release perfection every week requires a completely different mentality, often a completely different team too.

This is what I call product ‘micro-climates’, an ecosystem of people, processes, tools, and work that evolves independent of the larger organization. Mobile and API teams are perfect examples. A product needs to go at it’s own pace, accelerate and improve based on its own target audience. Only when organizations align product teams to business goals does this really take hold and become effective.

Prove Your Success, Aim for a Shared Vision

I’ve never seen a Fortune 500 organically evolve to CD without buy-in from a C-level or at least VP. A single group can implement it, but will ultimately run into cultural challenges outside their group (like IT and infrastructure) unless they have the support of someone who controls both groups.

If you’re trying to move in that direction but are hitting barriers outside your team, you’ve may have bitten off too much for now, and need buy-in from above (i.e. an executive sponsor). For that, you need:

  • Proof that what you’re doing is actually improving your velocity
    ‘DevOps’ is a buzzword, but metrics that show how doing kanban/scrum with both teams in the room every day actually matters. If you aren’t already capturing these metrics, I’d suggest you start. The point is to have quantifiable, objective measures that undeniably show success.
  • How your success maps to your executive sponsor’s goals
    An executive often balances potential opportunities with opportunity costs. If you’re changing process, what’s the risk to your actual project? How can this be replicated to other teams? What’s at risk if you don’t do this? Why are other competitors doing it this way too? What strategic objectives does this change enable (i.e. faster releases == competitive advantage)? Take a few moments to think about what your sponsor is measured on, and map your goals to theirs.
  • A clear plan and schedule, not just a bunch of activity
    Adding one or two process improvements is one thing, that’s actually our responsibility anyway, but to move to a model like continuous delivery/deployment you need a plan that includes objectives, strategy, and then tactics. For instance:

    • Objective: meet demand for new features, obtain competitive advantage in market
    • Strategy: streamline the delivery process to achieve 1-2 week release cycles
    • Tactics:
      • Continuous integration of code, multiple commits per developer per day
      • Minimum 80% automated test coverage
      • Test coverage over 5 key platforms and 3 geographic markets
      • Automated security reviews before each release (i.e. like this)
      • Tractability of code changes to production user impact metrics

If you’ve been bitten by the CD bug, it’s more than just an itch to scratch. It takes some concerted effort, particularly in large organizations, but don’t let that hinder you. Get your own team on board, find your velocity metrics, link your proposal to executive goals, get that sponsor, and commit to an implementation plan. Others have done it, and so can you.

Gluecon 2016: Melody Meckfessel on Serverless Technology

I had the opportunity to attend Melody Meckfessel’s presentation at Gluecon 2016 last week. As someone with years of experience at Google, when she speak, smart people listen.

[paraphrased from notes]

We should all be optimistic about open source and serverless technologies. Kubernetes, an example of how to evolve your service, a means to an end, housing processes internally, making management easier for developers to deploy and scale horizontally, to update gracefully without causing downtime. One of the themes in the future of cloud-based computing is that is increasingly open source which makes it easier for developers to influence and contribute the software stack as it’s evolving. Our focus is switching to managing applications and not machines.

“…the future of cloud-based computing…is increasingly open source which makes it easier for developers to influence and contribute the software stack as it’s evolving.”


(photo credit: @rockchick322004)

Serverless means caring about the code, embedded in all cloud platforms. In App Engine, you run code snippets and only get charged for your app or service as it scales up or down. With container engine, you run containers but don’t specify the machine it runs on. In the future, we’re not going to be thinking or talking about VMs. What does it mean for us developers? It will enable us to compose and create our software dynamically. As one of the most creative and competitive markets, software puts us in the same room and presents us with the same challenge: how to make things better, faster.

Melody tells a story about a project she was working on where they were using a new piece of hardware. They were having trouble scaling during peak load, holiday traffic being really important to their particular customer. They were constantly scrambling and for the first 6-9 months, she spent her time on primarily DevOps related work. This was frustrating because she wanted to work on features, seeing the potential of what she could do, and she could never quite get to that.

As developers, we are constantly raising the bar on the tools we use to release, and correspondingly our users’ expectations increase. Also as developers, we have the ability to create magic for users, predicting what they want, putting things in context, and launching the next great engaging thing. In a serverless future, developers will be focused on code, which means that PaaS (platform as a service) will have to evolve to integrate the components it’s not doing today. To do that, developers will need to shift Ops work from themselves more to cloud providers, being able to pick and choose different providers. Developers come to a platform with a specific language that they’re productive in, so this is a place where PaaS providers will have to support a variety of runtimes and interpreters. App Engine is the hint and glimmer of creating an entirely new developer experience.

“In a serverless future, developers will be focused on code…will need to shift Ops work from themselves more to cloud providers.”

What does a serverless future mean for the developer experience?

We will spend more of our time coding and have more and more choice. Right now, we’re in a world where we still have to deal with hardware, but as that changes, we’ll spend more of our time building value in our products and services and leave the infrastructure costs to providers and the business. If we want to do that, developers need to make it very easy to integrate with machine learning frameworks and provide analytics. Again, to do this, we need to free up our time: hence NoOps. If we’re spending all out time on ops, we’re not going to get to a world where we can customize and tailor our applications for users in the ways they want and expect. This is why NoOps is going to continue to go mainstream.

If we’re spending all out time on ops, we’re not going to get to a world where we can customize and tailor our applications for users in the ways they want and expect.

Think about if you’re a startup. If you’re writing code snippets, you may not need to think about storage. You don’t need to worry about security because the cloud providers will take care of that for you. Some wifi and laptops, and that’s your infrastructure. You’ll have machine-oriented frameworks to allow that app to be really amazing. This idea that you can go from prototype to production-ready to then scale it to the whole planet. Examples of really disruptive technology because they were enabled to do so by cloud resources.

To get there, we’re going to have to automate away the configuration and management and the overhead. We still have to do this automation. We have work to do there.

Multi-cloud in NoOps is a reality.

People are using mixed and multiple levels of on-prem IT and hybrid cloud; the problem is that the operational tools are siloed in this model though. This makes it very hard to operate these services. As developers, we should expect unifying management…and we should get it. Kubernetes is an example, just another way for teams to deploy faster. Interestingly, we’re seeing enterprises use Docker and Kubernetes on-prem; the effect of this is that it will make their apps and services cloud-ready. When they are faced with having to migrate to the cloud, it will be easy to do it.

“…we’re seeing enterprises use Docker and Kubernetes on-prem…it will make their apps and services cloud-ready”

Once you’re deployed like this though across multiple clouds and service providers, you’ll need to have an easy way to collect logs and perform analysis; StackDriver is an example of this. It’s this single-pane-of-glass view that enables developers to find and fix issues fast, to see what’s happening with workloads, and to monitor more effectively. Debugging and diagnosing isn’t going to go away, but with better services like Spinnaker and App Engine, we’ll be able to manage it more effectively.

Spinnaker providers continuous delivery functionality, tractability throughout our deployment process, it’s open source. As a collaboration with Netflix, Melody’s team worked hard on this. It was a case of being more open about the software stack we’re using and multiple companies coming together. We don’t all need to go build our own thing, especially when we share so many common problems.

Debugging and diagnosis

The problem is that there’s all this information across all these sources and it’s hard to make sense of it. It’s usually in a time-critical situation and we have to push out a quick fix as soon as we can. Part of streamlining that developer and debugging experience in the future cloud is having the tools at our disposal. These are things like being able to trace through a complex application for a performance issue, going back through the last 3 releases and see where the slow-down started, or production debuggers where you can inspect your service that’s running in the cloud and go to any point in the code to look through variable and see what’s happening. Error reporting as well needs to be easier, as errors can be spread across multiple logs, it’s hard to see the impact of the errors you’re seeing. Errors aren’t going away, so we need to be able to handle them effectively. We want to reduce the effort it takes to resolve these errors, we want to speed up the iteration cycles for finding and fixing the errors, and provide better system transparency.

“The faster we can bring the insight from these motions back in to our source code and hence optimize, those are all benefits that we are passing through to users, making us all happier.”

In the NoOps, serverless future, not everything will be open source, but we will expect that 3rd party providers should work well with all the cloud platforms. Meledy’s team is currently working on an open source version of their build system called Basil. Right after their work on Spinnaker in collaboration with Netflix, they’re looking for other opportunities to work with others on open source tools.

What does the world look like 5-10 years from now?

We’re not talking about VMs anymore. We’re benefiting from accelerated hardware development. We’re seeing integration of data into apps and compute so that we can have better insight into how to make applications better. It’s easier for machine learning to be embedded in apps so that developers can create that magical software that users expect. We don’t have to talk about DevOps anymore. We will have more time to innovate. In an open cloud, you have more opportunity to influence and contribute to how things evolve. Like thinking back on how there used to be pay phones and there aren’t anymore, the future of development is wide open, no one knows what it will look like. But contributions towards the future cloud are a big part of that future and everyone’s invited.

More resources:

CTO vs. CIO: How many tech “corners” do you really need?

Have you ever thought about what “departments” really means? The word “department” starts with another word: “depart”. Stop, think, continue reading.

Technical Chief Officer’s Dilemma: Departments and “Agency”

Are you in a situation where you honestly need people who purposely segregate themselves into groups that start with a departure from each other, rather than a congregation of ideas, people, and purpose?

If you are responsible for a technology “department”, you are responsible for a “failure”. #explain

Consider a geometric line, the most efficient way to connect one point to another. If only people were that easy. Get enough of them together and you start having to group them into manageable departments. IT, Development, Operations, Finance, Sales, Marketing, Management. Business lines to make things easy, right?

Departments are “Depart”-ments

Wrong. Department f*ck screw things up. Drawing lines isn’t a good thing unless if it’s to connect people with each other. They distract people from the simple truth that businesses who succeed are filled with people who instinctually understand that they are all on the same path, together.

Consider a geometric shape, the triangle. A line plus one point, an important point, an entire dimension. What good does it do to add another point beyond that? A square? Another department? Finance? HR? Marketing? Why?

I’m minimizing, I know wonderful, necessary in finance and human resource. Apologies to them, it’s just to make a point.

Only the Right Lines Need to Be Drawn

People who work with very large organizations know this inside out. Enterprises, government agencies, financial institutions. Corporations. The more lines there are, the more overhead and lack of progress there is. Sure, there’s stability, structure, fortitude; but the further we get away from connecting point A to point B in a straight line, the less efficient we are.

Truly effective business starts with figuring out how to define things with the least number of lines. Communication, organization, collaboration all benefit from simplifying how many lines are drawn. #karma

More reading:

DevOps, Burnout, and the Search for the Holy Grail

I’ll be speaking at APIdays Melbourne about the technological equivalent of the holy grail, continuous deployment, and why maybe we should re-think certain dynamics coming from the push to “do DevOps”, which like many good ideas is marred by poor implementations and shotty management.

2/2 Update: Things come up, shit happens, and I am incredibly bummed not to be able to be part of the crew at APIdays Melbourne this time around. However, priorities are priorities, and I’m not going to regret missing the 18 hour flight there and back.

Grateful for the opportunity, hope this doesn’t burn bridges, but sufficed to say I’ll be there in spirit. Thinking of shipping a TelePresence bot and asking @switzerly to set it up for me. 🙂

I’ll still be looking to find a more local forum for this talk, hopefully at APIstrat.

Of course, I’ll be showing how to inject comprehensive testing into a pipeline of API design, build, deployment, and monitoring tools, but I’m a people person more than anything else, so germane to my presentation will be the topic of how “doing DevOps” affects us at a personal level too.

Humans are tool builders, not the other way around.

Why are we talking about DevOps?

I love the ideas coming from that space. Any time people work closer, tighter, better together, I’m down. But revenue doesn’t care about you or me, and the impetus behind most practical implementations of continuous delivery are indeed revenue, over-trumped expectations from the business on IT as their main blocker rather than proper decision making.

Often the result of forcing unprepared teams to “do DevOps”: #burnout

In November at APIstrat Austin I stood up and said that teams are more important to get right than the software they produce, though they’re both very important. People produce software. If the people are buggy (i.e. bad team dynamics), you will see that in their product.

At the company kick-off last week, I sat in the front row as a panel of exec-level customers validated that the immense pressure to release software faster than ever before is real, is connected directly to revenue (loss not just gain), and is incredibly challenging due to people problems more than just technological ones.

Business leaders looking to implement new paradigms on technical teams will also find it surprisingly hard to “do DevOps” if there are cultural or personal issues laying around like land mines. From my last job, I know this first-hand.

I’m a Developer, but My Cape is at the Dry Cleaners

15 years professionally and counting. Right now, I see that code written in an IDE isn’t the only important factor to bringing excellent products to market. Code of conduct in teams, the responsibilities a business has to its employees, and how we treat each other along the way to building world-class software are just as important for a sustainable business model

Sorry startups who “do DevOps” because it’s cool, call me in 6 months if you still exist and want to talk for real. I would *love* that as a podcast interview episode.

For now, like an underwhelming version of Clark Kent, I temporarily hang up my [developer] superhero cape, put on thick-rimmed glasses, and work a job in the big metropolis during the day. I am educating myself and rounding out my ideas on what it really takes to be in cutting edge technology. I surround myself with very driven, passionate, fun, and smart people to get better…at everything I can.

I am expanding my understanding of how to bring about great technology beyond what an IDE can provide me. I work with people, code, and businesses.

More reading: